Introduction
Running a model railway these days isn't as easy as you would imagine (unless you have a large budget). The basic idea is simple: instead of feeding more or less current to the locomotive, you provide it with a constant AC voltage and modulate a control signal on it. The signal is decoded in the locomotive and controls speed, light etc.
You can also use the signal to control turnouts and other devices in your layout. Ideally you'd build a decoder in every turnout and save a lot of cabling. But for economical reasons, you usually have one decoder for a set of turnouts. Still this adds up to a significant investment. Digitalization of a model railway makes you realize how mass production reduces prices, because you suddenly find yourself in a niche market where you cannot profit from this effect.
When I started the digitalization of my model railway a few years ago, the single most expensive part was the central unit that generates the modulation on the AC voltage and allows you to control your equipment. You'd think that this could somehow easily be done with a PC and indeed I found such a project. But for some reason or other, I never succeeded in running this software reliably.
The cheapest hardware I could get then that fitted all my needs was the Tams Easy Control. (Just recently, Märklin has introduced a cheaper hardware.)
But what I learned from my experiments with the PC based solution was that there exists a protocol called "Simple Railway Command Protocol". This can be used to connect a central unit that supports this protocol with GUIs running on a PC. There are several interesting client applications available.
Regrettably, the Easy Control does not support SRCP. It has a serial and an USB interface that support a protocol called "P50X" and originates from a central unit called "Intellibox". When I searched through the web, I found several free implementations of SRCP servers that should be able to interface between SRCP and a P50X talking unit. But again, I failed to get any of those working.
So I implemented my own. Was this really necessary? Well, I didn't want to fight with any C/C++ implementation. And all the Java implementations I found more or less claimed not to be for "productive" use, seemed abandoned or poorly designed.
The application
The application "SRCP for Central Units" (sorry, but simple names like "jsrcpd" were already taken) provides an adapter between SRCP and an existing central unit. Although designed to support different types of central units, the implementation currently only supports the Tams Easy Control (and as I only have this hardware, it won't support others unless some contributor turns up).
Srcpd4Cu is provided as an executable jar file and can therefore
simply be started as "java -jar srcpd4cu.jar".
It accepts a small set of command line options:
-c configuration_file- Specifies a configuration file to use instead of the built-in file (see below).
-d- Increase the debug level. This option can be specified up to three times.
-j- Normally the standard Java log configuration
is overridden to give the log messages and the log behavior
an appearance as known from commonly used applications.
However, Java logging is a powerful mechanism for
those who know how to use it. This option suppresses
any change of the logging configuration by the program
(and therefore the effect of options
-dand-s). Logging must be configured using the well known Java logging API mechanisms instead. -s- Use syslog to output the log messages instead of the console. Note that syslog must be running on your system and listen on port 514.
The behavior can be further influenced by a configuration file such as the following.
<?xml version="1.0" encoding="UTF-8"?>
<Srcpd4cu xmlns="http://www.example.org/srcpd4cu"
version="1.0" enforceReadAfterInit="false">
<!-- Configure an "Easy Control" central unit as backend -->
<EasyControl>
<!-- Specify the port to use for the connection to the Easy Control -->
<Port>/dev/ttyUSB0</Port>
</EasyControl>
</Srcpd4cu>
See the comments for the meaning of the directives. The
attribute enforceReadAfterInit="false" causes
Srcpd4Cu to accept modifying commands (SET, INIT) after a
device has been initialized. This violates the latest SRCP
specification (version 0.8.4). However few clients comply
to the latest version of SRCP in this respect, but accept
to talk to a 0.8.4 compliant server nevertheless. This
"backward compatibility flag" makes the clients work again.