DIY GPSDO project w/ STM32, TDC7200

[dmendesf]

That's very nice to know. I'm planning a device with a PTPv2 "slave" implementation for STM32 and one thing holding me back was a lack of an affordable grandmaster. Keep up with the good work!

[dmendesf]

Hi... how's this project going? Is it selling on Tindie yet?  Joking, i'm in need of a cheap PTPv2 grandmaster and looking for the alternatives... anything you can share?

Cheers 

[felixd]

Any updates?

[thinkfat]

Not right away. I find myself with little time to work on personal projects nowadays. I'm quite happy with the original STM32 Rubidium GPSDO, but I've abandoned the redesign and am focusing on the Beaglebone Black cape instead. Which is working great already, I'm just implementing some hardware options around the TIC that I wanted to play with, but in fact it's more down to software optimizations. The last problem I'm trying to solve is aligning the 1PPS output to be within a couple 10 nanoseconds around the GPS time pulse.

[Carsten]

I'm trying to build sth similar (STM32G4 + TDC7200 + OCXO) using the ZED-F9T, which has superb sub-nanosecond timepulse stability with quantization correction. I have a few concrete technical questions that I haven't been able to answer reading your posts. I'd appreciate it if you could take the time to answer these:

- The 74HC390 works and outputs a 500kHz signal to the TDC7200 (which is not yet mounted)

Have you had any issues with continuously feeding a relatively fast, periodic stop signal into the TDC7200 (i.e., without a preceding start signal)?

Why are you dividing the 10 MHz down to 500 kHz before feeding it to the TDC's stop input? I'm assuming this is to prevent aliasing, i.e., missing full periods of the 10 MHz signal, resulting in actual drifts outside the +-50 ppb range cyclically mapping into that range. By dividing it the 10 MHz by 20 you achieve a +-1 ppm measurement range. Any reasons other than that? Are there any issues with the TDC's clock and stop signals being the same 10 MHz signal?

I intend to directly feed the 10 MHz into the TDC and to resolve the aliasing by using a 32-bit timer capture to measure the GNSS 1PPS with ~6 ns resolution (170 MHz timer clock) relative to the OCXO's 10 MHz, which also serves as the STM32's HSE clock source. Any comments on that?

While experimenting with the platform I found a couple of key factors for good performance:

• Keeping thermal equilibrium is most important. Temperature changes cause major disturbance. Probably not in the Rb oscillator itself, but the TIC measurements are affected by the temperature and also the DAC and the OpAmp have a temperature dependency which needs to be modeled for compensation. I'm currently trying to figure these out, but it's not really that easy without a stable reference to compare against. I know that I have about -1ns/K on the TIC measurement but to which part it is the TIC or DAC and OpAmp is not quite clear. I'll have to dig out the data sheets to get a ballpark figure for those.
  

Have you been able to determine the cause of the TIC measurements' -1 ns/K temperature coefficient? It shouldn't be the TDC7200 due to its self-calibration. Could it be 3x the 74HC390 propagation delay, which has a likely non-negligible temperature dependency?

Just a quick update on the status of the GPSDO for the Beaglebone Black.
The project is not dead. In fact it is coming along very nicely and has seen a couple of interesting additions.

The most interesting addition is that I'm feeding UTC time and 1PPS timestamps from the GPS into "chrony" (NTP server) to create a stratum-1 time server. I'm also experimenting with PTP so that the device can act as a PTPv2 "Grandmaster" clock.

Just asking out of curiosity: How are you feeding time into the BBB? You wrote that you don't plan to use its PRUs. From my understanding the BBB runs from its own (drifting) clock source and any time transfer would also be affected by scheduling and interrupt jitter. Are you using a hardware timestamping Ethernet PHY to overcome that? Which accuracy can you achieve with NTP/PTP?

[thinkfat]

Hi Carsten, welcome to the forum.

Regarding your question:

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.

