Tom,
Tom Van Baak wrote:
>> 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'
Tom Van Baak wrote:
>> However, the current GPS/UTC offset numbers before and after the nearest
>> leap seconds are still 18/18, so there is no current leap second
>> announcement, and WNlsf may be ambiguous.
>
> Perhaps call it "immaterial" rather than "ambiguous"? The fact that it's
> 18/18 mean
On Wed, Jun 12, 2019 at 8:39 AM Richard Langley wrote:
> And a further nit-pick. The leap-second information is not included in the
> GPS Almanac (as reported in news items), per se. Of course, it's in the
> navigation message, but elsewhere in the Subframe 4 and 5 data. And it is
> only needed t
And a further nit-pick. The leap-second information is not included in the GPS
Almanac (as reported in news items), per se. Of course, it's in the navigation
message, but elsewhere in the Subframe 4 and 5 data. And it is only needed to
relate GPS Time to UTC. Most GPS receivers operate on GPS Ti
In message <7bca6012-4303-68e7-bd57-85bf881fd...@burnicki.net>, Martin Burnicki
writes:
>UTC correction parameters:
> t0t: 2057|405504.000, A0: -9.31323e-10 A1: -2.66454e-15
> WNlsf: 2185, DN: 7, offs: 18/18
>Last leap second eventually at UTC midnight at the end of Sat, 2021-11-27
> However, the current GPS/UTC offset numbers before and after the nearest
> leap seconds are still 18/18, so there is no current leap second
> announcement, and WNlsf may be ambiguous.
Perhaps call it "immaterial" rather than "ambiguous"? The fact that it's
18/18 means no positive or negative l
Paul Hirose wrote:
> Thinking I had missed a pending leap second, I checked the IERS site,
> but Bulletin C says the offset is still 37 seconds and nothing is
> scheduled. ???
The GPS satellites transmit the week number of the nearest leap second
(WNlsf) as 8 bit value only, giving a valid range o
On Tue 2019-06-11T13:33:44-0700 Paul Hirose hath writ:
> issued another letter to its user group, highlighting the exact problem: “We
> found that a software design error resulted in the system misinterpreting
> GPS time updates due to a ‘leap second’ event, which typically occurs once
> every 2.5
[from Flying magazine]
Collins Aerospace notified its user base of a cascade of reports it had
received beginning at 00:00Z on June 9 that certain GPS and GLU models
were not operating properly. The specific models, the GPS-4000S sensor
and the GLU-2100 multi-mode receiver (supporting ADS-B Ou