Page 5 of 8

PostPosted: 09.04.2013, 21:39
by rjversluis
Hi Manolo,

I also thought about the RasPi as CS:

Rocrail <-> DigInt <-> Socket <-> CS-Deamon <-> GPIO

A local TCP/IP or UDP connection will not desire much RasPi resources and as far as the CS-Deamon concerns will be platform independent.
And it is not really needed to run the Rocrail server on the RasPi directly; Many possibilities. ;-)

For the DigInt you can chose the best fitting protocol. (Loconet, Xpressnet...)

Rocrail should remain HW independent.

PostPosted: 10.04.2013, 08:41
by mserrano
Hi Rob,
Nice! I like your approach.

What I can do is:
-At the DigInt (rocpi): replace the code to send serial commands for a TCP connection to the CS daemon. The serial commands are HW independent, but moving to a socket connection it will be also possible to run rocrail out of the RasPi. Obviously I will remove the code to interface the GPIO (buttons and leds so far) which is completely HW dependent
-At the CSdaemon(rpic): move here the code to send serial commands and interface the GPIO here.
I will make a first proposal during the weekend, it should not be difficult to get something isolated following your schema,

PostPosted: 11.04.2013, 21:11
by mserrano
Ok, It has been faster than expected.

It is a preliminary version, but I have now a daemon making indepenent rocrail from the rpi.

As a first approach I have evolved the rocpi DigInt to a pretty simple library sending commands though a TCP connection. If I am understanding it right, in the long term the best option would be to avoid this rocpi library and make use of loconet or xpresessnet libraries already existing... Main problem: I have never worked with those protocols, so it can take me a while to make the daemon translate their commands. Of course I am assuming these protocols can send any kind of commands to the daemon (and the ucontroller behind): MM, NMRA, MFX, programming, selecting a PT,... retrieve information from consumption... etc. I have to study it... any reference is welcome.

In the meantime, and in order to have a full proof of concept, the daemon is understanding the simple commands sent from rocpi and forwarding them to the GIPO and the serial port (for the uc). There is no communication from the daemon to rocrail at this stage.

I leave the files for your evaluation. As I said, any feedback is welcome. My purpose is to focus next on completing the HW part, at least:
- uc code for programming and reading cv
- management of the PT
For family reasons :D I am going to be a little more busy the next months...but I promise to come back to the problem of getting a standard protocol between rocrail and the daemon.

Compiled version of rocrail with rocpi
Source code
RPIC Daemon
Last version of instructions

PostPosted: 12.04.2013, 06:23
by rjversluis

if you are not familiar with Loconet or Xpressnet you could use RocNet: ... et-prot-en

PostPosted: 12.04.2013, 12:14
by mserrano
Thanks Rob,

I will look into it. It seems a pretty nice described protocol!
Actually it is quite similar to the "protocol" I am using between the daemon and the ucontroller – and therefore between rocpi and the damon (attached). Thus, it should not be so hard to make a translation in the daemon and dismiss the rocpi library I am using.
For most of the commands I can see the equivalent in rocnet. However, is it possible to extend/modify rocnet? I am missing the capability to access 28 functions in NMRA… and also the mechanism to signal long address NMRA protocol /short address…
Well, and If I could ask, it would be also nice to have the fgroup as part of the function message. Currently neither the ucontroller nor the daemon are storing f28 function status – this is something available in rocrail – and , even if I can think a way around - make the daemon store the status of all locos and then compare to get the fgroup – it would be nice to get the fgroup when making the translation in the digint.
As I said, this last point can be overcome somehow, but I do not see the way to get the 28 functions and L/S NMRA.
For the next version of the firmware (with full support for all programming modes), it seems rocnet also needs further descriptors – I can only see the programming of stationary decoders.
Please let me know if I can help somehow. With the info I have from the wiki it seems perfectly feasible to use rocnet as supporting protocol.
Best regards,
PS: don't get confused with the simple "ptrocol" i used... only green commands are implemented so far... i could explain the other colours... but moving to rocnet.. there is no need for some of them (orange).

PostPosted: 12.04.2013, 13:06
by rjversluis
Hi Manolo,

extending RocNet is no problem, but modifying is tricky because its already used in other applications.
But all depends on the modification.

PostPosted: 12.04.2013, 13:29
by mserrano
Hi Rob,

I understand the issue of modification.

For the long and short NMRA addresses, the extension could be as simple as replicating the NMRA protocol types and use descriptors that are free:

