Yet another DIY GPSDO - yes, another one

[caiser01]

I just found this thread recently and decided to give this GPSDO design a try. I acquired an OSC5A2B02 OCXO, a Neo M8N, and a GPS antenna from AliExpress. The Black Pill I already had.

For fun and simplicity, I decided to build an absolutely bare bones, super lazy version of this GPSDO on a breadboard. Picture is attached. It is really is the simplest/laziest version I could put together. It has just the STM32 Black Pill, the Neo M8N module, the OCXO, and six passives. I didn't have any 22k resistors handy for the DAC so I changed it to use 10k resistors and 22uF caps (same time constant as 22k and 10uF). Also didn't have a 180 ohm resistor for the series resistor for the 10MHz so I used a 220 ohm instead. I didn't add any decoupling caps at all. Again, this is super low effort. I commented out most of the hardware options in the sketch (see attached screenshot).

So far, it seems to be working. The only possible issue I've noticed is the averages (10s, 100s, 1000s, 10000s) are always zero. Any ideas what might be happening there?

Back in the first few pages of this thread, someone was very concerned about needing a proper PCB and getting all the exact components, etc. I wanted to put this very minimal version together on a breadboard to show how simple it is to test out this project.

[MIS42N]

So far, it seems to be working.

I started out with a simple design (not this one) and it "worked". But it depends on what you mean by working. Unfortunately it is quite difficult to determine how well a GPSDO works, except by comparison with a better source. Which most people don't have.

I ended up with a more complex design isolating the OCXO with a separate supply and buffering the control voltage. A big improvement.

Of course, it depends on if you want the GPSDO for something, or just messing about. Even a messing about version tends to be more accurate than any standalone oscillator. And that is good enough for many people. I know my first design is being used as a standard by other people. They consider it "good enough".

[AndrewBCN]

I just found this thread recently and decided to give this GPSDO design a try. I acquired an OSC5A2B02 OCXO, a Neo M8N, and a GPS antenna from AliExpress. The Black Pill I already had.

For fun and simplicity, I decided to build an absolutely bare bones, super lazy version of this GPSDO on a breadboard. Picture is attached. It is really is the simplest/laziest version I could put together. It has just the STM32 Black Pill, the Neo M8N module, the OCXO, and six passives. I didn't have any 22k resistors handy for the DAC so I changed it to use 10k resistors and 22uF caps (same time constant as 22k and 10uF). Also didn't have a 180 ohm resistor for the series resistor for the 10MHz so I used a 220 ohm instead. I didn't add any decoupling caps at all. Again, this is super low effort. I commented out most of the hardware options in the sketch (see attached screenshot).

So far, it seems to be working. The only possible issue I've noticed is the averages (10s, 100s, 1000s, 10000s) are always zero. Any ideas what might be happening there?

Back in the first few pages of this thread, someone was very concerned about needing a proper PCB and getting all the exact components, etc. I wanted to put this very minimal version together on a breadboard to show how simple it is to test out this project.

Very nice minimalistic build, thanks for the pictures.

There is a problem somewhere because the OCXO frequency averages are not being calculated. This task is performed by function calcavg() in the code, once per second since it is called from the interrupt service routine that is triggered by the PPS from the GPS. I'll have to think about it for some time to get an idea about what could be causing this.

As you have proved, the STM32 GPSDO does not require a PCB and has quite good flexibility regarding the analog components values. I would still add at least a couple of decoupling capacitors around the OCXO.

[caiser01]

But it depends on what you mean by working.

I mean the firmware seems to be functioning (apart from the averaging) and the system as a whole seems to be doing what it's meant to do. Performance testing the system is another matter.

I ended up with a more complex design isolating the OCXO with a separate supply and buffering the control voltage. A big improvement.

I have read through the excellent notes you've posted in your own thread and found it all very educational!

Of course, it depends on if you want the GPSDO for something, or just messing about. Even a messing about version tends to be more accurate than any standalone oscillator. And that is good enough for many people. I know my first design is being used as a standard by other people. They consider it "good enough".

