FRC Radios

The IFI radios are Ewave SCREAMER422 radios. They transmit at 9600 bps and have a serial RS-422 (not RS-232!) interface that runs at 19200 bps. There is documentation on Ewave's site that covers their whole range of radio modems, but it doesn't provide enough information about the SCREAMER422 to actually use it.

The radios up through 2006 haven't changed much since they were introduced and are still pin-compatible (although there was some improvement which seems to be ignorable from a programmer's point of view). The OI and RC have had at least three major revisions, but I'm discussing the old 2001-2003 system which is least useful for FIRST now (which is what I have lying around).

As of 2007, all new radios have been provided. These new radios are made by IFI themselves. It looks like the channels are further apart now (to reduce interference between adjacent channels?) but otherwise the specs are the same. The new radios cannot communicate with old E-Wave radios, but the interface to the RC is essentially the same.

Radio pinout:

There is a differential pair for data in each direction. On the radio, A receives and B transmits. The radio uses one DS75176B transceiver (unidirectionally) for each differential pair.

In order to use the radios with other equipment without sacrificing compatibilty with the IFI OI/RC, you need to build an RS-232 to RS-422 adapter. Use a MAX232 or equivalent to convert RS-232 to TTL and then one or two DS75176Bs to convert TTL to RS-422. Since the signal levels are 5V, you can treat the B+ line as TTL TXD from the radio, although this method will be susceptible to noise and so is not appropriate for use on a robot. The radio has a terminating resistor on the A pair so you must have a high-current differential driver for that pair. Note that the command/data line is TTL going into the radio, so it does not need an RS-422 driver.

All this differential signalling uses a lot of power (compared to unterminated RS-232 or TTL) but it greatly improves resistance to noise, which is why they did it. Robots are a very noisy environment, especially in FIRST where most people working on the robot probably don't know how about EMI measurement and control.

The radio appears to be able to be modified to have a TTL or RS-232 interface. There are pads on the main PCB for components to make the interface RS-232 or TTL, and to change power connections. Only one interface can be enabled this way at one time (this should be obvious). The missing U8 is a MAX232E or equivalent, and C5-C8 are its capacitors (see the datasheet). R10-R11 can be populated with 0-ohm resistors to enable the TTL interface. The DS75176B's must be removed if another interface is enabled. I have not tried this, however, so you are on your own if you want to try it. Also note that the radios will not work with the IFI control system (and either they or the control system may be damaged) if you change the interface.

Using the Radio

The radio has two modes: data and command. In data mode, all bytes received by the radio are interpreted as bytes to be sent. In command mode, the radio can be configured with ASCII text commands.

Command mode is entered by driving pin 6 low. Note that pin 6 is a TTL-level input, so low is 0V and high is 5V relative to pin 5 (GND). If you use a receiver on a MAX232 or similar, remember that the receiver inverts the signal so code on the host must assert the line (I chose RTS) to enter command mode.

The radio is always able to receives data, but the transmitter is turned off by default and must be activated by code. You can receive data on channel 40 after power-on without issuing any commands.

I don't know what happens if a packet is received while in command mode.

Radio Data

The radios always transfer data as 26-byte packets. The first two bytes must be 0xff. The rest of the bytes can be anything, and there is no error detection. You must provide your own (e.g. with a CRC) since the radio link will have occasional errors.

In data mode, the radio will wait for two consecutive 0xff bytes and then transmit those and the next 24 bytes. When processing data from the radio, your code should also wait for two 0xff bytes in case a packet was corrupted or interrupted by switching to command mode.

Be aware that while the interface to the radio is 19200 bps, the link between the radios is only 9600 bps. This means that it is possible to send data to the radio faster than it can transfer it. If this occurs, the radio will immediately abort transmission of the current packet and start sending the new data. I have not tested whether the sequence 0xff 0xff in a packet will cause the receiving radio to think this has happened, but I suspect it will. It looks like the OI/RC packet formats were designed to avoid this sequence.

Radio Commands

Commands are sent as ASCII text without any end-of-line characters. The radio's response is also text and does contain EOL's. The radio's response ends with OK if the command was valid or ER if not.

Ewave's documentation explains all of the commands (except for two secret ones) in detail. That files lists all commands for all models, however. Here is a list of all the commands that I have found to work on the IFI radios that I've tested:

The Ec0mp command must be issued to access all channels. Otherwise the C command will only work on certain channels. The FIRST OI sends this command when initializing the radio.

To maintain compatibility with the IFI control system, you shouldn't use Ds. It isn't really necessary anyway if you are able to switch to command mode and configure the radio whenever it's turned on.

Code

Here's a ridiculous use for IFI radios: a chat program for Linux.

Sample code for using serial ports in Linux: serial.c

Code to talk to the radios: radio.c