Re: Comments on Civil Time decision tree
In message [EMAIL PROTECTED], Peter Bunclark writes: On Mon, 26 Sep 2005, Poul-Henning Kamp wrote: On the other hand, even if we agree on one standard, or even just leave UTC as it is, are the astronomers and geophysiscists going to abandon UT1 ? If so, then this is the first I've heard about it. Of course not. And that was exactly my point: civil and scientific timekeeping was two different issues and they have different semantics and needs. Most of this argument is still centered around the unarticulated question: who owns UTC. Wouldn't it be fair if the non-scientific (ie: civil) world told the astronomers (and any other scientists) to bugger off and not impose scientific requirements on civil time ? After all, scientists have several timescales of their own already, and plenty of means to implement them, whereas UTC is the only agreed upon and widely available civil timescale. -- 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: Comments on Civil Time decision tree
On Sep 26, 2005, at 7:09 AM, Poul-Henning Kamp wrote: Now, what we you mean by civil time standard ? Most countries reserve the definition of civil time for their national parliaments (or other some other tacitly assumed legitimate political power). They generally take UTC, apply a timezone and very often a DST ruleset. Point taken that the language still needs to be defined. Of course, some might find that additional support for the position that we are in no way ready to decide on changes to civil time standards if we can't even agree what civil time is. It would probably be wiser to recast this question in terms that do not even hint at usurping sovereignty. Funny - my wife always says the same thing... Whether it is called UTC, GMT or solar time, there is some coherent international time scale concept underlying the individual choices made by individual countries. That is what we are trying to define (some of us, anyway). Isn't a suggestion that we ignore natural time (based on whatever natural clock) in favor of technology time (based on whatever ensemble of physical clocks we have built or might build in the future) more likely to be viewed as an attack on national sovereignty? After all, the current pastiche of legal time systems successfully interoperate precisely because they are all based on the concept of mean solar time no matter how obscure the intervening standards process. It is the proposal to abandon leap seconds from only SOME of the sovereign national clocks that threatens interoperability. I suspect that interoperability would be one issue we can all agree on. So as long as you include scientific use with civil use, then the answer to this question is many no matter which way you go. We already have many examples of the distinction between scientific and civil uses of time. This discussion has never really been about the former. If it was, then the folks pushing the ITU proposal would have simply renamed their new timescale something other than UTC - say, TI, as was decided in Torino. That would allow the astronomers to continue to maintain UTC internal to their community which undoubtedly would be a much less expensive proposition. It is the folks who want to abandon leap seconds who are making an unwarranted and unwise connection between civil time and science time. And that was exactly my point: civil and scientific timekeeping was two different issues and they have different semantics and needs. Well, other than the fact that you are committing the same error in assuming that there is one single scientific time scale, I agree with you. Most of this argument is still centered around the unarticulated question: who owns UTC. Wouldn't it be fair if the non-scientific (ie: civil) world told the astronomers (and any other scientists) to bugger off and not impose scientific requirements on civil time ? The flaw here is that you are excluding the scientific users - precisely the folks who know how to address the issues - from helping craft a solution. Scientists live in the civil world, too. Under what circumstances are a few dozen committee members a world unto themselves? It seems rather naive (the word daft also comes to mind) to suggest that common sense scientific issues such as that civil time obviously mimics solar time - to some level of precision we certainly could discuss - have no place in making decisions about civil time. Is the fact that the Earth rotates purely a scientific question? Or is this something a typical Earthling might be expected to know? After all, scientists have several timescales of their own already, and plenty of means to implement them, whereas UTC is the only agreed upon and widely available civil timescale. I agree - although there certainly is nothing to stop us from laying international civil time upon some other underlying timescale like TI. The fact, that you appear to now be agreeing with, is that there is one civil time standard. That being the case, we really ought to labor to get it right, not to cut some inane deal with naive corporate entities. I suspect plenty of the more cogent corporate entities would reject the current proposal if anybody had thought to ask them about it. Rob Seaman National Optical Astronomy Observatory
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: Comments on Civil Time decision tree
In message [EMAIL PROTECTED], Daniel R. Tobias writes : On 26 Sep 2005 at 16:09, Poul-Henning Kamp wrote: Other more laid back parliaments like the Danish have not been able to find time to revisit the issue since 18xx and still use solar time at some more or less random coordinate. You mean like the U.S. Congress? http://tycho.usno.navy.mil/260.html ...the standard time of the first zone shall be based on the mean solar time of the sixtieth degree of longitude west from Greenwich... (and so on for all the other zones) Well, at least they had the sense to use a longitude divisible by 15. Not so lucky in Denmark: 50°19' Imagine for instance that we send a probe out of the solar system at seriously high speeds and it manages to get as far as 6 light months away: Under the current UTC rules we would be unable to upload a leap-second warning and get it there before it is too late. I would suppose that such a space probe would have little need to be synchronized with earthly solar time, and thus might be best off operating on TAI, with any adjustments to UTC for the sake of humans observing it on Earth being done at the Earthly end of things. Again: merely trying to point out that the only one timescale argument Rob pushes doesn't work. -- 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: Comments on Civil Time decision tree
On Sep 26, 2005, at 11:56 AM, Poul-Henning Kamp wrote:Again: merely trying to point out that the "only one timescale" argument Rob pushes doesn't work.This misrepresents my position. There are clearly many time scales for many purposes. One of those purposes is something that might be referred to as "International Civil Time". It is this civil time scale that is the key issue for any proposed change to the current UTC standard. Personally, I am happy to acknowledge that no such international standard currently exists. Shoehorning UTC into that role is not a very good fit, at least not if it is asserted that we must destroy UTC in order to save it.It is rather clever how UTC manages, through the mechanism of leap seconds, to transport both Universal Time (Mean Solar Time) and Atomic Time in one convenient package. The convenience of this mechanism is being criticized. Either those criticisms are invalid, in which case the ITU proposal should be rejected - or the criticisms are valid, in which case it may well make sense to explicitly separate Atomic Time from Solar Time. Perhaps that is what you mean by your statement above.But, in a world with separate time scales for Atomic and Solar Time, it seems far more likely that any representation of International Civil Time should be based solely on Solar Time, not on Atomic Time. For the vast majority of cases, Civil Time clearly "mimics" - and must continue to mimic - Solar Time. Doesn't it make more sense to simply reconfirm the wisdom of the ages that Civil Time IS Solar Time?E pur si muove!Rob SeamanNational Optical Astronomy Observatory
Re: Comments on Civil Time decision tree
In message [EMAIL PROTECTED], Randy Kaelber writes: On Mon, Sep 26, 2005 at 02:33:00PM -0400, Daniel R. Tobias wrote: I would suppose that such a space probe would have little need to be synchronized with earthly solar time, and thus might be best off operating on TAI, with any adjustments to UTC for the sake of humans observing it on Earth being done at the Earthly end of things. That's the way we do it for interplanetary stuff now. Data from spacecraft are typically returned in spacecraft clock time (SCLK, which is pronounced sclock) and then translated to whatever time base you want it in. Right now, the clock on Mars Odyssey (as I type this) should be reading 2/0812228033. Dealing with things like leap seconds, local time conventions, and other time conversions are all handled here on Earth. But that strategy breaks down for human space flight ? -- 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
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: Comments on Civil Time decision tree
On Tue, Sep 27, 2005 at 01:13:18AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Randy Kaelber writes: As an aside, most of the people who were/are on Mars Rover teams that I talked to really liked the extra 30+ minutes a day. The only thing they didn't like was when mundane earthbound things conflicted (It's 4 am, but I don't want to eat at Denny's and I really need to get to the bank.) with their Martian schedule. Astronauts on Mars would not have that problem. :-) You mean decent restaurants are open at 4am on Mars ? :-) Yes. Great food, but very little atmosphere (*rimshot*). -- Randy Kaelber[EMAIL PROTECTED] Scientific Software Engineer Mars Space Flight Facility, Department of Geological Sciences Arizona State University, Tempe, Arizona, USA