The divide-down to 500kHz was indeed meant to avoid aliasing. Initially I didn't have a counter connected to the 10MHz, so something had to be done. I did not see any issues with the clock input and the STOP signal being coherent.

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. This would also prevent feeding constant STOP signals into the TDC. I have seen a circuit from a fellow forum member somewhere that does this, I cannot remember however where. It is remarkably simple, with just a 74HC74. I think it is just by connecting the clock inputs of the two FFs to the 10MHz clock, connecting the 1PPS pulse to the first D input and connecting the first Q output to the D of the second FF. The Q output of the second FF is your STOP. Then you can use the TDC in Mode 1.

I've not been able to determine the temperature dependency of the measurements satisfactorily, but I have added a D-FF after the 500KHz signal that synchronizes it with the 10MHz again. I think that has helped.

Feeding the time into the BBB That is a neat trick indeed. The DMTIMERs of the AM3358 can be driven by an external clock. So, I just feed them with the 10MHz OCXO output. Then I capture the 1PPS signal from the GNSS receiver using the same timer, that works in hardware with no latency due to interrupt processing or stuff. I then take timestamps from the captured counter value to have a PPS source for "Chrony". Additionally, I use the exact same timer as the system clocksource. Since the counter is clocked by the disciplined OCXO, it has effectively zero drift against the GNSS. So I get a zero-drift system time:

Code: [Select]

root@ptpgm:~# chronyc tracking 
Reference ID    : 50505330 (PPS0)
Stratum         : 1
Ref time (UTC)  : Sat Apr 16 15:35:35 2022
System time     : 0.000000000 seconds fast of NTP time
Last offset     : +0.000000000 seconds
RMS offset      : 0.000000000 seconds
Frequency       : 0.000 ppm slow
Residual freq   : +0.000 ppm
Skew            : 0.000 ppm
Root delay      : 0.000000001 seconds
Root dispersion : 0.000002431 seconds
Update interval : 1.0 seconds
Leap status     : Normal

I hope this answers your question.

Best regards,
Matthias

[Carsten]

Thanks for the welcome and for answering my questions. That is a neat trick indeed. 

[thinkfat]

It's been a while since I was active on this project.

I always wanted to characterize the performance of my GPSDO and lacked the equipment to do so, but that has just recently changed.

Forum member and fellow time nut @erikka found an ingenious way to turn a nanoVNA-H4 into a very accurate phase and frequency measurement device with just a firmware change. He has started a thread about it on the forum, you can find it here: https://www.eevblog.com/forum/metrology/very-accurate-phase-and-frequency-measurement-using-the-nanovna-h4-hw/msg4594966/

The attached graph from TimeLab shows the current BBB-GPSDO hardware against the timebase of my 53132A counter, which is equipped with the high-stability OCXO option. The counter had less than 24h to warm up, it was powered down a couple of months, which is far from ideal for an OCXO, but it was all I could do with reasonable effort for now. I'll later fire up one of my Rubidiums for comparison.

The blue trace is the raw measurement, magenta is after removing linear drift, which should compensate the OCXO drift. The green trace is the TIC output from the GPSDO, which shows its phase error against the GNSS reference. It serves as a "worst case" depiction, the GPSDO output can never be worse than this curve.

Since I have no way right now to characterize the 53132A timebase itself properly, I cannot give an absolute statement of the GPSDO output yet, I can only say that its stability is "not worse than" what the magenta trace shows. But that's already something.

[thinkfat]

And another measurement result, this time referenced against one of my Rb oscillators. I think it is quite interesting.

As you can see, up to tau=5s it is much noisier than the previous measurement against the 53132A timebase. That is somewhat expected from a surplus LPRO-101. However, the result above t=5s is _better_. That means the previous measurement was likely dominated by the 53132A timebase above 5s and not the GPSDO.

So, up to 5s, the GPSDO is as least as stable as the green curve, and above 5s it is at least as stable as the blue curve.

