Since the old gpskit gps was showing pro ... / 2014-02-16

2014-02-16 Since the old gpskit gps was showing pro ...
Since the old gpskit gps was showing problems in ntp tests earlier I decided now that the weatherstation computer is up and running on the alix.1c board to try a different gps unit: The Holux GR-213 GPS I still have from earlier wardriving. holux 213 gps

Not much of a succes sofar. First the GPS did not get a lock at all. I was expecting a delay in acquiring a lock since it hadn't been used in over a year but after a day and a half it still wasn't locking. So I moved it a bit which led to a lock (blinking led). But ntpd was still not using the GPS_NMEA driver. When I had time to have more of a look than just the graphs at NTP server stats I noticed ntpd was still seeing GPS_NMEA as a falseticker. Which is about right, when I look at the peer stats the GPS_NMEA clock has an offset of about 500 milliseconds(!!) compared to the rest.

To my best knowledge I can find the right offset with 'enable calibrate'. But documentation is very minimal on this matter: Reference clock drivers - ntp 4.0.99k documentation has:
The recommended procedure is to enable the function, let it run for an hour or so, then edit the configuration file using the time1 values displayed by the ntpq utility and clockvar command.
With 'enable calibrate' on I see after a long run:
ntpq> peer
     remote           refid      st t when poll reach   delay   offset  jitter
+greenblatt.idef    2 u  137  512  377    1.012    1.780  87.722
*metronoom.dmz.c .PPS.            1 u  166  512  377   18.297   -1.207  46.401    2 u  119  512  377   16.604   -1.104  27.267
xGPS_NMEA(0)     .GPS.            0 l    4   16  377    0.000  -529.94   3.286
ntpq> clockvar
associd=0 status=0000 , no events, clk_unspec,
device="NMEA GPS Clock",
poll=762, noreply=0, badformat=0, baddata=0, fudgetime1=0.000, stratum=0,
refid=GPS, flags=0
So even after running for a long time with clearly an offset between the other clocks and the reference clock there is no change in the suggestion for the time1 factor, still showing 0.000.

Remarks in [ntp:questions] enable calibrate? suggest 'enable calibrate' will only work when there is a PPS signal available, and confirm the lack of documentation and samples I found.

The Holux GR-213 also does not have a PPS signal to the outside at all, so I can't use a PPS signal anyway.

Update: Some sleep, thinking and reading later: first of all, time1 is the PPS time offset and time2 is the gps message offset, found by reading ntpd documentation Generic NMEA GPS driver.

So I started looking for the right offset with the driver in noselect mode. After some testing I found a reasonable answer with:
# GPS as time source without pps
server minpoll 1 maxpoll 4
fudge time2 +0.544
And now things look better:
ntpq> peer
     remote           refid      st t when poll reach   delay   offset  jitter
+greenblatt.idef    2 u    2   64   77    0.956   -2.252  41.400
*metronoom.dmz.c .PPS.            1 u    5   64   77   17.921   -2.236   1.190    2 u    3   64   77   16.254   -2.750   0.880
+GPS_NMEA(0)     .GPS.            0 l    2    8  377    0.000   -5.916   1.100

Tags: ,

IPv6 check

Running test...
, reachable as PGP encrypted e-mail preferred. PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers

Meningen zijn die van mezelf, wat ik schrijf is beschermd door auteursrecht. Sommige publicaties bevatten een expliciete vermelding dat ze ongevraagd gedeeld mogen worden.
My opinions are my own, what I write is protected by copyrights. Some publications contain an explicit license statement which allows sharing without asking permission.
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews
This page generated by $Id: newsitem.cgi,v 1.58 2022/12/12 15:34:31 koos Exp $ in 0.009766 seconds.