DIY GPSDO project w/ STM32, TDC7200

[thinkfat]

A couple of new findings:

I graphed START, STOP and TRIGG signals with my scope. The START and STOP traces showed that indeed the signals were locked against each other with no apparent jitter (at least not that I could see it on the scope). I conclude that this is therefore a viable setup for a performance test.

Then I used the TRIGG signal as an indicator of when the start command from the MCU is executed by the TDC. I tried creating a trigger criterion for the assumption that TRIGG to START < 5ns causes an invalid measurement. This wasn't entirely conclusive. Indeed I found that when TRIGG to START is < 5ns I get a bogus measurement, but the frequency of bogus measurements is much higher than the events observed by the scope. This could mean that the window is much larger than those 5ns from the datasheet. Playing around with the trigger window hints that the critical window might be more in the tens or even hundreds of nanoseconds range.

I decided then to discard all the measurements with implausible TIME1. Using only the samples of the 1µs cluster as total population, the standard deviation calculates to around 38.5ps. 
You can confirm the calculation based on the previously posted data set in Excel. Filter the TOF column to show only values < 2µs, then use the SUBTOTAL() function to calculate stdev.

So far, so good, however the next headscratcher is right around the corner. When I set the 1PPS input to an actual 1 second pulse signal, I get 4 clusters, spaced exactly 500ns. Confirmed with the scope, the signals are not properly locked. The phase shifts exactly 90 degrees every second. Might be some peculiarity of the instrument itself. I'll investigate that. I wanted to update the software of the Siglent anyway.

[iMo]

I decided then to discard all the measurements with implausible TIME1. Using only the samples of the 1µs cluster as total population, the standard deviation calculates to around 38.5ps. 
You can confirm the calculation based on the previously posted data set in Excel. Filter the TOF column to show only values < 2µs, then use the SUBTOTAL() function to calculate stdev.

And here is the histogram from the above data with the ~55ps quantization visible.

[iMo]

You may also improve the measurement such you
1. set the NEO's 1PPM output to 128Hz (48MHz/375000=128)
2. set TDC7200 to 128 averaging cycles
3. you should get an interrupt in 1sec period with new data
4. TOF= normLSB * (TIME1 - TIME2) + (CLOCK_COUNT1 / 128) x 100ns

[iMo]

The INTB output of the 7200 is open drain, you need a pullup resistor there (or set the MCU's input with pullup).

[thinkfat]

The INTB output of the 7200 is open drain, you need a pullup resistor there (or set the MCU's input with pullup).

Yup, I missed that. Forgot to put a pull resistor, but it seems the MCU's internal pull-up is sufficient.

[iMo]

So far, so good, however the next headscratcher is right around the corner. When I set the 1PPS input to an actual 1 second pulse signal, I get 4 clusters, spaced exactly 500ns. Confirmed with the scope, the signals are not properly locked. The phase shifts exactly 90 degrees every second. Might be some peculiarity of the instrument itself. I'll investigate that. I wanted to update the software of the Siglent anyway.

Try with higher frequency at the 1PPS, like 10k/1k/100Hz.

[thinkfat]

You may also improve the measurement such you
1. set the NEO's 1PPM output to 128Hz (48MHz/375000=128)
2. set TDC7200 to 128 averaging cycles
3. you should get an interrupt in 1sec period with new data
4. TOF= normLSB * (TIME1 - TIME2) + (CLOCK_COUNT1 / 128) x 100ns

Excellent suggestion! I just modified my software to use the cycle averaging feature and set the Siglent to provide a 128Hz pulse. This works nicely, the phase shift is gone, measurement results are stable.

[iMo]

I still think the "3us issue" is coming outside the 7200 (hw or sw wise). I could imagine myself the 5ns between setting TRIGG and incoming start rising edge could be critical. But more than 5ns is not a realistic number, imho. The 3us issue comes from a problem with the input rising edges sequence, or some wrong setting of the 7200 registers. For example with some weird setting of CLOCK COUNTER STOP MASK value you will be ignoring the first 1-2 stop edges.

[thinkfat]

Ignoring some Stop edges will not make a difference for TIME1, though.

[iMo]

In past I messed with an FPGA shooting start/stop edges at around 100ns apart, 7200 in mode 1, readings 10-100x per second. 7200 soldered on an DIL adapter board, put into the solderless breadboard, wired to BluePill. The sequence was under BP control - BP initiated the process in the FPGA - thus the 100ns TOF was single-shot. The library as-is from the github. Never saw that kind of problem. I did not use INTB btw, I simply read the registers after some small delay. Also TRIGG output was not used.

[iMo]

You may also improve the measurement such you
1. set the NEO's 1PPM output to 128Hz (48MHz/375000=128)
2. set TDC7200 to 128 averaging cycles
3. you should get an interrupt in 1sec period with new data
4. TOF= normLSB * (TIME1 - TIME2) + (CLOCK_COUNT1 / 128) x 100ns

Excellent suggestion! I just modified my software to use the cycle averaging feature and set the Siglent to provide a 128Hz pulse. This works nicely, the phase shift is gone, measurement results are stable.

I've been just thinking what would be a better solution
a) 128x averaging in the 7200, or,
b) single measurements with the TOF results, done say 128x per second, and then the 128 TOFs averaged..

