[LinuxPPS] Nmea driver and GPS18LVC
tlhackque
tlhackque at yahoo.com
Tue Aug 5 17:42:15 CEST 2014
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.
--
This communication may not represent my employer's views,
if any, on the matters discussed.
More information about the discussions
mailing list