From: Joe Mehaffey Newsgroups: sci.geo.satellite-nav Subject: Re: the Year2000 problem> Or is it really a problem at all for most of us? Date: Thu, 20 Nov 1997 16:31:39 -0500 Lines: 149 Message-ID: <3474AC3B.2@mehaffey.com> References: <34725C20.4F32@mehaffey.com> <64uks3$1ijm$1@mail1.wg.waii.com> <347393CF.E12@mehaffey.com> <654jb0$198s$1@mail1.wg.waii.com> Reply-To: joe@mehaffey.com Mime-Version: 1.0 To: Marc Brett Xref: equinox-news sci.geo.satellite-nav:54158 This is a multi-part message in MIME format. --------------2969210B560C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Marc, I wonder.. Do you expect Magellan, or Garmin, or Trimble, or Lowrance to spend $50,000 to $100,000 to test their $250 consumer GPS receivers EXHAUSTIVELY for PROBLEMS OF ANY KIND? Y2000 problems or any other kind of problems? If you are a manufacturer, you always look at the economic trade offs. (If you fail to do so, you are only one step from bankrupcy.) You trade off a) moderate testing for a moderate price and know you may have to do field upgrades against b) exhaustive testing for HUGE costs and know that you may have to do field upgrades anyway because you missed something. I would say that in the REAL world, trade off (a) is alway chosen and for the best of reasons (b). If the WORST problem discussed in the writeup following should occur, I personally think that most of us will have no problem with sending our units in for an upgrade. We KNOW that for Garmin, Lowrance, Magellan and Trimble owners, there is little reason for ANY concern as the design of units produced in the last 3 years or so have no problem with EOW or Y2000 rollover. For the VERY FEW of us for whom any burp at EOW would be a problem, I recommend getting a unit from Trimble, Garmin, Magellan, etc that is certified airworthy. You pay about double for such units partly BECAUSE they have received extra testing and product quality attention. For my OWN part, I gladly ACCEPT the cheaper trade off so my handy pocket GPS costs me $250 instead of $500 to $1000. A little "burp" for a day or two around August 1999 will probably go un-noticed a lot easier than the expenditure of additional money to prevent the "burp". My best regards. Joe Mehaffey ==================================================================== --------------2969210B560C Content-Type: text/plain; charset=us-ascii; name="y2000dat.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="y2000dat.txt" 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 directly to the newsgroup. Joe Mehaffey --------------2969210B560C--