[thinkfat]

The datasheet suggests to use multi-cycle averaging to battle system clock jitter...

Anyway, here's a dataset of roughly 3300 samples. 128 averaged cycles, COUNT1 register already shifted, 10 calibration cycles, 128PPS input.

[thinkfat]

I'm also taking a couple of samples with the software averaging now, it seems already after a couple measurements that the std dev is lower (30ps vs. 43ps).

But I'm very much doubting that the formula from the datasheet for multi-cycle averaging is numerically sound for integer. The term "(CLOCK_COUNT1 >> log2(AVG_CYCLES)) * CLOCKperiod" looses a full 7 bits of precision. I'll rewrite it to "(CLOCK_COUNT1 * CLOCKperiod) >> log2(AVG_CYCLES)", that should be a lot better.

[thinkfat]

Results attached, approx. 1200 measurements for each strategy.

pps128_mc_avg128.txt is 128 cycle averaging done by the TDC7200, formula corrected. Std dev 37.86ps. measurements are heavily quantized.
pps128_soft_avg128.txt is 128 individual measurements averaged in software. Std dev 30.89ps The plot shows a slight drift even, so result might be better with all drift removed.

[iMo]

Both look interesting.. No idea which one is better, however

PS: added the original math

The visible drift in the soft aver is around 20ps 

[FriedLogic]

You may also improve the measurement such you
1. set the NEO's 1PPM output to 128Hz (48MHz/375000=128)
2. set TDC7200 to 128 averaging cycles
3. you should get an interrupt in 1sec period with new data
4. TOF= normLSB * (TIME1 - TIME2) + (CLOCK_COUNT1 / 128) x 100ns

Excellent suggestion! I just modified my software to use the cycle averaging feature and set the Siglent to provide a 128Hz pulse. This works nicely, the phase shift is gone, measurement results are stable.

I've been just thinking what would be a better solution
a) 128x averaging in the 7200, or,
b) single measurements with the TOF results, done say 128x per second, and then the 128 TOFs averaged..

Averaging might not work well with an actual GPS since there will normally be phase jumps on a 128Hz (or any other frequency) output from the ublox. The 48MHz clock is not exact, so the GPS will add or remove a clock cycle every so often to keep it close to correct.

The 48MHz on the M8N that I have is about 0.25PPM off, so that effectively means about twelve 20.8ns phase jumps a second.

Somewhere on the Leapsecond.com site there was a comparison of GPSDO performance with different measurement resolutions. In that case there was surprisingly little difference between measuring the GPS to different resolutions, although it may make a bit more difference with a newer GPS.

It should be possible to do a lot of separate measurements and identify jumps, but I doubt that it would be worth doing.
The 1PPS with quantization error message is probably as good as the GPS itself can work out the timing, and single measurements with a TDC7200 should normally be more than good enough to measure it.

[thinkfat]

Temperature drift is anyway going to mess big time with picosecond scale measurements. I may have underestimated that effect. Currently I only have the built-in temperature sensor of the STM32. I'm trying to make use of it to at least counter the large room temperature swings caused by the house heating. But it introduces quite a bit of noise by itself.

[Leo Bodnar]

Even after quantisation correction there is about 1ns wobble left.  On top of that there is residual phase wander as navigation solution tries to steer timepulse reference to selected time grid.  And then there are known unknowns like what the hell Galileo is doing?
It would be smart to budget in bound 1-2ns rms TP error even after all the corrections are done.
Leo

The 1PPS with quantization error message is probably as good as the GPS itself can work out the timing, and single measurements with a TDC7200 should normally be more than good enough to measure it.

[thinkfat]

Some experimenting with temperature compensation, see the attached data set. I'm using the internal temperature sensor of the STM32.

Format:
Col.1: uncorrected TOF, 128PPS, TDC multi-cycle averaging with 128 samples.
Col.2: picoseconds added to TOF for temperature correction
Col.3: temperature compensated TOF.
Col.4: temperature measured by the STM32 internal sensor, scaled according to the datasheet to °C. Not sure about the absolute value, you can pretty much disregard this column.

[iMo]

How did you compensate (the math)?

[thinkfat]

Simplest possible linear equation. Raw ADC value times magic value added to the TOF.

[iMo]

It went from 323ps/C to 15ps/C.

[thinkfat]

Maybe a bit worse, I need to check the temperature conversion formula, I might have to scale the ADC value differently.

EDIT: I checked, the scaling is correct. So just the absolute temperature is unknown since I cannot check the actual die temperature, obviously

[thinkfat]

Started implementing ublox binary protocol parsing 
Looking at the LadyHeather protocol decoder makes my eyes bleed..

[texaspyro]

Looking at the LadyHeather protocol decoder makes my eyes bleed..

It's actually pretty simple once you get used to it.   It might take a couple of weeks of Ebola sized orifice leakage to get there.  Any Ublox decoder will do the same basic sequence of events.

Step 1:  capture a Ubox message (from start code to end code) into a buffer
Step  2:  get the message type code from the buffer and call the routine to decode that message
Step 3:  use tsip_byte, _word, _dword, _single, _double to get values from the message