SRCP-Spec

Simple-Radio-Control-Protocol (SRCP) Specification

StationList has implemented SRCP, and can now communicate with any radio that implemented this protocol.
If you want StationList to work with your radio then ask its creator to implement SRCP. It is simple and straight forward, implementation typical should be a one-afternoon-job

What is it?

SRCP specifies a method to control a radio and get its status back to StationList (or a similiar application).
To avoid any headache on user and software writer a very simple method was chosen.

Communication is done by sending UDP string messages. The sender just sends a msg, even when the receiving side is missing no timeouts or irritating warnings will occur. Each side opens a UDP-listener port at startup. No user interaction required.

Radio-App's that have implemented SRCP

XDR-GTK by Konrad Kosmatka

Marko Weck in his system controlling a Technics analog radio

IP-Address default is 127.0.0.1 (both parties run on the same local machine)

UDP Port default

StationList listens to port 9030 and sends to 9031

Radio-Application (like XDR-GTK) listens to 9031 (always +1) and sends to 9030

StationList behaves like a dumb terminal:
When a user changes the frequency within SL, it sends that frequency-value to the radio-app, which then tunes to that frequency and sends the new value back to SL. Only then will SL update its display.

Each partner only sends data updates when a change has occurred on his side. Regular querying is prohibited. So when the user changes the frequency at the radio-app, it will send its new value to SL.

Example

A single UDP msg from SL to the radio-app (target-port 9031) to set the radio to 87.5 Mhz looks like this:

from=StationList;freq=87500000

The radio-app then tunes to 87.5 Mhz sends back its actual set frequency to target-port 9030

from=radio-app-name;freq=87500000

SL and radio-app provide an option to use a different IP-Adr and Port. That allows several SL <--> radio-app combos running on the same PC independendly of each other.

Message-format [string]

has 2 or more fields sperated by ';'

fields unknown to the message-receiver are ignored

new fields for other purposes can be specified. They will not interfere with unaware message-receivers.

Field-definition:

Each field consists of name and value separated by '='

field: name=value

numerical values are always using base units. (Hz instead of kHz or MHz)

The first field is always the name of the message-sender

from=name of device

Example:

from=StationList

freq=n in Hertz

freq=? requests radio to send current value, so SL can update its display

Example

from=StationList;freq=87500000 --> radio now tunes to 87.5MHz

from=radio-app-name;freq=87500000 --> SL updates its display to 87.5 MHz

RcvLevel=n S-Meter Value [1..100]

Bandwidth=n [Hz] 1 .. 260000

negative values: radio uses automatic bandwidth mode

Bandwidth=? requests radio to send current value, so SL can update its display

RDS

PI=HexValue

PTY=HexValue

ECC=HexValue

AF=Original-RDS-HexValues (*) (max 25 byte values)

PS=Original-RDS-HexValues (*) (max 8 byte values)

RT1=Original-RDS-HexValues (*) (max 64 byte values)

RT2=Original-RDS-HexValues (*) (max 64 byte values)

ClearRDS=1 Clears entire RDS data in SL (only in rare cases needed)

* = decoding is performed by SL

Example

PI=F705;PTY=56;ECC=E0;AF=12345678... (all in one string)

(values in Hex, in AF: Hex byte-wise)

RDS message is only sent when the content has changed against the previous msg.

SL automatically clears its RDS data on each frequency change, no matter who initiated that.

Refresh rate: not faster than 5x per second.

The Rx can send all RDS-items in one message, no need to send each item seperately.

Note about AF

The AF-Data is a 25 byte long FIFO buffer in the Rx that is constantly filled up with each new (not yet in buffer) AF packet the Rx receives, the oldest entry gets lost when the buffer gets full. According to RDS-Specs there are no more than 25 entries. I am not sure if this is strictly obbeyed, at least this amount is sufficient for SL to do AF-search in the database.

So the Rx should first check if the new rcv'ed AF-byte is already is in the buffer, if not then add it. All unused byte are set to zero. The Rx doesn't need to sort that buffer, SL does it.