[LinuxPPS] Nmea driver and GPS18LVC
Paul
paul at lavender-fam.net
Wed Aug 6 14:17:45 CEST 2014
On 05/08/14 16:42, tlhackque wrote:
> On 05-Aug-14 10:10, Paul Lavender wrote:
>> On 05/08/14 10:36, tlhackque wrote:
>>> On 05-Aug-14 04:51, Paul wrote:
>>>> On 04/08/14 15:54, tlhackque wrote:
>>>>> On 04-Aug-14 09:03, Paul wrote:
>>>>>> I guess the configuration is in the title. I am using ntp 4.26p5,
>>>>>> with
>>>>>> NMEA compiled in. Hardware is a GPS18LVC, with no buffering.
>>>>>>
>>>>>> I`ll ask the questions as they occurred to me rather than at the end.
>>>>>>
>>>>>> First, how can I tell if ntp is locking to the NMEA sentences only,
>>>>>> which I would expect to be rather inaccurate, or to the NMEA and the
>>>>>> PPS?
>>>>>>
>>>>>> As soon as I powered up the GPS18 ntpq claimed that it was
>>>>>> providing a
>>>>>> stratum 1 time. (Hmm, so much for careful smoothing algorithms). It
>>>>>> rapidly went to an offset of 0.011 with a jitter of 0.020. More
>>>>>> significantly offsets to pool servers were of the order of -2 to -5.
>>>>>> Believable?
>>>>>>
>>>>>> Unfortunately next morning things were much worse. While GPS claimed
>>>>>> to be at an offset of 0.004, with an jitter of 0.013, the offset to
>>>>>> the pool servers was in the order of 200.
>>>>>>
>>>>>> Do you think I am locked to the NMEA only?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> _______________________________________________
>>>>>> discussions mailing list
>>>>>> discussions at linuxpps.org
>>>>>> http://www.linuxpps.org/cgi-bin/mailman/listinfo/discussions
>>>>>> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
>>>>> Oh, I run a GPS18LVC with PPS on this machine, which looks like this:
>>>>>
>>>>> ntpq -pn
>>>>> remote refid st t when poll reach delay
>>>>> offset
>>>>> jitter
>>>>> ==============================================================================
>>>>>
>>>>>
>>>>> o127.127.20.0 .GPPS. 0 l 46 64 377 0.000 0.002
>>>>> 0.009
>>>>> +192.168.208.148 146.51.136.107 2 s 32 64 376 1.242 0.459
>>>>> 0.055
>>>>> 192.168.148.10 192.168.148.43 2 s 21 64 377 0.737
>>>>> 0.039
>>>>> 2.120
>>>>> 192.168.148.136 192.168.148.43 2 s 1 64 377 0.562
>>>>> 0.081
>>>>> 0.036
>>>>> 2.us.pool.ntp.o .POOL. 16 p - 64 0 0.000
>>>>> 0.000
>>>>> 0.002
>>>>> 1.us.pool.ntp.o .POOL. 16 p - 64 0 0.000
>>>>> 0.000
>>>>> 0.002
>>>>> 3.us.pool.ntp.o .POOL. 16 p - 64 0 0.000
>>>>> 0.000
>>>>> 0.002
>>>>> 192.168.148.255 .XFAC. 16 B - 64 0 0.000
>>>>> 0.000
>>>>> 0.002
>>>>> ff05::101 .XFAC. 16 M - 64 0 0.000
>>>>> 0.000
>>>>> 0.002
>>>>> +64.246.132.14 .CDMA. 1 u 44 64 377 23.688 -1.597
>>>>> 0.612
>>>>> +199.102.46.73 .GPS. 1 u 39 64 377 46.286 5.092
>>>>> 0.744
>>>>> +199.102.46.77 .GPS. 1 u 19 64 377 43.824 4.293
>>>>> 0.651
>>>>> +204.9.54.119 .CDMA. 1 u 7 64 377 39.583 -0.880
>>>>> 0.252
>>>>> +199.102.46.80 .GPS. 1 u 60 64 377 43.601 4.664
>>>>> 0.664
>>>>> +199.102.46.75 .GPS. 1 u 19 64 377 43.802 5.680
>>>>> 0.762
>>>>> +199.102.46.76 .GPS. 1 u 4 64 377 43.585 4.597
>>>>> 0.576
>>>>> +199.102.46.79 .GPS. 1 u 8 64 377 46.384 5.050
>>>>> 0.549
>>>>> +2607:f058:20::c .CDMA. 1 u 34 64 377 31.304 0.588
>>>>> 0.555
>>>>> +74.117.238.11 1.15.132.3 2 u 15 64 377 39.015 6.812
>>>>> 0.758
>>>>> +199.102.46.74 .GPS. 1 u 36 64 377 43.706 4.216
>>>>> 0.533
>>>>> +162.243.55.105 209.51.161.238 2 u 13 64 377 13.734 1.122
>>>>> 2.881
>>>>> +69.55.54.17 128.59.39.48 2 u 40 64 377 16.054 2.523
>>>>> 0.497
>>>>> -64.132.226.3 .GPS. 1 u 2 64 377 56.251 -0.536
>>>>> 0.678
>>>>>
>>>>> The host is a Raspberry Pi, PPS kernel, I posted the hardware on
>>>>> the RPi
>>>>> forum - it's simply level shifted to a dedicated UART for the NEMA
>>>>> and a
>>>>> GPIO pin for PPS.
>>>>>
>>>>> ppstest /dev/pps0
>>>>> trying PPS source "/dev/pps0"
>>>>> found PPS source "/dev/pps0"
>>>>> ok, found 1 source(s), now start fetching data...
>>>>> source 0 - assert 1407163957.999996449, sequence: 9560404 - clear
>>>>> 0.000000000, sequence: 0
>>>>> source 0 - assert 1407163958.999997234, sequence: 9560405 - clear
>>>>> 0.000000000, sequence: 0
>>>>> source 0 - assert 1407163960.000001017, sequence: 9560406 - clear
>>>>> 0.000000000, sequence: 0
>>>>> source 0 - assert 1407163960.999996802, sequence: 9560407 - clear
>>>>> 0.000000000, sequence: 0
>>>>>
>>>>> Again, use the right edge of the PPS signal.
>>>>>
>>>> I,m finding more. clockstats is not hugely helpful because the ip
>>>> address of the NMEA and PPS are the same. So I tried slewing the NMEA
>>>> data, using time2 in the ntp.conf file. No effect, except sudden whole
>>>> second jumps - aha, that means it is locked to the pps, as soon as
>>>> ntpd is restarted. So I`ve unsoldered the PPS wire - so I can do this
>>>> step by step. Interestingly the NMEA offset is almost a whole second,
>>>> which could be a huge gotcha for the unwary. With no external
>>>> reference clock (in other words using only NMEA for disambiguation)
>>>> and the time2 parameter unset time would be a whole second out.
>>> Please reply to the list, not me.
>>>
>>> I posted a message with my configuration, hardware & the garmin
>>> technical data, but it is being held for moderation due to its size.
>>>
>>> The NMEA data *follows* the corresponding PPS rising edge. Many people
>>> don't find this intuitive. Think 'Beep', "at the beep, the time WAS
>>> ..."
>>>
>>> Further, the NMEA time can be off at low baud rates if you have too many
>>> sentences enabled. Use SNSRCFG (from garmin) to configure just $GPRMC.
>>> (Or, sometimes I'll also include satellites in view.) While you're at
>>> it, make sure you're at the latest firmware revision (anything before
>>> 3.70 will be troublesome).
>>>
>>> http://www8.garmin.com/support/agree.jsp?id=4055 - at this writing, the
>>> latest is 'GPS 18x PC/LVC software version 3.90'. Make sure you get
>>> the version that matches your unit (LVC).
>>>
>>> head -n 4 /dev/gps0 should return something like
>>> $GPRMC,092223,A,4216.6347,N,07131.0842,W,000.0,000.0,050814,014.6,W*78
>>>
>>> $GPRMC,092224,A,4216.6347,N,07131.0842,W,000.0,000.0,050814,014.6,W*7F
>>>
>>> Note these are 1 sec apart; the 4 is because the lines end with crlf,
>>> not \n.
>>>
>>> I guess I'll send the longer message to you directly.
>>>
>> Thanks for the info. So, I've unsoldered the PPS and I'm just using
>> the NMEA. My time2 correction is about 0.850, which I can adjust now
>> there is no PPS to complicate things. Jitter on the NMEA is 10mS or so
>> which is not that suprising. Naturally the ntp driver gives a stratum
>> on that of 0 (sigh).
>> Your ntpq output only shows me how poor my internet connection is, I
>> am getting jitters to pool servers in the order of 40 milliseconds. I
>> think my error between NMEA and pool is in the order of 50mS. which
>> means the next step should be noticeable.
>>
>> How did you manage to come up with such a precise time2 parameter?
>>
>> I'll connect the PPS and see if the time slews to closer than the pool
>> servers.
>>
>> What I will do is to list exactly what I found, when I get to the end
>> of this. There are some knowledgeable people here, but some downright
>> misleading information on teh interweb.
> Last time - reply to the list.
>
> Yes there is a lot of information that is just plain wrong.
>
> time2: stop ntp. start nmea only, no pool. setup PPS (not enabled in
> ntp) Make sure your GPS has a valid location (GPRMC length may vary;
> @4800, each char is about 2 msec of time2). run ppstest. assert edge
> will be offset, which at 4800 bps and just gprmc will be about 600 msec
> assuming you don't have long cables or a lot of other delay in your
> interface. It only needs to be close so the right second is selected.
> 10ms jitter and .850 time2 are a bit large for a reasonably modern host
> - are you using a USB UART? If so, you'll be better off with a parallel
> interfaced UART (PCI, whatever.) Also, change the PPS pulse width (with
> SNSRCFG); if time2 changes, you're on the wrong edge. (note that a
> wrong edge with a pulse width of 200 + ~650 = ~850...) This really is
> the most common error.
>
> My connection is a 50Mb/s fiber thru an enterprise router, so yes, it
> probably is better than yours :-)
>
> The newer version of ntpd supports the pool directive, which
> automatically selects the best servers from the pool and kicks out stale
> ones. The pool does contain a mix of good and bad servers. It can take
> a while to stabilize - the output I provided is after several months.
> It's easy to build from the source tarball - I strongly recommend it.
>
> tos minclock 15 maxclock 21 minsane 3
>
> pool 2.us.pool.ntp.org iburst preempt
> pool 2.us.pool.ntp.org iburst preempt
> pool 1.us.pool.ntp.org iburst preempt
> pool 3.us.pool.ntp.org iburst preempt
>
> If you want more help, post your complete configuration - host HW, OS,
> ntp & pps config, ntpq output, ppstest output, snsrcfg output & any
> other data that you have. Providing selective information and asking
> people to guess is ineffective.
>
Thanks, it looks like it has settled down now. After About 15 hours I`m
at an offset of 0.010, with a jitter of 0.013. Not great, but it should
improve. Offsets to pool servers are the order of -4, so I must be using
the correct edge of the PPS (it`s the assert). This is an ITX board, and
it is busy otherwise, so I wasn`t expecting the highest accuracy. Hence
I set the stratum to 1, and I`ll use a dedicated time server, with a
more accurate source as a stratum 0. I`m using a serial input, with low
latency set.
As far as I can see it would be wise to follow the slow process I used
in any new time server. I`m still suprised that the NMEA driver doesn`t
have two different statums depending on if the algorithm is locked to
More information about the discussions
mailing list