At this exact moment, I'm looking for "good enough". I just installed an ebay OCXO upgrade into my HP 53131A counter and I need a GPSDO to calibrate it. I think this will work sufficiently well for that purpose (for the moment at least). A bit later, I'd like to put a proper PCB together and blend some aspects of Andrew's design and yours to squeeze a bit more performance out. I'm not NIST, just a humble engineer looking to learn something and build myself a nifty tool in the process!

Very nice minimalistic build, thanks for the pictures.

There is a problem somewhere because the OCXO frequency averages are not being calculated. This task is performed by function calcavg() in the code, once per second since it is called from the interrupt service routine that is triggered by the PPS from the GPS. I'll have to think about it for some time to get an idea about what could be causing this.

As you have proved, the STM32 GPSDO does not require a PCB and has quite good flexibility regarding the analog components values. I would still add at least a couple of decoupling capacitors around the OCXO.

Thank you for the effort you've put in to date! I've been on the fence for a while about whether to pull the trigger on buying one of the Chinese ebay GPSDOs. But I much prefer the idea of open source design that can be tweaked to one's specific needs and can incorporate lessons learned from everyone else's experience.

And of course, when I get around to making a PCB, there will be plenty of decoupling caps 

Shortly after my post yesterday, I transferred the GPSDO to the basement and hooked it up to my HP 53131A. Both the GPSDO and the counter are connected up to a Raspberry Pi so I can check on them remotely. Pics attached. The 53131A is taking frequency measurements of the GPSDO with a 10-second gate time.

And yes, a scope probe may not be the best way to attach the GPSDO to the counter and I've looked into better ways (https://www.sitime.com/support/resource-library/application-notes/an10028-probing-oscillator-output).

At the end of the week, after everything has calmed down, I'll run through the calibration for the HP 53131A.

[AndrewBCN]

Again, I cannot thank you enough for this "minimalistic" build. It's great to see that with a reduced set of components one can still get a GPSDO that can be used as a frequency reference.

However, I still think there is a problem with your build, probably a very small detail that is preventing the GPSDO from working as it should. Are you certain the OCXO is getting effectively "disciplined" ? What I mean by this, is the PWM DAC voltage varying at all? The "disciplining" depends on the average frequency calculations and these don't seem to be happening. So I would guess the OCXO is not getting disciplined, in other words, the GPSDO is not working. Could you perhaps check the PPS pulse from the GPS with your scope, at the B10 pin on the BlackPill? Also there are a few lines in the code in the frequency reporting routine that I had used for debugging and then commented out, but they are still there. Perhaps uncommenting them and recompiling/reflashing the MCU would shed some light on the issue, if it's not too much work?

[caiser01]

AndrewBCN, to start with I checked the 1PPS signal and it is definitely there.

Next, I started monitoring Vctl with my 6.5-digit DMM and it does indeed seem to be varying, so the PWM is doing something. Here is some example data. I'm not sure if this is varying too much or not enough. This is sampling about once per second:

Code: [Select]

1.8132967
1.8132742
1.8132219
1.8132194
1.8132643
1.8132418
1.8132917
1.8132992
1.8133116
1.8132169
1.8132593
1.8132692
1.8132393
1.8132568
1.8132817
1.8132842
1.8132169
1.8132593
1.8132269
1.8131371
1.8132443
1.8132368
1.8132343
1.8132219
1.8131795
1.8132293
1.8131895
1.8131895
1.8132618
1.8132842
1.8132792
1.8132169
1.8132742
1.8131620
1.8131720
1.8132368
1.8132493
1.8132443
1.8132393
1.8132593
1.8132119
1.8132044

Finally, I looked for your debugging code and I think I uncommented all of it. Here is the output I'm getting now:

Code: [Select]

Fix time 994mS
Uptime: 000d 00:18:49
New GPS Fix:
Lat: 38.XXXXXX Lon: -85.XXXXXX Alt: 188.7m
Sats: 7 HDOP: 1.31
UTC Time: 15:35:05 Date: 30/8/2023

