Yet another DIY GPSDO - yes, another one

[danieljw]

Thankyou Jaroslaw!

ST7789V 2.8" WeAct is working well in my setup, looking forward to ili9488 4"

Really appreciate your efforts so far, this really is awesome

- Dan

[jmnlabs]

Thanks to everyone who's flashed v0.91 and sent feedback — a revision is up with fixes that came directly from real hardware other than mine. Special thanks to danieljw and lucido, whose testing and photos drove most of what's below.
Calibration now adapts to different detectors and oscillators. danieljw ran this against a Rubidium reference — the kind of stable external clock that makes these problems measurable — and hit two false rejections, both from sanity checks that were quietly tuned to my hardware:

CT rejected narrow-span EFC oscillators. A smaller Hz/LSB is desirable — it's finer resolution and one route to E-12 stability — but the check floored K at 0.1 mHz/LSB. His build measures 0.048 mHz/LSB and was wrongly refused. Lowered to 0.02 mHz/LSB; only genuine noise / no-GPS runs are now rejected.
LC anchored the calibration to a fixed 1.85 V, which is where my detector's ramp happens to sit. Builds whose ramp sweeps a different band (danieljw's runs lower, ~1.3 V) missed the anchor window and fell back to a coarse average ("weak result"). The anchor is now the measured midpoint of each run's ramp, so LC self-adapts per board.

Serial report now shows derived phase in ns after Vphase: once LC has calibrated, using the measured slope relative to zero_offset.
ILI9488 (480×320) layout, from danieljw's and lucido's photos: the body font was over-scaled (mapped 2→4, growing faster than the rows, so lines overran and the status bar was pushed off-screen) — body font kept at 2; the BMP sensor row was trimmed to fit the wider glyphs; and the User_Setup.h instructions were missing LOAD_FONT8, which the frequency readout requires.
A caveat on the ILI9488 work: I don't have that panel on hand — every 480×320 change here was made from lucido's and danieljw's photographs, so treat that screen as experimental. A proper geometry pass will follow once I have one. The 320×240 panels are unaffected.
Thanks again danieljw and lucido — a Rubidium-referenced measurement and photos from a different panel are exactly the kind of testing that surfaces assumptions baked into a single build. Much appreciated.
Download: GitHub — https://github.com/jmnlabs/GPSDO_FreeRTOS (latest release), and I've attached the package below for anyone who'd rather not use GitHub.


Best regards,

Jaroslaw

[lucido]

Hi Jaroslaw.

For the 9488 display, it's a little better, but still not perfect. I'm testing algorithm 10.
lucido

[jmnlabs]

Hi lucido,

Thanks for testing! Looking at your screenshot, I see a couple of things that concern me:
Vph: 3.299V — this is right at the ADC rail (3.3V), which means the phase detector is saturated at the upper limit.
Algo: 10 ACQ — the loop is still in ACQuisition mode and hasn't progressed to DPLL/LOCK.
Before we tweak the display layout further, I need to ask:
Do you have the LTIC (TIC) hardware built and connected in your test setup? The LTIC phase input is on PA1 and needs the actual TIC circuit (picDIV + phase detector) to work properly.
Have you run the LC calibration command? This is critical for algorithm 10. The LC command measures your detector's ns/V slope and operating point. Without it, the loop can't properly interpret the phase voltage.
If you don't have LTIC hardware yet, algorithm 10 won't work correctly — it needs the actual TIC measurements. In that case, you might want to test with algorithm 7 or 8 first.
Also, with Vph pinned at 3.299V, the detector might be in the wrong direction or the polarity might need adjustment (LPOL command).
Let me know what hardware you have connected and whether you've run LC!

Best regards,
Jarosław

[lucido]

Hi Jaroslaw.

THANKS FOR YOUR REPLY. Yes, I have the LTIC and the PIC DIV. This is a problem with the VPH: 3.299V high. During calibration, the VPH drops, but then eventually goes back high. Algorithm 8 works without problems. I think I have a hardware problem somewhere. I need to check better.

lucido

[jmnlabs]

Hi lucido,

