Yet another DIY GPSDO - yes, another one

[AndrewBCN]

I have now moved on to Erik's version of Lars' 1ns resolution analog TIC, and it works (thank you Erik!  ), except that I am seeing much more jitter in the TIC output than I was expecting, and it has two components:
- the regular and expected 21ns jitter from the u-blox GPS receiver MCU which runs at 48MHz.
- a random 30ns component which I guess could also be expected, apparently linked to signal propagation delays through the atmosphere and the relative movement of the satellites.

Unless the noise (i.e. the jitter) can be removed by software from the TIC information, its effective resolution is more like 50ns, not 1 ns. 

Lars only mentions this in his documentation:
"As the 1PPS has a lot of jitter, normally in the range 10-50ns p-p, the time measured between the 1PPS and 10MHz is filtered with a low-pass filter in the software."


Erik has already noted the 21ns jitter from the GPS MCU, so the TIC jitter is really in the range 25-50ns p-p. You cannot get less than 21ns jitter, at least with a u-blox receiver with an MCU clock frequency of 48MHz.

I guess I'll have to read Lars' source code to see how he dealt with this much jitter in software. This also confirms that my original FLL approach is the way simpler method to "close the loop" i.e. to obtain a Vctl to control the OCXO frequency.

Attached the DSO capture. The yellow trace is the rising edge of the 1PPS from the u-blox GPS receiver module, the green trace is the charging of the 1nF capacitor in the TIC circuit. The 10MHz noise in both traces is due to inadequate decoupling and the lack of a good ground in the breadboard assembly. That should be solved with a correct layout in the final PCB assembly. The ringing is probably the result of the DSO probe and the excessive impedance of the wiring in the breadboard assembly, but it is irrelevant as the ADC capture will occur a couple of µs later.

Now on to reading Lars' code!

[thinkfat]

There isn't a lot of magic in Lars' software regarding noise filtering. There is an EMA (Exponential Moving Average) applied to the TIC readings and then the rest is in the PI controller constants.

[Johnny B Good]

I have now moved on to Erik's version of Lars' 1ns resolution analog TIC, and it works (thank you Erik!  ), except that I am seeing much more jitter in the TIC output than I was expecting, and it has two components:
- the regular and expected 21ns jitter from the u-blox GPS receiver MCU which runs at 48MHz.
- a random 30ns component which I guess could also be expected, apparently linked to signal propagation delays through the atmosphere and the relative movement of the satellites.
====snip====

 That reference to a 30ns component caught my attention. JOOI, does this have a subsonic frequency in the region of 3mHz (around a period of 2 to 5 minutes) by any chance?

[iMo]

The Neo-7/8 modules have "Accuracy of time pulse signal 30ns RMS".. Peak-Peak value is much higher..

[erikka]

Even if the phase detector does not bring much extra resolution (from 100ns when only counting 10MHz edges to 20-50ns with the phase detector) the big advantage is you are now able to SEE the PPS jitter of the GPS so you know the measurement uncertainty and you are able to calculate your measurement error to prevent you are measuring and acting on noise.

[FriedLogic]

Unless the noise (i.e. the jitter) can be removed by software from the TIC information, its effective resolution is more like 50ns, not 1 ns.

  The u-blox binary UBX-TIM-TP message has the correction for the quantization error, so you can correct the TIC measurement for that. It can also just be logged to see how much it might affect the calculations.

  A delay line like a DS1023 is also sometimes used to correct the 1PPS in hardware so that the corrected pulse can be fed out to other equipment.

[AndrewBCN]

Unless the noise (i.e. the jitter) can be removed by software from the TIC information, its effective resolution is more like 50ns, not 1 ns.

  The u-blox binary UBX-TIM-TP message has the correction for the quantization error, so you can correct the TIC measurement for that. It can also just be logged to see how much it might affect the calculations.

Now that's very interesting. But obviously it's not how Lars's code does it, so I am still left wondering how/why nobody (except Erik) commented on this in the 37 or so pages of the Lars thread? I mean, one can see the voltage at the TIC capacitor jumping up and down by an equivalent 21ns.

But Lars's original TIC range is 1µs (because he divides the 10MHz from the OCXO by 10 before feeding it to the TIC), so 21ns is just a 2.1% error. I am feeding the TIC directly with 10MHz so my measurement range is 100ns, and 21ns represents 21%.

Hmm. Perhaps a "1ns resolution TIC" is only useful if the 10MHz OCXO frequency is divided by 10 or more before being phase-compared to the 1PPS? I'll have to think more about that. Also it probably means I'll have to order some 74HC390's.... 

A delay line like a DS1023 is also sometimes used to correct the 1PPS in hardware so that the corrected pulse can be fed out to other equipment.

Very interesting again. Yes, I was thinking about how to phase-correct the 1PPS from the picDIV-OCXO so it would be aligned (within 100ns) with the GPS-UTC time. That is a rather challenging bit of engineering creativity question...

Thank you for your comment, much food for thought.

[thinkfat]

Using a delay line on the output of the GNSS receiver will not give you a satisfactory 1PPS output. You correct the quantization error, but the measurement uncertainty is still there, roundabout 20ns - 30ns. What you want is a 1PPS derived from the OCXO and phase locked to UTC top-of-second.

[AndrewBCN]

Using a delay line on the output of the GNSS receiver will not give you a satisfactory 1PPS output. You correct the quantization error, but the measurement uncertainty is still there, roundabout 20ns - 30ns. What you want is a 1PPS derived from the OCXO and phase locked to UTC top-of-second.

Yes, that is exactly what I wrote. And since the picDIV is the simplest and cheapest solution to obtain a 1PPS from the OCXO, the question boils down to how to align/phase lock the 1PPS from the picDIV with the 1PPS from the GPS receiver, and ideally even correct the quantization error from the u-blox, since a u-blox proprietary message can provide the required information.

This is quite a challenging problem. And I can't find any information on anybody having solved this problem before in a DIY GPSDO or GPS clock.

[MIS42N]

The Lars 1ns figure is the outcome of using a 10-bit ADC and a 1000ns window. I have not looked at Lars code, but I suspect it steers the oscillator so the average reading from the ADC is middle of the range. i.e. about 500. To fine adjust the phase of the oscillator is just picking a different value to steer to. A a full cycle of phase adjustment is obtained by picking values between say 450 and 550.

The problem is Lars hardware is locked to 10 cycle blocks so if the output of the picDIV needs to be shifted by a large amount, it can't be done. A possibility is inserting hardware between the oscillator output and the picDIV that can block one cycle of the PIC clock each time it is triggered. Start the picDIV early and delete cycles until its output is within 100ns of where it should be, then change the phase of the oscillator to remove the residual.

The real problem is aligning the picDIV output to what?

[thinkfat]

Well obviously you align to the GNSS time pulse.

[MIS42N]

Well obviously you align to the GNSS time pulse.

Easier said than done. The electrical time pulse out of the GPS receiver may or may not be synchronous with the time as known to the GNSS satellites. If you use an active antenna with a 3 meter lead, there is a delay (about 15ns, depending on the material) between the signal reaching the antenna and reaching the GPS receiver. So the picDIV pulse should be ahead of the 1pps from the receiver. This has to be detected and measured in hardware, the processor is unaware of the arrival of the 1pps until it is interrupted, and because the processor clock (in the case of your usual Arduino) is not aligned with the local oscillator, there is a variable delay. There's other delays to consider. It's messy.

IMO just produce a 1pps somewhere within a microsecond or two of the 1pps from the receiver. What's it going to be used for? I can't think of one application that needs accurate time stamping to better than a microsecond. Measuring time intervals is a different matter, pulses exactly one second apart are useful and the picDIV can do that. But they don't need to be aligned to anything.

[thinkfat]

It's not that difficult, if you have a timer that can be clocked by the 10MHz OCXO output. Ideally, the timer would allow capturing an external event (the GNSS timepulse) and be configured to output a pulse on underrun on an externally visible output.

You would preset this timer to 9,999,999 counts and configure it to auto-reload on underrun. The externally visible underrun output is your 1PPS. Then you capture the timer count on the GNSS timepulse and tune the OCXO until the captured count is 0. You're within 100ns of the GNSS timepulse now. This basically selects the 10MHz "edge" you want to finetune the 1PPS output to. You do that with using your 1ns resolution TIC. I bet you can get the 1PPS output to within a couple nanoseconds around UTC top-of-second this way.

[FriedLogic]

Using a delay line on the output of the GNSS receiver will not give you a satisfactory 1PPS output. You correct the quantization error, but the measurement uncertainty is still there, roundabout 20ns - 30ns. What you want is a 1PPS derived from the OCXO and phase locked to UTC top-of-second.

It depends what it's being used for - the 1PPS from a GPS has a different set of errors compared to one derived from an GPSDO OCXO.

Some of the errors and fluctuations in the GPS timing are over tens of minutes and into hours. If the time constant in the GPSDO is short, it will not reduce them much. If it is long enough to reduce them, small instabilities and environmental sensitivities in the OCXO and the GPSDO measurement and control can cause significant errors.

It can also be used to improve the 1PPS with an FLL GPSDO.

[thinkfat]

Well, let's assume your control loop has locked on the GNSS timepulse, which you would typically detect by monitoring the phase between your timepulse output and the GNSS timepulse (or the selected edge of the 10MHz output), finding that it stays within the GNSS time uncertainty for a longer period of time (like, multiple times your control loop time constant). You can then be sure that the timepulse derived from the OCXO is more accurate and stable than the timepulse from the GNSS itself.

[AndrewBCN]

Using a delay line on the output of the GNSS receiver will not give you a satisfactory 1PPS output. You correct the quantization error, but the measurement uncertainty is still there, roundabout 20ns - 30ns. What you want is a 1PPS derived from the OCXO and phase locked to UTC top-of-second.

It depends what it's being used for - the 1PPS from a GPS has a different set of errors compared to one derived from an GPSDO OCXO.

Some of the errors and fluctuations in the GPS timing are over tens of minutes and into hours. If the time constant in the GPSDO is short, it will not reduce them much. If it is long enough to reduce them, small instabilities and environmental sensitivities in the OCXO and the GPSDO measurement and control can cause significant errors.

It can also be used to improve the 1PPS with an FLL GPSDO.

A GPSDO can output two 1PPS pulses, and each one has its advantages and disadvantages.

1. The 1PPS from the GNSS receiver. Short term jitter (1s): 50~100ns. Long-term deviation from UTC: essentially zero.

2. A 1PPS derived from the OCXO. Short term jitter (1s): <10ns. Long-term deviation from UTC: essentially zero if perfect satellite reception over the measured period, otherwise OCXO drift.

Obviously the 1PPS from the GNSS receiver is dependent on satellite reception. For networks that need a guaranteed UTC-aligned 1PPS, we must use the 1PPS derived from the OCXO, meaning we have to phase-align it with the 1PPS from the GNSS receiver. And if possible/practical, correct the phase-alignment for the GNSS receiver quantization error, the length of the antenna cable, etc.

It's not that difficult...

I think it's one of those things that seems "not that difficult" until you actually try to do it. I haven't found a single example of a DIY UTC-aligned 1PPS on the web. A picDIV will get us within 400ns of UTC top-of-second, but that's not "good enough", so I am still trying to find a way to align that to UTC within < 100ns (which is the bar I have set myself).

[thinkfat]

It's not that difficult...

I think it's one of those things that seems "not that difficult" until you actually try to do it. I haven't found a single example of a DIY UTC-aligned 1PPS on the web. A picDIV will get us within 400ns of UTC top-of-second, but that's not "good enough", so I am still trying to find a way to align that to UTC within < 100ns (which is the bar I have set myself).

I know one, from a fellow time-nut who's also active here on the forum. The implementation I outlined, roughly describes what he did, using some rather beefy STM32 clocked by the 10MHz OCXO output. My own DIY GPSDO based on a Beaglebone Black should be able to do it eventually, if I ever find the time to complete the PCB.

[AndrewBCN]

I think I found a possible solution which I should be able to test when I receive the 12F675 PICs and the PIC programmer in the coming days.

I would just take the 1PPS from the picDIV and compare its rising edge to the rising edge of the 1PPS from the GNSS receiver, using Erik's version of Lars' TIC. Then adjust the OCXO Vctl until the phase difference is as small as possible and preferably under 50ns.