Voltages:
VctlPWM: 1.86  PWM: 38229
Vdd: 3.27

Frequency measurements using 64-bit counter:
TIM4 ARR: 47999
TIM4 ch4 CCR: 28000
Most Significant 32 bits (OverflowCounter): 1
Least Significant 32 bits (TIM2->CCR3): 2622916214
64-bit Counter: 6897883510
Frequency: 10000000 Hz
10s Frequency Avg: 0.0 Hz
100s Frequency Avg: 0.00 Hz
1,000s Frequency Avg: 0.000 Hz
10,000s Frequency Avg: 0.0000 Hz

Something else worthy of note: When the micro is reset, the first couple blobs of status output DO show a non-zero value for the 10s average but then it goes back to zero. One time, I also observed a non-zero value for the 10s average after the thing had been running for several hours but it went right back to zero on the next output.

I've checked the schematic to see if I may have missed any connections and I'm continuing to check the breadboard, but so far haven't seen my mistake if it's there.

Appreciate your help!

[AndrewBCN]

Thank you for the debugging ! An important question: do you see the 64-bit counter increasing by 10 million every second? If you do, that essentially means the OCXO is working and the MCU is correctly counting the OCXO oscillations, which is the basis for the frequency calculations.

If you do indeed see the 64-bit counter increasing by 10 million per second, then I suspect you have found a bug lurking in my code and I'll try to reproduce your build here at home and check whether I have the same problem of missing frequency averages. It's highly likely that I should get exactly the same problem. And then I can start looking for the bug.

Fascinating! In any case, thank you for the build and for launching this investigation. 

Just a note: did you check the +5V fed to the OCXO? 

[caiser01]

Thank you for the debugging ! An important question: do you see the 64-bit counter increasing by 10 million every second?

It sure is increasing by 10e6 each second, so that part at least is working.

Just a note: did you check the +5V fed to the OCXO? 

Doh! Good catch! The 5V rail was sitting at about 4.6V. I have it hooked it up to my bench supply now and it's measuring a solid 5V. That's dropped Vctl down to about 1.78V and the output frequency as read by my (still uncalibrated) frequency counter with OCXO timebase is sitting pretty stable at 10000000.912n. Last digit is still slowly wandering by a few 100 micro-Hertz. Even with a possible bug in the code, this still pretty neat! 

[caiser01]

Progress! Averaging is now working!

What I had to do was uncomment a compiler define for a screen. I initially tried enabling GPSDO_OLED, which seemed to sort of working but slowed the serial output down to once every 30 seconds to 1 minute. Not really useable but the averaging did seem to be working. So then I tried disabling GPSDO_OLED and enabling GPSDO_LCD_ST7735. Bingo! Serial update rate is back to once per second and averaging is now working.

Let me just be clear, I did NOT actually connect an LCD. I haven't changed anything from my initial breadboard layout. I just turned on the compiler define for the ST7735 LCD. So it seems maybe there is an issue where averaging isn't working unless one of the LCD or OLED defines is enabled.

With averaging working, I'm observing that the GPSDO seems to be steering the OCXO frequency more noticeably. Things are looking better!

[AndrewBCN]

Well done! 
This proves you have really found a bug in my code. It seems that when the main loop loops too fast, the GPSWaitFix() function concludes (erroneously) that the GPS fix was lost and clears the averaging buffers. 
Or at least that's my analysis for now. 

I am still putting together a minimal build to further debug this issue, but your workaround should work for now and you should be getting a more precise "disciplined" 10 MHz reference frequency.

[AndrewBCN]

Minimal build assembled and powered, and lo and behold, as expected, all the frequency averages are zeroed. 
I'll be debugging the problem in the coming days. 

[thinkfat]

Well done! 
This proves you have really found a bug in my code. It seems that when the main loop loops too fast, the GPSWaitFix() function concludes (erroneously) that the GPS fix was lost and clears the averaging buffers. 
Or at least that's my analysis for now. 

I am still putting together a minimal build to further debug this issue, but your workaround should work for now and you should be getting a more precise "disciplined" 10 MHz reference frequency.

