[LEAPSECS] aircraft GPS receivers hit by leap second bug

[Warner Losh]

On Wed, Jun 12, 2019 at 8:39 AM Richard Langley <lang at unb.ca> wrote:

> And a further nit-pick. The leap-second information is not included in the
> GPS Almanac (as reported in news items), per se. Of course, it's in the
> navigation message, but elsewhere in the Subframe 4 and 5 data. And it is
> only needed to relate GPS Time to UTC. Most GPS receivers operate on GPS
> Time and compute positions of the satellites using Almanac data (for
> acquisition and tracking) including WN_a and t_oa (GPS Week and GPS Seconds
> of Week to get the Almanac reference epoch). Once the receiver solves for
> its clock offset (using the more accurate Ephemeris data), accurate GPS
> Time is available to the receiver and then it can compute UTC (correctly
> accounting for the leap-second offset). I guess somehow the Rockwell
> Collins receiver needs correct UTC to properly function. That's my
> interpretation anyway.
>

The almanac takes about 15-30 minutes to download depending on how smart
your GPS receiver is. And most GPS receivers these days cache much of this
information since it changes so slowly. GPS receiver can function as a
location device w/o knowing the UTC offset, and many do. However, they can
function as a timing device that provides UTC until this almanac is in
place (or you know your cached copy is good). All GPS receivers rely on GPS
time to do location computations, otherwise they will get the position
wrong... Some GPS receivers have a defective control loop that hangs until
the almanac is downloaded (thankfully those are rare). Some provide GPS
time as it it were UTC time until the almanac is downloaded (those are also
rare now-a-days). Some do crazy stuff when 1024 weeks have elapsed since
the last leap second (I'm looking at you Motorola Oncore). Some do weird
things when 128 weeks have elapsed (as is the case here). These are all
bugs in the implementation, but they are common enough that even a decade
after working on this stuff day-to-day I still can call to mind all the
exception cases I had to defensively program around because leap seconds
suck, as implemented, and should die in a fire. They are great in theory,
and serve a useful purpose, but the number of low-quality implementations
of them that persist to this day makes me despair they will ever be
implemented right enough to be universally useful w/o a 1s hick-up. I take
leap second smearing as vindication of this position, but few others see it
as the repudiation of the TF.460 I do...  so, I've got that out of my
system for another year :)

So yes, it's just a bug, true. But it shouldn't be brushed off as 'just'
anything...

Warner


> -- Richard Langley
>
>
> -----------------------------------------------------------------------------
> | Richard B. Langley                            E-mail: lang at unb.ca
>    |
> | Geodetic Research Laboratory                  Web: http://gge.unb.ca/
>    |
> | Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
>  |
> | University of New Brunswick
>  |
> | Fredericton, N.B., Canada  E3B 5A3
>   |
> |        Fredericton?  Where's that?  See: http://www.fredericton.ca/
>    |
>
> -----------------------------------------------------------------------------
>
>
>
> > On Jun 12, 2019, at 9:49 AM, Tom Van Baak <tvb at LeapSecond.com> wrote:
> >
> >
> > ✉External message: use caution.
> >
> > > However, the current GPS/UTC offset numbers before and after the
> nearest
> > > leap seconds are still 18/18, so there is no current leap second
> > > announcement, and WNlsf may be ambiguous.
> >
> > Perhaps call it "immaterial" rather than "ambiguous"? The fact that it's
> 18/18 means no positive or negative leap second is pending. Period.
> >
> > In other words, the value of WNlsf doesn't matter in this case. It's an
> 8-bit value so obviously it must always be something between 0x00 and 0xFF,
> or -128 to +127. Maybe it's a recent old value, maybe it's zero, maybe a
> future new value, or maybe random. It doesn't matter. What matters first
> are the tLS and tFLS values, which are currently 18/18 -- which means no
> leap second. Period.
> >
> > A similar issue arose in some GPS receivers during the 7 year "leap
> second drought" of 1998 to 2005. [1]
> > Here's the math:
> >       • GPS start date: 1980-01-06 (MJD 44244)
> >       • Most recent leap second: end of the day 2016-12-31 (MJD 57753)
> >       • Most recent leap second: prior to the day 2017-01-01 (MJD 57754)
> >       • Date of first Collins / GPS / ADS-B anomaly: 2019-06-09 (MJD
> 58643)
> >       • Date that Collins says their systems will start working again:
> 2019-06-16 (MJD 58650)
> > Note that (58650 - 57754) / 7 = 128.000
> > So it's a big Rockwell-Collins oops. Both the GPS receiver firmware
> engineer who wrote the embedded code and the tester using a fancy GPS
> simulator dropped the ball.
> > /tvb
> > [1] http://www.leapsecond.com/notes/leapsec256.htm
> >
> >
> > _______________________________________________
> > LEAPSECS mailing list
> > LEAPSECS at leapsecond.com
> > https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20190612/2436d854/attachment.html>