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 -- [email protected] > 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. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
