[time-nuts] GPS PRN 32
magnus at rubidium.dyndns.org
Wed Jan 27 18:40:27 EST 2016
Considering how the UTC parameters (IS-GPS-200H, Table 20-IX and section
188.8.131.52.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.
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.
On 01/27/2016 09:38 AM, Charles Curry wrote:
> Update on PRN 32 / SVN 23
> According to the NANU this was decommissioned at 22:00 on the 25th. It was 25 years old http://archive.is/a8GI
> Some timing receivers experienced problems, some did not. Don't know why that is yet.
> So far our count is 8 different GPS timing receivers experiencing problems - ranging from mid '90's models, but still in service to the latest new devices. Problems included loss of lock, squelching of outputs, pulling the frequency off and massive pps jumps. In one case the output of a receiver was so bad it was rejected by the equipment it was feeding but the receiver did not alarm!
> A couple of units in my lab, based on the latest multi-constellation engine from a major supplier, one with Rb one with CSAC, exhibited 5 or 6 phase jump events from about 1:45 am until 12:30pm on the 26th. Our support team was kept busy from about 2 am on the 26th with at least 7 of our timing equipment customers reporting GPS errors.
> It looks like bad ephemeris was being broadcast from some satellites.
> I would say this is a similar problem to the April 1st 2014 Glonass outage reported here http://gpsworld.com/the-system-glonass-in-april-what-went-wrong/
> charles.curry at chronos.co.uk
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts