DIY GPSDO project w/ STM32, TDC7200

[thinkfat]

I'm now using both channels of the waveform generator to generate the 10MHz input and the 1PPS pulse. The results are extremely boring: the measurements are super-stable now, like with the previous self-test. +1ps or -1ps from the median are the maximum deviation I get, and they're rare. I'll log a couple thousand measurements to get some data, but it's all pretty promising.

The nice thing about using a waveform generator is that I can tweak the phase of the 10MHz signal and look at the effect on the measurements.

Next test will be hooking up the GPS module I built to take a look at the 1PPS. I'm driving the waveform generator with the GPSDO as external clock so there should be a good correlation and no frequency drift.

[iMo]

The results are extremely boring: the measurements are super-stable now, like with the previous self-test. +1ps or -1ps from the median are the maximum deviation I get, and they're rare. I'll log a couple thousand measurements to get some data, but it's all pretty promising.

Hmm, to get something like +/-1ps is impossible, imho.
The TDC7200 itself is 35ps rms, that is perhaps 180 230ps p-p.
Perhaps your result is in ns?? Then you may get boring +/-1ns..
With a quality generator you cannot get something better than this histogram, as an example:

[thinkfat]

Hmm, to get something like +/-1ps is impossible, imho.
The TDC7200 itself is 35ps rms, that is perhaps 180ps p-p.

OK. Then I need to double-check the math. I'll record the register readings like you suggested and post them here as a CSV.

Attached find the first 1181 measurements, I get a mean of 10µs 100ns and a standard deviation of 0.28ps. That's indeed to good to be true.

[Leo Bodnar]

Should you not see quantisation like here?
55ps resolution and 35ps rms accuracy has always confused me - shouldn't all raw data bins be 55ps wide?
Leo

[iMo]

Attached find the first 1181 measurements, I get a mean of 10µs 100ns and a standard deviation of 0.28ps. That's indeed to good to be true.

Sure, doublecheck your math. You have to get 100ns +/-115ps ideally (in mode 1 !!), afaik.

In mode 2 working with 100ns pulse is not recommended - you will most probably get weird results.

PS: as recommended above, I would advice you to provide some measurements with well defined pulse length (ideally 1us in mode 2). Print out in .csv format all the TDC7200 registers/data and do analyze them. Fix your math and get your 7200 under full control

PPS: btw, the chip allows 1..128 averaging cycles (AVG_CYCLES) (see ch. 8.4.4 Multi-Cycle Averaging)

[iMo]

Should you not see quantisation like here?
55ps resolution and 35ps rms accuracy has always confused me - shouldn't all raw data bins be 55ps wide?
Leo

55ps resolution with 35ps sigma, 28ps accuracy - sure confusing, the granularity should be visible while zooming into the histogram, imho..

[thinkfat]

Alright, I found something: In the calculation of normLSB, the Arduino library assumed that CALIB2-CALIB1 can never become negative. But there's nothing in the datasheet that would support this.
Find attached some Excel sheet with my calculations based on register values.

[thinkfat]

What I'm not getting is the huge fluctuation in readings from the CALIBRATON1 and CALIBRATION2 registers. That doesn't look good to me.

EDIT: the waveform generator was setup incorrectly - I was feeding 10kHz instead of 10MHz. That is waaay out. It's not even spec'd. Minimum clock input is 1MHz according to the datasheet. Not a miracle the readings of the calibration values were strange.

[iMo]

There is an issue somewhere. It looks like you readings are weird. Doublecheck your SPI routines. And plz describe what you are measuring and how.

PS: read my above post - you cannot measure 100ns long pulse in MODE2 !!!

PPS: the normLSB cannot be smaller than 50ps, imho.

[thinkfat]

There is an issue somewhere. It looks like you readings are weird. Doublecheck your SPI routines. And plz describe what you are measuring and how.

PS: read my above post - you cannot measure 100ns long pulse in MODE2 !!!

PPS: the normLSB cannot be smaller than 50ps, imho.

See above. I was feeding 10kHz instead of 10MHz to the clock input. That would not work anyway. The TDC7200 can not operate under these conditions.

[thinkfat]

Some measurements after correcting the wavegen settings, see Excel sheet attached.

Conditions:
- clock input 10MHz from channel 1 of the wavegen.
- 1PPS input is fed with a 500kHz 50% duty cycle square wave from the second channel of the wavegen.
- the two channels are phase-locked. The phase is adjusted so that the period between start and stop should measure 1µs.

