[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.
- Re: [gpsd-dev] Parallel build broken?, (continued)
- Re: [gpsd-dev] Parallel build broken?, Eric S. Raymond, 2013/11/23
- Re: [gpsd-dev] Parallel build broken?, Gary E. Miller, 2013/11/23
- Re: [gpsd-dev] Parallel build broken?, Eric S. Raymond, 2013/11/23
- Re: [gpsd-dev] Parallel build broken?, Paul Fertser, 2013/11/23
- Re: [gpsd-dev] Parallel build broken?, Paul Fertser, 2013/11/23
- Re: [gpsd-dev] Parallel build broken?, Eric S. Raymond, 2013/11/23
- Re: [gpsd-dev] Parallel build broken?, Paul Fertser, 2013/11/23
- Re: [gpsd-dev] Parallel build broken?, Eric S. Raymond, 2013/11/23
- Re: [gpsd-dev] Parallel build broken?, Paul Fertser, 2013/11/24
- Re: [gpsd-dev] Parallel build broken?, Eric S. Raymond, 2013/11/24
- [gpsd-dev] (no subject),
Hal Murray <=
- Re: [gpsd-dev] (no subject), Sanjeev Gupta, 2013/11/24
- Re: [gpsd-dev] Parallel build broken?, Paul Fertser, 2013/11/24
- Re: [gpsd-dev] Parallel build broken?, Eric S. Raymond, 2013/11/24
- Re: [gpsd-dev] Parallel build broken?, Paul Fertser, 2013/11/24
- Re: [gpsd-dev] Parallel build broken?, Gary E. Miller, 2013/11/25
- Re: [gpsd-dev] Parallel build broken?, Paul Fertser, 2013/11/25
- Re: [gpsd-dev] Parallel build broken?, Gary E. Miller, 2013/11/25
- Re: [gpsd-dev] Parallel build broken?, Greg Troxel, 2013/11/25
- Re: [gpsd-dev] Parallel build broken?, Gary E. Miller, 2013/11/25
- Re: [gpsd-dev] Parallel build broken?, Paul Fertser, 2013/11/26