HomeProjectsDownloadsLinks
 Swarga Research

Projects > sircond

SiriusConnect Daemon

Back in 2005, I purchased a lifetime subscription to Sirius Satellite Radio. I also purchased a TimeTrax TTS-100 receiver package. Unlike today, where all new cars come standard with SiriusXM receivers, back then if you wanted to have Sirius in your car you had to purchase an aftermarket unit and install it in your car. SiriusConnect is a standard interface which Sirius developed to allow the manufacturers of third-party car stereos like Kenwod and Pioneer to control the functionality of a Sirius receiver add-on module. While intended for use in automobiles, a company called TimeTrax Technologies created a compatible interface designed for use with a computer at home. The TimeTrax TTS-100 consisted of a standard SiriusConnect car stereo receiver module and an interface box with a USB port and an audio output jack. The TimeTrax software allowed you to control the receiver from your Windows PC.

The TimeTrax TTS-100

If you've never heard of TimeTrax that's not surprising. It started out as a software application for the XMPCR, one of the first PC-controllable satellite receivers, that would capture the audio coming from the radio and split it nicely into individual .MP3 files. This app was very controversial at the time because it allowed people to effortlessly build up massive .MP3 collections at virtually no cost. The author of TimeTrax sold out to a company which was called TimeTrax Technologies. TimeTrax soon produced a similar receiver package for Sirius. Also included in the bundle was a Windows software package called Recast. Perhaps the most interesting feature of Recast was its authorization mechanism: every time you started it up, it would "phone home" to the TimeTrax servers and verify that you were licensed to run the software.  Somewhere along the line a software engineer named Jeremy Profitt, who reportedly helped TimeTrax Technologies to reverse-engineer the SiriusConnect protocol, offered a similar product called "Give Me Satellite Radio!" TimeTrax quickly put the kibosh on it, claiming ownership of all of Jeremy's satellite radio work; Jeremy subsequently disappeared from the satellite radio scene. Then TimeTrax itself disappeared about a year after that, for reasons that were never publicly disclosed. For a time the timetraxtech.com domain pointed to the XM web site, leading to speculation that XM and/or the RIAA had forced TimeTrax Technologies to shut down. Oh the irony.

When TimeTrax Technologies disappeared in 2006, their authorization servers disappeared with them and left their customers high and dry. The TimeTrax hardware was still working fine; it would have been a shame to throw it away. Clearly a new software package was needed, one that didn't depend on Draconian licensing in order to function. Enter sircond.

The idea behind sircond was to allow a single Sirius satellite radio receiver to stream audio throughout the house using standard streaming audio clients such as Winamp.While most of the software needed to do this already existed (e.g. Icecast, Darkice) a component that would allow the user to control the radio (turn power on/off, change channels, adjust the volume) as well as retrieve metadata updates (current channel name, current song title, the name of the artist) was missing. Sircond was created to fill this gap.

Step one was to figure out how to communicate with the radio. Since the basic Sirius tuner module is integrated by multiple manufacturers into their products I knew a protocol spec must exist, but my search was in vain. No doubt the spec was a closely-guarded corporate secret, only released to partner companies under an iron-clad NDA. Fortunately there were other pioneers in this area, some of whom had posted what they had been able to learn about the protocol. That was enough to permit basic functionality under Linux.

Beyond that, sircond is a pretty standard network server, accepting TCP connections from clients and processing commands presented in plain ASCII. The sircond protocol is intended to be human- and script-friendly. There are only four basic commands:

Commands

The SirCon Daemon's network protocol is line-oriented ASCII and is intended to be easy to use in scripts as well as directly by a human operator. 
There are 4 main commands:

The first 3 each have sub-commands; all commands and sub-commands are case-sensitive (uppercase only). Command lines are terminated by ASCII newline characters. Individual fields in a command line are delimited by ASCII space characters, whereas fields in responses are delimited by ASCII comma characters. Response fields which may potentially contain embedded delimiters are enclosed in ASCII double-quote characters.


CONTROL 

The CONTROL command is used to acquire read/write control of the radio. Upon initial connection, the network client has read-only access to the radio status. In order to change settings (e.g. tune to a new channel, or change the gain), the client must request read/write control by issuing the CONTROL REQUEST command. Only one client can have read/write control of the radio at any one time; if no other client currently has read/write control the control request is granted immediately and the daemon sends the response CONTROL,ACQUIRED. OTOH, if another client currently has read/write control, then the client making the request is placed into a wait queue and the daemon responds with CONTROL,PENDING. Later on, when the controlling client releases control, read/write control is automatically transferred to the next client in the wait queue and that client is notified via a CONTROL,ACQUIRED message. The controlling client keeps control until it either disconnects from the daemon or explicitly releases control byissuing a CONTROL RELEASE command.

GET

A client issues a GET command to retrieve the current setting of a radio parameter.
The general form of the GET command is GET <parameter-name>.

The following parameters are supported for the GET command:

SET

A client with read/write control issues a SET command in order to change a radio setting. The general form of the SET command is SET <parameter-name> <value-list>. <value-list> varies based on the parameter, with some parameters having multiple values and others having no values at all. Numeric parameters must be provided in decimal representation.

The following parameters are supported for the SET command:

For example, SET ASYNC 7 enables the time, signal quality, and SONGINFO event types, whereas SET ASYNC 0 disables all async events.

QUIT

A client issues a QUIT command in order to terminate the session and disconnect from the server. Upon receipt of this command the daemon will release read/write control (if the client has it) and close the client's TCP connection.