Chuck,
Because all the leap-second info is kept in GPS-calender form, and
essentially indicating current leap-second difference and which GPS week
(modulo 256). Check out the ICD for yourself, IS-GPS-200H:
8<---
20.3.3.5.2.4 Coordinated Universal Time (UTC).
Page 18 of subframe 4 includes: (1) the parameters needed to relate GPS
time to UTC, and (2) notice to the user regarding the scheduled future
or recent past (relative to NAV message upload) value of the delta time
due to leap seconds (ΔtLSF), together with the week number (WNLSF) and
the day number (DN) at the end of which the leap second becomes
effective. "Day one" is the first day relative to the end/start of week
and the WNLSF value consists of eight bits which shall be a modulo 256
binary representation of the GPS week number (see paragraph 6.2.4) to
which the DN is referenced. The user must account for the truncated
nature of this parameter as well as truncation of WN, WNt, and WNLSF due
to rollover of full week number (see paragraph 3.3.4(b)). The CS shall
manage these parameters such that, when ΔtLS and ΔtLSF differ, the
absolute value of the difference between the untruncated WN and WNLSF
values shall not exceed 127.
Depending upon the relationship of the effectivity date to the user's
current GPS time, the following three different UTC/GPS-time
relationships exist:
a. Whenever the effectivity time indicated by the WNLSF and the DN
values is not in the past (relative to the user's present time), and the
user's present time does not fall in the time span which starts at six
hours prior to the effectivity time and ends at six hours after the
effectivity time, the UTC/GPS-time relationship is given by
tUTC = (tE - ΔtUTC) [modulo 86400 seconds]
where tUTC is in seconds and
ΔtUTC = ΔtLS + A0 + A1 (tE - tot + 604800 (WN - WNt)), seconds;
tE =GPS time as estimated by the user after correcting tSV for factors
described in paragraph 20.3.3.3.3 as well as for selective availability
(SA) (dither) effects;
ΔtLS = delta time due to leap seconds;
A0 and A1 = constant and first order terms of polynomial;
tot = reference time for UTC data (reference 20.3.4.5);
WN = current week number (derived from subframe 1);
WNt = UTC reference week number.
The estimated GPS time (tE) shall be in seconds relative to end/start of
week. During the normal and short-term extended operations, the
reference time for UTC data, tot, is some multiple of 212 seconds
occurring approximately 70 hours after the first valid transmission time
for this UTC data set (reference 20.3.4.5). The reference time for UTC
data (tot) shall be referenced to the start of that week whose number
(WNt) is given in word eight of page 18 in subframe 4. The WNt value
consists of eight bits which shall be a modulo 256 binary representation
of the GPS week number (see paragraph 6.2.4) to which the tot is
referenced. The user must account for the truncated nature of this
parameter as well as truncation of WN, WNt, and WNLSF due to rollover of
full week number (see paragraph 3.3.4(b)). The CS shall manage these
parameters such that the absolute value of the difference between the
untruncated WN and WNt values shall not exceed 127.
b. Whenever the user's current time falls within the time span of six
hours prior to the effectivity time to six hours after the effectivity
time, proper accommodation of the leap second event with a possible week
number transition is provided by the following expression for UTC:
tUTC = W[modulo (86400 + ΔtLSF - ΔtLS)], seconds;
where
W = (tE - ΔtUTC - 43200) [modulo 86400] + 43200, seconds;
and the definition of ΔtUTC (as given in 20.3.3.5.2.4a above) applies
throughout the transition period. Note that when a leap second is added,
unconventional time values of the form 23:59:60.xxx are encountered.
Some user equipment may be designed to approximate UTC by decrementing
the running count of time within several seconds after the event,
thereby promptly returning to a proper time indication. Whenever a leap
second event is encountered, the user equipment must consistently
implement carries or borrows into any year/week/day counts.
c. Whenever the effectivity time of the leap second event, as indicated
by the WNLSF and DN values, is in the "past" (relative to the user's
current time), and the user’s current time does not fall in the time
span as given above in 20.3.3.5.2.4b, the relationship previously given
for tUTC in 20.3.3.5.2.4a above is valid except that the value of ΔtLSF
is substituted for ΔtLS. The CS will coordinate the update of UTC
parameters at a future upload so as to maintain a proper continuity of
the tUTC time scale.
--->8
The GPS date gears is different to normal dates, and all relevant events
is related in the form of these gears (or own set of scales if you so
like). The UTC information is no exception, it is more of the same, so
getting these things right follows the same pattern. You can do all
things perfectly correct, even if your displayed user date does not look
correct, of by 1024 weeks. I find this misconception of how GPS
receivers operate because very often people does not bother to look at
the details but only view it from their assumption of how it operates.
Since the IS-GPS-200H is a public document, download it and read it,
preferably with a good GPS book as useful reference. I had to explain
the 1024 week issue in a NTP bug, and it took some explanation before
they "got it" that this is really a system bug that receivers may or may
not "paper over". The new GPS signals have 13 bits of week numbers, so
that should make the new receivers able to handle the situation more
gracefully for a couple of years.
Cheers,
Magnus
On 11/09/2015 11:15 PM, Chuck Harris wrote:
Seems to me that there is more to this than just
getting the displayed date wrong.
It is true that the date will present wrongly, but
what about leap seconds?
If the GPS week rolls over at 1024, how will the
GPS figure out which is the proper calendar date
to apply the leap second?
-Chuck Harris
Hal Murray wrote:
paulsw...@gmail.com said:
Hmmm then why do I have to figure it out at all? I don't care what
the date
says.
Only that the Austron locks and does its frequency offset compare. It
would
be great not to have to do this.
If you don't care about the date, then don't worry about it.
It will do everything it did before. The only glitch is that the date
will
be off by 1024 weeks.
If you can't get the right date into your GPS unit, you can work
around the
issue in software. Just add 1024 weeks to the date until the date is
past
the build time of your fixup software.
That assumes you have some software to work with. That won't help if
you are
using a program that the vendor no longer supports.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