[erikka]

It would be interesting to see the ADEV of the PPS against the RB (should be 1/Tau) till at least 1000s and both the regulated and unregulated gpsdo output.
This should show a higher ADEV for the regulated GPSO in the decade before the PPS line starts to bring the ADEV down
Many Rb seem to have worse noise around 1s versus a good OCXO

[cncjerry]

I'm also converting some arduino + TDC7200 + sawtooth code to an STM32F7 board.   I recently added FREERTOS code and TouchGFX but now my TDC code is jumping one count, possibly due to FREERTOS time slicing even though the TDC7200 code runs in a capture compare interrupt level loop.  Need to look at it more closely.  One thing I found is the clock speed on the TDC7200 should be higher than practical for a 10Mhz based system.  You need an accurate clock with 50/50 duty cycle and the highest you can go, I think, is 5Mhz, unless you double it but then jitter might be a factor? Haven't explored all that yet.

I have most of it working but got interrupted by the holidays.  Getting the TDC7200 SPi calls correct were a pain but I have that all working now.  The command interface is working from a PC and the graphing works.  I need to take the ADEV code I have and rework the output for the small screen and TouchGFX.  Since I have extra usarts on the board, I've been kicking around either using a DMTD system with a TICC (dual 7200 TIC from TAPR) or use a 2ndary PPS reference input directly into the GPSDO system using another TDC7200.  Or possibly use the collected data from the PID loop, don't know yet.

Once I get this system tested using a standard PID loop I'm going to try to develop a neural network PID loop using the STM library, STMCube.AI.  I've seen some examples that look promising.  ideally, and I use that term loosely, I would like to have the neural net train all the way from GPS to ADEV using one of the more ideal ADEV masks.  I had tested some decent GPSDOs against my Cs beam and you can also get GPSDO ADEV masks from Timelab.  I expect this to take the rest of my pre-dementia life.

Jerry

[thinkfat]

It would be interesting to see the ADEV of the PPS against the RB (should be 1/Tau) till at least 1000s and both the regulated and unregulated gpsdo output.
This should show a higher ADEV for the regulated GPSO in the decade before the PPS line starts to bring the ADEV down
Many Rb seem to have worse noise around 1s versus a good OCXO

Yep, but there's no need to make that experiment myself. There's plenty of sample data, e.g. on leapsecond.com, there's sample set of GPS 1PPS against some Rb or Cesium clock, that could be used as a reference.

I agree about the Rb clock output. For example, the LPRO-101 has just a regular crystal oscillator that is not even heated. Additionally, those surplus Telecom Rb's all have the same problem, their Rb lamp is showing its wear and the reduced SNR shows up as noise on the output. They do lock, but the output stability is degraded. The FE-5680 are even worse, they have DDS artifacts on the output.

The Efratom FRK would likely be a better candidate, at least it has a heated, I think even temperature controlled XO. I have one, but it's broken and I don't find time to repair it.

However, I could think of a PLL filter with an OCXO to clean up the Rb output. That could be an interesting project.

[erikka]

The main reason to do the experiment using your current GPSDO project could be to validate if the GPSDO is working correctly
Here you have a simulation of the GPSDO algorithm using actual PPS data and TCXO stability data and the actual measurements including the performance of the GPSDO (green trace)
Seeing the disciplined TCXO trace stay below the PPS trace is confirmation the GPSDO is performing well.

[thinkfat]

The definition of "performs well" is subject to what you want to do with the GPSDO/GNSSDO. You may choose to have "slow" regulation and sacrifice some stability at tau=1000s, to have the cleanest possible output at small tau, or you may want the stability to be never worse than the 1PPS reference.

[hgl]

It would be interesting to see the ADEV of the PPS against the RB (should be 1/Tau) till at least 1000s and both the regulated and unregulated gpsdo output.
This should show a higher ADEV for the regulated GPSO in the decade before the PPS line starts to bring the ADEV down
Many Rb seem to have worse noise around 1s versus a good OCXO

