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: Comments on Civil Time decision tree
Randy Kaelber wrote: 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. The spacecraft that I've had experience with coordinate the spacecraft clocks with Earth-based time standards. The Solar and Heliospheric Observatory (SOHO) spacecraft (which at a distance of 0.01 A.U. can be considered to be on the edge of interplanetary space) synchronizes its onboard clock to TAI time, expressed as the number of TAI seconds since 1 January 1958. The spacecraft operators keep track of the clock drift, taking into account the approximately 5 second light travel time, and periodically uploads new clock frequency parameters to keep the onboard clock in sync with TAI to within a specified requirement. The upcoming Solar Terrestrial Relations Observatories (STEREO) go in orbit around the Sun, and are thus definitely interplanetary. They also use the JPL SPICE system, and thus spacecraft SCLK files, like other interplanetary missions. The STEREO clocks will be synchronized to UTC, including an adjustment for leap seconds. For both of these missions, the Earth-based time values, TAI or UTC, are calculated and maintained onboard the spacecraft. Bill Thompson P.S. Please excuse me if you get this message twice. I was having trouble with my subscription setup, and wasn't sure if it really went out the first time. -- William Thompson NASA Goddard Space Flight Center Code 612.1 Greenbelt, MD 20771 USA 301-286-2040 [EMAIL PROTECTED]
Re: Comments on Civil Time decision tree
Randy Kaelber wrote: On Tue, Sep 27, 2005 at 03:56:07PM -0400, William Thompson wrote: The spacecraft that I've had experience with coordinate the spacecraft clocks with Earth-based time standards. The Solar and Heliospheric Observatory (SOHO) spacecraft (which at a distance of 0.01 A.U. can be considered to be on the edge of interplanetary space) synchronizes its onboard clock to TAI time, expressed as the number of TAI seconds since 1 January 1958. The spacecraft operators keep track of the clock drift, taking into account the approximately 5 second light travel time, and periodically uploads new clock frequency parameters to keep the onboard clock in sync with TAI to within a specified requirement. I suppose I should've prefaced with an in my experience. :-) The upcoming Solar Terrestrial Relations Observatories (STEREO) go in orbit around the Sun, and are thus definitely interplanetary. They also use the JPL SPICE system, and thus spacecraft SCLK files, like other interplanetary missions. The STEREO clocks will be synchronized to UTC, including an adjustment for leap seconds. Ugh. Is there a compelling science or operations reason to try to synch this clock with terrestrial times on-board that I'm just ignorant about? It sounds like a more work and more things that can break, versus just profiling the on-board clock and making SCLK kernels to map back to terrestrial time frames. Maybe the exact times aren't so important? With Odyssey and THEMIS, if we're off by a second, it's a 30 pixel along-track offset error in our images, so we're pretty obsessed with knowing exactly when we start and stop imaging. On the contrary, exact times are extremely important in the STEREO project. Images from the two spacecraft are supposed to be synchronized to each other to better than a second. (The images from one spacecraft are actually delayed relative to the other to take into account the different solar distances of the two spacecraft--the amount of delay is periodically uploaded from the ground.) The accuracy requirement for the delivery of UTC to the instruments is +/- 0.410 seconds. Each instrument team commands its own instrument directly. Time-tagging is done via UTC. I sincerely doubt that the individual instrument commanding workstations know anything about SCLK files. The orbit and attitude files are provided in SPICE format, which is probably a first for these teams, and I've been leading the effort to learn how to use the SPICE kernels. I don't have the number in front of me, but I believe that the timing requirements for the SOHO spacecraft is even more stringent, on the order of 0.1 seconds. This is to support the helioseismology instruments. SOHO doesn't use SPICE, and thus does not have an SCLK file. The telemetry timestamps from both SOHO and STEREO are in TAI and UTC respectively, referenced in both cases to 1-Jan-1958. For the STEREO spacecraft, which uses UTC, one has to interpret this as the number of non-leap seconds, as is done with Unix/NTP time. There's a one-second period of ambiguity on the STEREO spacecraft whenever a leap second is inserted, and time critical operations will be avoided during that second. SOHO uses TAI time onboard the spacecraft, but all ground operations are done in UTC time. I wrote the software that many of the instrument teams use to convert between UTC and TAI in their data analysis software, as well as some of the commanding software. I can see SOHO using a geocentric time. It's relatively close to Earth and holds a more or less constant distance from it. It seems that STEREO is going to have a more complicated relationship with a geocentric coordinate frame. I'm not sure what the extra complication is. For both missions, one has to deal with a significant light travel time, much larger than the required time accuracy. The process of taking this into account is essentially the same, no matter where you are in the solar system, and no matter whether you feed the results back to the spacecraft, or simply take it into account on the ground. Bill Thompson -- William Thompson NASA Goddard Space Flight Center Code 612.1 Greenbelt, MD 20771 USA 301-286-2040 [EMAIL PROTECTED]
Re: Comments on Civil Time decision tree
Perhaps I might expand on some of Bill Thompson's statements in the context of the great convenience factor of using the current UTC standard.The accuracy requirement for the delivery of UTC to the instruments is +/- 0.410 seconds.High quality, cutting edge science doesn't always require nanosecond precision. In particular, when you are talking about an "experimental apparatus" such as the Solar System, in which light takes 16 minutes to cross the orbit of the Earth, and many hours to reach the outer planets, the few tenths of a second provided by raw UTC may well be exactly what is required. UTC provides simplicity in handling while retaining the option of later converting observed timestamps to TAI and thus to some dynamical timescale.Each instrument team commands its own instrument directly. Time-tagging is done via UTC.UTC - or any future civil time scale - provides a common clock to tie together both scientific and logistical requirements between a multiplicity of teams and team members. It is often the case that different instruments on a spacecraft are operated by different teams. Those teams have to address scientific concerns - they also have to interoperate with FedEx and with each other.I don't have the number in front of me, but I believe that the timing requirements for the SOHO spacecraft is even more stringent, on the order of 0.1 seconds. This is to support the helioseismology instruments.I worked on an asteroseismology experiment several years back in which 40,000 spectra of Procyon had to be acquired on an even barycentric time grid. Cadencing the exposures required converting Earth time (UTC) to the time as the wavefronts passed the Sun and triggering on the predicted clock tick. Sure, I could have referenced the barycentric corrections to something other than UTC, but I challenge anybody to engender confidence in such a conversion from an obscure, moving, Earth clock to a remote location a hundred million miles away. I can handle one or the other, but not both at the same time, with anything like an intuitive feel.There's a one-second period of ambiguity on the STEREO spacecraft whenever a leap second is inserted, and timecritical operations will be avoided during that second.So, presumably this is an example where handling a rare - but necessary - phenomenon "properly" was deemed to be not cost effective. However, they simply redefined the problem such that the "outage" was reduced to its minimum duration of one-second. In six hundred years, one might expect many affected parties to do the same - but of course, the minimum outage then will be 3600 seconds. On the other hand, we've heard apocryphal horror tales of GLONASS falling from the sky and other Ghostbuster scale apocalyptic events resulting from a leap second. Even if such projects chose not to handle leap seconds transparently, why should their system outages persist for more than the second achieved here by another space mission?For both missions, one has to deal with a significant light travel time, much larger than the required time accuracy.Much of the discussion to date has implicitly assumed that civil time here on Earth can simply be transported across the Solar System or the Galaxy as needed - that it is trivial to correct for distant locales. On the scale of tenths of seconds, this is likely true for spacecraft bound to the Sun. One questions if this is achievable - or desirable - at the level of nanoseconds, or perhaps even of microseconds or milliseconds, for very many scientific or utility purposes for Solar System travel.The process of taking this into account is essentially the same, no matter where you are in the solar system, and no matter whether you feed the results back to the spacecraft, or simply take it into account on the ground.And more to the point - why should such projects have to be responsive to such alien requirements? Presumably there were any number of factors involved in determining the timekeeping choices of these space projects as a response to various use cases. Is there any particular reason that they should be forced to put their system clock on the ground rather than on the spacecraft simply to meet the one-size-fits-all expectations of others?We've heard many times in many ways that atomic clocks are orders of magnitude more regular than our wobbling Earth. But this extends to other physical phenomena. We all know that atomic clocks are sufficiently regular time pieces that detection of relativistic effects is trivial. Think about that - what used to require exquisitely sensitive measurements during exceedingly rare opportunities such as a transit of Venus can now be carried out by a high school student (albeit a relatively well-heeled student) on a weekend trip to the mountains. General Relativity for everyman - Albert in a box.How nice! Isn't that support for ditching that dirty old UTC for 21st century technology? Well - no. A single atomic clock is a loose
