[LEAPSECS] aircraft GPS receivers hit by leap second bug

[Tom Van Baak]

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

And, in addition, it also allows one to determine which GPS cycle you 
are in.
I sent simulation results to one of you some years ago. I'll attach it here.
This is the output from gpsweek2 in my www.leapsecond.com/tools/ directory.

Ok, it's a hack, but one that appears to work as long as 2SOPS maintains UTC
leap second WN and DN values during long stretches between leap seconds.

The key to the trick is to realize that, as currently defined, from 1980 to,
say, 2100, there are only 240 possible leap seconds (June & December every
year for 120 years) out of 1440 months out of 43825 days.

For example, if GPS reported the 8-bit WN_lsf is 137 and the 3-bit DN is 7,
then the actual UTC date could be any one of:

WNe  137 (0x0089), cycle 0 WN10  137 (0x089), WN8 137 (0x89), DN7, 
1982-08-28
WNe  393 (0x0189), cycle 0 WN10  393 (0x189), WN8 137 (0x89), DN7, 
1987-07-25
WNe  649 (0x0289), cycle 0 WN10  649 (0x289), WN8 137 (0x89), DN7, 
1992-06-20
WNe  905 (0x0389), cycle 0 WN10  905 (0x389), WN8 137 (0x89), DN7, 
1997-05-17
WNe 1161 (0x0489), cycle 1 WN10  137 (0x089), WN8 137 (0x89), DN7, 
2002-04-13
WNe 1417 (0x0589), cycle 1 WN10  393 (0x189), WN8 137 (0x89), DN7, 
2007-03-10
WNe 1673 (0x0689), cycle 1 WN10  649 (0x289), WN8 137 (0x89), DN7, 
2012-02-04
WNe 1929 (0x0789), cycle 1 WN10  905 (0x389), WN8 137 (0x89), DN7, 
2016-12-31
WNe 2185 (0x0889), cycle 2 WN10  137 (0x089), WN8 137 (0x89), DN7, 
2021-11-27
WNe 2441 (0x0989), cycle 2 WN10  393 (0x189), WN8 137 (0x89), DN7, 
2026-10-24
WNe 2697 (0x0a89), cycle 2 WN10  649 (0x289), WN8 137 (0x89), DN7, 
2031-09-20
WNe 2953 (0x0b89), cycle 2 WN10  905 (0x389), WN8 137 (0x89), DN7, 
2036-08-16
WNe 3209 (0x0c89), cycle 3 WN10  137 (0x089), WN8 137 (0x89), DN7, 
2041-07-13
WNe 3465 (0x0d89), cycle 3 WN10  393 (0x189), WN8 137 (0x89), DN7, 
2046-06-09
WNe 3721 (0x0e89), cycle 3 WN10  649 (0x289), WN8 137 (0x89), DN7, 
2051-05-06
WNe 3977 (0x0f89), cycle 3 WN10  905 (0x389), WN8 137 (0x89), DN7, 
2056-04-01
WNe 4233 (0x1089), cycle 4 WN10  137 (0x089), WN8 137 (0x89), DN7, 
2061-02-26
WNe 4489 (0x1189), cycle 4 WN10  393 (0x189), WN8 137 (0x89), DN7, 
2066-01-23
WNe 4745 (0x1289), cycle 4 WN10  649 (0x289), WN8 137 (0x89), DN7, 
2070-12-20
WNe 5001 (0x1389), cycle 4 WN10  905 (0x389), WN8 137 (0x89), DN7, 
2075-11-16
WNe 5257 (0x1489), cycle 5 WN10  137 (0x089), WN8 137 (0x89), DN7, 
2080-10-12
WNe 5513 (0x1589), cycle 5 WN10  393 (0x189), WN8 137 (0x89), DN7, 
2085-09-08
WNe 5769 (0x1689), cycle 5 WN10  649 (0x289), WN8 137 (0x89), DN7, 
2090-08-05
WNe 6025 (0x1789), cycle 5 WN10  905 (0x389), WN8 137 (0x89), DN7, 
2095-07-02
WNe 6281 (0x1889), cycle 6 WN10  137 (0x089), WN8 137 (0x89), DN7, 
2100-05-29

So as you suspect there's lots of ambiguity here. But, look closer. Only 
*one*
of those dates is the last day of June or December. Therefore this 
leaves you
with a single unique answer instead of 25 ambiguous answers:

WNe 1929 (0x0789), cycle 1 WN10  905 (0x389), WN8 137 (0x89), DN7, 
2016-12-31

In other words, not only does this trick pinpoint which 256 week cycle that
you're in, but also which 1024 week cycle you're in. Hence, it's not only a
solution to obtaining the actual date of the recent or next leap second, but
it also tells you which 19.x year GPS cycle you're in. No more WNRO 
problems.

I wish I had come up with this 20 years ago; before the first WNRO. On 
the other
hand, it's a fragile hack that depends on leap seconds existing, on 
there being
at most 2 per year, and that 2SOPS retains leap second information in the
broadcast message even when there is no leap second pending.

/tvb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20190613/d839f7ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpsweek2-120y.txt.gz
Type: application/x-gzip
Size: 312368 bytes
Desc: not available
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20190613/d839f7ff/attachment-0001.bin>