[time-nuts] Re: Another leap second problem

[Tom Van Baak]

Here's a quick follow-up and resolution. The bug is real and it's not in 
GPS, not in the u-blox GPS receiver, not in "NTP" per se, but instead a 
rare-event code mistake in the embedded implementation of the 
high-performance NTP server that's in the LeoNTP Time Server 1200. Leo 
confirmed the 512 week theory [1] and just posted:

 > This issue has been corrected and the updated firmware 2.07 is
 > available here: https://www.leobodnar.com/files/LeoNTP-1200-v207.zip
 > The older legacy unit is not affected.
 > Many thanks for letting me know!

Thanks to Steve Sommars for bringing this interesting case to time-nuts, 
and thanks to Leo Bodnar for a quick code fix to their product. We 
normally don't discuss mundane NTP issues here on time-nuts but this one 
was cool.

For those of you interested: if WN_ls and WN_lsf fields in page 18 of 
subframe 4 of GPS are equal, then no leap second is pending, and further 
processing of leap second related fields is not necessary. The nerdy 
details are in section 20.3.3.5.2.4 of the GPS ICD [2]. I accidentally 
caught the 256 week event the first time it happened [3].

Thanks also to several posters who shared the gps-sdr-sim link [4]. I 
hope more time nuts play with it and report their findings.

/tvb

[1] 
https://febo.com/pipermail/time-nuts_lists.febo.com/2025-November/110278.html

[2] https://www.navcen.uscg.gov/sites/default/files/pdf/gps/IS-GPS-200N.pdf

[3] http://leapsecond.com/notes/leapsec256.htm

[4] https://github.com/osqzss/gps-sdr-sim