[ntp:questions] Motorola Oncore Surveyed Position

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Thu Sep 8 08:28:35 UTC 2011


Miguel Gonçalves 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.

There are two heights!

The real ASL height, which is what you get from a local topo map, and 
altitude above the GPS geoid, which can be significantly higher or lower.

I.e. check the type of altitude!

Terje
>
> 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 :-)
>
> 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 127.127.30.0 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 127.127.30.0 ONCORE[0]: Loading Posn from SHMEM
>>> 55810 40560.367 127.127.30.0 ONCORE[0]: Setting Posn and Time after
>>> Loading
>>> Almanac
>>> 55810 40562.091 127.127.30.0 ONCORE[0]: Posn:
>>> 55810 40562.091 127.127.30.0 ONCORE[0]: Lat = N  41.1745319deg,    Long =
>>> W   8.6560764deg,    Alt = 146.72m (481.36ft) GPS
>>> 55810 40562.091 127.127.30.0 ONCORE[0]: Lat = N  41deg 10.4719m,   Long =
>>> W   8deg 39.36458m,  Alt =  146.72m ( 481.36ft) GPS
>>> 55810 40562.091 127.127.30.0 ONCORE[0]: Lat = N  41deg 10m 28.32s, Long =
>>> W   8deg 39m 21.88s, Alt =  146.72m ( 481.36ft) GPS
>>> 55810 40564.365 127.127.30.0 ONCORE[0]: Waiting for Almanac
>>> 55810 40567.365 127.127.30.0 ONCORE[0]: Have now loaded an ALMANAC
>>> 55810 40567.365 127.127.30.0 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>
>>


-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"




More information about the questions mailing list