Closed - SRCP deficiency and Rocrail

Post Reply
Posts: 1320
Joined: 10.07.2012, 04:00
Location: Texas, USA

Closed - SRCP deficiency and Rocrail

Post by Richard-TX » 14.06.2013, 16:58

I know that there is a deficiency in the SRCP protocol and I have been thinking about it and there is absolutely no reason why we have to live with it.

As I recall the issue stems from the inability to get a full status from srcpd.

Why not create a special device for srcpd that responds in the fashion that is needed?

One solution is as follows:

To get a full status, simply doing a GET <bus_num> <address_num> <port_num> on the particular bus and address will result in the full status being dumped to the info channel.

This would not be hard to do. I could incorporate this feature into my Rpi device that I have already written for srcpd.

I am willing to write the device. All that is needed is the parameters of the devices extension.

Tell me precisely what is needed, and I will do it.

Doing something like this is perfectly legal within the terms of the srcpd documentation.

Last edited by Richard-TX on 07.08.2013, 10:52, edited 1 time in total.

Site Admin
Posts: 40997
Joined: 10.04.2006, 08:48
Location: Speyer, Germany

Re: SRCP deficiency and Rocrail

Post by rjversluis » 14.06.2013, 17:23

Richard-TX wrote:As I recall the issue stems from the inability to get a full status from srcpd.
Can you specify what you mean by "full status"?

Site Admin
Posts: 2668
Joined: 18.10.2010, 00:03
Location: near Karlsruhe/Germany

Post by LDG » 14.06.2013, 17:32

Hi Richard,

when you open an info channel to a srcp server you get (almost) all info that about the devices on the srcp server.

In addition to that I implemented in the srcp service in Rocrail some small extensions that send the missing data but are (almost :oops: ) compliant to the protocol:
- the status of all feedbacks (FB) is sent (also when status is 0)
- switch/signal (GA) status : we first send the "last active" decoder port for each switch/signal as port state "1" (according to current state in Rocrail) and then all port states as "0" (as the spec demands)
-> the client has all information and all further changes are distributed through the info channel so the client is up to date if it is using those messages.

Why do you want to introduce another command ?
If you want to "reinit" the status data of a srcp server (or just a bus) you may close and (re-)open the info channel (hard method) or use "GET <bus> DESCRIPTION" on the command channel with the compliant answer on that channel, but in background you are free implement (in your server) a trigger that starts resending of (only) the status messages for that <bus> on the info channel that are also sent when opening an info channel. <bus> == 0 may send all :)
A client with an info channel has to accept all spec compliant status messages sent there and is free to use or discard them :wink:


Posts: 1320
Joined: 10.07.2012, 04:00
Location: Texas, USA

Post by Richard-TX » 15.06.2013, 06:41

I am referring to the topic at

In that thread Lothar said.

"Because the srcp specification has no command to get the current state of a switch/signal/output there is a Rocrail extension during/before sending the port states after initialization of a session in info mode"

I was trying to come up with a way to resolve that deficiency or incorporate the feature that you added to Rocrail's srcp server into srcpd.

Post Reply

Return to “srcp”