Findings:
- I'm back to two clusters, spaced 2µs apart.
- Using the wavegen instead of the GPSDO didn't actually make a difference. I thought the problem gone when I was feeding a 10kHz clock instead of 10MHz. 
- 2µs is the period of the 500kHz clock used as the START/STOP signal.

Update:
This thread on the TI E2E community might be the same issue. Unfortunately it wasn't resolved.
https://e2e.ti.com/support/sensors/f/1023/p/828776/3117130?tisearch=e2e-sitesearch&keymatch=TDC7200%2520TOF%2520multiple%2520clusters#3117130

[iMo]

The numbers look much better now.

When you subtract 2us from those 3us long pulses you get 1.005us with 498ps stddev.
That jitter may come from your signal generator.
The rms jitter contributed by your signal generator is sqrt(10)*sig_gen_jitter_rms, thus ~100ps rms jitter off your Siglent will mess up the expected result accordingly..
Therefore I advised not to use an external signal source for that specific measurement.

3us issue - you feed the inputs by the "proper" edges, but mind there are inverters in the signal path. Doublecheck the polarity and sequence of the start-stop edges directly at the 7200 inputs.
In standard operation the inverters do not matter, as the 10MHz and 1PPS edges are random phased before the lock.

PS: during the "3us issue" the TIME1 shows 2.090748usecs = 37070*56.4ps.
The COUNT1 is always 10 CLOCKs.
It could mean - after the start edge the TIME1 sometimes runs ~2us long "waiting" for the first edge of the 100ns CLOCK.
Normally the first edge of the 100ns CLOCK comes in 1641*56.4ps.
Hmm.

PPS: ENABLE input - do not toggle the EN during measurements (it is a reset). Upon power up it should be LOW, then wait say 100ms and set it HIGH.

[texaspyro]

You might want to look at the source code for the TAPR TICC and see what that is doing...

[thinkfat]

The TAPR TICC driver for the TDC7200 is a bit weird, with its magic numbers and correction terms. But it's doing nothing special, apart from that.

I posted my question on the TI E2E forum, let's see if I get an answer there.

I wonder if there's a minimum time to maintain between starting the measurement and seeing the start signal?

EDIT: T_TRIGSTART, the time from the TDC enabling the TRIGG output (in response to a measurement start) to receiving the START signal is given as 5ns nominal. There is no minimum value, so this seems to be just a recommendation. But what if the time is much shorter than that?

[mino-fm]

Time from TRIGG to START is typ. 5 ns. Take a look at DS page 6 "Recommended Operating Conditions".

Edit: avoid shorter times. Internal logic is not as fast as its ring counter, so behavior is not predictable.

[thinkfat]

Time from TRIGG to START is typ. 5 ns. Take a look at DS page 6 "Recommended Operating Conditions".

Edit: avoid shorter times. Internal logic is not as fast as its ring counter, so behavior is not predictable.

Aye, that's good info. It might be the reason for the effect I have. I think it'd be prudent to configure an overflow value for the coarse counter and discard those measurements.

[iMo]

You do not use TRIGG output, that 5ns prop delay is not relevant in your system, imho.
You set the start bit via SPI and the 7200 waits on the starting edge which comes almost "randomly" (but in 2us period). After receiving stop signal the 7200 should ignore the start edge.

The largest TIME1 value in your case is 100ns/56.4ps = 1773. The "good result" is always 1641. That is interesting too. I would expect random values from 0..1773 for TIME1.
EDIT: ok, you get always 1641 because your Siglent's 10MHZ/500kHz outputs are phase "locked" internally, as you wrote.

Do you use INTB interrupt? Do you have the 1uF ceramic at Vreg there?

EDIT: Hmm, I still do not understand how you can get start-rising-edge stop-rising-edge 1us apart when feeding the 1PPS input with 500kHz signal. Does the Siglent allow to set 10MHz and 500kHz phases such the 10MHz/20 and 500kHz rising edges are always 1us apart? Could you doublecheck with oscope or LA directly at 7200 start/stop inputs if that happens always?

[thinkfat]

You do not use TRIGG output, that 5ns prop delay is not relevant in your system, imho.
You set the start bit via SPI and the 7200 waits on the starting edge which comes almost "randomly" (but in 2us period). After receiving stop signal the 7200 should ignore the start edge.

