In message <[EMAIL PROTECTED]>, Steve Allen writes:
>The inclusion of calendar year is an interesting addition to the
>original week-based scheme. The week-based scheme was perhaps chosen
>while noting that the week remained intact when Pope Gregory (and
>then, eventually, all the protestants) sw
On Mon 2005-09-26T10:27:11 -0400, John.Cowan hath writ:
> In addition, since GPS time is TAI - 19s, the GPS-UTC difference will
> eventually overflow any fixed-sized transmission packet (if transmitted
> as a delta or as a table, it makes no difference in the end).
Yes, but (as already mentioned)
> But a GPS receiver which uses the current leap second
> offset (UTC against GPS time) to help guess which 1024
> week period it is in will _eventually_ not work quite
> right.
I guess that begs the question - which of the hundred
GPS receiver manufacturers actually use the LS field
in the UTC su
I wrote:
So, dropping leap seconds from UTC would cause these receivers
to, eventually, go back 19 years on cold start? Hardly a major
catastrophe but worth noting.
Tom Van Baak replied:
There are no proposals to "drop leap seconds" as
such. The proposal, as I understand it, is/was to
hold le
: LEAPSECS@ROM.USNO.NAVY.MIL
Subject: Re: [LEAPSECS] RAS hits the news
Hornaday, Tem SPAWAR wrote:
> ...
> 3. As has been pointed out, some receivers also implement a clever
> hack to determine date that looks at UTC Leap Second (LS) value, and
> chooses a date based on WN, TOW, and
> So, dropping leap seconds from UTC would cause these receivers
> to, eventually, go back 19 years on cold start? Hardly a major
> catastrophe but worth noting.
Ed,
There are no proposals to "drop leap seconds" as
such. The proposal, as I understand it, is/was to
hold leap seconds at their curr
Hornaday, Tem SPAWAR wrote:
...
3. As has been pointed out, some receivers also implement a clever hack
to determine date that looks at UTC Leap Second (LS) value, and chooses
a date based on WN, TOW, and LS. That is, the receiver implements a
sliding 1024-week window whose limits are determine
Warner,
> These instances of overflow come from remainders of division
> operations overflowing. They all can be derived from a single base
> number (say number of seconds since 1970, MJD, etc). However, when
> you are deriving that single base number, it can be much harder.
Yeah, I also prefer
In message: <[EMAIL PROTECTED]>
"Tom Van Baak" <[EMAIL PROTECTED]> writes:
: Too much is made of the "overflow". Fields rollover all
: the time in real life and it's often a simple engineering
: matter to take this into account. Not sure I would call
: it "cheating". We get by fine with
Regarding GPS receiver date determination:
1. The GPS navigation message is 12.5 minutes long. A receiver should
resolve UTC correctly within 12.5 minutes. See ICD-GPS-200 (publicly
released).
2. Virtually all receivers can correctly resolve date (and will do so
quickly), given an initializat
> A cold GPS receiver takes about 20 minutes to get the almanac data
> from the GPS constellation. It is intrinsic to GPS that this is the
> case. You cannot get around this.
It's easy to solve that if the application requires it.
You could get the almanac from an external source;
such as anothe
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes:
>I think that it depends on the model of oncore receiver. The M12+
>appears to cache the almanac wrt leap seconds for a period of time
>after power is removed from them (I'm sure it does this if the power
>is off for minutes, I'm sure it doe
In message: <[EMAIL PROTECTED]>
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
: At least the Oncore receives will happily use a 2 year old alamanc
: to aid in getting first fix.
I've seen some receivers that don't do this, and consequently have
trouble getting first fix. These may b
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes:
>In message: <[EMAIL PROTECTED]>
>Rob Seaman <[EMAIL PROTECTED]> writes:
>: The question is whether "at least 20 minutes" (presuming this to be
>: accurate) is intrinsic to the system design or is rather a result of
>: poor implem
In message: <[EMAIL PROTECTED]>
"Tom Van Baak" <[EMAIL PROTECTED]> writes:
: > In addition, since GPS time is TAI - 19s, the GPS-UTC difference will
: > eventually overflow any fixed-sized transmission packet (if transmitted
: > as a delta or as a table, it makes no difference in the en
In message <[EMAIL PROTECTED]>, Tom Van Baak writes:
>I am wondering, though,
>if anyone knows of an example of a GPS receiver
>that caches the delta value from the last power-up?
>It seems to me this would take care of the delay in
>all but the most extreme cases.
Most receivers will cache the a
In message: <[EMAIL PROTECTED]>
Rob Seaman <[EMAIL PROTECTED]> writes:
: The question is whether "at least 20 minutes" (presuming this to be
: accurate) is intrinsic to the system design or is rather a result of
: poor implementation by some receiver manufacturers.
A cold GPS receiver
> In addition, since GPS time is TAI - 19s, the GPS-UTC difference will
> eventually overflow any fixed-sized transmission packet (if transmitted
> as a delta or as a table, it makes no difference in the end).
True, but the GPS signal format has a number of
fixed length fields and they do not caus
M. Warner Losh replies to Steve Allen:
In my understanding the GPS system itself handles leap seconds
pretty well, almost optimally.
One could say that GPS handles them perfectly, in that they do not
exist at all in the GPS time scale. However, GPS' propigation of
the GPS UTC offset leaves mu
M. Warner Losh scripsit:
> One could say that GPS handles them perfectly, in that they do not
> exist at all in the GPS time scale. However, GPS' propigation of the
> GPS UTC offset leaves much to be desired. That data is sent in the
> alminac, which takes at least 20 minutes to down when a reci
In message: <[EMAIL PROTECTED]>
Steve Allen <[EMAIL PROTECTED]> writes:
: In my understanding the GPS system
: itself handles leap seconds pretty well, almost optimally.
One could say that GPS handles them perfectly, in that they do not
exist at all in the GPS time scale. However, GPS
The UK Royal Astronomical Society just made a splash with the first
profesional press release in this entire process.
http://www.ras.org.uk/index.php?option=com_content&task=view&id=830&Itemid=2
The wireservices have all picked up the story, but most are just
excerpting from the RAS release.
This
22 matches
Mail list logo
