[time-nuts] Epoch rollover ?

[Dennis Ferguson]

On 21 Oct, 2011, at 11:53 , k4cle at aol.com wrote:
> Bruce, the most common cause of a GPS receiver getting the date incorrect is due to cross-correlation.  And cross-correlation is usually the result of too much gain in the GPS antenna's LNA.  And depending on the make of the receiver, some will clear the date information with a power cycling and others require erasing the flash memory where those parameters are stored.  Do you have a way to see the relative C/No reading for your receiver?  Most receivers start experiencing cross-correlation when this reading exceeds 50. Regards,  Doug, K4CLE…

That might be true in general, but seems exceedingly unlikely to be the
problem when the date error has a magnitude of exactly 1024 weeks.  The
problem is that while GPS tells you the time within a 1024 week "era"
it provides no information about which 1024 week era we're in so even
perfectly received GPS signals don't tell the unit what is needed to fix
that.  Either the receiver needs a separate source of time information
to determine the era, or it needs to implement a heuristic to guess at
it from the data it does have.

Some of the heuristics I've heard of are these (or maybe combinations of these):

- Assume the date must be more recent than when the firmware was compiled.
  By itself this leaves the device with a 1024 week rollover problem, but
  the 1024 weeks are counted from the date the firmware was compiled rather
  than from the GPS epoch.

- Assume the date must be more recent than the last date on which the unit
  saved restart information (ephemerides, etc.) in its flash memory, or
  whatever non-volatile storage it uses for this.  This may fail if the
  unit's flash memory fails.

- Guess at the "era" based on the leap second count (i.e. the UTC offset)
  informed by some expectation of how many leap seconds are likely to
  occur in each 1024 week era.  This would be an excellent heuristic if
  the rate of leap second insertion was relatively predicable over long
  periods, but as it has turned out the relative dearth of leap seconds
  in the past dozen years might cause particular implementations of this
  guestimate to fail now.

I don't know if any of this matters in the current case.  The last (which
I think was considered the "best practice", or at least the "best that
could be made of a bad situation", at the time the GPS rollover occurred)
is of particular interest right now since it suggests that ending UTC
leap seconds might eventually have some unintended consequences for boat
anchor GPS timing equipment.

Dennis Ferguson