I'm attaching photos of my hardware setup to the forum — you can see the picDIV and LTIC circuit on the small prototype board on the side.
Could you please share your hardware schematic/configuration, especially the picDIV and LTIC wiring? I'd like to compare our setups.
Also, a few questions about your OCXO:
What is the tuning range of your OCXO? (Hz/V or total span)
At what control voltage does your OCXO output exactly 10 MHz?
Did you ever achieve a stable 10000000.0000 Hz reading with algorithm 7 (or any other algorithm)?
Something doesn't add up in your case. On my bench, I typically achieve LOCK within 5 to 7 minutes. With your current uptime, you should have reached LOCK long ago. Looking at my screen (v0.91-rtos), after the loop locks I'm at:
Algo: 10 LOCK
Frequency: 10000000.0001 Hz (green = locked)
Vph: 1.789V, -68ns (very close to the calibrated zero_offset of 1.85V)
PWM: 40930, Vctl: 1.804V
The loop is working correctly and holding lock. If you're still stuck in ACQ or seeing Vph railed after this much time, there's likely a hardware issue — either:
The LTIC phase detector isn't connected/powered correctly
The picDIV isn't receiving the 1PPS sync properly
The OCXO tuning range/polarity doesn't match what the loop expects
Please share your schematic and let me know what frequency you're actually measuring. That will help me spot the issue.

Best regards,

Jarosław

[lucido]

Hi Jaroslaw.

A clarification: I gave the CT and then LC commands. The vph slowly dropped, and algorithm 10 started working, LOCKing.
So it's not a hardware problem. However, tomorrow I'm thinking of adding some bypass capacitors to improve stability.
I'm attaching the diagram I'm referring to.

[jmnlabs]

Hi lucido,

Great news! I'm glad to hear that after running CT and LC, algorithm 10 finally locked and everything is working properly. The screenshot looks much better now — green frequency, LOCK state, and Vph at a reasonable 2.583V. 👍
And yes, you're absolutely right — it wasn't a hardware problem after all! Sometimes the solution is just a couple of CLI commands away. 😊
You know, the README and CHANGELOG are like a good map — they won't do the hiking for you, but they sure help you find the trail faster. Though I admit, with all the updates and features, the CHANGELOG has grown into quite the novel! Maybe I should start writing it in larger font... 😄
Adding bypass capacitors is never a bad idea for stability, so that's a good plan.
Enjoy your locked GPSDO, and feel free to ask anytime — documentation or not, I'm always happy to help!

Best regards,

Jaroslaw

[Renate]

I can see that you've done a lot of work here. The multiple display options does make things a bit more complicated. Have you ever thought of integrating this with an emulator? Then you could test and layout out arbitrary displays more easily. Yeah, I know that's a bit of work. I've done it for a separate project that used 128 x 64 OLED. It was helpful and it makes "screenshots" easier.

Sorry, I still hate seven segment on raster displays.

[jmnlabs]

Hi Renate,

Thanks for the kind words and the suggestions!
Regarding the emulator: I totally see the value in having a PC-based emulator for laying out the UI and taking screenshots without touching the hardware. However, considering this is a hobby project and the codebase is already quite large, writing a full emulator would be a massive undertaking on its own. I'll stick to testing on the actual hardware for now, but it's definitely an interesting idea for the future.
As for the "seven segment on raster displays" — I completely understand your point! Using blocky 7-segment fonts on a high-res pixel screen can look a bit out of place if overused. The reason I use it for the main frequency readout (e.g., 10000000.000 Hz) is purely cosmetic: I wanted the GPSDO to look and feel like a classic, professional lab frequency counter when it's locked. For the rest of the telemetry data (sensors, GPS status, etc.), I stick to standard proportional fonts to keep it clean and readable.
Thanks again for the feedback!

Best regards,

Jarosław

[Renate]

I mean, you can just write a stub in C[++] that uses a subset of your current source files.
You just set the state of the device then hook the SPI/I²C routines to generate graphics.

