[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] Parallel build broken?
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] Parallel build broken? |
Date: |
Sat, 23 Nov 2013 06:45:38 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Paul Fertser <address@hidden>:
> On Sat, Nov 23, 2013 at 04:02:05AM -0500, Eric S. Raymond wrote:
> > Paul Fertser <address@hidden>:
> > > Actually, the GPS-UTC offset is part of the almanac (see e.g. [1],
> > > "word" 9, byte 1 of SubFrame 4). That's an important distinction to
> > > make since 30 seconds are enough (in ideal conditions) to download the
> > > whole ephemeris (for a given satellite) but obtaining full almanac
> > > requires at least 12.5 minutes.
> >
> > Hm. That does suggest killing off the fetch, doesn't it?
>
> I do not see any decent way to deal with the issue at all.
Yes. I misunderstood you; I thought you were inverting my belief
about the amount of time required to get the leap-second in a good
direction, but you were actually just pointing out that my terminology
was backwards. It's as bad as I thought...
> One possible universal measure would be to mark the time as inaccurate
> until after, say, 25 minutes (2x full almanac transmission interval to
> improve robustness) since start or a N-second jump in the reported
> time is observed (meaning the receiver finally got the offset). And it
> doesn't require knowing current GPS-UTC value at all.
But looking for an N>1-second jump might well fail on units manufactured
between the last leap-second change and now. They might well have the
current offset wired in as a factory default (it's what I'd do) so no jump
would be visible until after a leap second that hasn't happened yet.
> Or you can mark the time as inaccurate indefinitely until an external
> confirmation is received via gpsdctl (I can imagine a system of
> scripts that would start an NTP daemon and gpsd and would monitor the
> time discrepancy between the GPS receiver source and the other sources
> and once it's comfortably less than a second, tell gpsd that it's
> getting a fully valid signal).
Bletch. Complicated...
> OTOH, if you're ready to add some receiver-specific logic, it might
> come useful,
Receiver-specific logic is easy, if we can ID the receiver type.
> e.g. some Mediatek devices are able to report their
> current idea of leap seconds offset but it's not visible if it's
> a factory-programmed value or a freshly obtained one, so comparison
> with external data is needed.
As you point out, it doesn't solve the oroblem.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
- [gpsd-dev] Parallel build broken?, Christian Gagneraud, 2013/11/21
- Re: [gpsd-dev] Parallel build broken?, Eric S. Raymond, 2013/11/22
- Re: [gpsd-dev] Parallel build broken?, Gary E. Miller, 2013/11/22
- 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 <=
- 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, 2013/11/24
- 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