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.

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.

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:

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)

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.

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).

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.

[iMo]

Read the entire thread with thinkfat's elaboration of his design - he did elaborate with many aspects of the 7200 application.. Also TI's forum contains some hints and measurements (see below - I downloaded them from TI's forum in past when I messed with the 7200 in my reciprocal counter exercise).

[Carsten]

Thanks. I quickly went through the TDC7200-related part of thinkfat's thread (and found I'm missing a pullup on the TDC's INTB). The temperature dependency issues were my motivation to minimize any processing of the 10 MHz and 1PPS signals to the bare minimum before feeding them to the TDC. That minimum is the LMK1C1103, which is transparent in terms of (temperature-dependent) propagation delay, as it equally applies to the output ports.

For now I really want to finalize the design and layout. I'll consult that thread again when I start implementing the TDC7200 measurement.

[Carsten]

I've updated the schematic. Added an IMU (TDK InvenSense IIM-42652 on a separate breakout board) and pushed the active low-pass filter cutoff frequency to 10 Hz. Also preliminarily finished the layout. BOM is still open, so maybe a few capacitor/resistor footprints will change (to minimize assembly costs by picking parts without setup cost), but apart from that I consider the prototype design finalized. Will let it sit for a few days to review everything with some distance.

The board outline (including SMA connector base) is 100x100 mm, so it'll fit into a typical aluminum PCB enclosure, should the need arise. For unhoused use, I've place the OCXO under a plastic cover (Hammond 1551P) to shield it from airflow.

[thinkfat]

Carsten,

I remember I shared a little circuit with a 74HC74 to delay the stop pulse by 100ns (one 10MHz clock cycle). That circumvents the problem with the dead time in mode 1. Also, if you search the time-nuts archive, you'll find a similar design by member Tobias Pluess. He shared his full schematics on the mailing list as well. It is sure worth a look.

PS: I'd add an air pressure sensor as well. It is something I missed in my design, the next revision will have it.

[Carsten]

I remember I shared a little circuit with a 74HC74 to delay the stop pulse by 100ns (one 10MHz clock cycle). That circumvents the problem with the dead time in mode 1. Also, if you search the time-nuts archive, you'll find a similar design by member Tobias Pluess. He shared his full schematics on the mailing list as well. It is sure worth a look.

What's the advantage of delaying the stop pulse compared to relying on the 10 MHz stop signal's periodicity as I intend to do it? Values within the dead time (0 to 12 ns) should simply map to 100 to 112 ns. Do you see any reason that's not gonna work? The systematic error should be non-measurable, as the difference between sucessive 10 MHz edges is given by the phase noise floor (offset >1 MHz).

I have two reasons against using a synchronizer based on 74-type logic:

• Temperature dependency: The 74HC74 adds too much uncertainty in terms of potential temperature dependence of propagation delay (14/~40 ns typ./max. @ 5V). Even the high-speed CMOS variant 74AHC74, which I would recommend over the regular 74HC74, still fields a propagation delay of typically 3.7 ns at 25°C and min/max from 1.0 to 8.5 ns over the -40°C to +85°C temperature range. That's simply too much uncertainty (i.e., potential temperature dependence) between the edge measured by the TDC7200 and the edge output on the SMA connectors. The LMK1C1103 I'm using as a fanout buffer has max. 50 ps skew between channels over its entire -40°C to 125°C temperature range.
• Rise/fall times: The TDC7200 datasheet specifies the Maximum rise, fall time for START, STOP signals and Maximum rise, fall time for external CLOCK as nominally 1 ns. The 74HC74's transition time is substantially higher (7/19 ns typ./max.). Unfortunately, no rise time is given in Nexperia's 74AHC74 datasheet. The LMK1C110x specifies max. 0.7 ns rise/fall time.

PS: I'd add an air pressure sensor as well. It is something I missed in my design, the next revision will have it.

Do you also recommend that for OCXOs or just for your LPRO? AFAIK, OCXOs should be insenstive to air pressure due to hermetically sealed cases.

[0xFFF0]

Use LVC types. They have 1 or 2 ns rise time.

[Carsten]

Thanks for the suggestion. That rise time does sound better. Also, the 74LVC74's propagation delay is lower (1.0 to 5.2 ns in the -40°C to +85°C temperature range). However, I still don't see a reason to use an additional discrete component if I can achieve the same result via configuring the TDC7200 (CLOCK_CNTR_STOP_MASK = 1) and/or post-processing its measurements.

[0xFFF0]

In order to use the 7200 correctly, I can recommend this paper. Finest stuff.
https://github.com/TAPR/TICC/blob/master/docs/TAPR%20TICC%20User%20Manual.pdf

[Carsten]

I've read all official and unofficial documents on the TDC7200 that I could find, including the TICC docs. While many designs use dividers and/or synchronizers for the STOP signal, the TDC7200 datasheet gives no indication that STOP signals within the dead time or preceding the START signal have an adverse affect on subsequent measurements. thinkfat also conlcluded that Feeding the 10MHz into a counter and directly to the TDC7200 works:

I did have some issues with the TDC7200 which might have been due to the STOP signal coming too quickly after the START signal. The topic came up in this thread but could not be resolved satisfactorily. However, in praxi I have not seen any issues with sending STOP without a START before, according to the data sheet, the TDC7200 should be fine with this.
[...]
Feeding the 10MHz into a counter and directly to the TDC7200 works, but it is better to delay the 10MHz  STOP signal edge with regards to the 1PPS pulse by e.g. a flip-flop because the TDC7200 cannot measure down to 0ns.

I do not want to add a synchronizer, unless there's a absolutely solid technical reason for it.

As there's obivously some doubt about my approach, should I first verify that the TDC7200 works the way I intend to use it before having the GNSSDO manufactured?

[iMo]

..
As there's obivously some doubt about my approach, should I first verify that the TDC7200 works the way I intend to use it before having the GNSSDO manufactured?

I would do it..

[Theboel]

Hi Carsten,

I just curious how You measure the performance of GPSDO in Your application.

[mino-fm]

I do not want to add a synchronizer, unless there's a absolutely solid technical reason for it.

You can leave any delay circuit if you are sure your time difference is always >= 12 ns all of the time.
I wouldn't do so.

Originally, I wanted to measure and average 5 stop pulses,

I wonder how five stop pulses could improve your results. Pulsdifferences 2 - 5 should be exactly 100 ns.

TDC7200 compared to AS6500 is very noisy.

[Carsten]

I just curious how You measure the performance of GPSDO in Your application.

We conducted an automotive measurement with the Jackson Labs LC_XO GPSDOs (part of USRP X310) about 3 years ago. Boils down to packing them in a car, using separate antennas for each one (preferably with different orientation) to maximize the difference between each signal, and directly comparing the output signals of each GPSDO while driving. Results are published behind an IEEE paywall, sorry. Measuring between different vehicles is difficult. We only did that in a stationary scenario between buildings. Doing it on the move is complex and error prone as it requires a radio link with ideal line-of-sight conditions between participating nodes. While probably feasible, not worth the effort.

[Carsten]

You can leave any delay circuit if you are sure your time difference is always >= 12 ns all of the time.
I wouldn't do so.

It isn't. But time differences 0 < t < 12 ns should just wrap to 100 < t < 112 ns due to the periodic 10 MHz stop signal.

I wonder how five stop pulses could improve your results. Pulsdifferences 2 - 5 should be exactly 100 ns.

Averaging to reduce noise. No idea whether that would have a positive effect with the TDC7200.

TDC7200 compared to AS6500 is very noisy.

Thanks for the hint with the AS6500. I think I have looked at it before, because I distinctly recall the color scheme of the ScioSense website, but I must have discarded it because the QFN package scared me off or sth.
Honestly, now the specs blow my mind. I'll have to think how to proceed from here.

[WatchfulEye]

There's quite a nice set of experiments documented here:
https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf

My take from this is that the noise from the ZED-F9T is orders of magnitude higher than the noise from the TDC7200 at relevant loop bandwidths.

Also there is a possibility to "misuse" mode 2 if you are measuring phase offset to a clock edge. You just discard the "TIME2" measure, and only count clocks and use the TIME1 fractional measure. This avoids the additive noise which comes from summing what is effectively 2 measures. This is how I did it in my TDC7200 based GNSSDO. 

[Carsten]

There's quite a nice set of experiments documented here:
https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf

That's an informative paper, indeed. I already cited it in my initial post

Also there is a possibility to "misuse" mode 2 if you are measuring phase offset to a clock edge. You just discard the "TIME2" measure, and only count clocks and use the TIME1 fractional measure. This avoids the additive noise which comes from summing what is effectively 2 measures. This is how I did it in my TDC7200 based GNSSDO.

Haven't thought of that. That's a nice idea.

[thinkfat]

What's the advantage of delaying the stop pulse compared to relying on the 10 MHz stop signal's periodicity as I intend to do it? Values within the dead time (0 to 12 ns) should simply map to 100 to 112 ns. Do you see any reason that's not gonna work? The systematic error should be non-measurable, as the difference between sucessive 10 MHz edges is given by the phase noise floor (offset >1 MHz).

I have two reasons against using a synchronizer based on 74-type logic:

• Temperature dependency: The 74HC74 adds too much uncertainty in terms of potential temperature dependence of propagation delay (14/~40 ns typ./max. @ 5V). Even the high-speed CMOS variant 74AHC74, which I would recommend over the regular 74HC74, still fields a propagation delay of typically 3.7 ns at 25°C and min/max from 1.0 to 8.5 ns over the -40°C to +85°C temperature range. That's simply too much uncertainty (i.e., potential temperature dependence) between the edge measured by the TDC7200 and the edge output on the SMA connectors. The LMK1C1103 I'm using as a fanout buffer has max. 50 ps skew between channels over its entire -40°C to 125°C temperature range.
• Rise/fall times: The TDC7200 datasheet specifies the Maximum rise, fall time for START, STOP signals and Maximum rise, fall time for external CLOCK as nominally 1 ns. The 74HC74's transition time is substantially higher (7/19 ns typ./max.). Unfortunately, no rise time is given in Nexperia's 74AHC74 datasheet. The LMK1C110x specifies max. 0.7 ns rise/fall time.

PS: I'd add an air pressure sensor as well. It is something I missed in my design, the next revision will have it.

Do you also recommend that for OCXOs or just for your LPRO? AFAIK, OCXOs should be insenstive to air pressure due to hermetically sealed cases.

Lets just say I see behavior in the DAC output of my GPSDO that is clearly not only temperature related. It sure won't hurt to have more input data, and the next easy target after temperature is air pressure. Also I'm not so sure if OCXO are totally immune to air pressure, I remember some discussions on the topic on the time-nuts mailing list that suggest otherwise. It cannot hurt, IMHO.

Regarding delaying the stop signal, I really like your idea of using the mask function to ignore early stop events. I hadn't thought of that, I'll have to consider that.

[thinkfat]

Regarding the AS6500 - it's an expensive part and probably not worth the expense. Just how accurately do you want to sample the noise of the GNSS time pulse? Even with the F9T, the time uncertainty is still in the nanoseconds range.

[mino-fm]

Regarding the AS6500 - it's an expensive part and probably not worth the expense.

Did you ever use it?
I think: no.

[thinkfat]

Regarding the AS6500 - it's an expensive part and probably not worth the expense.

Did you ever use it?
I think: no.

I haven't used it. And I likely won't, looking at the spec sheet and the price it's listed for at Mouser (around. 24€ in single quantities). You don't need 20ps single shot resolution for a GNSSDO. 55ps is already plenty. The one-second uncertainty for the time signal of the F9T is at least two orders of magnitude worse. So, again, how accurately do you need to sample that noise?