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
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
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:mumble 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 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] 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
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] 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
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
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).
