[time-nuts] Re: Ublox messages before/after leap second event

[HÃ¥kan T Johansson]

Hi Markus,

thanks!

Yes, it is the field 'timeToLsEvent' I am mostly curious about.

Looking at the output from an LEA-M8T now, it gives reports that 
should extrapolate to having been:

2021-11-28 00:00:00 timeToLsEvent=0
2021-11-28 00:00:01 timeToLsEvent=-1

after the non-event at/after 2021-11-27 23:59:59, i.e. 256 weeks after the 
most recent actual leap-second 2016-12-31.  Since GPS only report leap 
second placement with 8 bits for the week number, this is as much as the 
ublox receiver can know.

That however does not tell how it would have looked after a real event.

This is the current report from the LEA-M8T (other messages omitted):

PPS-1
UART-1: UBX-NAV-TIMELS: 1b4093e8 00 00 00 00 02 12 02 00 fcdf5f11=-607d6h59m59s 0889 0007 00 00 00 03
UART-1: $GNRMC,065959.00,A,5742.76987,N,01201.36421,E,0.034,,280723,,,A*60
PPS-1
UART-1: UBX-NAV-TIMELS: 1b4097d0 00 00 00 00 02 12 02 00 fcdf5f10=-607d7h0m0s 0889 0007 00 00 00 03
UART-1: $GNRMC,070000.00,A,5742.76987,N,01201.36420,E,0.034,,280723,,,A*60
PPS-1
UART-1: UBX-NAV-TIMELS: 1b409bb8 00 00 00 00 02 12 02 00 fcdf5f0f=-607d7h0m1s 0889 0007 00 00 00 03
UART-1: $GNRMC,070001.00,A,5742.76987,N,01201.36418,E,0.034,,280723,,,A*6A

607 days is since then, i.e. 607 + 256*7 = 2399 days since 2016-12-31.
(365+365+365+366+365+365 + 31+28+31+30+31+30 + 27 = 2399)


For leap-second adjustment handling, I would anyhow base its happening on 
the actual time, and not the timeToLsEvent count-down hitting a specific 
value.

So easiest is likely to accept timeToLsEvent if it is counting and within 
+/- a few seconds around 0 at the critical time, and the leap delta to be 
non-zero.  As well as the time being 23:59:5x and the day the last of the 
month, or only 06-30 or 12-31 for now.

Most interesting would be the testing infrastructure I need to make 
probable that the code is working.  It does not make sense to handle a 
rare circumstance and then get other problems with normal behaviour.

My default handling right now is that after 7 reports of mismatching time 
(or just missing) $G?RMC (which would be 7 s after a leap-second) it stops 
claiming to be syncronised when reporting according to the old scale. 
Then it takes another 8 reports until it accepts and reports according to 
the new timescale.

Cheers,
HÃ¥kan


On Thu, 27 Jul 2023, Markus Kleinhenz via time-nuts wrote:

> Hi HÃ¥kan,
>
>> https://www.maths.tcd.ie/~dwmalone/time/leap2016/#nmea
>
> has a NMEA recording from an MAX-M8q from 2016.
>
> As for UBX-NAV-TIMELS:
>
> Are you talking about the field 'timeToLsEvent'?
>
> As the NMEA shows u-blox counting to second 60 I would assume it working
> like this:
>
> 11:59:58 timeToLsEvent=+2
> 11:59:59 timeToLsEvent=+1
> 11:59:60 timeToLsEvent=0
> 00:00:00 timeToLsEvent=-1
> 00:00:01 timeToLsEvent=-2
>
> Or for negative leap seconds:
>
> 11:59:58 timeToLsEvent=+1
> 00:00:00 timeToLsEvent=-1
>
> But these are only educated guesses.
>
>
> Regards,
> Markus
>
>
> Am 26.07.2023 um 19:21 schrieb HÃ¥kan T Johansson via time-nuts:
>>
>> Hi,
>>
>> I am looking for a dump of Ublox GPS messages at or around a leap second
>> event.  Was a while since the last...
>>
>> In particular the message UBX-NAV-TIMELS (b5 62 01 26) which contains
>> leap upcoming leap second info, and the seconds to/since the event.  To
>> know which second is considered as the '0' for the indicator in the
>> message.
>>
>> Just NMEA messages around a leap second event would be intresting too.
>>
>> This is for my FPGA GPS/NTP project.
>>
>> Cheers,
>> HÃ¥kan
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>