[LEAPSECS] aircraft GPS receivers hit by leap second bug

[Richard Langley]

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.

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