[time-nuts] GPS PRN 32

[Magnus Danielson]

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.

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.

Cheers,
Magnus

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
> 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.
>