Yet another DIY GPSDO - yes, another one

[uflex]

@Hilly,
Thank you for your feedback. Here’s a brief response to your eight points.

• The reason I initially chose the 7404 over the 7414 had, I thought, something to do with expected jitter, though now I can’t see a clear rationale behind it anymore. Likely, the difference wouldn’t have been that significant.
  
• The decision to use a double inverter was indeed to ensure a sufficiently low output impedance for the following low-pass filter. To be honest, it also helped that there were six of them available in the chip, and it seemed the best place to put the last one to use!
  
• The distribution amplifier: This is straightforward and and works as it should, though I must say. My reason for choosing LM7171s was their low headroom requirements, allowing them to deliver sufficient output levels with a relatively low & single-rail supply voltage, which made them easy to combine with an LDO regulator for the OCXO and other logic. Thinkfat's approach with a single MAX4022ESD+ also seems particularly effective to me and appealing to merge into a follow-up of my design. It also provides a good opportunity to re-evaluate and further streamline the power distribution and the mix of 3.3V and 5V logic to 3.3V only.
  
• Regarding the two CD74HC390 dual decade counters and 1kHz, 10kHz and 100kHz outputs: I considered using a second PICDIV for this job but ultimately saw no need for so many outputs, prevering just 1kHz but sine and square-shaped . I am, however, intrigued by the possibilities offered by these PICDIVs. I had more or less moved away from the Microchip PIC series, but, interestingly enough, there seem to be few alternative microcontrollers with a built-in synchronous counter.
  
• Rotary Encoder: In my opinion I find the resistive touch screens on small (affordable) LCDs don’t work very well. They require quite a bit of pressure on the display, and the user experience on such a small screen falls short compared to a rotary encoder. BTW: I do hope someone will take the time to adapt all possible settings from AndrewBCN to the screen. A hell of a job but very worthwhile.
  
• Thank you for the compliments on the Platformio/VSCode support, the documentation and my GPS module. USB support, by the way, is available on a limited number of NEO series as far as I know.
  
• I’ve added the Gerber files to my website. I deliberately held them back because I still wanted to incorporate the points from my bug list into a second version of my board.If you or others are interested in picking up the project, please let me know, and I’ll expedite the process.
  

[hilly]

I have a genuine u-blox NEO-M8N on  my bench, waiting to be substituted

I have used, and compared, a Chinese copy Neo 6M fitted to a cheap eBay board, against a genuine M8T (a timing module).

Interesting. I didn't realize there was a model dedicated for timing. Checking on it I see it is almost 4x the cost (new) of the M8N.
Probably - for me - not worth it. At least not at this point!

I didn't expect the super capacitor to have long term retention - just those few days between usage to maintain storage of the almanac.

[hilly]

Yes, I expected that with the dual inverters.  Having surplus in the box makes some design decisions easy!
I agree that @thinkfat's approach is appealing since the parts count is potentially lower.
The PICDIVs would do the job - but I'd have to learn to program another chip! My poor old brain might not survive!  Nevertheless, +1 for lowering parts count!
The touch screen I have is capacitive. I didn't want to mess with a stylus. It's fairly large - 4"/10cm as I have old eyes to match the old brain! Those tiny OLEDs are hard for me to read. 

[MIS42N]

Interesting. I didn't realize there was a model dedicated for timing. Checking on it I see it is almost 4x the cost (new) of the M8N.
Probably - for me - not worth it. At least not at this point!

Timing modules perform better in 'difficult' signal conditions. They are designed to operate in a fixed position (to locate the position they have a 'survey in' mode). Once the position is known the timing can compensate for varying signal delays. They are cheaper than dual band GPS modules that compensate by comparing signals at two quite different frequencies.

I've tested an M8T with my GPSDO (documented elsewhere) and it reduced the frequency error below 0.04 ppb consistently. Using a standard N GPS unit with a good signal got close to that but a poor signal could see 10 times that error at times.

I think Andrew's design is using a 16-bit resolution control voltage, the OSC5A2B02 has a control voltage pulling about 10Hz/V so about 0.08ppb per step. So a standard GPS module with a well placed antenna should be satisfactory.

[hilly]

I think Andrew's design is using a 16-bit resolution control voltage, the OSC5A2B02 has a control voltage pulling about 10Hz/V so about 0.08ppb per step. So a standard GPS module with a well placed antenna should be satisfactory.

