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

[Bob kb8tq]

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 <andrebalsa at gmail.com> 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 <kb8tq at n1k.org> 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.chris at 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 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.