paulswedb@gmail.com said:

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.

--
These are my opinions.  I hate spam.

OK great conversation.
Not sure when but far sooner then later will fire the system up and just
let it run for a week.
Regards
Paul
WB8TSL

On Mon, Nov 9, 2015 at 1:09 PM, Hal Murray hmurray@megapathdsl.net 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:

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:

GPS Time ignores (does not deal with) "Leap Seconds."
It is dealt with in the software translation from GPS time to UTC or local
time.
That is part of the reason there is a 16 second time difference between GPS
Time and UTC/local time.

--- Graham

==

On Mon, Nov 9, 2015 at 4:15 PM, Chuck Harris cfharris@erols.com wrote:

Well for the heck of it I just fired the austron 2201 up. Date was circa
1980 or something way back. Guess the battery went. That said set the date
and time to UTC and let it go. Almanac seems to grab a satellite every now
and then but it does not go into the full track mode.
I normally cheat this with a semi-automatic acquire and give it a list of
know satellites. But will just let it run for a day or so.
Regards
Paul
WB8TSL
Need to watch it this is not my thread.

On Mon, Nov 9, 2015 at 8:11 PM, Graham / KE9H ke9h.graham@gmail.com wrote:

Magnus,

Thanks for the detailed reply.  I haven't had a need (read: no customer
has paid me to do so...) to wallow through the GPS ICD, so that document
is foreign to me.

Your explanation clarifies the situation...  Now it makes sense.

Thanks!

-Chuck Harris

Magnus Danielson wrote:

...