Yet another DIY GPSDO - yes, another one

[enut11]

@Johnny B Good. Thank you for your generous input. Your knowledge of OCXOs and GPS is way ahead of me. I am a novice here so am happy to take baby steps for the time being. That is why I was attracted to the apparent simplicity of @AndrewBNC's GPSDO. If I can get this to work, it may lead to other similar projects - who knows?

[Johnny B Good]

@Johnny B Good. Thank you for your generous input. Your knowledge of OCXOs and GPS is way ahead of me. I am a novice here so am happy to take baby steps for the time being. That is why I was attracted to the apparent simplicity of @AndrewBNC's GPSDO. If I can get this to work, it may lead to other similar projects - who knows?

 I was pretty much in that position about four and a half years back myself with regard to ocxos and gpsdos. You'd be surprised as to where even a vague fascination in "Electronics" (to give the subject its generic all encompassing label) will lead you to these days.

 I started with a one valve (vacuum tube) radio kit based on the DK91 (90v HT and 1.5v heater) that had been donated/sold to my dad by one of his workmates (probably an unwanted gift) when I think I must have only been 11 or 12 years old way back in the early sixties. As to whether I managed to get it working is now lost in the mists of time.

 However my one abiding memory of what had sparked off my interest in electronics is of a "child safe" 3 volt powered transistor based multiproject electronics kit I'd received as a Christmas present shortly thereafter which was based on a hardboard pegboard which used schematic overlay sheets with holes matching the pegs on the plastic mountings onto which the components had been soldered to spring clips allowing solderless assembly (an early form of plug in solderless breadboard if you will). ISTR it having 7 such schematic overlays all of which I tried out, inventing a few extra variations of my own into the bargain, mostly in the (fascinating to me) subject of wireless communication.

 Afterwards, I gained an (one might say unhealthy) interest in the technical section of my local library on the subject of electronics, specifically, transistor based material (well, there was much less risk of electrocution than that inherent in the more classic thermionic valve based technology). From then on, I was doomed to a lifelong interest in the rapidly evolving subject of electronics (audio amps opamps, simple logic, hybrid valve/transistor MF transmitters, audio magnetic tape technology, microprocessors (of the Z80 kind) and so on. I won't go into any more detail since this almost certainly echoes the experience of many, if not most of this forum's membership.

 Suffice to say that, despite my lifelong experience, I'd still had something new to learn when I strayed into this particular rabbit hole of metrology. I too had to take 'baby steps' when I moved onto upgrading the crappy 50MHz smd oscillator in my much modified Feeltech FY6600 arbitrary wave generator to a 50MHz 0,1ppm tcxo board that had been my first step onto this particular road to 'metrology madness' (the second step being the upgrade to an ocxo that I could frequency inject stabilise to an external 10MHz reference), followed of course, by an inevitable search for 'perfection' in the form of building gpsdos and purchasing a couple of rubidium oscillators.

 You can take this relatively short (by my standards) missive as a hint as to what you may be letting yourself in for with this recently acquired interest in this project. Don't say you haven't been warned.

 

[enut11]

@AndrewBCN,
I want to start building a second GPSDO and I have an STM32 type 401 (instead of type 411). Will this project work with a type 401? It will only be a basic setup with no options.
enut11

[AndrewBCN]

@AndrewBCN,
I want to start building a second GPSDO and I have an STM32 type 401 (instead of type 411). Will this project work with a type 401? It will only a basic setup with no options.
enut11

Short answer: yes it will work with a 401.
Long answer: read the source code. 

[caiser01]

I finally got around to designing a PCB for this GPSDO. It's functional so far but I know there are improvements that can be made, so I'm interested to read what people smarter than me may have to say about this design

Here's what I did:

• SMD design with mostly 1210 size components. So far in this thread, I've only see through-hole designs. I prefer SMD when possible so that's the path I took. I chose larger 1210 size components where possible so that people could easily hand solder if desired. However, I freely admit that I "cheated" and had PCBWay populate the SMD components when the boards were fabricated    The through hole parts are just connectors and test points except for the OCXO itself and the hex inverter (more on this later).
• Two 5V linear power regulators (1117): one for the OCXO and another for everything else. This was just me copying what I've seen some other people doing with having the OCXO supply separately regulated from the rest of the circuit. The power supply is also where I made my most serious goof. In my rush to get done and use up my expiring coupons at PCBWay, I forgot to add heatsink pours for the regulators. This isn't the end of the world but the regulator for the OCXO will get painfully hot to the touch if the input voltage is above 10V or so. In the 7.5V-9V range, the regulator is just "warm" so I'm just keeping my input voltage in that range for now. I've revised the PCBs to include heatsink pours 
• INA219 current monitor integrated on the board. I did this just because I feel like all the available breakout boards for this are a bit clunky. There is a jumper footprint inside the sense resistor footprint to allow you to jumper out this section if you don't plan on populating the INA219.
• MCP9808 temperature sensor. I added this to the bottom side of the board directly underneath the OCXO to give a good reading on how warm that area is getting. Since the rest of the sensors in the firmware use Adafruit libraries, I followed suit here making it pretty simple to integrate the new sensor into the code.
• Optional I2C pull-up resistors (R9, R10). My OLED display and AHT20/BMP280 breakout both have pull-ups integrated but in case someone else wasn't using such an arrangement, I've left this provision for adding separate I2C pull-ups.
• Three buffered outputs (10MHz square, 10MHz sine, 1PPS). I made the hex inverter a socketed through-hole part to make it easy to experiment with different logic families (more below).
• Header provisions for either (both?) an SPI or I2C type display.
• PCB form factor designed to fit the Hammond 1598 enclosure. This was to make things (hopefully) easier for me personally. People with the appropriate tools, skills, and time can likely do better.

Been testing this on and off for a week or so. It is functional as my breadboard version was.

Code: [Select]

Fix time 767mS
Uptime: 000d 04:40:25
New GPS Fix:
Lat: 38.XXXXXX Lon: -85.XXXXXX Alt: 191.5m
Sats: 12 HDOP: 0.65
UTC Time: 21:23:51 Date: 7/3/2024

Voltages:
VctlPWM: 1.82  PWM: 36064
Vcc: 5.00
Vdd: 3.30
OCXO voltage: 5.02V
OCXO current: 177mA

Frequency measurements using 64-bit counter:
64-bit Counter: 168163190756
Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1,000s Frequency Avg: 9999999.997 Hz
10,000s Frequency Avg: 9999999.9868 Hz
AHT10 Temperature: 27.63 *C
Humidity: 35.97% rH
MCP9808 Temperature: 35.94 *C

I do have one thing nagging me. There is a "twitch" in the 10 MHz square wave output that coincides with the occurrence of the 1PPS pulse:



The "twitch" phenomena mostly seems to impact the amplitude of the ringing at the edge transitions and not so much the edges' occurrence in time.

I'm buffering both the 10MHz OCXO output and the 1PPS GPS signal through different gates of the same hex Schmitt trigger inverter. Connections details in the attached schematic. Since I flagrantly lifted that part of the circuit from other people's designs in this thread, I was wondering if anyone else had observed the same thing?

The video above was taken with a CD74HC14 populated. Of the chips I have, this one has the least "twitch". The 74AC14 and SN74AHCT14 both had much more noticeable "twitch" (and lots more ringing at the transitions but I believe that's characteristic of those respective logic families). Maybe it's nothing to be concerned about but since the point of a GPSDO is to have a precise timing reference, I was concerned.

The sine output is not impacted by the "twitch", although it does pick up a fair amount of ringing noise from the square wave. Perhaps it would be better to separate the output signals into different ICs for buffering?

The board files are all up on my GitHub (haven't yet committed the change for the heatsinks) for folks to peruse along with the files attached to this post

https://github.com/caiser01/BlackPill-GPSDO

Feedback is welcome!

[caiser01]

Here's a more extreme close up of the "twitch":

[MIS42N]

I finally got around to designing a PCB for this GPSDO. It's functional so far but I know there are improvements that can be made, so I'm interested to read what people smarter than me may have to say about this design

Here's what I did:

• SMD design with mostly 1210 size components. So far in this thread, I've only see through-hole designs. I prefer SMD when possible so that's the path I took. I chose larger 1210 size components where possible so that people could easily hand solder if desired. However, I freely admit that I "cheated" and had PCBWay populate the SMD components when the boards were fabricated    The through hole parts are just connectors and test points except for the OCXO itself and the hex inverter (more on this later).
• Two 5V linear power regulators (1117): one for the OCXO and another for everything else. This was just me copying what I've seen some other people doing with having the OCXO supply separately regulated from the rest of the circuit. The power supply is also where I made my most serious goof. In my rush to get done and use up my expiring coupons at PCBWay, I forgot to add heatsink pours for the regulators. This isn't the end of the world but the regulator for the OCXO will get painfully hot to the touch if the input voltage is above 10V or so. In the 7.5V-9V range, the regulator is just "warm" so I'm just keeping my input voltage in that range for now. I've revised the PCBs to include heatsink pours 
• INA219 current monitor integrated on the board. I did this just because I feel like all the available breakout boards for this are a bit clunky. There is a jumper footprint inside the sense resistor footprint to allow you to jumper out this section if you don't plan on populating the INA219.
• MCP9808 temperature sensor. I added this to the bottom side of the board directly underneath the OCXO to give a good reading on how warm that area is getting. Since the rest of the sensors in the firmware use Adafruit libraries, I followed suit here making it pretty simple to integrate the new sensor into the code.
• Optional I2C pull-up resistors (R9, R10). My OLED display and AHT20/BMP280 breakout both have pull-ups integrated but in case someone else wasn't using such an arrangement, I've left this provision for adding separate I2C pull-ups.
• Three buffered outputs (10MHz square, 10MHz sine, 1PPS). I made the hex inverter a socketed through-hole part to make it easy to experiment with different logic families (more below).
• Header provisions for either (both?) an SPI or I2C type display.
• PCB form factor designed to fit the Hammond 1598 enclosure. This was to make things (hopefully) easier for me personally. People with the appropriate tools, skills, and time can likely do better.

Been testing this on and off for a week or so. It is functional as my breadboard version was.

Not smarter but been down this track a bit.

I went the dual supply route and used a buck converter to get the input to the regulators at 7V to reduce the heatsink problem. A tradeoff between heat control and flexibility of input voltage, and complexity. Technically, no heatsink was needed as the dissipation is less than 1W per regulator but little ones were added to keep temps in the touchable region. What I didn't do was take care to isolate the earth for the OCXO and the earth to the rest. They should share an earth only at the earths for the regulators. Because I didn't do that, relying on the earth layer to have insignificant resistance, plugging a load into the BNC altered the control voltage fractionally causing a frequency change (less than 1ppb and corrected after a few minutes but still something that should have been designed out).

I'd say the "twitch" as you describe it may also come from the shared earth of the inverter IC. It doesn't look like it affects the leading or trailing edges of the output, so may not be significant.

The ringing can be controlled by impedance matching. My design used 5 x inverter outputs each into 270 ohm resistors combined to give an approximate 50 ohm source. If it then went through 50 ohm coax to a 50 ohm terminated load the ringing was small. Unterminated, there was significant ringing. The signal was over 2V p-p which was rather more than needed. I was thinking to redesign with only two inverters (as you have) with a pair of 270 ohm to the BNC and an 82 ohm (I think that was the right standard value) across the BNC (to give some sort of load if the output is unterminated, and look like a 50 ohm source if terminated in 50 ohm). I was using 270 ohm to limit current if the BNC is accidentally short circuit. There's probably a place for a couple of small caps (a few pF) to damp any residual ringing, but outside my pay grade to bother working them out.

A good idea to design with a particular enclosure in mind. My first PCB didn't, I got negative feedback.

[enut11]

I built the Budget GPSDO designed by @MIS42N and found an improvement in performance by adding an additional voltage regulator for the GPS Rx.  That mod may also work for this project.
enut11

https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/msg5348666/#msg5348666
Reply #93

[caiser01]

I've been watching the "twitch" on and off over the last 6 hours, and it doesn't seem as though it's affecting the leading and trailing edges in time. For now, I'm not going to worry too much about it. I'm eager to collect some long term data on this thing and see what that tells me.

@MIS42N, your point about grounding is a good one. I do tend to take the lazy approach with big ground planes on top and bottom but a device such as this one probably deserves more careful consideration of the grounding. A star ground may be a good alteration for a future revision of this PCB. If someone's is looking for an interesting design challenge, these GPSDO's certainly seem to fit the bill. I appreciate you sharing your experience in this thread and in the one for your own design.

@enut11, interesting results there when separating the GPS receiver on a separate regulator. As you and others have shown, stabilizing the OCXO control voltage is critical.

My next step is to set up a long term test and collect data, data, data.

Of course, before I do that I have to get my workbench cleared of all the spring cleaning junk it's collected recently 

[AndrewBCN]

Hi caiser01,
First, thank you for sharing your wonderful PCB and implementation of the STM32 GPSDO project.
Regarding the ringing and "spikes" you are observing: ringing is mostly due to impedance mismatches and the fast rise/fall rates of modern digital logic gates. The spikes you have observed I believe are due to not enough capacitor decoupling and crosstalk between logic gates in the 74HC14 IC.
AFAIK one can somewhat mitigate these issues using various tricks, but I am not qualified enough so I defer to other people with more knowledge and experience.
However as you noted, these circuit noise issues don't seem to prevent the STM32 GPSDO from working decently enough.
Please keep us posted about your data collection and experimenting, these are the exact reasons I created this project.
Cheers and again, bravo.
Andrew

[zilvinasa]

Hi,

Thanks for the nice toy Andrew - can't stop playing with it!

Few points:

1. in Linux (found it by accident) once the chip in DFU mode (it can be triggered with one finger), I have 100% success flashing using the line:
            dfu-tool write GPSDO_V006c.ino.bin -d 0483:df11

I had mixed results with dfu-util with this Blackpill. While with the tinysa devices the dfu-util works ok. 

2. I have extremely poor sky view, but I got cheap ebay salvaged M8T module which handles the situation pretty well as far as I can see. Does anybody have played/have ubx magic strings to send to M8T to work optimally in limited sky view? (managing survey mode)

3. Andrew, are there any steps towards FreeRTOS? (I don't "pushing" for it)

Zilvis (LY2SS)

[AndrewBCN]

Hi,

Thanks for the nice toy Andrew - can't stop playing with it!

...

3. Andrew, are there any steps towards FreeRTOS? (I don't "pushing" for it)

Zilvis (LY2SS)

Hi Zilvis and thanks for your post. Glad you are playing with it, that is/was one of my objectives. Unfortunately I have not had the time to work on this or any other project for the last year, I am going through some difficult times  on many different aspects of my life.
So, no progress on moving the firmware to FreeRTOS. But still interested in doing it someday...

[thinkfat]

2. I have extremely poor sky view, but I got cheap ebay salvaged M8T module which handles the situation pretty well as far as I can see. Does anybody have played/have ubx magic strings to send to M8T to work optimally in limited sky view? (managing survey mode)

Have you done the survey-in for using the timing mode? U-Center would be a good help here. Apart from this, not much else you can do. You can play a little with the elevation mask and with the maximum number of SVs to use for time calculation, but in my experience, they're not really improving things when you have a limited sky view anyway.

[caiser01]

I still haven't managed to clear a space at home to set up my long term test but I have done some other tinkering to try and reduce the ringing on my square wave output.

I spent some time messing about with several different hex inverters, both CMOS and TTL, but ended up back with CD74HC14 as this had the lowest amplitude ringing of any of the CMOS parts. The TTL 74AS04 was slightly better but being TTL had the disadvantage of not being able to give a full 5V swing with the output loaded. After much research and experimentation, my ultimate solution was to bodge in a couple of 39pF shunt capacitors, one for each of the two paralleled outputs I'm using for the square wave. These shunt the higher frequency ringing to ground at the expense of rise/fall times, which I'm fine with for my use cases. It also eliminates the aforementioned "twitch" since that phenomena was only present in the ringing.

When terminated into 50 ohms, the square wave is looking pretty good I think. There's just a bit of overshoot in each transition, which could be eliminated by increasing the shunt capacitors to 43pF or 47pF. I happened to only have 39pF on hand and can live with the results. Going straight into the scope without termination the square wave output is only "square-ish" but again, good enough for me tinkering in the basement.

Of course, all of this is simply treating the symptoms and not the illness, which as others have pointed out is the impedance mismatch between the OCXO output and the first inverter input. The "real" fix for my design is either to move the hex inverter right next to the oscillator to reduce the length of the 10MHz track to virtually zero or control the impedance of the 10MHz track to eliminate the mismatch. It'd be a good learning experience to go through the design work for this but I've already gone a bit over budget on PCBs for this hobby project. I'm also not keen on ending up with a house full of "reject" board designs. I can be happy with what I have at this point and the files are on GitHub if someone else wants to take a crack at it.

I've found a small bug with the OLED display code today: When the date rolled over from 31/3/2024 to 1/4/2024, it came out as 1/4/20244. Picture below for proof but should be an easy fix; just need to add some spaces at the end of the date string to blank out the previous characters or left pad the month and day with zero to make them fixed length.

I've test fit the board into a Hammond 1598CBK and the fit is good. At this point, I just need to cut the holes for the connectors and the display. I'm also considering constructing a small insulated box for the OCXO to see if I can reduce its power consumption by keeping more of the heat inside. I have a bit of ceramic fiber insulation left over from a repair kit for my kitchen oven; might see what I can do with that.

But the big thing is still to get my damn workbench cleaned up so I can start a long term test with this thing.

[ABLI]

Hello, I measured the frequency of 10M using the stm32 module, but its accuracy is 9999999.49hz, which seems to be different from Andrew's. Why is that

[thinkfat]

What did you measure it with? What was the reference?

[ABLI]

I use 10m OCXO,and 1 pps

[daddioo]

thinkfat asked you what reference and resolution you use in the frequency meter, ES: to read the frequency of 10000000.00, you must have a reference resolution in the frequency meter at least .00 or higher, if you don't have a precise reference in the frequency meter you will continue to read the wrong frequencies.

[ABLI]

A resolution of.00 was taken by measuring a frequency reading of 100sA resolution of.00 was taken by measuring a frequency reading of 100s，

[AndrewBCN]

Hello ABLI,
Thank you for testing the STM32 GPSDO.
As far as I can see from your last comment, your OCXO and the GPSDO are working within specs, if you are using another instrument (for example a normal frequency meter) it is likely to be less accurate than the STM32 GPSDO itself.
10MHz +/- 0.003Hz is a rather good performance for a simple GPSDO design. 

[ABLI]

I am very glad that you can confirm my test result. I would like to ask whether the measurement method in the last reply is correct. Does the reference refer to another frequency counter?

[JLMa]

Hi guys

I've breadboarded Andrew's GPSDO and I'm trying to compile and upload the firmware to the STM32F411.

I manage to do it fine using an STLINK-V2, I'm using PlatformIO IDE not arduino ide.

platformio.ini file is :

Code: [Select]

; PlatformIO Project Configuration File
;

[env:blackpill_f411ce]
platform = ststm32
board = blackpill_f411ce
framework = arduino
debug_tool = stlink
upload_protocol = stlink
monitor_speed = 115200
monitor_dtr = 1

; Specifif build flags to get USB serial on the blackpill.
build_flags =
    -D PIO_FRAMEWORK_ARDUINO_ENABLE_CDC
    -D USBCON

lib_deps =
  # TinyGPSPLus : Gestion du module Neo 8m
  mikalhart/TinyGPSPlus @ ^1.0.3
  # Moving Average : lisser les mesures de capteurs.
  jchristensen/movingAvg @ ^2.3.1
  # SerialCommands : parsing/tokenizing library
  ppedro74/SerialCommands @ ^2.2.0
  # U8g2Lib : gestion de l'afficheur OLED
  olikraus/U8g2 @ ^2.34.13
  # Adafruit ST7735
  #--> Compile sans erreur ! adafruit/Adafruit ST7735 and ST7789 Library @ 1.6.0
  adafruit/Adafruit ST7735 and ST7789 Library @ ^1.10.0
  # Adafruit GFX
  #--> Compile sans erreur ! adafruit/Adafruit GFX Library @ 1.7.5
  adafruit/Adafruit GFX Library @ ^1.11.5

I'm facing this curious behaviour regarding USB connection... Once I connect the STM32 to my Linux box, the USB does not show in /dev - I'd expected something like /dev/ttyACM0 to be created when connecting the black pill to the linux box.
BUT nothing happens ! I do not even get any "New USB device found " at 'dmesg -w' on linux.

If I go in DFU mode (press and hold boot0, press and release NRST, release NRST), linux 'dmesg -w' shows device 0483:DF11 (the pill in DFU mode) has been connected,

I did try to flash some bootloaders (Weact HID, or the one by Roger Clark) but I still can't connect the pill to linux and get a proper USB device to connect a terminal windows in order to get the different messages that are Serial.printed by firmware...

Any clue ?
Thx in advance !

[JLMa]

Ive been testing around with just the blackpill board (disconnected from GPSDO circuit) and managed to have USB connection work.

Basically I connected the pill through STLINK-V2 to upload a simple counting code with output on Serial. Still connected through STLINK, if I connect USB-C port to the linux box, /dev/ttyACM0 is created and I can connect with PlatformIO Serial term and get the count generated by the uploaded code...

But again, if I connect the black pill through USB-C, nothing happens !?!

It puzzles me...

[AndrewBCN]

Hi guys

I've breadboarded Andrew's GPSDO and I'm trying to compile and upload the firmware to the STM32F411.

I manage to do it fine using an STLINK-V2, I'm using PlatformIO IDE not arduino ide.

platformio.ini file is :

Code: [Select]

; PlatformIO Project Configuration File
;

[env:blackpill_f411ce]
platform = ststm32
board = blackpill_f411ce
framework = arduino
debug_tool = stlink
upload_protocol = stlink
monitor_speed = 115200
monitor_dtr = 1

; Specifif build flags to get USB serial on the blackpill.
build_flags =
    -D PIO_FRAMEWORK_ARDUINO_ENABLE_CDC
    -D USBCON

lib_deps =
  # TinyGPSPLus : Gestion du module Neo 8m
  mikalhart/TinyGPSPlus @ ^1.0.3
  # Moving Average : lisser les mesures de capteurs.
  jchristensen/movingAvg @ ^2.3.1
  # SerialCommands : parsing/tokenizing library
  ppedro74/SerialCommands @ ^2.2.0
  # U8g2Lib : gestion de l'afficheur OLED
  olikraus/U8g2 @ ^2.34.13
  # Adafruit ST7735
  #--> Compile sans erreur ! adafruit/Adafruit ST7735 and ST7789 Library @ 1.6.0
  adafruit/Adafruit ST7735 and ST7789 Library @ ^1.10.0
  # Adafruit GFX
  #--> Compile sans erreur ! adafruit/Adafruit GFX Library @ 1.7.5
  adafruit/Adafruit GFX Library @ ^1.11.5

I'm facing this curious behaviour regarding USB connection... Once I connect the STM32 to my Linux box, the USB does not show in /dev - I'd expected something like /dev/ttyACM0 to be created when connecting the black pill to the linux box.
...

Yes, that is exactly the expected behavior.
And since your Linux kernel is not even detecting any USB device being connected, that would indicate there is a hardware problem, not a software one.
However your next post contradicts this:

Ive been testing around with just the blackpill board (disconnected from GPSDO circuit) and managed to have USB connection work.

Basically I connected the pill through STLINK-V2 to upload a simple counting code with output on Serial. Still connected through STLINK, if I connect USB-C port to the linux box, /dev/ttyACM0 is created and I can connect with PlatformIO Serial term and get the count generated by the uploaded code...

But again, if I connect the black pill through USB-C, nothing happens !?!

It puzzles me...

Very puzzling.
I have a few suggestions:
1. Try a different USB-C cable! Yes, this may seem like a strange suggestion, but I have had my share of problems with USB-C cables.
2. Try a different USB port on your PC, preferably a well-tested USB 2.0 port.
3. If you have Windows installed (yes, I know... yuck!), check and see what happens when you connect the Black Pill.
4. If you have a second Black Pill, try it.
5. Remember that the OCXO has a high power consumption during warm-up time, and if you are powering the entire GPSDO setup through the USB connection, this could cause a drop in the supply voltage and cause strange problems.
6. It could be a problem related to your power supply circuit, can you post more details about your breadboard build (a picture would very much be appreciated!).
Merci!

[JLMa]

Hi Andrew

USB-C cable issue... Just check the basics and it should work !

Sorry for the bandwith loss...
Jose