The author is director of engineering and operations for Wisconsin Public Radio; this article is based on his presentation at last year’s NAB Show.
Wisconsin Public Radio is a statewide radio service with three networks airing on 34 stations. WPR successfully has been transmitting Program Associated Data text to HD and FM-RDS receivers via these stations for about two years. The metadata we are sending includes both static and dynamic information: station call signs, slogans, music title/composer/artist, talk show topics, names of shows and program hosts, weather reports and station promotional information.
As an active participant in our state Emergency Alert System, as well as a leading proponent of PAD transmission, it struck me that it would be a useful public service for listeners if text information for serious EAS alerts were visible on the radio receivers with RDS capability and HD capability. Our goal: If a listener hears the EAS alert tones but misses the audio message, a glance at the radio display would provide the important info.
Immediately the question arose as to whether or not we should include information related to weekly and monthly tests in the EAS data being fed into the WPR PAD stream. I weighed the options, and discussed the pros and cons with colleagues. Most felt that EAS testing is meant more for proof of system performance and less for education of listeners. For example, most stations conduct weekly tests with no announcements purely for confirmation that the technology is working. Monthly tests more often contain announcements, and in many areas do serve a secondary listener-education purpose — they sound more like alerts. Should EAS tests show up on radio data displays? Our decision was “no”; we would only transmit PAD data for actual emergency alerts, but the question remains open pending future feedback from listeners.
GETTING STARTED
What would be our sources of appropriate emergency alert information? Where should it come from and where should it be sent? Given the geographically-coded nature of the EAS system, the WPR EAS encoder/decoder in each region of the state should be the source of the EAS text for the PAD data system serving the stations in that region. The EAS system would become another input source for our PAD system.
It seemed wise to shake out any kinks in this project using our flagship station WHA AM-970 in Madison, Wis. WHA would be the guinea pig, especially handy since the equipment that would be involved would all be found in our Radio Operations Center just down the hall from my office!
So the first stage of the project would be to put EAS on the HD PAD stream for WHA and the RDS text signal going to WHA’s FM translators. If this proved successful the next stage of the rollout would be to add EAS messages to the HD-PAD and RDS of our other Madison area stations. And eventually the project would grow to include our stations in Milwaukee, Green Bay and other areas of the state.
WPR’S PAD SYSTEM
Fig. 1 shows the relatively complex system necessary for WPR’s transmission of Program Associated Data. To the left on the diagram you can see most of the inputs — the PAD information sources for networks. In the middle of the image is the main PAD sorting/routing system based on Arctic Palm’s Center Stage product, and to the right are the regional sorting/routing systems and examples of the outputs — the radio stations transmitting the data. Note that the geographically-coded Emergency Alert information is to be inserted into the “regional” data flow that serves clusters of stations in a given geographical area.
Interconnection of the various pieces of the existing system is provided by TCP/IP communications by wired Ethernet. I noticed that all the EAS devices involved had Ethernet ports — wouldn’t it be nice if the emergency information could move from the EAS encoder/decoder to the PAD sorting system by TCP/IP on the local area network? Networked connections could be especially useful given that in many instances our EAS equipment is not located in the same room or even the same building as the PAD server.
DETAILS, DETAILS
All the WPR stations are driven by Sage Alerting ENDEC equipment. Sage let me know that the ENDEC can send a file by FTP, and there are hopes for RDS encoders and HD gear will eventually be able to use that data directly. Unfortunately this idea would set up a one-to-one relationship between the EAS unit and its station’s HD and RDS encoders, not suited to our more complex plans in which the emergency alert information from an EAS box would be merged into an already existing flows of metadata headed out to multiple stations in a given region.
Sage suggested that the serial port output from the EAS units would be another possibility. Most, if not all, of the manufacturers of EAS equipment provide a serial text output that is sometimes used to drive wall displays and video character generators (Fig. 2).
At the same time, Arctic Palm Technology responded to my inquiry and confirmed that their Center Stage Live software had a module in beta test for handling serial Emergency Alert System data. Arctic Palm had modified Center Stage’s “CSWeather” program to create the capability to handle EAS text data received via serial port. These serial ports seemed like the most likely source of appropriate text information about the EAS alerts for our PAD stream.
DODGING THE LIMITATIONS OF SERIAL
It appeared that the only practical option would be a serial connection. Unfortunately this is only convenient if the EAS box and the computer are relatively near to one another.
Since IP network connectivity was available near each system, I next envisioned using tunneling devices to carry the serial data via the Ethernet network. I have had considerable success sending both contact closure and serial data across the wide area network that interconnects our various radio facilities around the state. For example, when we produce one of our network call-in talk shows at one of our bureaus I provide a remote profanity delay “dump” button that is a contact closure tunneled through the Ethernet network.
Serial tunneling enables you to establish a link across an Ethernet network for signals like contact closures or RS-232. The serial data is packetized in both directions into Ethernet TCP/IP packets by a converter device, an adapter of sorts, sometimes called a serial device server. The packetizing allows a user to connect a serial device to another serial device via the Ethernet network in a way that is hopefully transparent to the serial devices and of little or no impact to other uses of the Ethernet network.
In my vision for the EAS PAD data connections, a serial-to-ethernet converter device would connect to the serial port on the Sage EAS unit and would make the serial data available via the existing local or wide area network. At the other end, the mating ethernet-to-serial converter could be used to send the data into a serial port on the PAD server.
A search for such products revealed numerous sources. One appealing unit was the Lantronix NET232+ devices offered by Grid Connect (Fig. 3). The hardware is simple and the supporting software seemed to be well regarded. Ease of configuration and reliability in operation are important in on-air systems such as these.
It was easy to imagine a pair of these NET232+ devices being used to tunnel the serial data across our Ethernet network as shown in Fig. 4.
AN EVEN BETTER IDEA
It occurred to me that the PAD server PC already had an Ethernet connection. Could the server receive the tunneled serial data directly? Digging deeper, I learned that the NET232+ could also be used to reach a “virtual serial port” directly in the computer, eliminating one of the converters. With this realization it was easy to imagine one NET232+ devices being used to tunnel the serial data from a Sage ENDEC across our Ethernet network to the PAD server as shown in Fig. 5.
Com Port Redirector is a free software utility available from Lantronix to send and receive serial data between a virtual Windows COM port and a NET232+ device. Most application programs should not know the difference between a real, hardware com port and the virtual port. As the Lantronix website describes it, Com Port Redirector is software that maps “virtual COM” ports on a PC platform. It redirects application data that would normally be intended for an attached device via the PC’s local serial (COM) port. Rather than going out the local serial port, the data is transmitted across the Ethernet network using TCP/IP. A device server attached to the network receives the data and transfers it from its own serial port to the attached equipment.
Likewise, data sent from the equipment to the serial port of the device server is transmitted back to the application software on the PC via Ethernet. Com Port Redirector receives the data and presents it to the control application in a virtual simulation, as though it came in from a COM port via a local serial connection.
But beware; some programs expect instant responses from serial ports when opening and closing com ports. To deal with this issue, Com Port Redirector can be set to keep the IP connection open even when the com port is closed, reducing latency and soothing these picky programs.
CONFIGURATION
Lots of details are important in setting both ends of the serial-over-Ethernet link: The Sage EAS unit’s serial port must be selected and configured — baud rate, data format, etc. Likewise there are various settings for the virtual serial port in the server, and the static IP addresses assigned to the network side of the link.
The Sage EAS unit’s serial port must be selected and configured — baud rate, device format, etc. I chose COM4 and 9600 baud.
The Sage ENDEC’s character generator serial output precedes each message with a number representing the “severity” of the emergency. This would be used by the Center Stage software to decide if the EAS information was to be sent through the PAD system, or not.
Level 1 message are direct threats to life and property like weather warnings, Level 2 are informational, like weather watches and Level 3 messages are tests. This would be used by the Center Stage software to determine if the EAS information was to be sent through the PAD system. A given organization might prefer for everything to be sent through for display on HD and FM-RDS receivers, but there is an argument to be made for limiting the messages being transmitted to actual alerts.
We decided to configure the CSWeather-EAS software to pass along only EAS Level 1 messages, and edit the text down to just the type of alert, with the phrase “for our listening area” added. This allows the coverage area of the radio station to automatically limit the geography of the alert. Radio displays are limited in the number of characters displayed, so it is important to keep the total text string down a readable length. In our configuration an EAS text message on a WPR station would appear like this:
TORNADO WARNING FOR LISTENING AREA
This message would continue to appear among the rotating PAD messages displayed for the duration of the emergency activation.
TESTING
First and foremost, I patched the Sage ENDEC out of the WHA program path so I could generate test messages without annoying the listeners. Don’t forget this step! I speak from painful experience back when we were first testing EAS gear in the 1990s.
With the redirector software installed on the PAD server computer and everything connected, I first used Windows own “HyperTerminal” program running on the PAD server computer to make the first connection and troubleshoot. There I was able to see test messages from the EAS unit.
Next I configured the CSWeather-EAS program to look to the same COM port and confirmed EAS test messages were being logged.
Then I configured the CS-Weather-EAS software program to forward warning-level 1 alerts, but not watches or tests, to the associated stations. For this first stage of the project the destinations are the HD PAD generator for AM station WHA and RDS encoder for its FM translator stations.
RESULTS AND SUMMARY
The CSWeather-EAS program keeps a log of all the EAS messages received and transmitted. Fig. 6 shows a sample page of this log showing of various tests and alerts. For each entry I’ve noted the type and whether or not the RDS and HD PAD text message was forwarded. This confirms that only Level 1 alerts are being sent to the radio receivers.
In summary, Wisconsin Public Radio has successfully added Emergency Alert System messages to the mix of metadata being transmitted via our Program Associated Data system for display on HD and FM-RDS receivers.
Our initial tests on our flagship AM station WHA and its FM translators proved the reliability of the system, and it has since been expanded to serve our other Madison-area stations. The next phases will bring this service to WPR stations in Milwaukee, Green Bay and other areas of the state.
Cost for this project is low, listener feedback has been positive, and the effort involved has paid off in useful public service. Our goal has been reached: If a listener hears the EAS alert tones but misses the audio message, a glance at the radio display will provide the vital info.
Steve Johnston, CSRE, started taking apart radios as a youngster and became a ham radio hobbyist at age 13. He worked for Susquehanna Radio Corp. for 20 years, then went into public radio as director of engineering and operations for Boise State Radio. In 2005 he moved to WPR. He holds FCC Radiotelephone and Radiotelegraph licenses, network engineering certifications, a BA in history and a master’s in business administration.
