[time-nuts] Garmin 18x GPS WNRO

[David G. McGaw]

I have a number of Garmin GPS-35s and GPS-18s.  In checking before the 
rollover, some had their RTC still running and one had lost the battery 
backup.  The ones with the correct date were OK as-is and the other just 
needed the Nonvolatile Memory updated with the correct date to come back 
into it.  All were fine through the event.  I expected they would be as 
I had brought the GPS-35s through the last rollover.  I like Garmin.  I 
wish Trimble had put this feature in the Thunderbolt.

David N1HAC


On 4/8/19 10:03 AM, Tom Van Baak wrote:
> Thanks to that Pulsar / Garmin thread some weeks ago I happened to be continuously logging serial/USB NMEA data from a Garmin 18x receiver.
>
> The PGRMF sentence was enabled. This Garmin-unique message reports both UTC date & time as well as GPS week & second. It's a very nice feature. As per-spec, GPS week goes from 0 to 1023 and GPS second goes from 0 to 604799 (7 x 86400, a week a seconds).
>
> And it worked perfectly. Here's the log:
>
> $PGRMF,1023,604793,060419,235935,18,4733.2519,N,12208.3663,W,A,2,0,337,2,1*3E
> $PGRMF,1023,604794,060419,235936,18,4733.2519,N,12208.3663,W,A,2,0,337,2,1*3A
> $PGRMF,1023,604795,060419,235937,18,4733.2519,N,12208.3663,W,A,2,0,337,2,1*3A
> $PGRMF,1023,604796,060419,235938,18,4733.2519,N,12208.3664,W,A,2,0,337,2,1*31
> $PGRMF,1023,604797,060419,235939,18,4733.2519,N,12208.3664,W,A,2,0,337,2,1*31
> $PGRMF,1023,604798,060419,235940,18,4733.2519,N,12208.3664,W,A,2,0,337,2,1*30
> $PGRMF,1023,604799,060419,235941,18,4733.2519,N,12208.3664,W,A,2,0,337,2,1*30  //  last second of 2nd GPS epoch
> $PGRMF,0,0,060419,235942,18,4733.2519,N,12208.3664,W,A,2,0,337,2,1*36  //  first second of 3rd GPS epoch
> $PGRMF,0,1,060419,235943,18,4733.2519,N,12208.3664,W,A,2,0,337,2,1*36
> $PGRMF,0,2,060419,235944,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*33
> $PGRMF,0,3,060419,235945,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*33
> $PGRMF,0,4,060419,235946,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*37
> $PGRMF,0,5,060419,235947,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*37
> $PGRMF,0,6,060419,235948,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*3B
> $PGRMF,0,7,060419,235949,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*3B
> $PGRMF,0,8,060419,235950,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*3C
> $PGRMF,0,9,060419,235951,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*3C
> $PGRMF,0,10,060419,235952,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*07
> $PGRMF,0,11,060419,235953,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*07
> $PGRMF,0,12,060419,235954,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*03
> $PGRMF,0,13,060419,235955,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*03
> $PGRMF,0,14,060419,235956,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*07
> $PGRMF,0,15,060419,235957,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*07
> $PGRMF,0,16,060419,235958,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*0B
> $PGRMF,0,17,060419,235959,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*0B  //  last second of April 6th UTC
> $PGRMF,0,18,070419,000000,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*04  //  first second of April 7th UTC
> $PGRMF,0,19,070419,000001,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*04
> $PGRMF,0,20,070419,000002,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*0D
> $PGRMF,0,21,070419,000003,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*0D
> $PGRMF,0,22,070419,000004,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*09
> $PGRMF,0,23,070419,000005,18,4733.2519,N,12208.3665,W,A,2,0,337,2,1*09
>
> You can see the GPS WNRO occur between:
>      1023,604799 and 0,0 GPS time, which is 060419,235941 and 060419,235942 UTC time.
>
> And you can see the delta between the GPS timescale and UTC timescale (18 leap seconds) at:
>     0,17 and 0,18 GPS time, which is 060419,235959 and 070419,000000 UTC time.
>
> Note that GPS WNRO (week number rollover) is unrelated to leap seconds, per se. They are completely separate, though both interesting and awkward disruptions in integer timekeeping.
>
> But because of the sum of leap seconds since GPS time began on 1980-1-6, there is currently an 18 second delta between GPS week rollover and UTC midnight rollover. This is why carefully written technical notes do not say GPS rollover occurs at midnight. Rather, they say it occurs near midnight (UTC). Or it occurred between April 6 and 7, 2019, or slightly vague words to that effect. Lots of words, papers, and all. But the above log shows it nicely.
>
> /tvb
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.febo.com%2Fmailman%2Flistinfo%2Ftime-nuts_lists.febo.com&data=02%7C01%7Cdavid.g.mcgaw%40dartmouth.edu%7C4d85ff3297814d94b1ad08d6bc2ca298%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636903297227141273&sdata=AvXPezDoCfCf7OD1nOtLzNvNFW713w0ewaa15hnH0TU%3D&reserved=0
> and follow the instructions there.