Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


CAP Implementation Guide Gives Glimpse to Future System

The greater flexibility of data transmission offers the possibility of improvements

Recently I found myself scanning through the CAP Implementation Guide, an interesting document prepared by EAS equipment manufacturers. The group is known as ECIG — EAS CAP Industry Group. CAP, of course, stands for the Common Alerting Protocol, which has been adopted as a standard data protocol for a revised emergency notification system currently in the works.

The guide is being developed to assist manufacturers in developing equipment that can operate compatibly. The goal is to have CAP equipment that will deliver the right messages to the public no matter which manufacturer’s system is used to send or receive messages. This is a worthy goal.

The new Emergency Alerting System under development is constrained by the need to operate within the existing EAS rules and SAME codes. CAP is a far more flexible and powerful system as it is based purely on data transmission, but ultimately it has to translate to something that works under the EAS system.

For example, the final “payload” of a radio emergency messaging system is an audio message. Under CAP, this audio message can be created from a text message using text-to-speech conversion, rather than relaying an analog audio file from sender to receivers, often over multiple generations. By generating the audio message from data, the quality can be maintained at a reasonable level even as the message is disseminated multiple times.

In my home state of Massachusetts, the Primary Entry Point for emergency alerts and monthly tests is an AM station with very broad reach, but the audio fidelity is noticeably lower than is typical on the many FM stations that then relay this alert. So this is a potential improvement. Done correctly, it also allows understandable messaging without having to find “announcer talent” amongst the state emergency management agencies.


The Guide provides the outlines of what could be possible in a new Emergency Alerting System. One of my pet peeves about the current EAS is its reliance on a daisy-chain of transmission. Typically, a single entry point station is used to generate the original alert or test, which is then relayed by other stations out to the public. In larger states, this can mean a significant delay before a message reaches the last radio station in the chain.

The capability of distributing emergency messaging via pure data transmission offers the possibility of building a system that does not require a daisy chain.

For example, the distribution of an emergency alert could now be accomplished via a relatively inexpensive path, such as the public Internet. All affected stations would receive the alert simultaneously, greatly speeding the distribution of an emergency alert at a fairly modest cost. An audio alert message could be placed at a website and downloaded automatically for playback from the receiver. A more hardened distribution system, such as satellite, would be an option where a higher reliability backbone is desired to supplement some or all of the chain.

One of the other great advantages of using alert distribution by a data path such as the Internet is the ability to conduct a “closed circuit” test of the system. Receivers can log all the relevant information, alert local engineering personnel and even respond back to the test sender with acknowledgement messages. To me, this offers the means to a large reduction of over-the-air testing, which we all dislike.

It may still be necessary to do the occasional “instructional” test to keep audiences educated on what an alert sounds like as well as to monitor actual system performance (similar to the existing Required Monthly Test) but weekly on-air tests potentially could be eliminated. That’s an improvement that broadcasters could get behind.


The CAP Implementation Guide also endorses a strict limit on message length of 1,800 characters maximum. This is important to make emergency messaging workable, both for direct display of the text message on advanced receivers or television systems and to keep the audio message within a two-minute length. Enforcing an efficient alert will contribute to the effectiveness of the system and reduce audience tune-out. The industry group recommends truncating audio messages of greater than 120 seconds, including those generated using text-to-speech conversion.

While the standard language for alert distribution is English, the CAP system supports audio messaging in multiple languages where this is desired. If a second, or even third, language version of an audio message is desired, the recommended operation is to have the receiver play the message in English, send the end-of-message data burst, and then play out any additional language messages immediately after the test concludes. This allows stations to select whether or not they wish to air alerts in more than one language based on their demographic service area, or to just stick with the English version.


A new feature of CAP is a class of alerts known as “Governor’s Must Carry.” By creating a new class of messages that can be generated by local state agencies, the system has an input for local emergencies. That’s an important feature of any new alerting system.

As most of you are aware, the EAS system is getting long in the tooth and is in need of updating to something more flexible and reliable. Discussions by government agencies have been under way for some time now, but many of the elements of the “new EAS” seem to be coming into place. From what I read in the Implementation Guide, some very good thinking has already taken place about how the future system could operate.

It’s important for all of us to stay aware of these discussions and to help to develop a system we all can live with. We can even hold out some hope that it will provide a useful public service and possibly save lives. That’s also a worthy goal.