[time-nuts] Re: The STM32 GPSDO, a short presentation
Hi Carsten I'm indeed using a similar setup where a TCXO is used as HE clock. The PPS triggers a 32 bit capture and the SW PLL controls the Vtune of the TCXO The PPS is generated using another timer which gives me the possibility to either output a PPS or 10MHz I'm using a TCXO because of cost, power consumption and size reasons and the performance is good enough for my application. An OCXO would for sure perform better. Erik. On 14-4-2022 23:44, Carsten Andrich wrote: Hello Erik, could you elaborate on your setup? Which oscillator (OCXO?) are you using to drive the STM32's PLL? I'm currently toying around with a (presumarly?) similar configuration. An RCB-F9T's 1PPS fed into an STM32G4's 32-bit timer capture to reference the 1PPS to a local oscillator with ~6 ns resolution, subsequently generating a stabilized 1PPS using another output channel of the same timer. The STM32's PLL is still using a cheap chrystal, but I'm currently working on replacing that with an OCXO. Best regards, Carsten On 01.04.22 18:19, erik at kaashoek.com (Erik Kaashoek) wrote: Nice, I'm trying to do something similar. But without the PICdiv or the TIC measurement. Only the GPS PPS into the STM32 and the stabilized PPS is generated by a timer in the STM32 First step was to measure against the running average of the GPS PPS. As can be seen in attached Timeplot measurement the phase error is (when temperatures stabilized) in the order of 10ns. Erik. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
Hello Erik, could you elaborate on your setup? Which oscillator (OCXO?) are you using to drive the STM32's PLL? I'm currently toying around with a (presumarly?) similar configuration. An RCB-F9T's 1PPS fed into an STM32G4's 32-bit timer capture to reference the 1PPS to a local oscillator with ~6 ns resolution, subsequently generating a stabilized 1PPS using another output channel of the same timer. The STM32's PLL is still using a cheap chrystal, but I'm currently working on replacing that with an OCXO. Best regards, Carsten On 01.04.22 18:19, erik at kaashoek.com (Erik Kaashoek) wrote: Nice, I'm trying to do something similar. But without the PICdiv or the TIC measurement. Only the GPS PPS into the STM32 and the stabilized PPS is generated by a timer in the STM32 First step was to measure against the running average of the GPS PPS. As can be seen in attached Timeplot measurement the phase error is (when temperatures stabilized) in the order of 10ns. Erik. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
Hi GPS modules tend to be “accuracy rated” in terms of what they do when fed with a signal generator. The “accuracy” is the departure from the reference pulse out of the generator. Oddly enough it does not include all of the delays involved ( yes that’s a bit weird). When you feed them with real signals from real sats, those numbers are only a guess. Under various conditions they may be a pretty bad guess. How well the GPSDO is at recognizing / catching these conditions and dealing with them will impact its accuracy. Bob > On Apr 1, 2022, at 9:53 AM, André Balsa wrote: > > So reading a little bit about the "three cornered hat method", it assumes > the errors in the three datasets are not correlated, which in the case of > testing three different GPSDOs is obviously not the case. However we > already have estimates of the magnitude of the error introduced by the GPS > PPS: I think many of you have already done this kind of measurement and > u-blox themselves have an old paper about their Neo-M6 receivers. So we can > put an upper bound on the magnitude of the error introduced by the GPS PPS > and then subtract it from the overall performance of the GPSDOs being > tested. > But I guess I am at this point quite off-topic in relation to my original > post. > Just a note to say that I am coding right now the option to print once per > second extensive data in tabulated format instead of the human-readable > format that is presently output, I should upload this new firmware tomorrow > afternoon after some testing. > > This is the data that will be presented in tab-delimited format: > > STM32 GPSDO reporting tab delimited fields > > Line no. (0 if no position fix, increments by one each second if position > fix) > timestamp (UTC) > uptime (days hours mins secs) > 64-bit count > frequency (Hz) > 10s freq. avg. (one decimal) (Hz) > 100s freq. avg. (two decimals) (Hz) > 1,000s freq. avg. (three decimals) (Hz) > 10,000s freq. avg. (four decimals) (Hz) > no. of sats > HDOP (meters) > PWM (16-bit, 1-65535) > PWM adc mov. avg. (V) > Vcc adc mov. avg. (5.0V nominal) > Vdd adc mov. avg. (3.3V nominal) > BMP280 Temp. (C) > BMP280 Atm. Pressure (hPa) > AHT20 Temp. (C) > AHT20 Humidity (%) > INA219 OCXO Voltage (5.05V nominal) > INA219 OCXO Current (2A maximum) > TIC (10-bit, 1024ns max) > > When a value is not available, the field contains "0". > > > > > > On Fri, Apr 1, 2022 at 2:43 PM Bob kb8tq wrote: > >> Hi >> >> The drift used in the original example is just one of many many things >> that can come up. There are a lot of “corner cases” in GPSDO design. >> The constellation does “this” and they all react. Ideally they would react >> to suppress whatever the issue is. It does not always work out that way. >> >> This is not in any way unique to GPSDO’s. You might have a set of OCXO’s or >> Rb’s as the elements in a three corner hat that all had the same tempco >> slope >> and magnitude. In a normal lab, that could create a problem. >> >> The first time I saw the topic debated it was at FCS. It was in relation >> to the >> Cs standards used in national time scales ….. ( and why having them all >> one >> model from one company wasn’t a great idea ). >> >> Bob >> >>> On Mar 31, 2022, at 10:06 PM, Chris Caudle <6807.ch...@pop.powweb.com> >> wrote: >>> >>> On Thu, March 31, 2022 6:28 pm, Bob kb8tq wrote: 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. >>> >>> That would matter if you wanted to know how good your clock or oscillator >>> was (in some sort of absolute sense). >>> If all you wanted to know was how good your GPSDO was, wouldn't that >>> common mode behavior just fall into an intrinsic aspect of using GPS? >>> I think in the case that you want to know how good your particular GPSDO >>> is at being a GPS disciplined thing, compare to other models (e.g. >>> Thunderbolt, Jackson Labs, HP, etc.) and you can get a good idea of how >>> well it performs given the limitations that it has to use GPS to >> function. >>> >>> The bigger problem I see with the original proposal were that there were >>> too many of the new design involved, I think three if the model under >>> design, and one other homebrew model, so there could be common mode >>> problems caused by e.g. a firmware error (frequency offset in a FLL comes >>> to mind) that would be hidden by having all the 3 models under test being >>> the same. >>> By testing e.g. one new model, one Thunderbolt, and one Jackson Labs it >>> should at least be possible to tease out what behavior is unique to the >>> new STM32
[time-nuts] Re: The STM32 GPSDO, a short presentation
Nice, I'm trying to do something similar. But without the PICdiv or the TIC measurement. Only the GPS PPS into the STM32 and the stabilized PPS is generated by a timer in the STM32 First step was to measure against the running average of the GPS PPS. As can be seen in attached Timeplot measurement the phase error is (when temperatures stabilized) in the order of 10ns. Erik. On 31-3-2022 12:52, André Balsa wrote: Hello fellow time-nuts, My second post to the list. I just wanted to mention that the STM32 GPSDO is a 100% Open Source project, fully documented in the GitHub repository https://github.com/AndrewBCN/STM32-GPSDO and the EEVblog thread https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/ . Also some details are available about the firmware in the stm32duino forum thread https://www.stm32duino.com/viewtopic.php?f=10=1031 The project has some unique features compared to any other commercial or hobby GPSDO and it is still very much in full swing and actively developed not only by myself but also by a few collaborators. One of the unique features of the STM32 GPSDO is that it uses both a PLL and an FLL. I developed the 100% software FLL around May 2021 and for the PLL I have borrowed Lars Walenius genius TIC design with Erik Kaashoek's modifications (using a 74HC74 instead of a 74HC4046) (WIP). I am also using a picDIV by Tom Van Baak to generate a UTC synchronized PPS (again, WIP). The project can be assembled on a breadboard in one afternoon provided one has all the parts and it works "out of the box". The BOM total cost stands at around 45€ for the basic version and 70€ with all the bells and whistles. The firmware leverages the Arduino programming environment and the hundreds of available libraries, and it is written with the express purpose of being easy to understand, maintain and further develop. It now stands at around 1700 lines of C/C++ code with extensive comments. The main communications channel for this project is the EEVblog thread mentioned above. Greetings from France, Andrew ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
So reading a little bit about the "three cornered hat method", it assumes the errors in the three datasets are not correlated, which in the case of testing three different GPSDOs is obviously not the case. However we already have estimates of the magnitude of the error introduced by the GPS PPS: I think many of you have already done this kind of measurement and u-blox themselves have an old paper about their Neo-M6 receivers. So we can put an upper bound on the magnitude of the error introduced by the GPS PPS and then subtract it from the overall performance of the GPSDOs being tested. But I guess I am at this point quite off-topic in relation to my original post. Just a note to say that I am coding right now the option to print once per second extensive data in tabulated format instead of the human-readable format that is presently output, I should upload this new firmware tomorrow afternoon after some testing. This is the data that will be presented in tab-delimited format: STM32 GPSDO reporting tab delimited fields Line no. (0 if no position fix, increments by one each second if position fix) timestamp (UTC) uptime (days hours mins secs) 64-bit count frequency (Hz) 10s freq. avg. (one decimal) (Hz) 100s freq. avg. (two decimals) (Hz) 1,000s freq. avg. (three decimals) (Hz) 10,000s freq. avg. (four decimals) (Hz) no. of sats HDOP (meters) PWM (16-bit, 1-65535) PWM adc mov. avg. (V) Vcc adc mov. avg. (5.0V nominal) Vdd adc mov. avg. (3.3V nominal) BMP280 Temp. (C) BMP280 Atm. Pressure (hPa) AHT20 Temp. (C) AHT20 Humidity (%) INA219 OCXO Voltage (5.05V nominal) INA219 OCXO Current (2A maximum) TIC (10-bit, 1024ns max) When a value is not available, the field contains "0". On Fri, Apr 1, 2022 at 2:43 PM Bob kb8tq wrote: > Hi > > The drift used in the original example is just one of many many things > that can come up. There are a lot of “corner cases” in GPSDO design. > The constellation does “this” and they all react. Ideally they would react > to suppress whatever the issue is. It does not always work out that way. > > This is not in any way unique to GPSDO’s. You might have a set of OCXO’s or > Rb’s as the elements in a three corner hat that all had the same tempco > slope > and magnitude. In a normal lab, that could create a problem. > > The first time I saw the topic debated it was at FCS. It was in relation > to the > Cs standards used in national time scales ….. ( and why having them all > one > model from one company wasn’t a great idea ). > > Bob > > > On Mar 31, 2022, at 10:06 PM, Chris Caudle <6807.ch...@pop.powweb.com> > wrote: > > > > On Thu, March 31, 2022 6:28 pm, Bob kb8tq wrote: > >> 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. > > > > That would matter if you wanted to know how good your clock or oscillator > > was (in some sort of absolute sense). > > If all you wanted to know was how good your GPSDO was, wouldn't that > > common mode behavior just fall into an intrinsic aspect of using GPS? > > I think in the case that you want to know how good your particular GPSDO > > is at being a GPS disciplined thing, compare to other models (e.g. > > Thunderbolt, Jackson Labs, HP, etc.) and you can get a good idea of how > > well it performs given the limitations that it has to use GPS to > function. > > > > The bigger problem I see with the original proposal were that there were > > too many of the new design involved, I think three if the model under > > design, and one other homebrew model, so there could be common mode > > problems caused by e.g. a firmware error (frequency offset in a FLL comes > > to mind) that would be hidden by having all the 3 models under test being > > the same. > > By testing e.g. one new model, one Thunderbolt, and one Jackson Labs it > > should at least be possible to tease out what behavior is unique to the > > new STM32 device. > > > > -- > > Chris Caudle > > > > > > > > ___ > > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe > send an email to time-nuts-le...@lists.febo.com > > To unsubscribe, go to and follow the instructions there. > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send > an email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the
[time-nuts] Re: The STM32 GPSDO, a short presentation
Hi The drift used in the original example is just one of many many things that can come up. There are a lot of “corner cases” in GPSDO design. The constellation does “this” and they all react. Ideally they would react to suppress whatever the issue is. It does not always work out that way. This is not in any way unique to GPSDO’s. You might have a set of OCXO’s or Rb’s as the elements in a three corner hat that all had the same tempco slope and magnitude. In a normal lab, that could create a problem. The first time I saw the topic debated it was at FCS. It was in relation to the Cs standards used in national time scales ….. ( and why having them all one model from one company wasn’t a great idea ). Bob > On Mar 31, 2022, at 10:06 PM, Chris Caudle <6807.ch...@pop.powweb.com> wrote: > > On Thu, March 31, 2022 6:28 pm, Bob kb8tq wrote: >> 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. > > That would matter if you wanted to know how good your clock or oscillator > was (in some sort of absolute sense). > If all you wanted to know was how good your GPSDO was, wouldn't that > common mode behavior just fall into an intrinsic aspect of using GPS? > I think in the case that you want to know how good your particular GPSDO > is at being a GPS disciplined thing, compare to other models (e.g. > Thunderbolt, Jackson Labs, HP, etc.) and you can get a good idea of how > well it performs given the limitations that it has to use GPS to function. > > The bigger problem I see with the original proposal were that there were > too many of the new design involved, I think three if the model under > design, and one other homebrew model, so there could be common mode > problems caused by e.g. a firmware error (frequency offset in a FLL comes > to mind) that would be hidden by having all the 3 models under test being > the same. > By testing e.g. one new model, one Thunderbolt, and one Jackson Labs it > should at least be possible to tease out what behavior is unique to the > new STM32 device. > > -- > Chris Caudle > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an > email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
nea...@gmail.com said: > 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? I think an amateur can do a reasonable job of calibrating a rubidium. I wouldn't adjust anything, just measure the actual frequency and use that as a correction factor when processing other data. The idea is to assume it has good long term stability and compare it with GPS (which has very very good long term stability). Do you know about TVB's picDIV and picPET? http://www.leapsecond.com/pic/ If you have a scope, use a picDIV to make a PPS from the rubidium. Compare the PPS from GPS with the PPS from the rubidium. Reset the picDIV until they are close together. They will drift slowly. Hopefully very slowly. Come back in an hour or day and see how far they have drifted. Now do the math. Repeat. I have a Rigol scope. I'm pretty sure I could program it to automate the data collection. If you have a counter/timer that your PC can talk to, measure the time from one PPS to the other. If you have a PC, get a picPET, clock it from the rubidium and watch the PPS from a GPS. The picDIV is only accurate to 400 ns. You can get a lot better than that if you pick your times to match when the picPET shifts across a clock edge. Mumble. I don't know how to describe that in words that will be easy to understand. It will be obvious after you see it. Consider reading a clock that only ticks once per second, like the typical CMOS clock on a PC. Assume your PC has a clock and you want to know how far off it is. Spin reading the CMOS clock until it changes. Then grab your PC clock. That gets you your PC clock close to the beginning of a second. For the picPET, instead of using 2 samples 24 hours apart, adjust the start/stop times for your 24 hour run to start right after the picPET fraction-within-a-second changes. For more accuracy, get a TAPR TICC. $229 https://tapr.org/product/tapr-ticc/ Thanks John. You did a wonderful job. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
Hi
The simple answer is to use your three corner hat approach and
use a different source for each of the corners. Possibly a cheap
Rb for one and a fairly good OCXO for another. Then make your
GPSDO the third corner.
No, you don’t eliminate all questions this way, but you do address
the common mode problem.
To properly come up with accurate data then you are into the
“welcome to Time Nuts” empire of “many sources” that you can
compare to each other. You can then start sorting the good ones
from the bad ones.
Yes, you could instead spend a lot of money on a commercial
standard and just use that. Some do.
Bob
> On Mar 31, 2022, at 8:20 PM, Neal Pollack wrote:
>
> So then, I think what I hear you saying, is that if a 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 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 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 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 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 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
>> 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
[time-nuts] Re: The STM32 GPSDO, a short presentation
On Thu, March 31, 2022 6:28 pm, Bob kb8tq wrote: > 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. That would matter if you wanted to know how good your clock or oscillator was (in some sort of absolute sense). If all you wanted to know was how good your GPSDO was, wouldn't that common mode behavior just fall into an intrinsic aspect of using GPS? I think in the case that you want to know how good your particular GPSDO is at being a GPS disciplined thing, compare to other models (e.g. Thunderbolt, Jackson Labs, HP, etc.) and you can get a good idea of how well it performs given the limitations that it has to use GPS to function. The bigger problem I see with the original proposal were that there were too many of the new design involved, I think three if the model under design, and one other homebrew model, so there could be common mode problems caused by e.g. a firmware error (frequency offset in a FLL comes to mind) that would be hidden by having all the 3 models under test being the same. By testing e.g. one new model, one Thunderbolt, and one Jackson Labs it should at least be possible to tease out what behavior is unique to the new STM32 device. -- Chris Caudle ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
So then, I think what I hear you saying, is that if a 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 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 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 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 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 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
> 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
[time-nuts] Re: The STM32 GPSDO, a short presentation
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 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 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 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 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 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,
[time-nuts] Re: The STM32 GPSDO, a short presentation
On 3/31/22 2:40 PM, Bob kb8tq 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 We all know that GPS is "truth" and has no errors, common or otherwise ... But seriously, three cornered hats work best if all the sources have similar statistics, but say you compare 2 GPSDOs against OCXO, even if the OCXO is an order of magnitude or two worse (at long tau), where does it fall in the "trying to discipline a wet noodle" territory. One might also be able to do different tau ranges - GPS is not so hot in the short run (1000 seconds) but is quite good in the long run (days), while an OCXO is the reverse (which is why we make GPSDOs at all). So, if you're looking to measure the performance of a new GPSDO, can one do two sets of measurements - one against OCXO and one against GPS, and then see how you do against each of the component curves. After all, the hope is that the GPSDO is better than either of the other two. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
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 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 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 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 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@lists.febo.com -- To unsubscribe
> >> send an email to time-nuts-le...@lists.febo.com
> >>> To unsubscribe, go to and follow the instructions there.
> >> ___
> >> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe
> send
> >> an email to time-nuts-le...@lists.febo.com
> >> To
[time-nuts] Re: The STM32 GPSDO, a short presentation
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 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 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 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@lists.febo.com -- To unsubscribe >> send an email to time-nuts-le...@lists.febo.com >>> To unsubscribe, go to and follow the instructions there. >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send >> an email to time-nuts-le...@lists.febo.com >> To unsubscribe, go to and follow the instructions there. > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an > email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
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 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 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@lists.febo.com -- To unsubscribe > send an email to time-nuts-le...@lists.febo.com > > To unsubscribe, go to and follow the instructions there. > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send > an email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
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 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@lists.febo.com -- To unsubscribe send an > email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The STM32 GPSDO, a short presentation
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@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
