Re: RAS hits the news
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) switched calendars. I think you are far overestimating 1970 electronics :-) The week based scheme was a compromise forced by number of bits available and how much electronics could be dedicated to the task of receiving the signals. For a long time the almanac was something you had to manually enter into the receive (which is probably why almanacs are still published by the GPS control segment people). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: RAS hits the news
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) that does not preclude getting the difference between GPS and UTC right for the immediate future (by which I mean the expected useful life of most GPS receivers) with the addition of a little bit of heuristic algorithm that predicts the magnitude of the 8-bit signed Delta-t_LS as compared with the 10-bit unsigned Today is a big day for GPS, for the launch of the first of the next generation of SVs just happened. http://www.cnn.com/2005/TECH/space/09/26/rocket.launch.ap/index.html The new GPS L2 ICD that describes the Block IIF SVs is available via this web page http://www.navcen.uscg.gov/gps/modernization/default.htm under the link that reads "ICD-GPS-200 Rev. C" There are two significant additions in the Block IIF signals. 6.2.5 and 20.3.3.5.1.13 indicate that bits 7 through 22 of word ten in page 25 of subframe 5 will be a 16-bit integer giving the calendar year (curiously it does not specify whether this is signed or unsigned, but the Control Segment has around 14000 years to clarify that point). 30.3.3.1.1.1 indicate that bits 39 through 51 of L2 CNAV message type 1 will be a 13-bit unsigned integer which extends the range of the existing "Transmission Week Number" from 1024 weeks to 8192 weeks. This extends the ability of a GPS receiver to tell when it is from not quite 20 years to over 150 years, which should be longer than any GPS receiver is likely to last. Unfortunately, 30.3.2 indicates that message types 1 and 2 are temporary and will be replaced by the as yet undefined messages 7 through 9. This no doubt will reduce the likelihood that a GPS receiver will bother to use them. 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) switched calendars. Thus the GPS scheme is probably robust against anything short of adoption of the doomed-to-fail "World Calendar" schemes which proposed the intercalation of weekday-free days, but which had little hope of ever being adopted. As such the inclusion of calendar year does not prohibit the adoption of new calendars with new year schemes so long as the change is adopted with sufficient lead time to permit the firmware in GPS receivers to be updated. With the calendar year available, the fact is that the signed 8-bit quantity Delta-t_LS is no longer a limitation. It will be something like 3 years before the combination of calendar year and Delta-t_LS values is incapable of producing an unambiguous result. On Mon 2005-09-26T11:26:00 -0700, Tom Van Baak hath writ: > The other point I was trying to make is that there are > web pages that still claim that "GPS WILL FAIL" on > such and such a date because of the 8-bit leap second > field. This sort of hyperbole is uncalled for. Mea culpa. I have more homework to do on my web pages to incorporate these very details. It remains the fact that most existing GPS receivers will fail by around 2070 or so, but that really should not be much of a surprise or inconvenience to their owners. -- Steve Allen <[EMAIL PROTECTED]>WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: RAS hits the news
> 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 subframe data message to help determine which 1024 GPS week cycle it is? Although the idea was around since at least 1996, if it were me writing GPS receiver firmware I'd probably opt for manufacture date (ROM) and most recent almanac date (NVRAM) as guides to determine which 1024-week GPS cycle it is at power-up. Is there any way some of the GPS manufacturers can jump in and tell us what they actually do? Not that it matters, really, for the leap second debate. But I'm always nervous when helpful statements about what could be done become, over the years, authoritative statements about what is actually done. Anyone from Garmin, Trimble, Magellan, Javad, etc. on the list? /tvb
Re: RAS hits the news
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 leap seconds at their current value. Of course - by "drop leap seconds" I meant drop them from the specification so that no further leap seconds would be inserted. The current offset between UTC and TAI (and therefore GPS time) would be maintained. In this case no computer or GPS receiver or cell phone or clock appliance or any man-made timing related intra-planet technology would go forward or back or anything. Observe that nothing will break, for example, if the 12/31/2005 leap second were to not occur. The only problem is that UTC would soon diverge from UT1 beyond 0.9 seconds and so extra-planet devices (e.g., precision telescope systems) would need correction at some point. This introduces a large set of interesting, legitimate, philosophical and financial questions by, especially, astronomers. But either way, nothing with GPS receivers will break. Not immediately. 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. If no more leap seconds are inserted the UTC-GPS offset will stick at about 13 or 14 seconds or whatever it is now (or will be after the end of this year) which the GPS would associate with the current 1024 week cycle. On a cold start in 2025 it will find that same offset and assume that it's back in 2005 or there abouts. Actually, things could start to go off the rails in about 512 weeks (about 9.8 years). As I said, this is not a big issue at all. In particular most current GPS receivers will probably be dead by then anyway, though one of my GPS receivers in current use is over 12 years old.
Re: RAS hits the news
Or, at least, be in error by some modulo 19.6 year value. Not a major catastrophe, but mitigation could be a major expense for some GPS users. --Tem -Original Message- From: Leap Seconds Issues [mailto:[EMAIL PROTECTED] On Behalf Of Ed Davies Sent: Monday, September 26, 2005 12:24 PM To: 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 LS. That is, the receiver > implements a sliding 1024-week window whose limits are determined by > the current value of LS. Current date "will" then reside within this > 1024-week window. 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.
Re: RAS hits the news
> 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 current value. In this case no computer or GPS receiver or cell phone or clock appliance or any man-made timing related intra-planet technology would go forward or back or anything. Observe that nothing will break, for example, if the 12/31/2005 leap second were to not occur. The only problem is that UTC would soon diverge from UT1 beyond 0.9 seconds and so extra-planet devices (e.g., precision telescope systems) would need correction at some point. This introduces a large set of interesting, legitimate, philosophical and financial questions by, especially, astronomers. But either way, nothing with GPS receivers will break. /tvb
Re: 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 LS. That is, the receiver implements a sliding 1024-week window whose limits are determined by the current value of LS. Current date "will" then reside within this 1024-week window. 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.
Re: RAS hits the news
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 to use words like remainder, modulus, or rollover rather than overflow (which sounds like something unforeseen or a mistake). > Could you tell me what year it was if I told you it was Monday, > October 15th? No, you couldn't. You could tell me that it might be > 2001, but it could also be 2007 or 1990. You need more information to > resolve the ambiguity. If I told you that it was Monday, October 15th > and that TAI-UTC=32, you'd know it was 2001. If I told you > TAI-UTC=100, you might guess that it is 2063, or maybe even 2068 or > 2057 or maybe other years earlier or later depending on your leap > second model, utc-ut1 tolerance parameters, and other factors > unknowable today. I understand the problem but think, in this case, it is grossly overstated. Not only do can you know the leap second number, and the modulus GPS week number, but also the date of manufacture and the date of last signal acquisition. We also know about the useful and market lifetime of electronic gadgets. In all real-life situations this is sufficient to resolve the 20 year cycle. The counter-example I used in years prior to the August 1999 WNRO event was -- the only way a GPS receiver could come up with the wrong date was if you turned it on in the 90's, turned it off for at least 19.5 years, and then turned it on again. In that case, it would still provide correct navigation but, yes, it would come up with the wrong date. And that's assuming the manufacturer didn't apply a leap second heuristic (which wasn't published at the time). See also: GPS Week Number Rollover (WNRO) http://www.leapsecond.com/notes/gpswnro.htm 256-Week Leap Second Bug http://www.leapsecond.com/notes/leapsec256.htm > The GPS 1024 week overflow is easier to deal with, since it is a 20 > year ambiguity, not a 5 year one. You can make a better guess than in > my example, I'll not argue. The better the guess you make based on > today's understanding, the more external factors that might cause you > to be wrong. Eg, leap second rules changes, lifetime of GPS signals, > etc. > > I guess I agree with you that these things are doable. Working out > the details, however, makes them non-trivial. > > Warner The other point I was trying to make is that there are web pages that still claim that "GPS WILL FAIL" on such and such a date because of the 8-bit leap second field. This sort of hyperbole is uncalled for. I don't see this any more or less of an engineering detail than a PC booting up and not knowing for sure if it's 1905, 2005, or 2105. /tvb
Re: RAS hits the news
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 just 7 names for days : of the week; calendars that rollover every 12 months, : wristwatches that overflow every 12 hours... 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. Could you tell me what year it was if I told you it was Monday, October 15th? No, you couldn't. You could tell me that it might be 2001, but it could also be 2007 or 1990. You need more information to resolve the ambiguity. If I told you that it was Monday, October 15th and that TAI-UTC=32, you'd know it was 2001. If I told you TAI-UTC=100, you might guess that it is 2063, or maybe even 2068 or 2057 or maybe other years earlier or later depending on your leap second model, utc-ut1 tolerance parameters, and other factors unknowable today. The GPS 1024 week overflow is easier to deal with, since it is a 20 year ambiguity, not a 5 year one. You can make a better guess than in my example, I'll not argue. The better the guess you make based on today's understanding, the more external factors that might cause you to be wrong. Eg, leap second rules changes, lifetime of GPS signals, etc. I guess I agree with you that these things are doable. Working out the details, however, makes them non-trivial. Warner
Re: RAS hits the news
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 initialization "seed" date that is within about +/- 512 weeks of true date. The receiver will adjust date forward or backward based on this seed date, the 10-bit GPS Week Number (WN), and GPS time-of-week (TOW) (i.e., day of week) transmitted by the satellites. 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 determined by the current value of LS. Current date "will" then reside within this 1024-week window. 4. A receiver may be at risk for needing a software update if its authors picked too small a value to associate with each LS increment, and if Mother Nature doesn't cooperate and slow the earth's rotation at something close to the mean rate. I note that the interval between the last LS increment and the next one will be 7 years. --Tem
Re: RAS hits the news
> 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 another GPS receiver, a base station, a memory card, a cell phone data service, the internet, etc. > The GPS format already does this, even more efficiently than you might > think. There's two 8 bit quantities, and two 10 bit quantities that > represent the current and future leap second data. The 8 bit fields, > as others have pointed out, are due to overflow in the next century or > so. The week number also overflows in GPS. Many receivers 'cheat' > and use a prediction algorithm to know which 1024 week epoch we're in > by looking at the number of leap seconds. So when that field > overflows (be it at 7 bit or 8 bit (it is defined to be a signed > number, but that definition could be change)), better algorithms will > be needed. Firmware or manufacture date is also a method used to establish the correct epoch; this is true for GPS receivers as well as any clocks or watches that display 4-digit years. Add to that any PDA or PC with a CMOS clock. 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 just 7 names for days of the week; calendars that rollover every 12 months, wristwatches that overflow every 12 hours... Has someone on the list looked into the details on how Galileo or the new GPS L2/L5 messages handle leap seconds? /tvb
Re: RAS hits the news
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 doesn't if it is off all weekend, but >don't know where the cutoff point is). The real test is to power off, disconnect antenna and power on. If it reports leap second status then, it must clearly trust the cached almanac 100%. My conclusion was that it didn't until it had seen a timestamp from a satellite which would confirm that the almanac was current. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: RAS hits the news
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 be the Oncore VP that we stopped deploying years ago, but are in our leap second testing matrix because important customers still have them deployed. I can watch our status screen as they happily cycle through different sets of satellites a couple a minute until they get one good one... Of course the VPs we used loose all knowledge when power goes away... : But they will not use anything but the current almanac to report : leap seconds. 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 doesn't if it is off all weekend, but don't know where the cutoff point is). Other GPS recievers, from other manufacturers, that we've tested will report the alamanac data even after being off all weekend. The older VP will not cache the almanac data at all beyond the charge in the capacitors in the power supply when power is removed. Warner
Re: RAS hits the news
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 implementation by some receiver manufacturers. > >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. Actually I think the number is around 15 minutes from the time you get code data from the first satellite. (I have always wondered why the almanac isn't staggered between the satellites, that way you get get it at least four times faster on average). >Others are >cold only if they have been off so long that they have no way of >knowing the current correct leap count. Given that BIPM only >publishes 6 months in advance, this means that the longest a receiver >can be off is about 6 months. I think you risk confusing two things here. At least the Oncore receives will happily use a 2 year old alamanc to aid in getting first fix. But they will not use anything but the current almanac to report leap seconds. >Also, a GPS receiver that has cached the almanac can acquire >satellites much more quickly than one who has to wait for the almanac >to be downloaded. This is btw, the original design rationale for the almanac data set. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: RAS hits the news
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 end). : : True, but the GPS signal format has a number of : fixed length fields and they do not cause a roadblock : for receiver firmware engineers. There are fixed-sized : 256 and 1024 week number fields that "overflow", : for example, and all modern GPS receivers get them : right. It is trivial for a receiver to handle the equivalent : 256 leap second rollover should one occur in the next : hundred years. Many of the week number roll over algorithms use the leap second count as a good first guess which 1024 week epoch you are in. If that field rolls over, then these algorithms will need adjustment. So it is likely doable, but it might not be completely trivial due to the irregularity of leap second insertions. : On the question of UTC updates; it's true that a cold : GPS receiver has to wait up to 12 minutes for the : correct GPS/TAI/UTC delta. 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 cache some value. That is why I've been careful about saying "cold" since there are different definitions of "cold" between receivers. Having a cached almanac greatly speeds satellite acquisition time. This is why many GPS receivers do well when off for up to about a week, and then have a much longer acquisition time when they are turned on after a longer haitus. They have to 'guess' at what satellites are in the sky and rotate through their guesses until they happen to hit on one that is in the sky and can download more accurate almanac information. Fortunately, that almanac data is transmitted more frequently so once you have one, it goes pretty fast to acquire the rest. Warner
Re: RAS hits the news
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 almanac if they have a piece of CMOS RAM for it. The Oncore series certainly do. But appearantly the Oncore only uses the Almanac to get a quick first fix when you power it back up, and for this even a quite old almanac will do since in general the orbits are quite stable. The Oncore doesn't seem to trust the cached/uploaded almanac beyond that, until it has received confirmation that it is indeed the current almanac. I'm not quite sure what confirmation it takes to satisfy the Oncore on this point, but it looks like it is the specific sub-frame of the almanac which contains a timestamp of some sort, because it takes from up to twelve minutes to happen, but it does not coincide with the @@Cb return of the newly aquired almanac. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: RAS hits the news
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 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. As I stated before, various recievers have differing definitions of 'cold'. Some are 'cold' the instant you turn them off. Others are cold only if they have been off so long that they have no way of knowing the current correct leap count. Given that BIPM only publishes 6 months in advance, this means that the longest a receiver can be off is about 6 months. Many modern receivers do a good job of caching the data over short to medium periods of being off. This is why others have reported that you get the right time from a Garman within a few seconds of power on. Also, a GPS receiver that has cached the almanac can acquire satellites much more quickly than one who has to wait for the almanac to be downloaded. Many receivers, when acquiring satellites, take a while to do this when they have no almanac. This adds a little time to recovery. I believe the almanac is retransmitted every 18: seconds, but I've been saying 20 because it takes a little time (a couple of minutes) to find the first satellite to start the process. : A typical design pattern for conveying crucial metadata that is only : rarely updated is to also convey a timestamp or expiration date. : Either the eggs are expired or they aren't. There certainly are ways : for a GPS receiver to store metadata - even over a period of a year. : Having cached the leap second table, the only question is whether it : is expired for which a 4 or 8 byte timestamp would be quite sufficient. The GPS format already does this, even more efficiently than you might think. There's two 8 bit quantities, and two 10 bit quantities that represent the current and future leap second data. The 8 bit fields, as others have pointed out, are due to overflow in the next century or so. The week number also overflows in GPS. Many receivers 'cheat' and use a prediction algorithm to know which 1024 week epoch we're in by looking at the number of leap seconds. So when that field overflows (be it at 7 bit or 8 bit (it is defined to be a signed number, but that definition could be change)), better algorithms will be needed. Warner
Re: RAS hits the news
> 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 cause a roadblock for receiver firmware engineers. There are fixed-sized 256 and 1024 week number fields that "overflow", for example, and all modern GPS receivers get them right. It is trivial for a receiver to handle the equivalent 256 leap second rollover should one occur in the next hundred years. On the question of UTC updates; it's true that a cold GPS receiver has to wait up to 12 minutes for the correct GPS/TAI/UTC delta. 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. Come to think of it my Garmin comes up with the correct UTC time within seconds of power-up so it must be doing something right. /tvb
Re: RAS hits the news
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 much to be desired. That data is sent in the alminac, which takes at least 20 minutes to down when a reciever is started "cold"[*]. Um - the quote you are replying to was actually: In my understanding the GPS system itself handles leap seconds pretty well, almost optimally. It's some receivers which have difficulties. 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. Although you know the GPS time to within a few tens of nanos as soon as you have 4 satellites, you have to wait another 20 minutes after that to know UTC time if you are coming up cold. One can debate the meaning of 'almost optimally' til the cows come home, but my views lean away from such a characterization... A debate of the meaning of "almost optimally" is at the heart of any design effort. One might assert that this list could debate such, but the fact is that has only extremely rarely been what has been debated over the past six years. Is GPS close to, or far from, optimal? I suspect it is closer to optimal than the complete abandonment of the process that is being pushed by the ITU. A typical design pattern for conveying crucial metadata that is only rarely updated is to also convey a timestamp or expiration date. Either the eggs are expired or they aren't. There certainly are ways for a GPS receiver to store metadata - even over a period of a year. Having cached the leap second table, the only question is whether it is expired for which a 4 or 8 byte timestamp would be quite sufficient. The conceptual fault here - as with so much of this discussion - is a design that assumes that the receivers or other clocks will not be restarted "frequently" (another word whose definition we could debate). Rob Seaman National Optical Astronomy Observatory
Re: RAS hits the news
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 reciever is > started "cold"[*]. 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). -- One art / There is John Cowan <[EMAIL PROTECTED]> No less / No more http://www.reutershealth.com All things / To do http://www.ccil.org/~cowan With sparks / Galore -- Douglas Hofstadter
Re: RAS hits the news
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' 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 reciever is started "cold"[*]. Although you know the GPS time to within a few tens of nanos as soon as you have 4 satellites, you have to wait another 20 minutes after that to know UTC time if you are coming up cold. One can debate the meaning of 'almost optimally' til the cows come home, but my views lean away from such a characterization... Warner [*] The definition of cold varies from receiver to receiver, but all of them necessarily have a cold state (turn it off for a year, and it is guaranteed to be cold in that it can't possibly know the leap second values).