That would simultaneously adjust the OCXO frequency to a phase locked 10MHz and synchronize the picDIV 1PPS to UTC top-of-second (within 100ns, which is the objective I set myself).

At least in theory, that should work. In practice: we'll see when I build it and test it.    

EDIT: the PICs 12F675 have arrived, now just waiting for the PIC programmer to test the above.

EDIT2: In case anybody is wondering why I would want a 1PPS aligned to UTC within 100ns, it's because that's exactly twice as good as the FacePlant GPSDO "Time Machine". 

[AndrewBCN]

I have decided to rebuild one of my STM32 GPSDO prototypes on two breadboards, with every single possible optional module and trying to minimize noise.
I took a picture of the layout before wiring it. (see below)

This STM32 GPSDO prototype includes, clockwise from top left:

• Regulated power supply (5V and 3.3V).
• 10MHz squarewave OCXO.
• INA219 current sensor module.
• 74HC74 for the TIC / phase detector.
• picDIV (PIC12F675).
• 74HC14 output buffer and square to sine filter.
• I2C OLED display.
• HC-06 Bluetooth module.
• AHT10 temperature and humidity module.
• Yellow status LED.
• BMP280 atmospheric pressure and temperature sensor.
• u-blox Neo-M8N GNSS module; note the SMA connector for an external antenna.
• The brains of the GPSDO: an STM32F411CEU6 "Black Pill" MCU module.

 
Still waiting for the PIC programmer...

[iMo]

FYI - I built my gpsdo+reciprocal counter on the exactly same 2 solderless breadboards - with rather moderate results (too much noise/jitter in my measurements). Those boards are not well suited for prototyping systems where you are going to chase uAmps, uVolts and XXXpicoseconds, imho.. A tiny bang into your workbench and your data will be jumping all over the place..

PS: better you go with those green "perfboards", for chips using precision sockets soldered into it, smaller green breakout boards for smd parts, soldering in all the passive parts, wiring with careful selection of grounding points, beefy decoupling, etc.

[Johnny B Good]

 @AndrewBCN

 Thanks for posting that breadboard layout picture before wiring it all together.

 Once you've got it all wired up, those components are going to be buried underneath a rat's nest of jumper wires that you dare not disturb once you manage to get it doing something that approximates its intended function, for fear you'll send it all haywire (in this case, a rather apt expression!  ).

[iMo]

The cheapo jumping wires a) contain almost no copper, b) wire is not soldered to the pin.
For the green perfboards soldering jobs I've been using wires from cat5 patch cables (solid or stranded). Also doublecheck the cat5 solid ones - there is a lot of copper clad aluminum ones on the market (not easy to recognize).

[AndrewBCN]

Yes, I am quite aware that noise and jitter are a problem with the GPSDO prototypes built on these cheap breadboards, if you check the previous scope captures I have posted, the noise is quite obvious.

In this development phase of the STM32 GPSDO project, they have proven (just) good enough for testing various circuit ideas and allowing me to write the frequency measurement algorithms and test them.

At some point I'll probably start soldering things on a perforated board (which I already have), but I am not quite there yet.

Some ideas I still want to test and have some fun with, on this latest breadboard prototype:
- Committing calibration and configuration parameters and data to the MCU flash using the EEPROM emulation library for the STM32.
- Expanding flash using a separate SPI memory chip to log days/months of data (yet another optional module...).
- More tests of Erik's version of Lars' TIC.
- The picDIV.
- 1PPS from OCXO+picDIV, synchronized to UTC.
- Measuring the power consumption of the STM32 GPSDO.

The really tedious part of all this experimentation is wiring everything...    (The picture below is for you, JBG)

[bob91343]

The latest news about my quest for a black pill is that there is no news.  Aliexpress has no means to ask for help.  I finally found a US phone number but all I get is an answering machine.  So I am out the money and am obviously not going to get my part.

[AndrewBCN]

The latest news about my quest for a black pill is that there is no news.  Aliexpress has no means to ask for help.  I finally found a US phone number but all I get is an answering machine.  So I am out the money and am obviously not going to get my part.

How much did you pay for the STM32F411CEU6 "Black Pill", Bob, if I may ask? And which vendor was it that you ordered from, on AliExpress?