4 ms·
It's not that surprising that it has a problem with error, because the reality is, there's no correct solution for dealing with this kind of error. The first q
by elfchief 11y ago
It's not that surprising that it has a problem with error, because the reality is, there's no correct solution for dealing with this kind of error.
The first question, of course, is "how do you determine when there's an error?" Half the GPS constellation was broadcasting the data, and for almost all purposes it was 'correct' data, other than being wrong. Perhaps ground stations could determine that they're getting different data from different satellites (if they have some good ones in view), or maybe they could just decide that the new parameters differed enough from the old ones to be implausible, but neither of these is a cut and dry "I definitely have an error" ... but let's say you have a foolproof way to determine that A0/A1 are incorrect. Great. THEN what do you do?
You could just decide to use the previous value for that parameter... which is great for a single clock, but what about clocks elsewhere that have a different value (the one being broadcast by the rest of the satellites) or an out of date value (say, a clock that was powered off while traveling in a broadcast van)? Barring external communication, you could have an arbitrary number of different interpretations of the current time -- a different one for each ground station!
You could also just accept that the new parameters are correct, but how do you then get your clock to the new correct time, without having a second (or other time period) that's significantly longer or shorter than a second? There's a lot of gear that expects a second to be a specific length, which is not gonna be happy if the length changes. (Think of playing back an audio file that's exactly 30 minutes long, and needs to start and stop at specific times, down to the bit. You then configure your system to send one bit every (1/bitrate) seconds exactly. How does that system recover when 13µs of bits go missing? How do you coordinate that behavior over multiple disconnected systems around the world which may have gotten the same information at different times (or not at all)?
From reading the article, it sounds like what happened was that the units didn't fail because of the GPS issue, but that they start throwing alarms (probably while going into a mode where they ran off only their internal (disciplined) oscillator. This seems like absolutely the right thing to do -- "uh, boss, things look really not-right here, and I can't fix it without breaking something, you really need to come deal with this yourself." (Note the comments about 'thousands of system warnings' but none about 'cellphones broke.') This is, from what I can see, really the only reasonable behavior these devices could have.
(disclaimer: I don't have any direct data on what broke vs. what complained loudly and woke people up. I'd love to have some solid, not-parsed-by-the-tech-media data on this topic, if anyone has any.)
- contingencies 11y agoI don't know anything about the specific event. However, regarding your question of how to programmatically handle partial failure scenarios, I would reduce the trust in individual components (eg. satellites, receivers, receiver firmware releases, etc.) via redundancy and a voting-type mechanism to evaluate individual component outputs and their changes over time versus probable reality. Such a system would possibly include multiple offline clocks to match prior signals and thus maintain increased fault/drift-tolerance.