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