Content-Type: Text/Plain Content-Description: GPS time & time zone offsets >>>>> Atomic time reception. >>>> On which Transmitter >>> In the UK, the Rugby 60kHz time signal. >> My thought is that a GPS receiver might be best here? (AFAIK >> universal coordinated time is what GPS sends out?) Until quite recently, I didn't know what GPS used internally. Oddly enough, just this morning, I read a posting on another mailing list that describes it. It appears reasonable but I can't vouch for its veracity. If it's correct, GPS uses it's own time system with units of 1/403200 of a week (about 1.5 seconds). I've attached the entire article since I found it interesting -- others might too. I just hope the information contained therein is right. :-) So atomic time reception, whether by radio waves or by modem (via US NTIS, ex-NBS, ACTS) or by Internet NTP seems like a more accurate method. >> [...] same time signals out planet-wide so you'd just need to >> rotate a 24-position switch (be it virtual or physical ) to >> the right time zone & you're set [...] > Well, if you've got the GPS signal all decoded like that, you > already _know_ where you are. ;-) In terms of physical position on the earth, I agree. But what has that got to do with time zones, daylight savings time, etc. Those are all _political_ animals. At least in the United States, time zones are based on political location. So you'd need a full set of geographic boundaries of all the states so that you could convert your earth location into which political entity (state, sometimes county) controls your time zone and if/when you observe daylight savings time. It's a real can of worms. Lee Jones ------------------------------------------------------------------- Jones Computer Communications lee@frumble.claremont.edu 509 Black Hills Dr, Claremont, CA 91711 voice: 909-621-9008 ------------------------------------------------------------------- >From bounce-4phun-Scanning--253-lee=frumble.claremont.edu@onelist.com Tue Oct 13 02:15:37 1998 From: "Victor Healey" To: <4phun-Scanning@onelist.com> Date: Tue, 13 Oct 1998 05:20:22 -0700 Message-Id: <000001bdf6a3$d9b28760$03000004@dad> In-Reply-To: <3622BDB6.80D4DD36@iaw.on.ca> Mailing-List: list 4phun-Scanning@onelist.com; contact http://www.onelist.com Delivered-To: mailing list 4phun-Scanning@onelist.com Precedence: bulk Reply-To: 4phun-Scanning@onelist.com Mime-Version: 1.0 Subject: [4phun-Scanning] Re: date rollover in GPS satellites Status: RO From: "Victor Healey" November 1997 LETS MAKE A MOLEHILL OUT OF AT LEAST one MOUNTAIN! Is the Year 2000 GPS "problem" REALLY a Problem at all? ================================================================= I asked one of our GPS engineering consultants who is well versed in GPS technology theory and practice to tell us what spectacular event would happen to a GPS that was NOT "Y2000 compliant". Not much says he. Read on for further comments. Since he does not have time to respond to questions from the newsgroup, he has asked that his name not be published. Here are his comments. ================================================================== Joe, you wanted to post my comments about the Y2k and EOW "controversy" (let's see now, that means End of World in Year 2000, doesn't it, like the television psychics want to predict). Well, here is The Short Version (consider it an abstract). Consider this oversimplified. But I note that at least one of your readers won't be satisfied with anything less than an official manufacturer's certifying stamp on each unit, accompa- nied by an international press conference and appearances on Oprah, Nightline, and Larry King Live and attested to by Bill Clinton (;->). Hey, ya know what? As far as position and navigation goes, Y2K (and any other artificial calendar counting time) doesn't matter one bit to a GPS receiver. The position of the SV is found from the orbital elements and the difference between the epoch of the element set as transmitted in the navigation message and the time of transmission of the message. It's only a _difference_ in time, not the absolute time. And both the orbital element time and the message time are contained in the message. The computer doesn't care whether you are measuring on a Gregorian calendar, a Moslem calendar, a Chinese calendar, a Jewish calendar or one you just made up. The algorithm just takes the times given in the message and calculates the current Mean Anomaly, from which you get the True Anomaly, from which you ultimately get the position of the SV in GPS coordinates (NOT lat/lon, UTM, or other geography units). The only place the date appears in some sort of everyday calendar format is on your display screen. And as has been pointed out many times before, the receiver's clock is, at most, only used to get the initial search configura- tion. It is _not_ used for the PVT solution iteration (Position- Velocity-Time). When you put your receiver in free search mode ("autolocate"), it doesn't even use its own clock. The "message received" time is determined as part of the solution in deriving the pseudoranges for each satellite used. Sort of like the lat/lon vs UTM in 100 different datums. The number shown isn't what the computer in the GPS uses anyway - it's only there for display purposes. The system coordinate system is an Earth- centered Earth fixed Euclidian system, no latitudes, no Eastings. Hey, guess what? It's like GPS time vs UTC vs your local standard or daylight time. The GPS uses GPS time for its computations, then displays whatever you want. In the vast majority of units (all the consumer toys and virtually all the marine and air navigation units) you can't display the GPS time, even if you want to. The time units are 1/403200 of a week, which is about 1.5 seconds, not seconds or nanoseconds (it's 1/806400 of a fortnight, though (8>D). The one problem is the week rollover. And, ya know what? That really is only a problem for a unit that doesn't have a current ephemeris for a given SV for a short time around the rollover date. If you are more than a few hours past the rollover, all the SVs will have a new ephemeris, your internal clock will be counting up mod 1024 weeks, and you are fine. The problem comes when you have an ephemeris which is epoch 1023.xxx weeks and your clock has rolled over to 1024.yyy, which means it reads 0.yyy. It will compute a negative time, unless your unit has a way of catching that (as do all units from the major manufacturers in the past 5 or 10 years). But, since the ephemeris is uploaded a couple times a day, at worst your position computation will be wrong for a day or so in August 1999. My understanding from the manufacturers I have talked to (4 of the major ones), or indirectly from ones Joe, Sam, and Jack have had contact with, is that current units catch even that small problem. Some older units will have a hard time locking on because they are calculat- ing visibilities from the canonical orbital elements stored in ROM, but once they have locked on and updated their ephemeris set, they will give the right location and time of day (but not the right calendar day, just off by about 230 days). Sigh! What it comes down to is that there are a bunch of folks who have absolutely no concept of how orbital calculations are done. Sorry folks, the Earth isn't flat, it isn't the center of the universe, and even the Sun isn't the center of the universe. I groan every time I see another of these anthropocentric, ethnocentric, or worse yet, egocentric postings that claims that the poster's way of viewing things is the only way, and the rest of the universe can --- whoops, the universe can't jump in the lake can it? (My calendar is the only one, my footruler is the only way to measure, my view of the world is the only correct one -so there!) ======================================================== I edited the above very slightly for clarity. If anyone has questions/comments, please post. Joe Mehaffey