Network Time Protocol (NTP) on Ultibo Pi

[MarkMLl]

Some of this complexity can be illustrated by a Venn diagram, see e.g. this diagram.

Although that does rather skimp on the "what do you call yourself?" and "with which neighbouring village do you engage in ritual combat at weekends?" fronts :-)

MarkMLl

[mas steindorff]

My experience is that there is a slowly-varying systematic error between the various satellite constellations, a much larger variation between that and a PPS signal, and forget anything to do with a radiocode clock using consumer electronics.

Dido!  but try and convince anyone you have a measurement better than "GPS".  Still have management folks that figure I'm full of it.  My testing was over 16 hour windows (at night) and a saw slow drifts up and down.  I was thinking it had something to do with cloud cover somehow creating a delay but different constellations make more sense as the drifts were somewhat repeatable on a 24 hour scale. (but so were the clouds to some degree).

[MarkMLl]

Dido!  but try and convince anyone you have a measurement better than "GPS".  Still have management folks that figure I'm full of it.  My testing was over 16 hour windows (at night) and a saw slow drifts up and down.  I was thinking it had something to do with cloud cover somehow creating a delay but different constellations make more sense as the drifts were somewhat repeatable on a 24 hour scale. (but so were the clouds to some degree).

It's fair to assume that the maths embedded in each type of GNSS satellite is different, that the update methodology is different, and that the time that corrections are implemented for different constellations differs. As such, it is a wonder that they agree as well as they do (sub-microsecond).

So the problem boils down to "I'm in Europe, to what extent should I correct Galileo by the input from other constellations?".

Slightly later: https://galmon.eu/

Code: Text  [Select][+][-]

1. 08:10 UTC: Galileo-UTC offset: -1.84 ns, Galileo-GPS offset: -0.32 ns, GPS-UTC offset: -3.21 ns, BeiDou-UTC offset: -4.77 ns, GLONASS-UTC offset: 2.79 ns, GLONASS-GPS offset: 45.63 ns, 18 leap seconds (GPS/Galileo)
2.  
3. 08:20 UTC: Galileo-UTC offset: -1.84 ns, Galileo-GPS offset: -0.32 ns, GPS-UTC offset: -2.28 ns, BeiDou-UTC offset: -4.77 ns, GLONASS-UTC offset: 3.73 ns, GLONASS-GPS offset: 42.84 ns, 18 leap seconds (GPS/Galileo)
4.  

Note the drift above, even over ten minutes or so.

MarkMLl

[AlanTheBeast]

My experience is that there is a slowly-varying systematic error between the various satellite constellations, a much larger variation between that and a PPS signal, and forget anything to do with a radiocode clock using consumer electronics.

Dido!  but try and convince anyone you have a measurement better than "GPS".  Still have management folks that figure I'm full of it.  My testing was over 16 hour windows (at night) and a saw slow drifts up and down.  I was thinking it had something to do with cloud cover somehow creating a delay but different constellations make more sense as the drifts were somewhat repeatable on a 24 hour scale. (but so were the clouds to some degree).

What were you testing it against?

Please describe your test in some detail and what was the scale of the "slow drifts up and down".

Clouds won't bother it, but ionospheric and tropospheric changes will certainly challenge it.

[AlanTheBeast]

Slightly later: https://galmon.eu/

Code: Text  [Select][+][-]

1. 08:10 UTC: Galileo-UTC offset: -1.84 ns, Galileo-GPS offset: -0.32 ns, GPS-UTC offset: -3.21 ns, BeiDou-UTC offset: -4.77 ns, GLONASS-UTC offset: 2.79 ns, GLONASS-GPS offset: 45.63 ns, 18 leap seconds (GPS/Galileo)
2.  
3. 08:20 UTC: Galileo-UTC offset: -1.84 ns, Galileo-GPS offset: -0.32 ns, GPS-UTC offset: -2.28 ns, BeiDou-UTC offset: -4.77 ns, GLONASS-UTC offset: 3.73 ns, GLONASS-GPS offset: 42.84 ns, 18 leap seconds (GPS/Galileo)
4.  

Note the drift above, even over ten minutes or so.

MarkMLl

From your post:

Gal-UTC is 0 change over 10 minutes.
Gal-GPS is 0 change over 10 minutes.
GPS-UTC is 0.93 ns over 10 minutes.

