AEP 5.5C Update Update: Bugs Identified, Being Fixed

February 11, 2010

Here is the latest on the AEP 5.5 update and and another error that actually occurred two weeks later.

On January 11, 2010 when the GPW Wing and the 2SOPS loaded the updated AEP 5.5C software to the "B" side of the ground control segment, it immediately caused a problem with a specific subset of GPS
SAASM receivers.

First of all, readers need to understand that one of the purposes of the 5.5C AEP update is to enable selective availability anti-spoofing module (SAASM) functionality in coded receivers. The software for the SAASM functionality has been resident in various certified SAASM receivers for sometime, but was never implemented in the ground control segment of the GPS. The AEP 5.5C update alleviates that problem for the majority of SAASM receivers, but for one manufacturer it has caused problems. The updated control segment software sends a specific code to SAASM receivers that allows them to authenticate the message and ensure that the code is correct, and is being sent from the GPS and not some other source. For most receivers this worked without a hitch, but for one manufacturer there is a software bug or glitch that must be corrected before the receiver can authenticate. This fix is in progress and will most likely be implemented as a software or firmware update to the receivers.

Another problem with a different set of receivers manifested itself exactly two weeks after the AEP 5.5C update was made on January 11. Those that have researched this problem in some depth feel that the problem is totally unrelated to the AEP update and would have occurred regardless.

On January 25, another set of GPS receivers started experiencing a major issue that has essentially rendered them unusable until the problem is fixed.

Reportedly, the Federal Aviation Administration identified a nuisance alarm (once per 12.5 minutes) with a civil timing receiver they use.

To understand this problem, recall that GPS keeps track of time in weekly segments that are represented by a number expressed in binary terms as part of a 32-bit word. This particular receiver, for some reason, stores the GPS 32-bit word with the timing information in the same general area where the error codes for the receiver are stored. You can probably see where this is going. Incredibly, the current weekly code in binary in the current navigation message perfectly emulates one of the receivers error codes, also in binary for this particular receiver and you guessed it: the receiver sees the timing portion of the navigation message and interprets it as an error message and immediately resets. This reset behavior becomes a continuous looping process that continues until the receiver resets a certain number of times, and as a planned safety feature virtually locks the receiver and it will no longer receive and integrate the navigation message. In other words, the receiver refuses to synchronize with the navigation message.

Again this is considered by all concerned to be another receiver software bug that must be dealt with by the manufacturer, and that process is ongoing.

Of course software bugs, or glitches, are a fact of life for our digital software-controlled world today, and although it is more of a rarity in the GPS world than in the PC world, it does happen.

Conspiracy theorists who have been active over the last month can relax now. There is no grand assault on the GPS by terrorists or others, it is just a couple of software bugs that have indeed wreaked some havoc with certain receivers. But the solutions are being implemented as you read this.

Yes, as it turns out, strict compliance with the receiver interface control document (ICD) may have prevented the first issue, but the second is just one of those serendipitous events that will occur from time to time no matter how careful we are.