Hehe, let me guess: you rely on counters for timekeeping instead of a constant timer tick

[AndrewBCN]

I have sort of confirmed my earlier hunch about the bug being triggered by the main loop looping too fast.
I have compiled a debug version of the GPSDO firmware with a

Code: [Select]

delay(200);single extra line in the main loop. This wastes 200ms inside the main loop.
As expected, the minimal GPSDO now correctly calculates and reports the average frequencies.

But that's not solving the bug, which clearly lies inside the gpsWaitFix() subroutine. I think I'll have to take a good look at gpsWaitFix() and perhaps rewrite it.  (meaning this will take some time)

Apart from that, since the temperatures here in France are exceptionally high, I have not managed to enter DFU mode on my various Black Pills, so I am using and recommend a clone or original ST-LINK V2 adapter (around $5) to flash the STM32F411CEU6 Black Pills used in this project. This works like a charm, irrespective of ambient temperature. See picture below.

[caiser01]

I think I'll have to take a good look at gpsWaitFix() and perhaps rewrite it.  (meaning this will take some time)

Appreciate you working on it!

Apart from that, since the temperatures here in France are exceptionally high, I have not managed to enter DFU mode on my various Black Pills, so I am using and recommend a clone or original ST-LINK V2 adapter (around $5) to flash the STM32F411CEU6 Black Pills used in this project. This works like a charm, irrespective of ambient temperature. See picture below.

I flashed WeAct's custom version of the STM32 HID bootloader to my Black Pill a long time ago.

https://github.com/WeActStudio/STM32_HID_Bootloader/releases/tag/2.2.2

You have to hold down KEY while pressing NRST to start the bootloader before pressing Upload in Arduino IDE, but it saves me having to worry about how warm the room is and it means I don't need STM32CubeProgrammer installed.

[AndrewBCN]

Hi everybody,
Just a quick progress report. So after examining the code for the gpsWaitFix() subroutine and the main loop, I have decided to completely rewrite both, and that actually means rewriting two of the most important functions in the STM32 GPSDO firmware.
And I realized that I had a very serious problem, because I am trying to read and parse the messages from the u-blox GPS module while juggling all the other tasks that are required by the GPSDO, such as displaying the status on various displays, reading the sensors, and transmitting a status report over USB serial every second.
I revisited the FreeRTOS webpage and noticed there is now an STM32duino version of FreeRTOS, meaning it is possible to use the FreeRTOS constructs in an Arduino sketch for the STM32 series of MCUs.
FreeRTOS implements tasks, a scheduler, semaphores, etc and enables the programming of multiple threads on an MCU.

Short story long, the STM32 GPSDO firmware is going multi-threaded and I will be having a lot of fun while rewriting a good part of the STM32 GPSDO firmware using FreeRTOS. So that's what's in the pipeline for firmware version 0.07a. I expect this to take at least a couple of months if not longer, and if anyone wants to join in the fun, please do!

The first step is to reorganize the main loop() and gpsWaitFix() functions into various tasks and schedule these tasks correctly, and also determine how these tasks are triggered, etc.

A final note: I have switched from the "old" Arduino IDE 1.8.13 to the "new" Arduino IDE 2.2.1 as my main development tool for the STM32 GPSDO firmware and it is working 100% fine. Also I am using an ST-LINK V2 clone to flash the STM32F411CEU6 Black Pill, as I found it more reliable (but unfortunately slightly less practical) than the DFU method.

[iMo]

FYI- stm32duino supported the FreeRtos some ~7-8years back already..
https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/STM32F1/libraries

[caiser01]

This is another option you may want to look at in comparison to FreeRTOS:

https://github.com/arkhipenko/TaskScheduler

It may be simpler to use than FreeRTOS. Unless, of course, you just really want to learn FreeRTOS, which is okay too!

[thinkfat]

Short story long, the STM32 GPSDO firmware is going multi-threaded and I will be having a lot of fun while rewriting a good part of the STM32 GPSDO firmware using FreeRTOS. So that's what's in the pipeline for firmware version 0.07a. I expect this to take at least a couple of months if not longer, and if anyone wants to join in the fun, please do!

