[ntp:questions] Motorola Oncore Surveyed Position

unruh unruh at wormhole.physics.ubc.ca
Wed Sep 7 15:20:59 UTC 2011

On 2011-09-07, Miguel Gon?alves <mail at miguelgoncalves.com> wrote:
> Hi Terje!
> Thanks!
> My Oncore reported 146 m altitute but I checked with Google Earth and with
> my iPhone and my altitude at this location should be 75 m. I am using 75.
> It's working fine since 20110907T2300Z.

That is about 200ns in time difference. 
What does "working fine" mean? for me it would mean that the time
delivered was as close to UTC as possible. But determining that it
pretty hard-- you need an independent source of time to compare it

> I will let it run for a few days and plot some graphs and share them with
> the list.
> Yes... I know Oncore performance (and even Garmin 18, 18x and Sure) are more
> than enough for NTP but I am a time freak, pardon, nut :-)

If so, then the gps unit is not where you should be concentrating your
attention. Its errors are already far less than other sources of time
inaccuracies in your system. 

a) the interrupt latency on whatever you use to get that pps into your
system is far larger than that of the receiver. You probably should get
yourself some better hardware to enable the PPS edge to be timestamped
far more accurately.
b) Use chrony rather than ntpd. All of the tests that I and Lichvar have
run have shown that chrony performs much better at timekeeping ( 3-20
times better depending on whose tests you look at) This is looking at
the scatter of the offsets on reading the gps signal from a conditioned
c) Put your computer crystal into a temperature compensated oven, or use
the temperature compensating versions of ntpd. ntpd's slow response to
change interacts badly with the temperature fluctuations within most
computers whose workload varies over the day.

The above are probably in inverse order of priority if you really want
your computer to keep the best time possible-- ie if you are a time
freak/nut. Look at the peerstats file on your gps and see if you see a
daily variation (as in www.theory.physics.ubc.ca/chrony/chrony.html for
the ntpd running system) That is almost certainly due to temperature
variations in your computer. Get rid of those first. Then when your
system's errors are fluctuating around the 1us mark without obvious
correlation, look at the interrupt latency problem. 

> Cheers,
> Miguel
> On 7 September 2011 08:33, Terje Mathisen <"terje.mathisen at tmsw.no"@
> ntp.org> wrote:
>> Miguel Gon?alves wrote:
>>> Hi Terje!
>>> Thanks for your reply.
>>> I switched again to mode 4 and started again to see if I missed something.
>>> I
>>> believe I'll only have to wait 10000 seconds = 2 hours and 46 minutes...
>>> not
>>> much. :-)
>>> Unfortunatelly clockstats doesn't show position, only time. I believe this
>>> is because it's in position lock (0D?) mode. Here's a sample:
>>> 55810 40276.220 3524296275.999957838 2011 249 11 11 16 15
>>> rstat   08 dop  0.0 nsat 10,2 traim 1,0,1 sigma 77 neg-sawtooth -24 sat
>>> 35000080
>>> By the way... I was looking at the clockstats file and noticed that when I
>>> switched to mode 4 as I said earlier I got this
>>> 55810 40560.366 ONCORE[0]: Loading Posn from SHMEM
>>> 55810 40560.367 ONCORE[0]: Setting Posn and Time after
>>> Loading
>>> Almanac
>>> 55810 40562.091 ONCORE[0]: Posn:
>>> 55810 40562.091 ONCORE[0]: Lat = N  41.1745319deg,    Long =
>>> W   8.6560764deg,    Alt = 146.72m (481.36ft) GPS
>>> 55810 40562.091 ONCORE[0]: Lat = N  41deg 10.4719m,   Long =
>>> W   8deg 39.36458m,  Alt =  146.72m ( 481.36ft) GPS
>>> 55810 40562.091 ONCORE[0]: Lat = N  41deg 10m 28.32s, Long =
>>> W   8deg 39m 21.88s, Alt =  146.72m ( 481.36ft) GPS
>>> 55810 40564.365 ONCORE[0]: Waiting for Almanac
>>> 55810 40567.365 ONCORE[0]: Have now loaded an ALMANAC
>>> 55810 40567.365 ONCORE[0]: state = ONCORE_RUN
>>> It seems this is my location... :-) Now you know where I live! :-)
>>> So the position is stored in the shared memory and when I reset the unit
>>> (mode 4) it uses the position stored in there.
>>> Anyone help care to comment this?
>> That seems like canonical behaviour, i.e. the way you want it.
>> As long as that position is within 3-5 m your timestamps will be within
>> 10-15 ns, which is comparable to the inherent jitter in Oncore timing
>> receivers.
>> For NTPD it is far better than you actually need, except TRAIM might cause
>> problems if you started with a position 300 m (1 us) off.
>> Terje
>> --
>> - <Terje.Mathisen at tmsw.no>
>> "almost all programming can be viewed as an exercise in caching"
>> ______________________________**_________________
>> questions mailing list
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/**questions<http://lists.ntp.org/listinfo/questions>

More information about the questions mailing list