So then, I think what I hear you saying, is that if a <insert person/newbie/time-nut> wants to see if a GPSDO that they built, or purchased on ebay, is working OK, then they really need to purchase a non-GPS rubidium oscillator on ebay, and use that as a ref to compare their GPSDO under test?
And, I assume that since we have no idea if the used rubidium oscillator from ebay is working properly anymore (aside from output seen on a counter), then we should take that rubidium oscillator to a calibration vendor and pay them to test it, correct? Then, we can measure? Neal On Thu, Mar 31, 2022 at 4:43 PM Bob kb8tq <[email protected]> wrote: > Hi > > Consider the case: > > GPS shifts ( possibly due to any of a number of issues). All three modules > “move” forward in time by 15 or 20 ns over some time period. > > The GPSDO’s all do their thing and shift frequency by the appropriate > amount. > > Since all three devices in your three corner hat did the same thing at the > same time, all of the delta this / delta that numbers just sit there. They > do > not show the frequency shift at all. > > Yes, it’s a bit of a contrived example, but it is why a common mode issue > is going to be a problem. > > Bob > > > On Mar 31, 2022, at 6:38 PM, André Balsa <[email protected]> wrote: > > > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 -- [email protected] -- To unsubscribe > >>>> send an email to [email protected] > >>>>> To unsubscribe, go to and follow the instructions there. > >>>> _______________________________________________ > >>>> time-nuts mailing list -- [email protected] -- To unsubscribe > >> send > >>>> an email to [email protected] > >>>> To unsubscribe, go to and follow the instructions there. > >>> _______________________________________________ > >>> time-nuts mailing list -- [email protected] -- To unsubscribe > >> send an email to [email protected] > >>> To unsubscribe, go to and follow the instructions there. > >> _______________________________________________ > >> time-nuts mailing list -- [email protected] -- To unsubscribe > send > >> an email to [email protected] > >> To unsubscribe, go to and follow the instructions there. > > _______________________________________________ > > time-nuts mailing list -- [email protected] -- To unsubscribe > send an email to [email protected] > > To unsubscribe, go to and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- [email protected] -- To unsubscribe send > an email to [email protected] > To unsubscribe, go to and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] -- To unsubscribe send an email to [email protected] To unsubscribe, go to and follow the instructions there.