Protocol types(table)

0 256 256 step interpreted (8 bit only)
1 DCC 28 NMRA DCC with 28 speed steps
2 DCC 128 NMRA DCC with 128 speed steps
3 DCC 14 NMRA DCC with 14 speed steps
3 MM 1 Märklin/Motorola
4 MM 2 Märklin/Motorola
5 MM 3 Märklin/Motorola
6 MM 4 Märklin/Motorola
7 MM 5 Märklin/Motorola

11 DCCL 28 (10+old code)
12 DDCL128
12 DCCL14
or whaterver feels OK. This way there is no impact in current implementations. BTW... the MM1 and DCC14 share the same code?
For the 28 functions extending the current mobile action command maybe tricky:
3 function F1-F6 + lights F7-F12 protocol

One option would be to add bytes after the protocol byte.... but does not seem ok... and could be misleading for some existing implementations.. if they receive a longer message than expected.
The other option would be to create a new mobile action command for function:
10 functionx f0-f7 f8-f15 f16-f23 f24-f28 p rotocol
or even best
10 functionx functionbyte fgroup
If for the fx issue we talk about extending instead of modifying, the digint should send both messages.
I am just thinking out loud.
For the programming, I have’t gone so far.

PostPosted: 14.04.2013, 20:15
by skippa
Hi Manolo,

I am also looking for a solution to ddx my layout with the raspi (without using the usb). Unfortunately, I can neither program nor invent electronic circuits. I am able to solder them together though :-)

So I can not offer any more help than to betatest your circuit. This I would love to.


PostPosted: 14.04.2013, 22:10
by mserrano
Thanks Jens,

I will let you know when a stable version of the circuit is ready. I am only missing the part of the circuit to read decoders when programming.

Best regards,


Future use of RaspBerry PI

PostPosted: 19.04.2013, 21:33
by treinbert
Hi Manola,

I am also very anxious to start using a simular product. I have difficulty in producing a PC-board, but I can solder small boards. I am using three kinds of systems on my layout. It starts of course with RocRail, but also iTrain and for some people I use KopLoper (unfortunaly only on Windows).

The use of the PI as DDX is very interesting for all systems. My PI has been running RocRail for the last year already, but I have not yet tried it on a larger scale, but only on my demo-layout. The full layout will use over 256 feedbacks, 60 points and 48 signals.

I am thinking of using LocoNet for the full layout, but on the other hand I think about Dinamo, to be 2-rail, 3-rail, analog and digital independant.


PostPosted: 20.04.2013, 15:33
by Richard-TX
I am not sure if it would help anyone, but I came up with a modification to srcpd. What it does is respond to accessory requests and executes a program or script on the Rpi.

For example:

throwing a switch would cause the program /usr/local/bin/rpi-b3-a7-p1 to be executed.

In addition the program "/usr/local/bin/rpi-script -b3 -a7 -p1" would also be executed.

There is no impact if the scripts do not exist. By using python scripts one can address/control the GPIO bus on the Rpi.

My latest version of srcpd-rpi is at

To build on a Rpi, simply run configure, make, make install.

An example srcpd.conf is included in the README.rpi

PostPosted: 21.04.2013, 09:26
by Richard-TX
Has anyone tried using a USB->RS232 converter to generate DDX DCC signals?

Personally I feel that the proper way to deal with a RPI is to use a USB hub. Plug the keyboard, mouse, wifi, etc. into the hub. I also use a spare USB port to power the Rpi.

PostPosted: 21.04.2013, 12:18
by mserrano
Yes Richard,

One of the first things I did was trying with an USB-converter. As Peter Giling was anticipating the signal is cut every now an then. I checked with him the modifications on the ORD-3 both for the ttyAMA0 and the ttyUSB0 options.

In summary, it works, but the quality of the signal is not great.

Bes regards,


PostPosted: 21.04.2013, 12:21
by mserrano
Hi Bert (and all),

I hope to conclude this week the part of programming on the main.. and then next weak the reading of CV.

With that, I will close for now the developements in SW, and will try to come with a PC-board easy to build for everyone.

I will keep you infomed... this week little progress due to excess of work at the office.

Best regards,


PostPosted: 23.04.2013, 14:33
by Richard-TX
mserrano wrote:Yes Richard,

One of the first things I did was trying with an USB-converter.
In summary, it works, but the quality of the signal is not great.


I would have thought that the FIFO in the RS-232 chip would have prevented any choppy communications. Thanks for checking that.