One thing I noticed is a UBX command to report quantization error (assuming I'm reading the specs correctly) which could potentially lead to even better results if it could be leveraged. I'm not sure if this command is available in the M8N - probably is in M8T.

[thinkfat]

I think Andrew's design is using a 16-bit resolution control voltage, the OSC5A2B02 has a control voltage pulling about 10Hz/V so about 0.08ppb per step. So a standard GPS module with a well placed antenna should be satisfactory.

One thing I noticed is a UBX command to report quantization error (assuming I'm reading the specs correctly) which could potentially lead to even better results if it could be leveraged. I'm not sure if this command is available in the M8N - probably is in M8T.

It's available in the M8T. And quite helpful, because it significantly reduces the PPS signal jitter. It should in fact be available in any M8 that supports outputting a PPS signal.

[hilly]

It's available in the M8T. And quite helpful, because it significantly reduces the PPS signal jitter. It should in fact be available in any M8 that supports outputting a PPS signal.
[/quote]

Yes, I went back into the protocol section of the document and found that what I saw was the UBX-CFG-TMODE2 command, for which the document states "This message is available only for timing receivers".
A bit of a mixup on my part.

[MIS42N]

It's available in the M8T. And quite helpful, because it significantly reduces the PPS signal jitter. It should in fact be available in any M8 that supports outputting a PPS signal.

My understanding is it doesn't reduce the jitter in the 1PPS signal, what it does is tell how much to adjust the actual arrival time of the 1PPS to be theoretically accurate. If the 1PPS arrives at time X and the quantization error in the previous UBX message says the quantization error is -3327 picoseconds, then the theoretical arrival time is X-3327ps. The 1PPS still jitters around, due to the internal clock not being locked.

So it's useful if the processor is decoding the UBX messages, then the processor can do the adjustment. I don't know enough about Andrew's design to know if it decodes the serial stream from the GPS.

[Solder_Junkie]

Regarding the differences between an M8T (timing version of the M8 series), and an M8N (navigation version)... From the UBlox spec sheet the 1pps accuracy for the M8T with a clear view of the sky is ≤ 20 ns, whereas the M8N spec sheet gives a figure of 30 ns (RMS), or 60 ns (99% of the time).

I'm not sure how much real difference the above makes as it is only a small difference in practical terms if you are using a GPSDO with a long time constant. For what it's worth, see the attached image showing a cheap eBay "6M" module (blue trace) vs a genuine M8T module (red trace), both with the same NEC high spec oven in my "Lars" GPSDO. In both cases the antenna is an external "mushroom" type with a clear sky view. The reference setup is a rubidium oscillator with the rubidium and the GPSDO feeding the two inputs of a TinyPFA (phase frequency analyser), the software is TimeLab. Caution, the rubidium may be less stable than the GPSDO, I am not sure as I don't have any better reference.

1 part in 10^10 is +/- 1 Hz at 10 GHz... which is probably more than accurate enough for nearly all practical purposes. From the graph you will see the 6M version is 1 part in 10^10 most of the time and the M8T is 5 parts in 10^11, give or take the stability of the rubidium, which is specified as +/- 3 parts in 10^11 over 10 seconds, and 1 part in 10^11 over 100 seconds.

SJ

[LADmachining]

@Hilly,
Thank you for your feedback. Here’s a brief response to your eight points.

<snip>

• I’ve added the Gerber files to my website. I deliberately held them back because I still wanted to incorporate the points from my bug list into a second version of my board.If you or others are interested in picking up the project, please let me know, and I’ll expedite the process.
  

I am interested in building your version of the GPSDO to test alongside some of the other versions that have been posted about on the forum (PaulV Lars V4, MIS42N, AndrewBCN etc).  So a big thumbs up from me for updating the PCBs when you have the time. 

Anthony

[Solder_Junkie]

Anothony, I guess you will find little difference between similar versions of the same GPSDO ideas.

At the "quick and dirty" side you have the GPSDO units by Leo Bodnar that use a navigation grade GPS module and a TCXO. They have some jitter but are ready to use in a minute or so from switching on, they can easily be configured to output any frequency from 1 Hz to 1.1 GHz and are relatively low cost and "just work". They currently cost 132 GBP (model LBE-1420), I have two of his units.

At the other end of the market, you have rubidium laboratory standards that use a GPS input to give the rubidium a nudge every now and again. From memory they compare the difference over several minutes and make an adjustment then wait several more minutes.

In the middle ground you have the units such as we are discussing here, these are going to be broadly similar and are mainly limited by the stability of the oven used. I haven't used a CTI oven in a GPSDO as I have a very high spec NEC oven. However, for less than 5 GBP for a used CTI oven (eBay from China, inc postage) they are good enough for hobby use.

A final couple of points... if you are using the correction data from the GPSDO itself, as opposed to measuring the frequency/phase difference to an external reference, you will never be sure of the real stability of the unit. For the most part we would be more than happy with an accuracy/stability of 1 part in 10^9 (1 Hz in 1 GHz). Before GPS units became readily available, some of us used 60 KHz standards that were only good to 1 part in 10^8 (short term). Now we can easily obtain 1 part in 10^10. Overall, it depends on what use you have for a GPSDO.

SJ

[MIS42N]

A final couple of points... if you are using the correction data from the GPSDO itself, as opposed to measuring the frequency/phase difference to an external reference, you will never be sure of the real stability of the unit. For the most part we would be more than happy with an accuracy/stability of 1 part in 10^9 (1 Hz in 1 GHz). Before GPS units became readily available, some of us used 60 KHz standards that were only good to 1 part in 10^8 (short term). Now we can easily obtain 1 part in 10^10. Overall, it depends on what use you have for a GPSDO.

SJ

In my design the control voltage is a synthesized 24 bit DAC by dithering a 10 bit PWM and using a lot of filtering to get rid of the PWM artifacts. It is buffered so the control voltage can be derived from a stable supply voltage (I've been using a MAX6350 rated around 1ppm/C change of voltage). With a stable and accurate control voltage it is not necessary to apply changes frequently. An OSC5A2B02 OCXO has a pull of 10Hz/V which if using a 16-bit DAC is frequency steps of about 8 part in 10^-11, which limits the theoretical accuracy of the OCXO output. Add to that most designs don't derive from a stable voltage source, more likely something like a 7805 regulator which is a lot less stable than the MAX6350. And if the control voltage comes from a microprocessor, it is likely the processor draws varying current which affects the voltage further. The system then spends much of its time compensating for environmental changes rather than changes in the OCXO. The method I use negates those potential sources of variation and is able to adjust the frequency in steps of less than 1 part in 10^-12.

Back to changing the control voltage infrequently. In the current running GPSDO, the control voltage is held stable for 1024 seconds then a change applied. The change is computed from the average phase difference of the GPS 1PPS and the OCXO for the first 512 seconds and the second 512 seconds. This gives a notional phase difference at the end of the measurement period and a frequency error. The change applied is to reduce the phase difference to zero at the end of the next measurement period. The change of control voltage can be directly translated to a change of frequency knowing the pull.

The point is, the frequency change is a fair measure of the frequency accuracy. The change is greater than the error, as it has to compensate for both the phase change and the frequency error. So if the changes are consistently below 4 parts in 10^-11 it is reasonable to suppose the frequency was more accurate. And it would be a strange OCXO that had short term fluctuations that just happened to average out over 1024 seconds every time. So I believe in this case the external reference is the GPS 1PPS signal itself and no local reference is required to have confidence in the GPSDO.

[JoeJoe2024]

Update to post my results......In case someone is also curious to see what this setup can achieve...
o23l-q327 OCXO + ublox m10 with window-side patch antenna...
Is this the expected performance?

Fix time 1031ms
Uptime: 000d 15:38:40
New GPS Fix:
Sats: 12 HDOP: 1.92
UTC Time: 01:41:31 Date: 24/12/2024

Voltages:
VctlPWM: 2.69V  PWM: 64881  OCXO disciplining: ACTIVE  Trend:  uf+

Vdd: 3.29V

Frequency measurements:
64-bit Counter: 563104742959
Frequency: 10 MHz
    10s Frequency Avg: 10000000.0 Hz
   100s Frequency Avg: 10000000.00 Hz
 1,000s Frequency Avg: 9999999.997 Hz
10,000s Frequency Avg: 10000000.0040 Hz
20,000s Frequency Avg: 10000000.00195 Hz

...............
The problem can be temprally fixed by using longer gps wait time as per pervious posts.....
............

Hi, Thanks for this great project!

I am new to this project, and I wired a prototype using minumum parts, i.e., GPS receiver, OXCO(DAPU O23L-Q327), and Bluepill, My firmware is 0.06c from github.
The fcount seems to work ok in warmup and calibration, with delta offtset near 10 Mhz. However, the reported delta values frequently jumps to 0, which distroy the f quene.
Any hints to solve this would be greatly appreciated！

Thanks！

Code: [Select]

fcount64 = (tim2overflowcounter << 32) + lsfcount; // hehe now we have a 64-bit counter
        Serial.print(F("Current Freq Offset:"));
        Serial.print( fcount64);
        Serial.print(F("   Previous Freq Offset:"));
        Serial.print( prevfcount64);
        Serial.print(F("   Delta:"));
        Serial.println(fcount64 - prevfcount64); 
        //Serial.println(fcount64 - prevfcount64);
        if (fcount64 > prevfcount64)