The largest TIME1 value in your case is 100ns/56.4ps = 1773. The "good result" is always 1641. That is interesting too. I would expect random values from 0..1773 for TIME1.
EDIT: ok, you get always 1641 because your Siglent's 10MHZ/500kHz outputs are phase "locked" internally, as you wrote.

Do you use INTB interrupt? Do you have the 1uF ceramic at Vreg there?

EDIT: Hmm, I still do not understand how you can get start-rising-edge stop-rising-edge 1us apart when feeding the 1PPS input with 500kHz signal. Does the Siglent allow to set 10MHz and 500kHz phases such the 10MHz/20 and 500kHz rising edges are always 1us apart? Could you doublecheck with oscope or LA directly at 7200 start/stop inputs if that happens always?

As I interpret it, T_TRIGGSTART is the recommended time between starting a measurement and the START signal arriving. TRIGG is output by the TDC as a response to the start command from the MCU and the TDC is ready for a measurement within 5ns. This can be interpreted as a guard time. Since the 500kHz signal on START is not correlated to the measurement start from the MCU, it may well fall within this window. In normal 1PPS operation, it's not really relevant as there is always plenty of time between the start command and the 1PPS pulse. In hindsight, I could have routed the START signal to a GPIO. I'll put that on the TODO list for the Rev2 board.

Yes, I'm using the INTB interrupt and I also read the INT_STATUS register to check if a measurement is done when I receive it. I  have a 1µF MLCC on VREG. Voltage on VREG is around 1.5V which seems reasonable.

Checking START/STOP directly on the TDC inputs is on my TODO list. But the soldering is a bit fiddly, I need to find a quiet hour to do it. The Siglent allows me to set arbitrary phase relation between the outputs. I can shift them against each other at will.

[iMo]

So set the phase shift to 1.050useconds (1us+100ns/2).. What happens then?

[thinkfat]

The phase shift is affecting only the time between start and stop. Not the time between the measurement start command that arms the TDC and the START signal that starts the actual TOF measurement.

[iMo]

So try to add a random delay (0..100us for example) into your MCU code how it affects the result.

Since the 500kHz signal on START is not correlated to the measurement start from the MCU, it may well fall within this window.

You run the MCU with its internal RC oscillator (from schematics) so the event would be rare. Your 3us issue is almost in half of the measurements.

[FriedLogic]

Hi,

An Arduino that uses crystal for the microcontroller can be quite good for generating pulses to test basic TDCs. With basic stuff like port writes, NOPs and loops, delays can be set to 1 clock cycle as long as the interrupts are off during the delay. I got the delay into the milliseconds that way, although it takes care since the compiler tries to optimize out that sort of thing. The compiler can change behaviour between versions too, so it may optimize differently.

IIRC, the results were mostly under 0.5ns P-P for a basic acam TDC-GP21 board.

I'm sure that there are more elegant ways to do it, but it's very simple for the sort of short delays that are usually needed with a GPSDO. Making a tester with a PIC like the dividers that Tom has on Leapsecond.com has been on my to-do list for a long time...

[mino-fm]

Checking START/STOP directly on the TDC inputs is on my TODO list. But the soldering is a bit fiddly, I need to find a quiet hour to do it.

For start signal I use a single D-FF to synchronize between trigger enable and input signal. D-input is set by IO-pin after TDC-trigger is enabled. Here's my short code for STM32F4xx:

void trigger_TDC(void)
{
volatile int n = 5;   
  TDC_write_cmd(0x4140);    // Abgleich auf 10-fach einstellen; default setting
  TDC_write_cmd(0x4081);    // Trigger inkl. autom. Abgleich ausgeben; enable START, set TRIGG
  while(n--);                         // interne Trigger-Verarbeitung vom TDC abwarten; waiting a short time
  GPIO_SetBits(GPIOC, TRIG1_BIT);           // Trigger-Ausgang auf '1'; set IO-Pin => D-input of D-FF
}

As you see an extra delay is inserted (and needed) before setting IO-pin. Omit this and you get weird numbers from time to time.

[iMo]

FYI - a voodoo note form TICC source (not sure it is still valid):

  // NOTE NOTE NOTE
  // The TDC chip is *supposed* to set INTB after seeing the
  // first stop edge.  That doesn't work -- the interrupt never happens.
  // Workaround is to set for two stops, and rely on the COUNTER_OVERFLOW
  // timer below.  It's ugly, and it slows down the maximum measurement
  //rate, but it works.

[mino-fm]

I can't confirm this. I'm using mode 1 with 1 x stop.