Welcome to a world of hurt.

[vindoline]

Thanks to Andrew for this great project! I wanted to share my build. For my use case, I need the GPSDO in a more permanent, rugged box. I designed a PCB to fit a common 100 x 76 x 35mm project box that I use.

The OCXO I used is the OSC5A2B02 that rhb brought to my attention in https://www.eevblog.com/forum/metrology/low-cost-lt1-ppb-10-mhz-oxcos-on-ebay/

The end plates of the enclosure are replaced with custom PCB panels with cut-outs for the BNC jacks, OLED display, antenna, etc.

The trickiest part was fitting in the OLED display. There is just barely enough room to fit it in. I used small black nylon nuts and bolts to mount the display to the front PCB panel.

In the end, I was very happy with how the build turned out!

I've put the Diptrace design files and the gerbers up on Github: https://github.com/vindoline/STM32-GPSDO_build

[AndrewBCN]

Thank you very much and congratulations, vindoline, this is an absolutely gorgeous build. 
I am working again on the firmware these days, hopefully it will upgrade the performance of the GPSDO even further when it is ready! 

[kff]

Andrew -- cool project. I have all the components on order from AliExpress and will try to put everything together in the next few weeks.

I wanted to chime in regarding your planned switch to FreeRTOS. I would personally try to avoid that, as concurrent execution can be its own can of worms. It's easy to introduce subtle non-deterministic bugs in threaded code, and debugging that code can be hard.

Instead, have you thought about making your gpsWaitFix() function non-blocking? You could essentially call it with every iteration and let it process whatever bytes are available. You could rename the function to gpsProcessData() and return true when a gps fix is available. The main loop could then keep track of how long it has been since gps updated and act accordingly. Something along the lines of:

Code: [Select]


bool processGpsData() {
  if (!Serial1.available()) return false;
   while (Serial1.available() > 0)
    {
      GPSchar = Serial1.read();
      gps.encode(GPSchar);
      ...
    }
    return (gps.location.isUpdated() && gps.altitude.isUpdated() && gps.date.isUpdated());
}


and in your main loop

Code: [Select]

if (gpsProcessData()) {
  // Got a new fix, handle it
  ...
  gpsStartFix = millis();
} else {
  if (millis() - gpsStartFix > gpsWaitTimeMs) {
    // Handle missing fix
  }
}

Again, the point is to make GPS reception non-blocking, which should hopefully make the main loop easier to reason about. You could make similar changes to other parts of your code, such as sending out USB reports (i.e. you could pre-populate a buffer with the data that you need to send and only transfer as much per iteration as availableForWrite() allows).

Does this make sense, or did I misunderstand the nature of the issues that you are having with the current code?

Hi everybody,
Just a quick progress report. So after examining the code for the gpsWaitFix() subroutine and the main loop, I have decided to completely rewrite both, and that actually means rewriting two of the most important functions in the STM32 GPSDO firmware.
And I realized that I had a very serious problem, because I am trying to read and parse the messages from the u-blox GPS module while juggling all the other tasks that are required by the GPSDO, such as displaying the status on various displays, reading the sensors, and transmitting a status report over USB serial every second.
I revisited the FreeRTOS webpage and noticed there is now an STM32duino version of FreeRTOS, meaning it is possible to use the FreeRTOS constructs in an Arduino sketch for the STM32 series of MCUs.
FreeRTOS implements tasks, a scheduler, semaphores, etc and enables the programming of multiple threads on an MCU.

Short story long, the STM32 GPSDO firmware is going multi-threaded and I will be having a lot of fun while rewriting a good part of the STM32 GPSDO firmware using FreeRTOS. So that's what's in the pipeline for firmware version 0.07a. I expect this to take at least a couple of months if not longer, and if anyone wants to join in the fun, please do!

The first step is to reorganize the main loop() and gpsWaitFix() functions into various tasks and schedule these tasks correctly, and also determine how these tasks are triggered, etc.

