Magnus Danielson wrote: > Charles, > > Considering how the UTC parameters (IS-GPS-200H, Table 20-IX and section > 20.3.3.5.2.4) got upset for some of the SVNs, the correction from GPS > time (as corrected for that PRN) into UTC got a shift of almost 13,7 us. > As a GPS receiver receives information, solves for position and time > (fixed timing receivers naturally only for time), correct into GPS time > and then into UTC you end up with having to select the information from > one of the GPS satellites for translating the GPS time into UTC time. > Depending on the state of that GPS receiver, it may or may not select > this bad info, and it may change selection at any time. That's why we > have observed receivers of the same brand and same FW fail at different > times, but starting having problems at the same trigger time. While > there can be receivers that have some form of protection from this > particular problem, I guess many don't, and in this case, the specifics > of the receiver FW and the actual state of the receiver may have cause > the full range of heavy to no impact. I would be careful to make to much > judgment of various receivers because of this. It is clear that it's a > serous hit to at least most of them.
Absolute correct, IMO. > I remember the impacts from PRN 31 and PRN 32. The re-occuring GPS WN > wrapping issue is another. This instance is rather unique in it being > related to the ground infrastructure seems to have provided bad upload. > > There is an intense amount of work behind the scenes. Some patience will > be needed before even a minimalistic statement can be found. Now there's a statement available. See my other post. Martin _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.