Hi Erik,

very interesting project. I've been using software-defined radios for
5~6 years now to evaluate our various frequency references (mostly
GNSSDOs) [1]. However, the resulting measurement setups are quite
expensive (>20k€ for 8 synchronous channels with USRPs X310), bulky
(2HE, 500 mm depth), heavy (>10 kg), and power hungry (>100 W). I've
been sporadically pondering how to design a cheap and compact, yet
highly accurate alternative for about a year now. My current, unverified
idea for a quad channel time interval counter is to combine 4 TDC7200
with an STM32's 32-bit timer capture (also has 4 channels). The TDC
should enable ~50 ps resolution.

How do you plan to implement the edge detection (blocks "A/B edge
detect")? What resolution are you designing/hoping for? What's the
purpose of the CPLD, i.e., what does it do that the MCU can't?

Best regards,
Carsten

[1] https://arxiv.org/abs/1803.01438

On 16.07.22 16:31, Erik Kaashoek via time-nuts wrote:

On 7/16/22 12:44 PM, Carsten Andrich via time-nuts wrote:

could you gang up multiple TICCs somehow?

Hi Carsten,

On 16-7-2022 21:44, Carsten Andrich via time-nuts wrote:

I had a look at the TDC7200 and it could fit in the design but the time
resolution is unbalanced with the TCXO performance. Yes, for DMTD it
could be nice but 5ns resolution should be good enough

Two fast comparators (
https://datasheet.lcsc.com/lcsc/2206101816_Gainsil-GS8743-TR_C840038.pdf
) and DAC's to set the trigger level

5 ns or, if overclocking, 4 ns

It replaces all the small logic IC's.  An example is the capture logic
and the edge selection that must be before the capture logic, and it is
used as an IO extender to drive the switches in the signal path
(high-Z/50 ohm, pre-scaler, etc...)

A complete prototype using discrete logic instead of the CPLD is working
up to 100 Mhz and the pre-scaler is proven up to 4 GHz. The SW is fully
functional, including interpolation for  both frequency and phase,
although still a bit rough. There is still a certain amount of phase
pulling due to the non optimal layout.
Erik.

On 17.07.22 04:57, Lux, Jim via time-nuts wrote:

John Ackermann has actually done that and dubbed it the Multi-TICC [1].
It's not for sale and the necessary effort to assemble it is
substantial. I'm tempted to instead spend design effort to get similar
functionality with 4~8 channels onto a single PCB with one MCU. I think
it's feasible, but I haven't had the time to prototype it.

Best regards,
Carsten

[1]
https://tapr.wpengine.com/tapr-file-area/time-freq/multi-TICC_App_Note_2020-01.pdf

Hi Erik,

On 17.07.22 07:28, Erik Kaashoek via time-nuts wrote:

Particularly for measuring short intervals, which is relevant for GNSSDO
comparison, the TCXO should have negligible effect. Assuming a 2 ppm
frequency error, a time interval of 25 us corresponds to an error equal
to the TDC's 50 ps resolution.

Do you expect any propagation delay mismatch between the comparators to
affect the results?

Some STM32 support timer capture with up to 200~250ish MHz (e.g.,
STM32F745 @ 216 MHz [1] and STM32H742 @ 240 MHz [2]), which would
natively enable your desired resolution. I've verified using timer
capture for this purpose works with an STM32G474 at 174 MHz and a ZED-F9T.

Best regards,
Carsten

[1] https://www.st.com/resource/en/datasheet/stm32f745ie.pdf#page=33
[2] https://www.st.com/resource/en/datasheet/stm32h742bg.pdf#page=42

On 7/17/22 10:56, Carsten Andrich via time-nuts wrote:

My local ham group has actually built two multi-TICCs on request as a
fund-raiser, and we could probably be talked into doing more.  Given
four TICCs, Front Panel Express sheet metal, an RPi, various cables and
connectors, etc., and a little bit for the volunteers, it's not cheap by
ham/hobbyist standards, but a bloody bargain by professional ones. :-)

If anyone is seriously interested in having one built, contact me off
line and we'll see what we can do.

John

Hi Erik,

On 7/16/22 16:31, Erik Kaashoek via time-nuts wrote:

This is useful. If you also can make it accept 5 MHz it will be even
better. Depending on where you are, 5 or 10 MHz is the base frequency.

Each additional input after 2 will give additional capability to measure
things.

While not directly visible in the architecture, there is two things I'd
like to high-light:

First is the input side, it needs to have as low noise as possible, but
also amplification around the trigger point to increase slew-rate with
as little bandwidth as needed. This is the traditional wisdom at least,
for best single-shot resolution performance. Then you have people like
me that points out more subtle points, but those becomes valid only after:

The maximum sample rate of the TIC is important. For good result, you
want to decimate the samples before or integrated with phase, frequency
and linear drift estimation. The gain of that depends heavily on the
hardwares ability to do high rate of samples, since this can then
increase the amount of samples that goes into each estimation.

With such decimation in place on high enough sample rate, some noise can
actually be beneficial. This will reduce the single-shot resolution for
the benefit of decimated resolution. This technique was in commercial
use in the 70thies, but before it could be fully analyzed.

Cheers,
Magnus

Hi Magnus

On 18-7-2022 14:58, Magnus Danielson via time-nuts wrote:

Can do.

More than 2 full blown inputs (e.g. with fast coparators and
subsampling) may not be possible.

The used input comparators can do 100MHz and have a hysteresis of 5mV
around the set trigger level. Would that work?

The advantage of having all the counters inside the MCU is the ability
to reach high sample rate with little effort. Currently 5e4 sample/s is
possible, further optimization may still be possible. The 5e4 samples
are used in frequency and phase estimation.
With 5ns TIC resolution and the subsampling the frequency difference
between two clocks, one at 1MHz and one at 1.00000001MHz, can be
measured with maximum 3e-10 variation, including the pulling that
happens when the two clocks have (almost) equal phase.
The phase measurement of the same two clocks has about 100ps variation.
The HW is still a dead bug style mess so improvement should be possible.

Where do you put the noise? The subsample moments? I tried and that did
not help. Maybe bad implementation.
The trigger level? But that would not help with square wave input
The reference clock? How would you do that?
Its possible to switch the internal reference clock (derived from TCXO
or external reference) to another frequency to avoid a simple integer
relation with the measured clocks. For test I implemented
213.33333333333MHz, 200MHz and 2045MHz as reference clock frequencies
and for measurements of multiple of 1MHz the 213.333333333MHz clock
delivers the best results.

Erik.

Hi

Quick one on noise injection and decimation:

Some structures for measuring time have a very abrupt boundary between two readings.
You put in >2 to  <48 ps and you always get a LSB of 0 out. You put in >52 to <98 ps and
you get a LSB of 1. Move to the previous / next bins and something similar happens.

If your very stable signal is slowly creeping along over a 40 ps range this is not a great thing.
The device gives very little useful data for further processing. Yes, you do need a signal that
has << 40 ps of jitter in order to even see this happening ( in the example case ….). In a world
full of ground loops and funky coax this may not be as easy as you might think.

The implication above is that this happens in the middle of the bin. That may not be the case.
The switch point in adjacent bins may be very different. At some point this can get pretty
strange. Significantly un-equal bin sizes are tough to deal with.

This sort of thing is hardly unique to TDC’s. There are a number of processes that do this
sort of thing.

Bob