Doesn't make much sense unless the data is presented at 10 min intervals but the sampling is not in sync.

[mas steindorff]

It's been a while but from what I remember:
I was testing a (Temperature controlled Osc) Clock's calibration in a circuit of our own design.  I could capture the difference between the 1PPS from the GPS and the counter I had running off the TCO at 16MHz.  I setup a program that would collect/log this data every few seconds.  I was also monitoring the temperature of the air and the board and the TCO as part of the data set but these did not change as I had the system in a Temperature controlled box for this testing.  I was after the long term drift difference between the GPS and our clock and expected a liner drift.  But what I found was the differences I was logging would slowly grow for about an hour or two and then change. the rate of change sometimes would be reversed or would get worst but the error would return to 0 in the long scale. in other words if I average the differences over a longer term, it would go to the same value as it started with.
since this 0 drift was what I was after, I only ran the test 4 or 5 times while the hardware was not being used.  all of my testing on different boards came to nearly the same results (± 10 parts in 16e6 per test).

[MarkMLl]

Doesn't make much sense unless the data is presented at 10 min intervals but the sampling is not in sync.

Go read their code. It's open source.

MarkMLl

[MarkMLl]

since this 0 drift was what I was after, I only ran the test 4 or 5 times while the hardware was not being used.  all of my testing on different boards came to nearly the same results (± 10 parts in 16e6 per test).

I think the first thing one has to assume is that none of the GNSS designers and operators are idiots, so their underlying maths is probably sound. Following on from that, one needs to look at the available signals and make a "best guess" of a datum by looking at some weighting of the available signals that results in minimal overall discontinuities.

One approach which would probably be valid would be to start off by assuming that your oscillator runs at the same rate as UTC, and over (say) 24 hours optimise weighting to minimise the GNSS errors relative to that. Then keep the same weighting and see if it continues to minimise errors over say a month: if it does then there's a reasonable chance that you've accounted for the various constellations inherent differences.

People such as drone operators make a great fuss over the fact that they can get a stable position from GPS etc., but are decidedly coy about whether the position remains stable over hours or days. My experiments, even using differential correction relative to a comparatively local fixed site, suggests that they're brushing a great deal under the carpet.

MarkMLl

[AlanTheBeast]

Doesn't make much sense unless the data is presented at 10 min intervals but the sampling is not in sync.

Go read their code. It's open source.

I spot a simple arithmetic discrepancy in data you post, and you want me to go looking for the source of the discrepancy?  Your issue, your mystery to solve.

As previously stated:   I'm testing an NTP client at the user end which is in the low ms "realm" of errors using a reference method that is in the very low µs realm of error with reference to a receiver with a manufacturer declared error of ±30ns RMS, ±60 ns / 99%.  Even if the receiver were "off" by full microseconds it wouldn't mean much for this test. 

And obviously the receiver can't account for the couple ns that are a burr under your saddle blanket...

[AlanTheBeast]

since this 0 drift was what I was after, I only ran the test 4 or 5 times while the hardware was not being used.  all of my testing on different boards came to nearly the same results (± 10 parts in 16e6 per test).

I think the first thing one has to assume is that none of the GNSS designers and operators are idiots, so their underlying maths is probably sound. Following on from that, one needs to look at the available signals and make a "best guess" of a datum by looking at some weighting of the available signals that results in minimal overall discontinuities.

One approach which would probably be valid would be to start off by assuming that your oscillator runs at the same rate as UTC, and over (say) 24 hours optimise weighting to minimise the GNSS errors relative to that. Then keep the same weighting and see if it continues to minimise errors over say a month: if it does then there's a reasonable chance that you've accounted for the various constellations inherent differences.

People such as drone operators make a great fuss over the fact that they can get a stable position from GPS etc., but are decidedly coy about whether the position remains stable over hours or days. My experiments, even using differential correction relative to a comparatively local fixed site, suggests that they're brushing a great deal under the carpet.

GPS isn't that stable, position wise, so there are things there in plain site and no carpeting is required, but perhaps their eyesight needs checking:

