With all of the Federal money available for “Intelligent Transporation Systems”, smog reduction, etc., it really surprises me that no one in the US has organized an effort to develop a industry protocol to send coded traffic info “in the background” to mobile receivers via RBDS.

I realize that the existing RDS/RBDS standard already provides a TP flag and the ability to switch from cassette/CD to radio or raise volume during voice traffic anouncements, but that's early 80's technology (an enhancement of Blaupunkt's old ARI system) and requires that the information must be carried “in band”. Therefore, it conflicts with regular programming and is a “turn-off factor” to listeners who aren't driving.

In most metro areas, the DOT already has the ability to monitor traffic speed on most of the major highways, and they can also manually post the location of accidents or construction delays. This information is available online on websites like traffic.com. For example, the Philadelphia real-time map is available at http://www.traffic.com/Philadelphia/index.html.

That's great if you have Web access in your car and don't mind surfing while you try to drive. I don't know of many drivers who do.

What we need is a scheme that simply broadcasts this data in continuous coded form using spare RDS groups. The receivers would collect it and could either display it visually (in text form by route number/milepost/exit number — or on a map), or announce it audibly with a voice synthesizer.

This idea becomes much more practical if you consider that GPS receivers are rapidly dropping in price, such that it's not a big deal to factory-install them in cars. Anyone with OnStar or a fancy navigation system already has one. So let's interface the GPS receiver with the traffic data decoder so any irrelevant reports are filtered out. (The broadcast protocol would tag each report with coordinates, making this feature possible.) There's no need to know what happened 20 miles behind you.

The driver could even store their daily commuting route in memory; when they pull out of their driveway in the morning they would hear a “customized” current report. An instant update would be available by hitting a button.

Of course, location-specific public warning data (enhanced EAS) could be disseminated this way as well. Getting the datastream to the broadcaster's encoder would be handled via internet, or by off-air relay, to keep costs down.

The receiver chipset would be designed to keep the FM tuner operational in “RBDS decode mode” only whenever the user is listening to AM. In this mode, the FM section would simply scan for the closest transmitter carrying the traffic data; operation would be “transparent” to the user, who would hear the desired AM program.

Needless to say, the biggest challenge here is getting all of the players (broadcasters, receiver makers, car guys, chip designers, departments of transportation, FEMA, etc.) to talk to one another. I doubt that the FCC would need to get involved here (RBDS is already legal), so perhaps there's hope.

Mark Humphrey, CPBE
chief engineer
WPLY/WPHI Philadelphia

---

Send comments to radio@primediabusiness.com.

---