The RDS encoder is configured and controlled via the serial port. The RDS specification define a specific protocol (UECP, Universal Encoder Communication Protocol) to be used for communication with a RDS encoder. The communication is asynchronous, (normally 2400) with a framing format.
Consult RDS Universal Encoder Communication Protocol UECP Version 5.1 for more information
The electrical and mechanical interface is accomplished with a serial interface based on the EIA RS 232C (compatible with V24/V28) with full-duplex and hardware handshaking.
Either a 25-pin SUB-D or 9-pin SUB-D connectors can be used. Here we use a 9pin-SUB-D male connector as a DTE (Data Terminating Equipment). The signals on the 9-pin DTE connector are;
| Pin | Signal | I/O | Signal description |
|---|---|---|---|
| 1 | DCD | I | Data Carrier Detect, optional |
| 2 | RXD | I | Received Data |
| 3 | TXD | O | Transmitted Data |
| 4 | DTR | O | Data Terminal Ready |
| 5 | GND | - | Signal Ground |
| 6 | DSR | I | Data Set Ready |
| 7 | RTS | I | Request to Send |
| 8 | CTS | O | Clear to Send |
| 9 | RI | I | Ring Detect, optional |
The data is transmitted with 8 bit characters in asynchronous mode. Each byte is preceded by 1 start bit and followed by 1 stop bit. There is no parity bit. Transmission speeds can be 75, 150, 300, 600, 1200, 2400, 4800, 9600 and 19200, 38400, 57600, 115200 bps, but here we use 2400.
The data is sent as a series of data frames.
A frame comprises a series of bytes, delimited by two reserved bytes, which mark the beginning (STA) and end of the frame (STB). Each frame contains a destination address, defining the set of encoders to which the record is being sent. A sequence counter for each separate record. The message length, then the message itself and terminated with a CRC check.
Since the start and stop bytes must be unique, ie; must not occur in any other fields of a frame. The frame is byte-stuffed prior to transmission inorder to transform a reserve byte occurrence into two stuffing bytes. The opposite happens reception, the byte-stuffed frames are removed prior to frame processing. This allows a message to freely uses any byte value. The transmitted message length will increased but the defined length of a message will always be the shortest unstuffed state.
A non-zero message field, consists of one or more message elements, each with a specific structure.
Subject to a maximum field length of 256 bytes, several message elements may be packed together into one message field. Note: An individual message cannot be split over two frames. Also this length will decrease if optional fields are included.
The complete two message field may be represented as follows:
MEC,[DSN],[PSN],[MEL],[MED],[[MEC,[DSN],[PSN],[MEL],[MED]], ...
Where the fields in square brackets are optional.
| Field description | Descriptor | Field Length |
|---|---|---|
| Message Element Code | MEC | 1 byte |
| [Data Set Number] | [DSN] | 0...1 byte |
| [Programme Service Number] | [PSN] | 0...1 byte |
| [Message Element data Length] | [MEL] | 0...1 byte |
| [Message Element Data] | [MED] | 0...254 byte |
The UECP transmission is quite simply a standard serial asynchronous communication, fully explained on the WEB and does not require repeating here. The MEC frames are sent and a reply expected to confirm the communication. Being a standardised protocol any generic RDS UECD program can be used for the basic setup of the encoder, with independence of the manufacture of the encoder. However the UECD also permits manufacture specific commands to be sent. Obviously to take advantage of these enhancements the API from the manufacturer of the encoder is required.
The encoder presented here is basic in nature and does not use any "special" commands.
An Abbreviated List of MEC Commands
Some of the peculiarities of this protocol are byte stuffing
and the inclusion of a cyclic redundancy check (CRC).