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
[email protected]
______________________________________________________________________
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 -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