(I mean, as long as you're doing Claude, why not ask it?)

[jmnlabs]

Hi Renate,

You're absolutely right about the technical approach — writing a C/C++ stub and hooking the SPI/I²C routines to generate graphics is exactly how a display emulator is built. The technical feasibility isn't the issue.
However, this thread is about a hardware GPSDO — disciplining a real OCXO with real GPS 1PPS, real TIC measurements, and real LTIC calibration. Writing a PC emulator would be an entirely separate project (desktop software), which diverges from the core purpose of this discussion.
As for Claude — yes, I use it extensively as a programming assistant, and I'm quite open about it in the project's README. It helps me handle the heavy lifting of the embedded firmware, which leaves me more time to focus on the actual hardware, algorithm design, and bench testing. If I were to use it to write a PC-side emulator, I'd still have to maintain, debug, and integrate it, which is time I'd rather spend on the GPSDO itself.
My workflow is working well: I test on the actual GPSDO hardware, verify against real GPS signals, and iterate based on bench measurements. Let's keep the focus on the GPSDO itself — algorithms, calibration, hardware design, and real-world performance. If someone wants to write a simulator as a side project, they're welcome to, but it's not something I'll be prioritizing here.

Best regards,

Jarosław

[jmnlabs]

GPSDO-FreeRTOS v0.93-rtos — ILI9488 display received, firmware nearly complete

Hi everyone,

Good news — the ILI9488 display has arrived and is working well with the latest firmware!
I'm currently running v0.93-rtos with the LTIC 3-stage PLL (Algorithm 10), and the system is holding lock nicely. The display layout has been adjusted for the 480×320 resolution, and all the key telemetry is showing correctly (frequency, PWM/Vctl, GPS status, sensors, Vphase, and qErr correction).
Current status:
Firmware is nearly complete — just a few more essential tests to run
Documentation needs final cleanup and organization
If everything passes validation, I'll upload the source files to both the forum and GitHub this evening (Polish time, CET/CEST)
The changes from v0.91 include:
Full ILI9488 support with optimized layout
Minor bug fixes and stability improvements
Updated documentation
Thanks to everyone who provided feedback and test data during development — especially Dan Wiering for the Rb-referenced traces and all the bench testing.
Stay tuned for the release later today!

Best regards,

Jaroslaw

[jmnlabs]

Hi everyone,

I’ve just pushed v0.94-rtos to GitHub, and I know a few of you have been waiting for full support for the large TFT displays, so here it is!
A quick hardware story: I actually received an ILI9486 instead of the ILI9488 I ordered. To make matters worse, the panel has a defect — the right edge of the screen is completely dead. However, I didn't want to wait for a replacement or deal with a return, so I just made it work with what I had. If the layout looks slightly shifted in my photos, that's why!
Current status and future plans:
The firmware is now essentially feature-complete. I don't plan to add any new functionalities for the foreseeable future. From now on, my sole focus is on bug hunting and stability. If you spot any issues, weird behaviors, or edge cases, your feedback and logs are highly welcome!
My biggest hope is that integrating the large TFT support didn't break anything in the highly refined v0.91 codebase.
And a minor hardware casualty...
During the final testing, I managed to yank the entire prototype board off the desk with the programmer cable. It survived, but the OCXO is now drifting at a wild, uncontrollable rate. Fortunately, these OCXOs are cheap, and I have spares, so it's just a minor inconvenience and a good reminder to secure the cables!
You can find the source code on GitHub here:
🔗 https://github.com/jmnlabs/GPSDO_FreeRTOS
Attachments to this post:
v0.94-rtos: Full source code (for those who prefer not to use GitHub 😉).
v0.91-rtos: Stable fallback version (without large TFT support) in case you run into any regressions with the new release.
Thanks again to everyone who tested, provided feedback, and waited for this update. Let the bug hunting begin!

Best regards,

Jarosław

[lucido]

Thank you so much Jarosław, I'll upload the new firmware to the STM32 and test everything.

lucido

[jmnlabs]

Hi everyone,

A quick update following my previous post about yanking the prototype off the desk with the programmer cable.
Mercifully, the OCXO's drift has decreased significantly after the fall, and I'm now getting a beautiful, rock-solid lock on Algorithm 10 with the v0.94-rtos firmware! As you can see in the attached photo, the loop is holding perfectly (Vph: 1.865 V, dPh: +27ns), and the ILI9486 display is rendering the new layout nicely (despite the dead right edge of the panel).
However, this whole exercise confirmed what I already suspected: these small, cheap OCXOs just have too much inherent drift for a high-performance GPSDO.
So, the next phase of the project is clear: designing a dedicated PCB for a proper oven-controlled oscillator. I actually have both the Trimble 34310-T2 and the NAVICOM NOX038663XS on hand, and I want to utilize them in the new design. The NAVICOM has a universal footprint, which makes it an attractive option.
Quick question for the community: Does anyone know if the NAVICOM NOX038663XS is perhaps a rebranded Oscilloquartz 8663-XS? The part numbers look suspiciously similar.
If anyone here has experience with these specific OCXOs, their EFC characteristics, or specific PCB layout requirements (thermal isolation, power supply filtering, etc.), I'd love to hear your thoughts before I start routing the board.

Best regards,

Jarosław

[lucido]

Hi Jarosław.
Version 0.94 seems to be working. Sorry for the delay in responding, but everything shut down and I had to restart the GPSDO. The only thing I noticed was that some blue text appeared quickly at the top and then disappeared.

lucido.

[MIS42N]

However, this whole exercise confirmed what I already suspected: these small, cheap OCXOs just have too much inherent drift for a high-performance GPSDO.

The cheap OCXOs require a long settling time to be stable, I let them run a week before deciding if they are any good. Many years ago I worked in a Standards laboratory, the OCXO providing the reference signal was run for four months before its drift minimised. It then had a very consistent small drift. Almost all OCXO will drift, it is normal.

A different problem is the control voltage/frequency change ratio. Cheap OCXO can be 0.1V/Hz, more expensive 1V/Hz @ 10Mhz. If the control voltage is derived from a 16 bit DAC the cheap one is limited to steps of around 8mHz but the better one is 0.8mHz. And any variation of the supply to the DAC is similarly reduced by a factor of 10.

I guess it depends on your definition of 'high performance'. My original target was stable and accurate to within 1 part in 10^9 or 0.01Hz @ 10MHz. There aren't many hobby applications that need better than that. A GPSDO with a cheap OCXOs can achieve that easily. With much fiddling I was able to achieve around 2 parts in 10^11 but that seemed to be a limit with the cheap OCXOs I used.

[lucido]

An oscillator takes a long time to stabilize, especially if it has been turned off for a long time or if it is turned off and then on again.

[lucido]

Hello everyone.
I left the GPSDO on all night, and the results don't seem bad  In theory, a GPSDO should never be turned off, but that's another story. A while ago, I read an application note from Agilent that talked about the stability of their time bases inserted into their frequency counters. Originally, they said to let the oscillator warm up for three months, then they ran various tests and switched to three days, which was more practical.
I forgot to be careful, because dealing with these issues can easily lead you down a rabbit hole.

lucido

[jmnlabs]

Hi lucido, Hi MIS42N,

Thank you both for the detailed feedback and for taking the time to test the new version!

@lucido: Glad to hear v0.94 is running well for you after the restart! Regarding the fleeting blue text at the top of the screen: that sounds like a transient status message (possibly a brief GPS parsing update or a display buffer artifact during a state change). I will keep an eye on it and try to reproduce it on my bench. If you happen to catch it again, a quick photo or a note on what the system was doing at that exact moment would be incredibly helpful for tracking it down.
You are also completely right about the Agilent app note and the infamous "rabbit hole"! I love that story about the warm-up time being reduced from 3 months to 3 days for practicality.

@MIS42N: Thank you for this excellent and highly accurate breakdown. You are absolutely right on all counts. The math regarding the 16-bit DAC resolution (8 mHz vs. 0.8 mHz steps) and the supply noise rejection based on EFC sensitivity (0.1 V/Hz vs. 1 V/Hz) is spot on. This is a classic metrology reality check.

I fully agree that for 99% of hobbyist and even many professional applications, a cheap OCXO hitting 1e-9 (or even 2e-11 with patience and fiddling) is more than sufficient. My motivation for moving to the Trimble/Navicom PCB isn't because the small OCXOs are "bad", but rather because I want to see how well the v0.94 LTIC algorithm (with its self-learning drift compensation and qErr correction) performs when the hardware is no longer the limiting factor. It is primarily an engineering exercise in removing bottlenecks to see the true potential of the control loop.

Thanks again to both of you for the valuable insights, the bench testing, and for keeping the discussion grounded in real-world metrology. This kind of feedback is exactly what makes this project better.

Best regards,
Jarosław

[jmnlabs]

Hi everyone,

I’ve just pushed v0.95-rtos to GitHub. This release focuses on global timezone support, display layout refinements, and fixing a few phase-measurement quirks.

A quick personal note on the timezone update: Having the pleasure of participating in this great, Australian-founded community, it would have been a disservice to leave the local timezones broken. Fixing Adelaide was the priority, but I got a bit carried away and ended up implementing the whole world. ;-)

