Hi all,
matsakis.demetrios_at_USNO.NAVY.MIL wrote:
>
> -----Original Message-----
> From: Jim Ray [mailto:jray_at_bipm.org]
> Sent: Tuesday, November 04, 2003 3:21 AM
> To: igsmail_at_igscb.jpl.nasa.gov
> Cc: ruth.neilan_at_jpl.nasa.gov
> Subject: [IGSMAIL-4679]: upcoming UTC anomaly
>
> ****************************************************************************
> **
> IGS Electronic Mail 04 Nov 00:20:13 PST 2003 Message Number 4679
> ****************************************************************************
> **
>
> Author: Jim Ray
>
> FYI, here is my synthesis of reports from a variety of sources
> floating around the Internet.
>
> At the end of 27 Nov 2003, exactly 256 weeks will have elapsed since
> the last UTC leap second, at the end of 31 Dec 1998. Because the GPS
> week number counter in the UTC subframe data message is only 8 bits
> (maximum value of 256), it will reset. Receivers that do not account
> for the truncated GPS week values when determining UTC from GPS time
> may report an invalid UTC date.
[...]
The GPS Interface Control Document (ICD) states in paragraph 20.3.3.5.4
that:
"The user must account for the truncated nature of this parameter as
well as truncation of WN, WNt, and WNlsf due to rollover of the full
week number. The CS shall manage these parameters such that the absolute
value of the difference between the untruncated WN and WNlsf values
shall not exceed 127."
It would be easy for the GPS Control Segment to prevent us from that
anomaly.
At the end of August I've already sent a proposal to
nisws_at_navcen.uscg.mil how that anomaly could easily be omitted, but the
people at the NaveCen are so arrogant that they find they needn't even
send any reply.
There would be an easy way to prevent that failures: if the GPS control
segment would upload a leap second week number (WNlsf in the ICD) which
corresponds to a truncated week number in the recent past, e.g. two
weeks ago, then any GPS receiver would decode the week number correctly,
determine that the leap second has occurred just two weeks ago, and thus
continue to work without error.
Since both the number of leap seconds transmitted by the satellites
(delta_t_ls and delta_t_lsf in the ICD) contain the same numbers, the
GPS receivers see the same conditions as if a leap second had really
been inserted two weeks ago.
For example, the current week number is 1233, two weeks ago is 1231,
i.e. 4CF hex, so the control segment should simply set the 8 bit
truncated week number to CF hex.
If there will be no leap seconds in the future, the uploaded week number
could be updated every few weeks to prevent from the rollover in the
future.
Regards,
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
Received on Mon Nov 10 2003 - 04:19:17 PST