Visit our Popular Forums

CarinaPDX · 15-02-2019, 17:25

Quote:

Originally Posted by Brian.D

This from the GPS.GOV

"Navigation solution should be OK since GPS time is internally self consistent, but associated time tags could be incorrect thus corrupting navigation data at the system level."

This is not correct by my understanding. The problem is that solving for position requires using data from the current ephemeris with the current satellite data. The ephemeris data is downloaded for a period of time (days). By getting the days messed up between the previous and current epoch the module is unable to make sense of the previous ephemeris to resolve the current satellite data, so no position (as was my experience last time). The only way to get a good position in this case is to throw out all of the ephemeris and date info and load all current data from scratch - hence the factory reset. There may be GPS modules that are able to get position while displaying the wrong date but that is not at all guaranteed - the accurate date is needed internally in order to use the correct ephemeris data to resolve the current satellite transmissions. You absolutely cannot count on getting a good fix with a bad date.

Greg

belizesailor · 15-02-2019, 17:33

Quote:

Originally Posted by sagablu

Who will wind the watch if all humanity is gone?

...or update the paper charts?

hellosailor · 15-02-2019, 22:10

Greg-
I have a vague but haunting memory that the ephemeris data is pushed out every 16-17 minutes over the entire system. Which means a GPS really needs 17+ minutes to do a cold start, to ensure it has the correct current data. But also, that an error from having outdated or incorrect ephemeris data, should go away in 17~ish minutes, no?
The first time this happened, I may have missed the memo but I don't think there was any mention that it would happen "again" at all.

CarinaPDX · 15-02-2019, 23:36

I don't know the period of repetition - I could ask my brother but I don't think it is important. More to the point is the duration of the information - I'm pretty sure it is on the order of days (i.e. once downloaded for one satellite it doesn't download again until it expires). All that matters is that there is ephemeris for, say, week 1023 while the satellite says it is week 0. The firmware needs to be able to handle the fact that week 0 is later than week 1023, which means the increment is actually a reset to 0. And no, waiting a few minutes or hours didn't fix it back in 1999.

Yes, it was understood back then that it was the first of many times that the week counter would reset; it was only that it had never been seen before and was difficult to test that it was overlooked and/or not debugged. Everything made today for the consumer market uses GPS modules inside, usually bought from specialists like Sirf or uBlox. The interface used to be NMEA 0183 out of the module, although other protocols are sometimes used now. If NMEA is used then the modules are mostly interchangeable and they are just a cheap commodity. Garmin is one of the few manufacturers of consumer products that makes their own modules. Raytheon used to be big. Sirf used to be big but now u-Blox is one of, if not the, leaders. While it is possible that the firmware in the end product messes up the data from the module it seems to me that we are talking about a firmware error in the module. I suspect that many of the suppliers of modules today didn't even exist 20 years ago so this is their first rollover. And to save a few pennies many modules do not have the ability to take firmware updates, and even if they did the end product does not likely provide for reflashing the module. My guess is that this is a problem from just one or at most two module manufacturers that screwed up, and they are used in a number of products. Pardon me, but just stupid...

Greg

Riggerman · 22-02-2019, 06:38

There We go. the millennium crash all over again. Remember. The world will end. Put your computer in a lead encase safe. Yadyayadya.

RobinScurr · 22-02-2019, 06:42

From one GPS geek site:

Quote:

Should I Be Concerned?

Because this it is the second time the GPS week rollover will occur, many receiver manufacturers have prepared for it, and newer receivers will continue to operate without issue.

You should be concerned, though, if either of the following applies:

* Receiver has been fielded for more than 10-15 years without firmware updates
* Receiver is a core component of a critical timing system – ask yourself – what is the impact to my system if the GPS receiver stopped operating or put out wrong GPS or UTC information

In these cases, we want to verify that an issue will not occur. At a minimum, we recommend consulting your receiver manufacturer to confirm that the issue has been fully tested and will not occur.

I went looking to see if my Garmin chartplotter would be OK and could not find anything thus far. However I did find these?

Service Advisory 1905: GPS Rollover

Service Advisory 0835 Rev A: GPS Week Rollover in Flybuddy GPS and Model 2001/2101 GPS Systems

I understand a few units had a problem when the week went from 999 to 1000, and this 2nd Garmin issue may be related to that. The issue was in the GPS chipset and could not be corrected by an update.

Apparently how your unit will be affected depends on how the developer handles time? An issue exists with the time of day ... GPS time is NOT corrected for leap-seconds, and so is currently 18 seconds off UTC. A UTC offset value is transmitted every 12.5 minutes, BUT it is up to the developer on IF and HOW they unitize it. (Do they use it at all? If they do, do they save the offset value? Do you have to wait each time the unit is powered up to re-learn it?)

raysmythe · 22-02-2019, 10:06

Thanks for this information. So, if my Garmin Chartplotter goes goofy in April, I should simply remove my flash card, reset to factory, then reload my fancy stuff, then it will be good, right? *yeah, the old 545s isn't the very finest, but it gets me there