|
From: | Michael J. Tubby B.Sc. MIET |
Subject: | Re: [gpsd-dev] gpsd rolls back to 1999 |
Date: | Sat, 22 Jun 2019 12:22:39 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 |
On 22/06/2019 08:30, Hal Murray wrote:
2. The system time being correct *before* gpsd invocation would give it a clueThere is no pivot logic on the ntpd side when looking at SHM. I thought there was pivot logic for the NMEA driver, but I can't find it. It may be in the parse/generic driver. There is pivot logic in the TSIP Parse Driver - I put it there about 6 months before the first roll-over in August 1999 - it goes: if (week_no <= 990) week_no += 1024; I guess this approach would work for some (old) GPS receivers: if (week_no < 1024) week_no += 2048; but the problem is the *very* old ones are easy to fix but the 10-12 year old ones less so because there are other arbitary pivot points in different firmware by different manufacturers. We are currently in week number 2058 so I guess: if (week_no < 1024) { week_no += 2048; } else if (week_no < 2058) { week_no += 1024; } might kick the can down the street for a while longer ... Mike Using the system time at startup might work for gpsd. It seems counter to ntpd's assumptions.I seem to remember this being discussed in detail, lots of detail, on the list. I sort of thought the above two safety nets were in place.The discussion may have been on the ntpsec list.Q1: What is your recommendation?A) Get a recent GPS unit. B) See belowQ2: How can I use PPS from gpsd, yet not the absolute time?A) GPSD doesn't work that way. B) Ask Gary C) Don't do that. Work with what GPSD does by fudging things on the NTP side. --
Michael J Tubby B.Sc. (Hons) MIET
/ Technical Director Thorcom Systems Limited This email and any attachments to it may be confidential
and are intended solely for the use of the individual to whom
it is addressed. |
[Prev in Thread] | Current Thread | [Next in Thread] |