[Top][All Lists]

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

[gpsd-dev] (no subject)

From: Hal Murray
Subject: [gpsd-dev] (no subject)
Date: Sun, 24 Nov 2013 16:36:20 -0800

address@hidden said:
> 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.

In general, I don't think it's practical to detect whether a GPS receiver 
knows the leap second offset.  The NMEA sentences don't have any way to tell 
you that critical piece of info.  Trying to reverse engineer things gets into 
a horrible tangle.

Note that there is nothing magic about device powerup.  Most GPS gizmos have 
a battery to keep track of the time so they can get started quickly.  Once 
you have a battery, it's close to free to remember things like the leap 
second offset.

I don't know if the batteries last more than 6 months.  If they do, there is 
the chance that a leap second will have been announced and happened since the 
device last updated it's almanac.

My vote is to document the whole mess and punt.  In the context of NTP, if 
ntpd is configured to use several other servers, even over a crappy network, 
they will out-vote a broken GPS unit.

Hacks like wait for twice as long as the almanac update interval may not work 
if there is a burst of noise (or whatever) at the time(s) when that chunk of 
data is coming down.

It might be possible to work with either the NMEA gurus and/or the individual 
manufacturers to provide that info.  Something like another field tacked on 
the end of the GPRMC sentence would do it.  So would a software patch/mode 
that said "invalid" if it didn't have a recent almanac.

It might be possible to make a list of devices that did-the-right-thing in 
this context.  I think that means mark any answers as invalid unless they 
know the leap-offset and/or get a recent version from battery backed memory.

Trying to verify experimentally that an individual device did the right thing 
seems like a hard task.

It might be fun to make a decision tree for this problem.  There will be a 
lot of unknown/guesses in there.  (This seems like a good thesis topic.)

These are my opinions.  I hate spam.

reply via email to

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