Tom, Tom Van Baak wrote:
Steve,I'm thinking the problem is not with GPS or with modulo arithmetic.
I fully agree.
I'm in contact with Leo and others for the root cause or the scope of the problem as reported on twitter. I'll say more later.Per the GPS ICD, when dt_LS == dt_LSF there is no leap second to speak of; not in recent past; not in near future. The 8-bit WN and DN fields are not applicable to a non event.
That's exactly what the firmware has to be taken into account.Some old firmware of the first Meinberg GPS receivers back in the 1990es had a similar problem.
At that time there were leap seconds inserted once every 12 or 18 months. Also, at that time the expectation was then, that the interval between leap seconds would become shorter, and not longer, and I guess the folks who designed the data format for the GPS satellites assumed that the offset +/- 127 week from "now" was sufficient to handle that.
Meinberg GPS receivers use a 16 bit week number internally, and it was derived from the 10 bit week number of the "current" GPS time.
The 8 bit week number included in the UTC offset parameter set had to be expanded to that 16 bit week number.
So the very old Meinberg firmware also tried to expand the 8 bit week number to determine when the next leap second event would be and *then* looked at the 2 UTC offset parameters before and after that even.
Happily, it soon became clear that this was a wrong approach, and the handling was changed.
When dt_LS != dt_LSF you know there is a nearby leap second event. You then look at WN and DN to determine when. It could have been in the recent past, it could be in the near future, or even in progress. By "recent past" and "near future" I mean ±127 weeks (about ±2½ years).
Exactly. That's what the Meinberg GPS firmware now does when it evaluates the UTC parameter set from the satellites.
Of course, even if no leap second is scheduled, the truncated week number and day number of the latest leap second event are still transmitted, and in fact you can show the date derived from the expanded week number, but the date alone is just informational, and not considered as upcoming leap second event.
In fact, also the Meinberg GPS receiver firmware derives an extended week number 2185 from the satellite data. The "mbgstatus" program from an older version of the Meinberg driver software package for GPS PCI cards now shows the same wrong week number which refers to a leap second event in November 2021:
---------------------------------------------------------------- UTC correction parameters: CSUM: 1550, valid: 0001 t0t: 2168|147456.0000000, A0: 0 A1: -1.77636e-15 WNlsf: 2185, DN: 7, offs: 18/18 Last leap second eventually at UTC midnight at the end of Sat, 2021-11-27 ----------------------------------------------------------------But, as said earlier, this is only informational. Because the 2 UTC offset values are identical ("18/18"), the PCI card and API won't generate a leap second warning in November.
Some time ago, you (Tom) published an idea that could help to determine the real week number from the truncated on, and solve the +/- 127 week ambiguity. The point was to not only check the week number from the UTC parameter set, but also the day number, and the combination of week number and day number should expand to the end of June or December.
I've implemented that in our library, and the "mbgstatus" program from the current driver package shows (in verbose mode) the true date of the latest leap second event:
---------------------------------------------------------------- UTC correction parameters: CSUM: 15DA, valid: 0001 t0t: 2168|233472.0000000, A0: 0 A1: -1.77636e-15 WNlsf: 2185 (true: 1929), DN: 7, offs: 18/18 Current GPS/UTC offset: 18 s, no leap second announced. Nearest leap second just before UTC midnight on Sun, 2017-01-01. ----------------------------------------------------------------
Clearly this design means GPS cannot give indefinite past history of a previous leap second(s), nor indefinite future notice of a pending leap second(s). This is not a problem given how UTC is currently defined and managed. BIPM has a good track record of 6 months (~26 weeks) of notice. The official UTC spec is 1 month (~4 weeks) of notice so a 127 week GPS limit is more than adequate.
Yes, but as you can see above, your idea to solve the ambiguity was really helpful. Thanks for that.
On 7/25/2021 8:54 AM, Steve Allen wrote:On Sat 2021-07-24T18:50:50-0700 Tom Van Baak hath writ:In the news: "GPS will broadcast a 0 second leap second in 128 days" https://news.ycombinator.com/item?id=27944776
I think the title of this article is just misleading.As far as I can see, the GPS satellites are transmitting data according to the specs (ICD), and the expansion of the truncated week number is not ambiguous *if* a leap second is scheduled, and the leap second date is within the +/- 127 weeks range from the current week.
Martin
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