A final note: I have switched from the "old" Arduino IDE 1.8.13 to the "new" Arduino IDE 2.2.1 as my main development tool for the STM32 GPSDO firmware and it is working 100% fine. Also I am using an ST-LINK V2 clone to flash the STM32F411CEU6 Black Pill, as I found it more reliable (but unfortunately slightly less practical) than the DFU method.

[Solder_Junkie]

Really neat construction Vindoline! Have you guys run comparisons between one of these very simple GPSDOs and something like a rubidium? I have a James Miller Simple GPSDO (http://www.jrmiller.online/projects/ministd/manual.pdf), A Leo Bodnar GPSDO (https://www.leobodnar.com) and a Murray Greenman one (https://www.qsl.net/zl1bpu/PROJ/NGPSDO/New%20GPSDO.htm).

The latter was described at great length on this forum, mostly in the Lars Walenius version that it is based on.

While any of them work reasonably well, by using a really good oven and a timing GPS module, the short term stability can be significantly improved. My own Murray Greenman GPSDO with an NEC oven oscillator and a UBlox Neo M8T module, has up to ten times less short term "jitter" than either of the other two, as measured with a phase frequency analyser and a rubidium oscillator. Most of the measurements I see on the web relate to longer term Allan Deviation, I am more interested in the short term stability as mine is used to control amateur radio transceivers and frequency counters.

The Lars or Murray GPSDO is still pretty simple to make...

SJ

[AndrewBCN]

Thanks for the numerous and excellent suggestions, kff, I still have to set aside a few hourss to go through the code, but unfortunately other matters have higher priority these days. I'll certainly look into your code fix for the GPSWaitFix() function, and I agree that it is much simpler than a switch to FreeRTOS. 

[vintageradiobuff]

I found this thread a few weeks ago and have read most of the 36 pages of it. I just got all the bits and pieces and finished bread-boarding it this afternoon. I have run into a problem though. When it is turned on, it goes through the OCXO warmup routine and starts the initial calibration, but then it is stuck on the "Calibrating... please wait" screen interminably. The GPS receiver achieves satellite lock (as evidenced by the LED pulsing once per second and I do have a 1PPS signal when checking on the oscilloscope. I bought the Neo M8N on Aliexpress, but it actually appears to be an M7 labelled as an M8N (both windows and u-center identify it as M7). Could this be the problem? Does the Arduino code for the M8 not work on an M7? if that is not the problem, what else could it be?

[Solder_Junkie]

Regarding Chinese copy fake Ublox modules. I bought a cheap board from eBay which was advertised is “Ublox Neo-M7N”, there was a sticker on the module pretending it was a Ublox Neo-M8N… U-Center reported it as a 7.

As the board suited my purpose, I removed the fake and bought a genuine M8T (the timing version of an M8) from Mouser… not cheap! Removing one of these fakes needs care. Soldering a replacement is easy once you have the fake off the board.

Whether it is worth the effort depends on how deep your pockets are. The difference between the two types is shown in the attached image. The board used in the comparison uses a Chinese copy Neo-M6, which had identical performance to the M7N that was removed.

I setup my modules using U-Center, not via the software commands discussed in this thread.

The setup is:

Lars Wilenius GPSDO with an NEC Toyocom TCO-6703N 10 MHz ovened osc.

Antenna is a roof mounted “mushroom” type.

The M6 uses only GPS satellites, the M8T is configured for fixed location with SBAS turned off, GPS and Galileo satellites both used together.

TinyPFA phase frequency analyser connected to TimeLab software. These are low cost instruments based on the TinyVNA H4 (only difference is user swappable firmware), with a noise floor around 10^13, costing 65 GBP plus postage (https://www.mirfield-electronics.co.uk/).

The  comparison oscillator is a rubidium fed into the B input of the PFA.

The magenta trace is using an M8T, the blue is with a fake M6. Longer loop times reduce the frequency excursions, but you see the difference easily with 60 second timing and some averaging in TimeLab.

SJ