- first off they have the benefit of a very over determined solution
- secondly they have the benefit of SBAS in many places, esp. North America (WAAS) and Europe (EGNOS).
further...
- stability though smart use of accelerometers (aiding)
- stability in the very nature of the control system of the drones: the control 'loops' tell the drone much about its real movement in the air
- possible stability through vertical pointing cameras (DJI drones for example will auto land with remarkable accuracy - if the operator gives the drone the opportunity to take the reference image(s) in the several seconds after take off (ie: climb vertically to about 10m and pause.  This does not work all that well in strong winds as the drone is "pushed off centre" before it's high enough to make the reference image(s)).

- appearance of stability in a few minutes or even 10's has little to do with hours, days or more.

[AlanTheBeast]

It's been a while but from what I remember:
I was testing a (Temperature controlled Osc) Clock's calibration in a circuit of our own design.  I could capture the difference between the 1PPS from the GPS and the counter I had running off the TCO at 16MHz.  I setup a program that would collect/log this data every few seconds.  I was also monitoring the temperature of the air and the board and the TCO as part of the data set but these did not change as I had the system in a Temperature controlled box for this testing.  I was after the long term drift difference between the GPS and our clock and expected a liner drift.  But what I found was the differences I was logging would slowly grow for about an hour or two and then change. the rate of change sometimes would be reversed or would get worst but the error would return to 0 in the long scale. in other words if I average the differences over a longer term, it would go to the same value as it started with.
since this 0 drift was what I was after, I only ran the test 4 or 5 times while the hardware was not being used.  all of my testing on different boards came to nearly the same results (± 10 parts in 16e6 per test).

Hard to evaluate that, but one could wonder about temperature hysteresis of the setup as well (despite the care of the setup [ qui custodit custodes]).  But - as said - the ionosphere and (to a lesser degree) the troposphere do change from day to night and that alone could account for some of what you observed.  A big part of SBAS (WAAS here, EGNOS in Europe, other systems in Japan QZSS (very, very clever) and India refer) as things "taming" these effects.

[MarkMLl]

I spot a simple arithmetic discrepancy in data you post, and you want me to go looking for the source of the discrepancy?  Your issue, your mystery to solve.

No mystery at all. I cherry-picked a couple of readings a few minutes apart, purely to illustrate that the relative timing /does/ vary and that there are people interested in it.

I'd add that in my case I've got identical receivers, a shared antenna and splitter, and matched final cables... and I still see relative drift easily detectable on a logic analyser.

You make the point that decent drones use multiple mechanisms to achieve stability. I'm making the point that for precision timing you can't ignore the fact that there are multiple GNSS constellations each reporting a slightly different time relative to UTC: even if one doesn't attempt to correct for it one should be aware of it: and that's /particularly/ the case in somewhere like the UK which doesn't have its own easily-accessible system (or a clear relationship with some jurisdiction which does).

MarkMLl

[MarkMLl]

- appearance of stability in a few minutes or even 10's has little to do with hours, days or more.

Yes, I agree. The point I was making was that people who say "my drone is stable therefore it demonstrates that you /can/ get stable nSec timing from GPS" are brushing stuff under the carpet.

MarkMLl

[AlanTheBeast]

I spot a simple arithmetic discrepancy in data you post, and you want me to go looking for the source of the discrepancy?  Your issue, your mystery to solve.

No mystery at all. I cherry-picked a couple of readings a few minutes apart, purely to illustrate that the relative timing /does/ vary and that there are people interested in it.

You cherry picked and failed to notice that the information didn't pass its own checksum.

I'd add that in my case I've got identical receivers, a shared antenna and splitter, and matched final cables... and I still see relative drift easily detectable on a logic analyser.

You make the point that decent drones use multiple mechanisms to achieve stability. I'm making the point that for precision timing you can't ignore the fact that there are multiple GNSS constellations each reporting a slightly different time relative to UTC: even if one doesn't attempt to correct for it one should be aware of it: and that's /particularly/ the case in somewhere like the UK which doesn't have its own easily-accessible system (or a clear relationship with some jurisdiction which does).

Yes, so many people need UTC±1 ns in the world.  Do you suggest an advertising campaign?  Raise funds?

[MarkMLl]

Yes, so many people need UTC±1 ns in the world.  Do you suggest an advertising campaign?  Raise funds?

<Shrug> Our use cases and interests differ.

MarkMLl