Key changes in v0.95:

Global Timezones & DST: Implemented full POSIX timezone rules (407 zones, 88 rules built-in). Half-hour offsets and southern-hemisphere DST are fully supported. Just type TZ Adelaide (or any other city) and the clock is correct. The TO command now also accepts minutes (e.g., TO 9:30).

Vcc on the 480×320 TFT: The 5V rail is now displayed next to Vdd. The layout was regrouped to accommodate this cleanly: qErr moved next to Alt, and Vdd regained its second decimal place.

Phase & Sawtooth Display Fixes: dph now reads ovf outside 15–85% of Vsat (instead of showing a confident but wrong number). The receiver sawtooth correction is now subtracted on-screen, and qErr is visible for all algorithms, not just algo 10.

UI & CLI Polish: Added the first per-command help page (H TZ). The survey-in notice moved from the header to the status bar (where it belongs and doesn't get clipped).

Bug Fixes: CT countdown now works properly (was stuck at 0s). Fixed frequency jumping on the 320×240 panel, restored missing side rails, and ensured Vdd is visible on non-LTIC builds.

Upgrading:

EEPROM migration is fully automatic. If you are upgrading from v0.94, your settings will be preserved without a factory reset.

You can find the source code and documentation here:
🔗 https://github.com/jmnlabs/GPSDO_FreeRTOS

As always, bug reports and feedback are highly welcome. Let the testing begin!

Best regards,

Jarosław

[lucido]

Thank you so much, Jarosław, for your dedication.

lucido.

[lucido]

Greetings everyone.
Unfortunately, I have a problem with my circuit and I can't get it to look like it was before with algorithm 10. The vphase is always high. I need to check my circuit better.
Thanks everyone.
lucido.

[jmnlabs]

Hi lucido,

Don't jump to hardware conclusions just yet! A consistently high Vphase (near the rail) is a classic symptom of the OCXO drifting over time or the LTIC calibration becoming stale, rather than a broken circuit.
Before you start checking traces or components, I highly recommend running the built-in calibration procedures to reset the loop's operating point. This fixes the issue in 99% of cases:

Run CT (Calibrate & Tune) first.
This will measure the current plant gain (Hz/LSB) of your specific OCXO and automatically derive fresh, optimal PID coefficients for all algorithms. If the OCXO's sensitivity has shifted, this ensures the loop has the correct "strength" to correct it.

Run LC (LTIC self-calibration) second.
This is the most critical step for your specific symptom. LC will sweep the phase detector, find the new zero_offset (the true center of the exponential ramp), and measure the local ns_per_volt slope. This will pull your operating point back to the middle of the detector's usable range, allowing Algorithm 10 to lock properly again.

A quick checklist before you start:
Ensure you have a solid GPS fix (the calibrations rely on a stable 1PPS).
Let the OCXO warm up for at least 15–30 minutes before running the procedures.
After both CT and LC complete successfully, don't forget to save the new parameters with ES.
If LC passes the checks and gives you a good zero_offset and ns_per_volt, your hardware is almost certainly perfectly fine, and Algorithm 10 should lock beautifully again.
Let me know the results of the LC serial log if you run into any issues. We'll get it sorted out!

Best regards,

Jarosław