I bought a used UCCM GPSDO module from Samsung on EBAY for about 40$ 3 years ago from China.
The picture shows the GPSDO as external reference for the FA-2 vs. my best Temex MCFRS-1 Rb for 24h.  The Temex Rb uses an internal 20 Mhz XT-Cut oscillator and the Samsung GPSDO has a STP2945LF oscillator.

[erikka]

@hgl
Out of curiosity, do you know why the noise slope of the FA2 is not 1/Tau?

[hgl]

1/tau only applies to white PM noise. The FA2 also has other noise components generated by the power supply, reference oscillator, nonlinearity of the interpolator, etc.  With long-term measurements, the white noise also averages out.

[erikka]

@hgl
Do you still have the .tim file, I'd like to zoom in so I can better understand the nature of the noise.

[hgl]

With stable32 ( http://www.stable32.com/ ) you can generate different noise variants and save to file.

[0xFFF0]

the worst: 10 000 000 001 606 448E+07

[erikka]

Thanks for the raw measurement.
It helps me to understand the amount or other forms of "noise", next to white noise, in the FA2
Attached the FA2 noise compared to the tinyPFA noise
The tinyPFA also has some random walk that becomes visible when running long measurements. A similar bump around 100s

[hgl]

Recommendation for further reading

W.J.Riley  http://www.wriley.com/Learn%20Frequency%20Stability%20Analysis%20Using%20Stable32.pdf

Enrico Rubiola  http://rubiola.org/pdf-slides/2016T-EFTF--Noise-in-digital-electronics.pdf

[cncjerry]

The big factor that comes into play is the survey, don't know if your code is sending the message to the GPS or not.  You can also use Ublox UCenter, but we found huge differences in performance as the survey completes at less than 1m.  It took a few days for my GPS, a Ublox lea-m8t, to finish down to .25m.

The attachment below plots the TIC high/low/average (red/blue/black), the DAC EFC voltage (green) and number of sats in view (orange) with the middle being 10 sats and the absolute peak of 15.  The survey completed after the 4th block from the left and you can see how the TIC and DAC EFC voltage settled down. This oscillator (Wenzel low noise sprinter, chosen for phase noise opposed to ADEV) is still drifting high as it hadn't been turned on in years.  This code was based on Lars, modified quite a bit, and then became the basis for my STM32F7 code.  With a time constant of 512 the oscillator will stay less than +/- 5ns if left alone after the survey.  But any draft, significant rain, etc., will make it drift  as much as +/- 20ns.

Jerry

[0xFFF0]

Does the survey have to be initiated/activated? What commands do you send or receive from the Ublox?

[cncjerry]

If you are using a ublox timing receiver, that which you should be using (models ending in T, though I think the models ending in 'F' are timing as well), then it depends on the model.  At some point in the 5's or 6's they changed from sending tmode to tmode2.  Best way to send it is with Ublox Ucenter code for windows (free).  I would stay away from Ucenter V2 and find V1, Release 22.10 or around there as it is much easier to use, no login accounts, etc.

You bring up the config messages screen, scroll down to timing, find tmode or tmode2 depending on your model, and then set the parameters to like 10,000 observations and something less than .5 meters.  Depending on the Ucenter version, you have to be careful as at one point you could send meters but the model expected centimeters or vice versa.  Find v22 and put .25 meters, enable the srvin message and you can watch it count down.
 
Depending on the variance, I use .25m, it will take time to get there.  .25m at c (300km/s will give you the minimum possible variance for the accuracy of your GPS and DO.  So .25m is 7.5e-10th if I did my math correctly and since it is actually the square root of that variance, and I can't remember if the software takes that into account, you can assume you will be less than 1ns from where the GPS thinks it is.  You can see on the chart I posted that the numbers were varying +/- about 25ns or so, maybe even as much as 50ns  until the survey completed.  At that point, the variance in TIC with sawtooth correction came down to much less than +/5ns.  Other factors impact that though, temperature, humidity, power fluctuations, turning the lights on, anything that can upset a low noise oscillator.

Instead of using Ucenter, you can send the command from your code and the only tricky part is the CRC characters that need to be calculated.  There is a 500 page manual on the Ublox GPS modules that explains all this.

I don't know who wrote this code.  It was either Lars or Jim Harman, I modified it for the tmode2 message.  Only thing to consider is if you send it and change your mind and want to send it with a looser variance, you need to send it with a cancel code (0x00) first.  Once you send it, you should also config messages in Ucenter to receive the srvin messages so you can watch the progress.  When the observations stop counting up, then the survey is completed.

This example is already setup for 1m^2 so you can send it as-is.  You don't need to fill in the lat/long/altitude as that will be filled in by the GPS quickly and then resolve to the variance.  Once you get it fixed at .5m or less, you can send it a fixed location message at reboot as long as you don't move your antenna. 

This makes a very big difference in the performance of a GPSDO.  Once I get my STM32 code completed, I am going to see if it will count down to 10cm.  I've heard of people setting the variance to 1cm.  I think you should also set the max number of sats to between 5 and 7 and raise the angle to minimize fluctuations from low sats.  There is quite a bit on the web about that.  Thinking is that 5 high sats with strong cn ratios is better than 12 sats banging away at your receiver.   My variance also correlated more quickly when I did that.  I think I used 5 sats and 25 degrees with cn > 35.  That is in like the sat5 message?  can't remember.  Again, Jim H. really helped me with all this.  I'm sure there are much more knowledgeable people on here that can throw-in at this point.

call this routine with a duration of at least 5,000 to get 1m

Code: [Select]

//----------------------------------------------------------------------------------------
//----------------------------------------------------------------------------------------
// Send the Ublox CFG-TMODE2 message to initiate a survey of length duration sec
void startSurvey(long duration) { // jth changed to tmode2 message as m8t doesn't support tmode
  // note LSB is sent first
  uint8_t packet[] = {
    0xB5, 0x62,                 // header
    0x06, 0x3D,                 // class = CFG, id = TMODE2
    0x1C, 0x00,                 // length = 28
    0x01,                       //  01 survey in, 00 cancel, 02 fixed 
    0x00,                       // reserved
    0x00, 0x00,                 // flags     
    0x00, 0x00, 0x00, 0x00,     // X coordinate ignore for survey, set for fixed
    0x00, 0x00, 0x00, 0x00,     // Y coordinate as above
    0x00, 0x00, 0x00, 0x00,     // Z coordinate as above
    0x00, 0x00, 0x00, 0x00,     // position variance measured
    (uint8_t)(duration & 0xFF), //duration
    (uint8_t)((duration >> 8) & 0xFF),
    (uint8_t)((duration >> 16) & 0xFF),
    (uint8_t)((duration >> 24) & 0xFF),
 //   0x40, 0x42, 0x0F, 0x00,     // position variance = 1 m^2
    0xE8, 0x03, 0x00, 0x00,     // position variance = 1 m^2
    0x00, 0x00                  // 2 bytes for checksum  
  };

  sendPacket_crc(packet, sizeof(packet));
  
}

//----------------------------------------------------------------------------------------
// send a packet to Ublox with crc
void sendPacket_crc(uint8_t *packet, uint8_t len) {
  uint8_t ck_a = 0;
  uint8_t ck_b = 0;

  for (uint8_t i = 2; i < len-2; i++) {   // compute crc
    ck_a += packet[i];
    ck_b += ck_a;
  }

  packet[len-2] = ck_a;                   // put crc in packet
  packet[len-1] = ck_b;

  for (uint8_t i = 0; i < len; i++) {     // send it out
    Serial1.write(packet[i]);
  }
  
}