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

[André Balsa]

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.