Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug
Tom, Tom Van Baak wrote: >> What I meant is that if you try to derive the date of the last recent >> leap second from WNlsf if the 2 offsets *are* the same, the result is >> ambiguous since you don't know if you are in a +/- 128 weeks interval, >> or if another 256 weeks interval has passed. That's exactly what we are >> observing right now. > > Let me explain a cute trick. The ± 128 or modulo-256 week ambiguity that > you mention is certainly true, as well as the 19.x year 1024 week GPS WNRO > that we all know. > > But look one step deeper. Each 8-bit week number and 3-bit day number used > to describe the most recent or pending leap second must necessarily be the > last day of a calendar month, per UTC rules, yes? It turns out this fact > can be used to resolve the ambiguity that you speak of. [...] This is really cute! If you permit, I'll see if we can add this to our driver software packages. Thanks, Martin ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug
Tom Van Baak wrote:
>> 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.
Yes, the WNlsf number is immaterial for timing computations as long as
the 2 offset values don't differ.
What I meant is that if you try to derive the date of the last recent
leap second from WNlsf if the 2 offsets *are* the same, the result is
ambiguous since you don't know if you are in a +/- 128 weeks interval,
or if another 256 weeks interval has passed. That's exactly what we are
observing right now.
> 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.
Yes, and as I wrote in my previous email the Meinberg GPS firmware
doesn't evaluate WNlsf for timing in this case.
Only some of our utility programs try to find out the date of the last
recent leap second, and display it just for informational reasons.
As mentioned before we used the word "eventually" ("probably" in the
next software release) to say that due to the ambiguity this is not
necessarily a distinct date.
> A similar issue arose in some GPS receivers during the 7 year "leap
> second drought" of 1998 to 2005. [1]
Yes.
> 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.
Exactly.
Martin
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug
On Wed, Jun 12, 2019 at 8:39 AM Richard Langley 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. LangleyE-mail: l...@unb.ca >| > | Geodetic Research Laboratory Web: http://gge.unb.ca/ >| > | Dept. of Geodesy and Geomatics EngineeringPhone:+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 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 > >
Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug
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. LangleyE-mail: l...@unb.ca | | Geodetic Research Laboratory Web: http://gge.unb.ca/ | | Dept. of Geodesy and Geomatics EngineeringPhone:+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 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@leapsecond.com > https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug
In message <7bca6012-4303-68e7-bd57-85bf881fd...@burnicki.net>, Martin Burnicki writes: >UTC correction parameters: > t0t: 2057|405504.000, A0: -9.31323e-10 A1: -2.66454e-15 > WNlsf: 2185, DN: 7, offs: 18/18 >Last leap second eventually at UTC midnight at the end of Sat, 2021-11-27 That is similar to what my old Oncore UT reports: Leap second info: 2021-11-28 00:00:00 NONE 77714184 seconds (899 days) from now -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug
> 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@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug
Paul Hirose wrote: > Thinking I had missed a pending leap second, I checked the IERS site, > but Bulletin C says the offset is still 37 seconds and nothing is > scheduled. ??? The GPS satellites transmit the week number of the nearest leap second (WNlsf) as 8 bit value only, giving a valid range of ~+/- 128 weeks from "now". The last leap second was on 2016-12-31, and counting the number of weeks in 2017, 2018, and 2019 until now, this sounds like close to 128. I haven't computed the exact number, but I'm assuming that the range was just recently exceeded. I'm currently out of the office, but I've heard from my colleagues that the currently sent WNlsf number is 0x89. 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. When the next announcement starts the offsets will change to 18/19, and WNlsf will also be updated to be in range. The "mbgstatus -vvv" program for the Meinberg GPS PCI cards now shows a wrong leap second date for 2021, too: UTC correction parameters: t0t: 2057|405504.000, A0: -9.31323e-10 A1: -2.66454e-15 WNlsf: 2185, DN: 7, offs: 18/18 Last leap second eventually at UTC midnight at the end of Sat, 2021-11-27 while just recently the displayed leap second date was (correctly) 2016-12-31. However, Meinberg GPS receivers evaluate WNlsf *only* if the 2 offset values differ, i.e. there is really an announcement of a leap second, and WNlsf is in a valid range, so these receivers don't have a problem with a wrong leap second. If no leap second is announced then extended week number and thus the date *can* be wrong, but it's just informational, and the word "eventually" is used to point out the ambiguity. Martin ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug
On Tue 2019-06-11T13:33:44-0700 Paul Hirose hath writ: > issued another letter to its user group, highlighting the exact problem: “We > found that a software design error resulted in the system misinterpreting > GPS time updates due to a ‘leap second’ event, which typically occurs once > every 2.5 years within the U.S. Government GPS satellite almanac update. Our > GPS-4000S-100 version software's timing calculations have reacted to this > leap second by not tracking satellites upon power-up and subsequently > failing. The U.S. Government distributed a regularly scheduled almanac > update with this ‘leap second’ on 0:00GMT, Sunday, June 9, 2019, and the > failures began to occur soon after.” This is obscuration throwing blame where it does not belong. Other models of GPS have had no problems. Better reporters have indicated that that the manufacturer issued a bad software update. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] aircraft GPS receivers hit by leap second bug
[from Flying magazine] Collins Aerospace notified its user base of a cascade of reports it had received beginning at 00:00Z on June 9 that certain GPS and GLU models were not operating properly. The specific models, the GPS-4000S sensor and the GLU-2100 multi-mode receiver (supporting ADS-B Out requirements), are installed in Collins Pro Line 21 and Pro Line Fusion avionics systems in many business jets, as well as in some aircraft used by regional and major airlines. In fact, Forbes reported on June 9 that a slew of airlines had cancelled flights on Sunday because of similar issues—including a group of Boeing 717s flown by Hawaiian Airlines. When we contacted Collins Aerospace on the morning of June 10, we were sent the bulletin noted earlier, and advised that operators were encouraged to call in with their experience and contact information so that they could be informed of a resolution when it had been found. Later that day, Collins issued another letter to its user group, highlighting the exact problem: “We found that a software design error resulted in the system misinterpreting GPS time updates due to a ‘leap second’ event, which typically occurs once every 2.5 years within the U.S. Government GPS satellite almanac update. Our GPS-4000S-100 version software's timing calculations have reacted to this leap second by not tracking satellites upon power-up and subsequently failing. The U.S. Government distributed a regularly scheduled almanac update with this ‘leap second’ on 0:00GMT, Sunday, June 9, 2019, and the failures began to occur soon after.” Collins advises operators not to power up units until after the next scheduled update by the US government on June 16, 2019, at 00:15Z. [end quote] https://www.flyingmag.com/collins-receivers-struck-by-failure-modes/ The Avweb site has also picked up the story: https://www.avweb.com/news/collins-gps-errors-spark-flight-delays/ Thinking I had missed a pending leap second, I checked the IERS site, but Bulletin C says the offset is still 37 seconds and nothing is scheduled. ??? ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
