gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Parallel build broken?


From: Paul Fertser
Subject: Re: [gpsd-dev] Parallel build broken?
Date: Mon, 25 Nov 2013 07:13:15 +0400
User-agent: Mutt/1.5.17 (2007-11-30)

On Sun, Nov 24, 2013 at 06:56:18PM -0500, Eric S. Raymond wrote:
> A more conservative but much simpler strategy would be simply to bump
> up ept in the JSON reports by N seconds for 12.5 minutes (one almanac
> transmission period) after device powerup, where N is the maximum
> number of possible leap-seconds issued between the build date of the
> GPSD instance and now.

And so you'll get wrong time for the first 12.5 minutes almost always,
as most GPS units have an EEPROM to store almanac data, once they've
seen a new almanac, they'll use it right from power-on. Also, the
reception conditions are usually less than ideal, so it's not
realistic to expect the almanac to be downloaded in just 12.5 minutes.

Also with this approach you can easily get wrong time initially
(because of wrong estimation of the amount of leapseconds since gpsd
build date), then after 12.5 minutes see a jump to another wrong time
(assuming the receiver wasn't able to get the almanac "in time"), then
(finally) another jump to the correct time.

Basically, what I propose is to not lie to an NTP daemon. If you do
not know for sure, do not claim you know the right time. Probably you
can tell you know for sure after you see the receiver output jumps by
N seconds OR some considerable time passed (say, 1 hour), before that
just mark the time source as inaccurate.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]