Re: [gpsd-dev] [PATCH] Using GOODTIME_IS for UBX_MODE_TMONLY.

[Fred Wright]

On Sun, 20 Mar 2016, Hal Murray wrote:
> address@hidden said:
> > I looked into this possibility at one point and it turned out to be
> > uninteresting; the non-T variants already deliver more precision that WAN
> > time service can use, practically speaking, so the T variants would be
> > overengineering.  They might be a good fit for PTP over a LAN.
>
> I'd expect the T variants to keep delivering accurate time with fewer
> satellites.

Quite possibly, though *exactly* what they do is usually poorly
documented.

> Starting from scratch, you have 4 unknowns: X, Y, Z, and T.  (or the polar
> equivalents)  So you need 4 satellites to give you 4 equations so you can
> solve things.

Indeed, or more generally, you need at least four constraints to determine
four unkowns.  Additional constraints can be used as consistency checks
for integrity monitoring and/or improved accuracy.  The constraints can
come from satellite pseudoranges, other knowledge of position and/or time,
or some combination thereof.  The common cases are:

1) 3D fix based on at least four (or more) satellites.

2) 2D fix based on three satellites plus knowledge of altitude, either by
providing it explicitly or assuming that it's unchanged from the last 3D
fix.  The latter assumption is pretty good in a ship, but not necessarily
so good in an aircraft, or on land on rugged terrain.  And as Murphy would
have it, the latter circumstance also makes it more likely to be
satellite-challenged. :-)

3) Time-only fix (which might be called a "0D fix" for consistency with
the 2D/3D terminology) based on one satellite plus an accurate fixed 3D
position, usually obtained by averaging 3D fixes over some period of time,
preferably one sidereal day.

> If you assume you are on the surface of the earth and you have a good model
> of the globe (or your part of it), then you can get away with only 3
> satellites.  If you know your position, you can get the time from only one
> satellite.

The first part requires your ellipsoidal altitude to be known accurately.
Many receivers have a coarse geoidal model that's good enough to allow you
to provide geoidal altitude rather than ellipsoidal altitude, but they
don't have a terrain model allowing you to simply say "on the surface".

There's another situation which could have value in timekeeping
applications, though I don't think it's ever exploited.  If the only
assumption you make about the receiver's location is that it's somewhere
near the surface of the earth, and the only assumption you make about a
satellite's location is that it's somewhere in a GPS orbit, then the total
range uncertainty is about 5600km, i.e., about 18.7ms.  Thus, acquiring
one satellite is good enough to know the time within +/-9.4ms, with no
knowledge of position or ephemeris data at all.  This is, of course,
nowhere near normal GPS timekeeping accuracy, but it's in the same
ballpark as Internet-based NTP, and a couple of orders of magnitude better
than the two-second uncertainty of GSM cellphone-network time.

Going deeper, since every six-second subframe of the NAV data (the
smallest usefully decodable unit) contains a handover word which is the
GPS time of week, one knows the time of week +/-9.4ms within 6-12s of
acheiving data-bit lock.  If the week is known by other means, then the
full GPS time is known (+/-9.4ms) at that point.  Otherwise, one needs the
week number from subframe 1, 6-36s after data lock.  Either way, that's
GPS time, with the usual issues in converting it to UTC.

With multiple satellites acquired (even just minimally as above), one
could reduce the time uncertainty via simple intersection processing
(simliar to what NTPd does with multiple peers), without ephemeris
knowledge or complex calculations.

On Tue, 22 Mar 2016, Eric S. Raymond wrote:
>
> So, either the T variant is just plain difficult to lay hands on or
> the maker crowd has concluded that the T isn't cost-effective.  Could
> well be the latter - the vanilla UBX chips work very well indoors, much
> better than SiRFs.

Things like the T variant are purely firmware features, so the
manufacturing cost is zero, but the amortized engineering cost can be
significant if the feature isn't popular.  There's a pretty serious
chicken-'n-egg problem there.

With receivers that make raw observation data (and ephemeris data)
available, features like the "T variant" could be implemented purely in
software, though it would involve duplicating the fairly complex
position-solution calculations.  In principle, this could be done in GPSD,
though that would be a pretty severe case of mission creep.  In any case,
it doesn't make sense to implement code to process raw observations before
it even has code to make raw observations available to clients. :-)

Fred Wright