The Specific Area Message Encoding protocol for the Emergency Alert System adopted by the Federal Communications Commission and the National Weather Service contains no error checking component. The lack of this component leaves the content of all messages sent by these systems in doubt. Both systems are intended to carry critical life saving, and national security information to the public. Shouldn't information of this importance be protected by simple error checking codes? The problem can be overcome by simply appending a four character CRC-16 code to the end of each message. It is believed that this method would be backward compatible with equipment installed in the field. Though present equipment would not be capable of checking the CRC-16 code, this capability could easily be included in future equipment. Many installed units might be software upgradable to do the CRC-16 checking.
I. The present system.
For whatever reason the designers of the Specific Area Message Encoding (SAME) protocol did not include an error checking component in the message. They did foresee the possibility of transmission errors and included the requirement for transmitting the message three times and requiring the receipt of two identical messages for validation.
The two message procedure doubles the odds of receiving a valid message but it does not provide a high level of certainty. In fact it reduces the likelihood of receiving the message at all in a very noisy environment. Such a noisy environment is often the case for NOAA Weather Radio users where messages are most commonly sent during thunderstorms. Lightning present in thunderstorms produces random impulses in the receiver output resulting in single bit upset errors. Single bit upset errors are likely to cause all three messages to be different resulting in no valid message being received. Therefore, end user weather warning receivers should not use the two identical messages validation criterion.
Another potential source of errors is timing skew. The SAME specifications call for bit period timing to be 1920 +/- 1 microsecond. Assuming that this specification applies to both the encoder and decoder, in the worst case the longest message that can be sent without drifting out of specifications is 120 bytes long. That would limit the actual message to 10 location codes. The specification calls for messages up to 31 location codes (268 bytes) maximum. In the case of timing skew it is very likely that two or three messages would be identically wrong. Thus, the two identical messages criterion would not work in fact it would validate an invalid message. In reality decoders can overcome timing skew by recovering a clock signal from the received data.
There are other sources of errors such as multi-path, fading, equipment error, and various forms of interference. Each source of error has its own characteristics and the SAME protocol will perform differently in each case.
A received SAME message appears as the following:
There are normally a few extraneous characters received before and after the message. The start of the message can be found after the initial flag characters by matching the "ZCZC-" string. The only way to find the end of message is to wait for the carrier to drop, scan for the last dash and/or analyze the content pattern of the message. The beginning and end of message must be found before comparing messages for validation or the comparison will almost always fail.
My conclusion is that the present SAME protocol is very error prone and is not reliable enough for the purpose it is intended.
II. An improved system.
Techniques have been available for many years to transmit this type of data much more reliably. Not just after the fact error checking but forward error correcting codes, self redundant codes, or even more advanced techniques would have made this a much better system. However, the SAME protocol is already in place. So we are forced to consider how it can be improved.
It is easy to improve the message reliability by appending a four (Hexadecimal) character CRC-16 code to the end of the message. If the character at the end is something other than a dash and because the CRC-16 string does not match the present SAME pattern it would be rejected by present equipment as extraneous characters. New equipment would be able to recognize the CRC-16 and use it to validate the message. A SAME message with the CRC-16 appended would appear at the receiver as follows:
A character which is presently illegal such as ACSII ETX (decimal 3) could be used so that new equipment can find the end of the message more easily. Old equipment would simply see the appended characters as extraneous and ignore them.
The addition of an error checking component to the SAME messages would greatly improve the reliability of the system. The requirement for two identical message validation could be dropped with an improvement in reliability and equipment simplicity. Accuracy would be assured and the speed of message receipt would be doubled on average.
A small measure of security could be gained by adding a bias to the CRC-16 calculation at both ends of the link in an EAS application. If both the originating and the receiving stations maintained a confidential bias table in the SAME equipment it would make faking messages much harder. The bias technique cannot be used in a broadcast system ( e.g. NOAA Weather Radio ) because of the lack of confidentiality.
I have presented a technique for improving the reliability of the SAME protocol. By the simple addition of a CRC-16 code to the SAME messages at origination and checking at the receiver the reliability can be greatly improved. The technique is believed to be backward compatible with presently installed equipment. In most cases the only changes necessary will be in the form of software and are optional.
(C) Copyright 1999, by Richard D. Burgan - Permission granted for use if credit is given
Richard D. Burgan - WC8J home page