[time-nuts] NAVSTAR proteus GPS time and frequency unit

Mon Nov 9 20:00:29 EST 2015

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:
>>
>> paulswedb at 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 at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.