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 (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.

A single UDP msg from SL to the radio-app (target-port 9031) to set the radio to 87.5 Mhz looks like this:  
The radio-app then tunes to 87.5 Mhz sends back its actual set frequency to target-port 9030  

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.  
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  
freq=n in Hertz  
freq=? requests radio to send current value, so SL can update its display  
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

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  
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.  

  ©  3S design GmbH   Zeiterfassungs-Systeme   Zugangskontrolle-Systeme   BDE-Systeme   Ferienwohnung südliche Nordsee