Rapid Prototyping a Broadcast Radio Controller With Embedded Linux

When we first heard about the requirements for a project to network-enable to point-to-point broadcast radio we thought ``Kevlar, eh?'' The radio's goal (well, one of them) was to provide wireless communications in regions where traditional fiber optics were infeasible. We were surprised to hear that (particularly in countries with considerable political turbulence) fiber-optic cables were being dug up and raided for their valuable Kevlar sheathing (likely for home-brewed bullet-proof accessories). In these situations we were told wireless communications were ideal.

A typical radio installation may consist of 50-500 units arrayed in a manner to relay a digital signal across a large radio network. At each node a pair of radios provide point-to-point connectivity with the next node in the network (see Figure 1). These networks are frequently expansive, capable of spanning thousands of miles of often difficult-to-navigate terrain (one such installation is in the Amazon rain forest). Although each radio unit is preconfigured for installation, there are a number of adjustments and parameters that require routine attention. These include determining whether a radio is operating on a primary or secondary transmitter, measuring power supply voltage readings or verifying transmission frequencies.

The radio has a front panel that can be used to retrieve and adjust configuration parameters, but to do so requires an on-site operator. To ease administration and monitoring of a large network (particularly those, like the fiber-optic replacement, where it may be inconvenient or dangerous to service regularly on location), Moseley Telecommunications, our client, decided to add a suite of network accessible features. Since the existing radio was already reliable, Moseley wanted to minimize changes. They decided to add hardware to provide the additional functionality (dashed box, Figure 1).

Figure 1. Radio Diagram

The project requirements were as follows: to allow radio users the ability to use common TCP/IP protocols (SNMP and HTTP) to view and update the state of their radio, add network connectivity (routing) between units and add support for an Ethernet connection. These requirements were subjected to the following constraints: to support the existing I<+>2</+>C backplane, minimize software licensing costs and develop a working, embeddable prototype in just under two months.

Moseley was already leaning toward Linux software with a hardware choice of Bright Star Engineering's (BSE) ipEngine platform. The ipEngine board sported a Motorola MPC823 PowerPC processor (with I<+>2</+>C support), 16MB RAM, 2MB flash, 2 serial ports, 1 Ethernet port, a 16K gate FPGA (that went unused in this project) and a small footprint that would embed nicely into the existing radio case. At the time of development, the only available OSes for this system were a proprietary RTOS and a thinned version of Linux/PPC supplied by BSE. Since many of the desired features for this project were available in Linux distributions and there were no real-time constraints, we opted for the Linux OS. By choosing the BSE/Linux system we had already met our first two constraints (I<+>2</+>C support and zero-cost licensing). Next, we had to develop a working prototype in under two months.

The idea of developing a working prototype system on a Linux base under strict time constraints appeared a bit daunting at first. However, our experience with Linux software has demonstrated the power of an Open Source community with high-software availability at no cost. On the other hand, we became aware of some of the drawbacks of an Open Source community; namely, sometimes difficult to access community-based technical support, sparse documentation and the possibility of conflicts on differing platforms. These difficulties are often mediated by the responsiveness of developers in this community. However, time being precious, we did not want to get bogged down finding an ex-package maintainer or go through extensive porting of applications.

There were, fortunately, many factors in favor of Linux. Since SNMP and web support are widely available in Linux distributions, a large amount of time could be saved if clean ports could be made to our target platform. In addition, the fact that the Motorola-based target platform supported Linux/PPC allowed us to employ a standard PowerPC system running Linux/PPC 2.2.13 as a development environment and staging platform. This was a significant improvement over the Windows-based cross-compilation tools provided in the BSE package, making our full-system testing cycle as short as possible, which aided tremendously in keeping the project on schedule. Additionally, because this was a prototype system, we were able to use a rather complete target hardware system and not have to be as careful about memory restrictions as in a production environment (where purchasing large RAM and flash chips might be a bit hazardous).