Electronics > Projects, Designs, and Technical Stuff
GPSDO/GNSSDO: STM32G4 + u-blox ZED-F9T + TDC7200
Carsten:
Hello everyone,
I'm in need of a GNSSDO for accurate time synchronization of moving vehicles distributed over a few (dozen) square km. I've been professionally using the James Miller (G3RUH) Ministd, Jackson Labs LC_XO, and SRS FS740, but none of these deliver satisfactory results when used on the move. That's certainly not a flaw of these devices, because presumably they were not designed with a non-stationary use case in mind. Therefore, I decided to build a suitable GNSSDO myself. This is not a low-cost project. Development priorities are performance, simplicity, and value for money in that order.
I have positive experience with the u-blox ZED-F9P RTK GNSS receivers. As the F9P can achieve <5cm position accuracy with RTK correction data, its timing receiver sibling (ZED-F9T) should enable sub-nanosecond timing accuracy. The F9T supports differential timing via the same correction data used for RTK positioning. I'm not aware of any other GNSS timing receivers supporting this feature. The F9T also exhibits excellent Allan deviation (~5e-11 @ 10s). Therefore, the F9T is the center piece of my design, relying on the RCB-F9T board for prototyping.
Design aspects/goals:
* ZED-F9T timing GNSS receiver with RTK correction data
* 10 MHz OCXO as local reference oscillator (special OCXOs with low g-sensitivity for non-stationary use exist)
* TDC7200 for ~50 ps measurement of GNSS timepulse vs. OCXO
* STM32 32-bit timer capture (~6ns resolution) to resolve aliasing/ambiguity of TDC measurement
* <10ns relative accuracy within 10 km radius while on the move (preferably <1ns)
* stabilized pulse output derived from OCXO (not directly from GNSS receiver)
* configurable pulse properties (not only 1PPS) with fine-tunable delay (~200ps resolution via STM32G4x4 high resolution timers)
* integrated distribution amplifier for 10 MHz and 1PPS outputs (capable of driving 50 Ohm loads)
* part and manufacturing costs preferably <500€ per device (excl. OCXO)
My architecture is inspired (among others) by thinkfat's DIY GPSDO project w/ STM32, TDC7200. However, I hope to improve on these aspects:
* Minimize digital processing of OCXO output. Feed 10 MHz directly to TDC7200 without division via 74HC390 to minimize temperature dependence.
* Only use low-jitter clock ICs (e.g., LMK1C110x for fanout). No 74-type components, which AFAIK do not have jitter or phase noise specs.
* Active 1 Hz low-pass filter after tuning DAC to a) minimize noise (from supply, voltage reference, and DAC) fed to OCXO control voltage input and to b) enable finer than 16-bit tuning resolution via PWM. Assuming a 2 ppm tuning range, 16 bit yields 30 ppt frequency tuning resolution. At 10 seconds, that's already 300 ps, which is higher than the TDC7200's ~50 ps resolution. Hence, a finer tuning resolution may come in handy, of course depending on the actual stability of OCXO and GNSS.
My next step is to build a prototype PCB to put my ideas to the test. I've devised the preliminary architecture and put it into a schematic. The layout is in progress.
I've attached the schematic and would appreciate constructive feedback, prior to having it produced.
vk3jpk:
Hi Carsten,
I had a quick look at your circuit and notice that you are attempting to directly measure the time between the GNSS PPS and the next 10MHz OCXO rising clock edge using the TDC7200. Unfortunately this will not work as the TDC7200 has a minimum measurement interval of 12ns (according to the data sheet). In practise the time difference between the GNSS PPS and the next 10MHz clock edge will be in the range of 0ns through 100ns so you could be in trouble up to 12% of the time.
This is explained in some detail in the TAPR TICC Operation Manual (see https://web.tapr.org/~n8ur/TICC_Manual.pdf) along with the solution TAPR used to work around this issue in their situation which was also constrained by a relatively slow Arduino.
So you need to find a way to derive the time difference indirectly.
One method that I have personally used is to feed the GNSS PPS into a chain of D flip flops clocked by the 10MHz clock to create a synchroniser and use the TDC7200 to measure the difference between the GNSS PPS and the output of the synchroniser and then use this synchronised output with your microcontroller counter (assuming your microcontroller counter is also synchronous to the same 10MHz clock used by the TDC7200).
If you look at the equations for how the TDC7200 result is calculated you can eliminate the temperature variance in the synchroniser flip flop propagation delay by calculating directly from the TDC7200 measurements the time from the GNSS PPS rising edge to the 10MHz rising edge AFTER the rising edge at the output of the synchroniser. By happy coincidence this is the same rising edge your microcontroller counter will use (assuming it counts the output of the synchroniser and has a clock synchronous to the 10MHz clock used by the TDC7200).
James
Carsten:
Hi James, thank you for taking the time to look at the schematic.
--- Quote from: vk3jpk on August 06, 2022, 12:12:24 am ---I had a quick look at your circuit and notice that you are attempting to directly measure the time between the GNSS PPS and the next 10MHz OCXO rising clock edge using the TDC7200. Unfortunately this will not work as the TDC7200 has a minimum measurement interval of 12ns (according to the data sheet). In practise the time difference between the GNSS PPS and the next 10MHz clock edge will be in the range of 0ns through 100ns so you could be in trouble up to 12% of the time.
--- End quote ---
My idea to circumvent the TDC7200's dead time is to exploit the 10 MHz signal's periodicity. When it doesn't measure 0 to 12 ns, it should measure 100 to 112 ns. I haven't read anything in the datasheet that indicates the TDC7200 would be negatively affected from a stop pulse within its dead time (other than not measuring that stop pulse, of course). The way I understand the data sheet, early stop pulses are simply ignored:
--- Quote ---7. After reaching the Clock Counter STOP Mask value, the STOP pin waits to receive a single or multiple STOP
trigger signal from the analog-front-end (for example, detected echo signal of the ultrasonic burst signal)
--- End quote ---
Thinkfat also didn't have any issues with feeding continous 10 MHz stop pulses to the TDC. Even if the first stop pulse falls into the dead time and/or the first measurement is flawed, using the TDC's feature to measure multiple consecutive stop pulses could be used to filter out nonsensical measurement values.
--- Quote from: vk3jpk on August 06, 2022, 12:12:24 am ---One method that I have personally used is to feed the GNSS PPS into a chain of D flip flops clocked by the 10MHz clock to create a synchroniser and use the TDC7200 to measure the difference between the GNSS PPS and the output of the synchroniser and then use this synchronised output with your microcontroller counter (assuming your microcontroller counter is also synchronous to the same 10MHz clock used by the TDC7200).
--- End quote ---
Thanks for the suggestion. Using the TDC's CLOCK_CNTR_STOP_MASK to wait one 10 MHz clock period after the start pulse before processing stop pulses should have the same effect without relying on external circuitry. That's my plan B if above plan A fails.
iMo:
Also mind the 7200's resolution is 55ps with "35ps std dev" (rms)..
PS: Figure 15 of the DS shows the std dev vs. int clock dependency..
Carsten:
My design use the 10 MHz OCXO for clocking the TDC7200. A faster clock will only bring marginal std dev improvement (~5 ps as per Fig. 15).
Fig. 17 is also quite interesting. In timing mode 1, which I plan to use, the standard deviation deteriorates to ~100 ps at a 500 ns interval. Originally, I wanted to measure and average 5 stop pulses, but without appropriate weighting that could actually be detrimental compared to just using the first measurement.
Navigation
[0] Message Index
[#] Next page
Go to full version