Cmd Line
Common
The object server (rtbserver.exe) is the central element of the architecture.
Each managed object in the layout finds its counterpart in the object repository. These objects can be viewed and/or modified via the CLI. Any change in state of an object is immediately reflected on its counterpart. The system-wide publish/subscriber infrastructure ensures real-time distribution of changes, in both directions – to and from the layout. The IP network functions as a message bus.
This message bus architecture allows the distribution of system wide services across the network. The CLI for example, is a tool that connects/queries/subscribes to the message bus and can be started anywhere in the network.
Bus CLI
All stationary managed objects are connected to the bus. Of course, the bus can be a good starting point for gathering information about the layout. Below is the output of my test infrastructure with more than 31 objects connected to the bus. This quickly gives me general overview of what is out there and what the UIDs of the modules are.
FDX bus modules
The FDX bus connects the power boards and boosters. Here we see three power boards and three boosters connected to the bus.
HDX bus modules
The HDX bus distributes the DCC signal across the system. For this reason, the track interfaces are seen here, including the optional bus termination modules.
EDG bus modules
Finally, the accessory modules are connected to the EDG bus. We should expect to see many items listed here as there may be many accessories. In my test I connected 24 accessory modules. But in larger environments there can be hundreds of accessories. According to RTB philosophy, each object in the layout should have a unique instance in the repository.
Booster CLI
The booster also generate the DCC signal, which makes them very important and also interesting objects. Boosters have many interesting metrics to watch, such as voltages, currents, timings, DCC utilization and more.
For example, the boosters capture two current samples per DCC frame,
- max is the current on the first bit after the cutout (=inrush current)
- avg is the current on the start bit after the preamble (=steady current).
In the example below, we see booster #3 has a steady (average) current of just 88mA but the inrush after the cutout is 656mA. This happens, if decoders do not have sufficient blocking capacitance. Many commercial decoder have this problem. My homebrew decoder have an inrush limiter integrated. On booster #2 we see both avg and max being 80mA, which is a much better situation.
Booster real-time trace
This feature is big point! Any Booster can be traced real-time. All critical DCC metrics (e.g. voltage, currents, payloads including timing is printed real-time on the command line. It’s a complete coverage of the DCC/Railcom signal going in and out of a booster and seen on the tracks.
This powerful DCC/Railcom tracing capability is unique on the market and I am very proud of it!
Decoder CLI
How about mobile decoders? Not a problem!
Below we see all the mobile decoders on my system. Information such as decoder ID, manufacturer, model, firmware (if supported by the decoder) and the assigned DCC address are displayed. All information is dynamic and updated in real time.
The heartbeat column shows the time of the last valid Railcom response. If a decoder does not respond within 5 seconds, it assumes that it is offline (e.g. removed from the system) and the * disappears. The DCC generator begins to downgrade the address update to free up DCC bandwidth.
Decoder Railcom metrics
The RCN-217 standard defines a series of Railcom metrics such as speed, QoS, temperature, track voltage or distance traveled. My mobile decoders also report additional metrics such as motor current, CPU usage, context switching, brown-out counters and more because I like collecting metrics! I use the dbg1/dbg2 columns for development tasks. My decoders also report pitch and roll angles from the 9-axis motion sensor, if installed.
Decoder real-time trace
Here is another strong point!
Similar to boosters, decoders can also be tracked in real time. This means that all DCC frames sent to a decoder and the corresponding Railcom responses are printed on the command line in real time. The Railcom TTS1 and TTS2 timing information is particularly interesting as some decoders do not adhere to the Railcom timing specifications and cause problems on the tracks. All of this enables very sophisticated decoder analysis.
Decoder testing has never been easier!
Decoder POM and xPOM
Reading and writing CVs via the command line interface is very convenient as the output can be archived or further processed with other tools. First I am reading twelve CVs using POM which takes approx. 900ms. Afterwards, I am reading the same CVs using xPOM which only requires 240ms.
Decoder Service Mode
For backwards compatibility, service mode programming (also called “programming track”) is also supported. This mode is advantageous if the decoder’s DCC address is unknown or the decoder does not support Railcom POM/xPOM programming.
Decoder memory interface
My mobile decoders provide a low-level memory interface via the DCC-R protocol. This allows me to read all of the physical decoder memory (Flash, EEPROM, RAM, user space, backups, etc.). Of course, the microcontroller’s I/O space is protected to prevent the CPU from malfunction.
Decoder firmware update
How about this?
All my mobile decoders feature firmware update on the main tracks which is defined in my DCC-R protocol extension. The update protocol co-exists with the standard DCC protocol side-by-side allowing decoder updating while other operation continuous. Because the update protocol uses high frequency signaling outside the DCC framing, the update time remains very short. In the below example the firmware update of an D16 (NEM651) decoder took 8.3 seconds. Of course, there may be several decoder updates running in parallel over the same tracks.
