[LEAPSECS] Reliability (was Re: it's WP7A week in Geneva)

[Magnus Danielson]

Rob Seaman wrote:

> Tom Van Baak wrote:

> 

>>> when all is said and done).  A 12.5 minute down time means your 

>>> annual reliability can only be 4 9's, not 5 9's...  This is why many 

>>> receivers remember the last UTC offset values and warm start with 

>>> them if they have only been off a short period of time...

>>> Warner

>>

>> User code can usually handle being told by a GPS receiver that "UTC is 

>> not known yet; use GPS time instead". But when a GPS receiver says 

>> "sorry, by the way, all the UTC time stamps

>> I've sent you in the past quarter hour were off by one second", that 

>> might be a little more trouble to deal with.

> 

> Could somebody comment on the reliability of GPS receivers to deliver 

> GPS time itself?


On the first fix it has resolved GPS time, modulus the 1024 week 
wrapping. The receiver itself rarely needs GPS time as a compound unit, 
but it remains broken down to GPS week, Z-count (1,5 sec tick wrapping 
on new GPS week), and then some suitable high-rate counter. The 
individual channels build their own 1,023 MHz or 10,23 MHz counters 
(with doppler), 1 ms counter, 20 ms counter (for data bit alignment),
page and frame counters etc being synchronous to the receiver. The 
common high-rate clock is used to sample the phase state of the channels 
, pseudo-ranges is built, processed and out comes the ECEF results 
[XYZT]. Time-errors is adjusted according to some suitable algoritm, but 
occasional jumps is seen in the data for some receivers. See Misra&Enge 
for examples of that. A lot of the processing uses various forms of 
issue of data to give corrections to orbit parameters for instance. So 
broken up GPS time is in the very core of things. But cranking out date 
and time isn't, it's an adaptation to the user.

We have had issues where GPS time has not been reliable due to incorrect 
handing of the 1024 week wrapping. The produced UTC time as affected as 
a side consequence. If the receivers where using L2C they would be able 
to resolve this from the signal, as it has a 8192 week wrapping. Some 
early receivers used a bias scheme and in one case it processed the GPS 
week like this:

if (GPSweek < 500)
	GPSweek += 1024;

Works well until the actual GPS week steps from 1523 to 1524 in which 
the wrapped GPS week steps from 499 to 500 and the calculated GPS week 
after unwrapping steps from 1523 to 500. Those receivers frose. A 
firmware update could do this after the wrapping:

if (GPSweek < 500)
	GPSweek += 1024;
GPSweek += 1024;

That would keep them running for another 19 years.

Other receivers have other ways to handle it, including allowing the 
user to give the date as a hint. Infact, the current year is sufficient 
to resolve that wrapping.

Regardless, the GPS time can also "lie", but it is maybe about a decimal 
place less likely than UTC time from a system approach. However, if one 
blindly expects the GPS receiver to always give "correct" time, then one 
has opened up a pandora-box of troubles, as you obviously is not looking 
at the error handling needed particular for GPS receivers. To protect 
yourself you need to understand how they work and what failures and 
mal-functions they can have. But too many times I see them being treated 
as this box that takes a GPS signal and cranks out "correct time". Once 
in place, they are mostly forgotten except on tours among the equipment.

Cheers,
Magnus