[time-nuts] Re: The STM32 GPSDO, a short presentation

[André Balsa]

Hi Bob,
I haven't taken a close look at the math behind the Three-Cornered Hat
method yet, but I would imagine there is a mathematical way to remove or at
least quantify the uncertainty ("jitter") introduced by the (separate, but
similar) GPS receivers in the three GPSDOs under test?

On Fri, Apr 1, 2022 at 12:02 AM Bob kb8tq <kb8tq at n1k.org> wrote:

> Hi
>
> The gotcha of looking at one GPSDO against another is that
> the GPS side of things is “common mode” to all of the devices.
>
> Bob
>
> > On Mar 31, 2022, at 4:16 PM, André Balsa <andrebalsa at gmail.com> wrote:
> >
> > Hi Bob,
> > "You need an external / stable reference that is (hopefully) much more
> > accurate than the GPSDO to compare it to."
> >
> > I fully agree, and of course I don't have an atomic clock at hand. But I
> > was thinking that there is an alternative: the Three-Cornered Hat method.
> > In any case, we are not there yet, I still have to write the code for tab
> > delimited reporting, and then collect the data from the 4 different
> GPSDOs
> > I have here (3 x STM32 GPSDO + 1 x Lars' DIY GPSDO), and then setup
> > the Three-Cornered Hat measurement apparatus, and then collect more data,
> > etc...
> > Oh the joys of time-nuttery!
> >
> > On Thu, Mar 31, 2022 at 9:01 PM Bob kb8tq <kb8tq at n1k.org> wrote:
> >
> >> Hi
> >>
> >> One word of caution:
> >>
> >> You really can’t compute things like ADEV by observing the device
> against
> >> itself. You need an external / stable reference that is (hopefully) much
> >> more
> >> accurate than the GPSDO to compare it to.
> >>
> >> Bob
> >>
> >>> On Mar 31, 2022, at 2:18 PM, André Balsa <andrebalsa at gmail.com> wrote:
> >>>
> >>> Hello time-nuts,
> >>> This is a quick follow-up to my short presentation of the STM32 GPSDO
> >>> project, because as some of you noticed, the EEVblog thread is
> >>> unfortunately 27 pages long and growing... :(
> >>> A few pointers:
> >>> 1. If you are interested in the technical details or further
> >> understanding
> >>> of the project, I suggest reading **only the first post** in the
> EEVblog
> >>> thread and then jumping straight to the schematics in post #378, page
> 16
> >> in
> >>> the thread, and then reading the generously commented source code on
> >> GitHub
> >>> (download the zip file for the latest release and check the GPSDO.ino
> >>> sketch).
> >>> 2. The core of this project is made of just three components:
> >>> a. The STM32F411CEU6 "Black Pill"
> >>> b. The 10 MHz OCXO
> >>> c. The ublox M8N GPS receiver module
> >>> These three components plus a few resistors, capacitors and an LED and
> >>> voila!, you have a working GPSDO. Everything else is optional. But of
> >>> course the optional parts are where the fun is, really.
> >>> 3. Likewise the core of the firmware is just 15 lines of C code, which
> >> are
> >>> used to setup the 64-bit counter (10 lines) and the interrupt service
> >>> routine that reads the counter (5 lines). Everything else in the
> firmware
> >>> is built around these 15 lines of C code. Also to be honest, while
> these
> >> 15
> >>> lines of C code are well written, the rest... not so much. ;)
> >>> 4. So how does it work? Essentially we measure the frequency of the
> OCXO
> >>> every second (the 64-bit counter), average it over the last 10/100/1000
> >>> seconds (data stored in circular buffers), and adjust the OCXO control
> >>> voltage Vctl accordingly: if the frequency is too high, we decrease
> Vctl,
> >>> and if the frequency is too low, we increase Vctl. In other words,
> it's a
> >>> simple frequency locked loop, which all of you are familiar with.
> >>> 5. The performance? Hmmm... honestly I started working on this project
> >> with
> >>> the modest aim of 1ppb stability and that was achieved almost
> >> immediately,
> >>> also from the anecdotal data I and others have collected, the STM32
> GPSDO
> >>> achieves 0.1ppb stability after a couple of hours and 0.01ppb is also
> >>> achievable, without any correction being applied from the various
> >>> environmental sensors. I think ultimately 0.001ppb should be achievable
> >> but
> >>> that will take some work on the firmware.
> >>> 6. Those nice ADEV plots? Ouch: I don't have any. In the coming days I
> >> will
> >>> push to GitHub a new version of the firmware with reporting with proper
> >>> tab-delimited fields that will allow people to plot various charts and
> >>> study the correlation between supply voltages, OCXO power consumption,
> >> OCXO
> >>> frequency, atmospheric pressure, humidity, etc... A true smorgasboard
> for
> >>> statisticians!
> >>>
> >>> Greetings from France,
> >>> Andre' (Andrew)
> >>> _______________________________________________
> >>> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
> >> send an email to time-nuts-leave at lists.febo.com
> >>> To unsubscribe, go to and follow the instructions there.
> >> _______________________________________________
> >> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
> send
> >> an email to time-nuts-leave at lists.febo.com
> >> To unsubscribe, go to and follow the instructions there.
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
> send an email to time-nuts-leave at lists.febo.com
> > To unsubscribe, go to and follow the instructions there.
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe send
> an email to time-nuts-leave at lists.febo.com
> To unsubscribe, go to and follow the instructions there.