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: 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>



reply via email to

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