[LEAPSECS] 256-week / leap seconds / in the news

[Martin Burnicki]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20210725/0d4cd76b/attachment.sig>