DCC Command stations come in a broad range of brands, prices, and options, from basic units that control only DCC track, through to systems offering multiple interfaces to control not only DCC, but also items on other standardised bus systems like Loconet, X-Bus, R-Bus etc. There is also an open source DCC system called DCC++ that is based on the Arduino platform, allowing people to make their own DCC command station.
I have personally used 2 commercial command stations, and our N Scale club uses another one, so I’ll offer my own personal thoughts on these here. I am also trying out a DIY DCC Command Station and I’ll give my thoughts about that as well.
Note also that I use JMRI on my PC for controlling the layout, and my comments therefore relate to my experience using the DCC controllers with this software.
Roco Z21, z21 and z21 Starter
Roco have 3 different models of their system. The most basic model is the z21 Starter, followed by the white z21. Note that both these have a lower case z. Their top of the line system is the black Z21 (Capital Z). The difference between the models is the number and type of interfaces available.
My first DCC system was a Roco z21. This was the white model, but not the z21 Starter. The rest of this section discusses this model, as I don’t have any experience with the z21 Starter or the black Z21.
The z21 comes with a single DCC track output, capable of supplying up to 3.1 A to the tracks (depending on the connected power supply). It also has connections for connecting to DCC power boosters (B-Bus), feedback modules (R-Bus), hand-held throttles (X-Bus), and a wired network connection.
My system also included a WiFi modem / router in the box, which allowed the use of the Roco Z21 app to control trains. This is a well laid out app, although it only shows a single locomotive on the screen at any time, which can be a limiting factor if you are trying to run more than 1 locomotive simultaneously.
I found the z21 to be a capable DCC command station for my small layout, and overall I was reasonably happy with it. However, it does not have a connection for a separate Programming Track (where DCC decoders can have their settings changed by the user), and I found this to the the biggest limiting factor for me personally. This means that in order to perform any programming of the decoders, you have to either:
- Remove every locomotive from the tracks, apart from the one you are programming. This can get tedious if lots of programming is required. Or
- Have a toggle switch installed on the layout that in one position feeds the DCC to the main tracks, and in the other position feeds the DCC to a short section of track used for programming
The z21 also doesn’t allow many of its operating parameters to be adjusted. For example, DCC voltage on the tracks is determined by the DC power supply used to power up the z21, so if you need to raise or lower the track voltage, a different DC supply is required.
After using the z21 for a while I began to look around for a DCC Controller with more features. Naturally I looked at the Z21, but found the price was more than I wanted to spend.
The DR-5000 has a multitude of connection options available (including a built-in WiFi access point), as well as built-in support for a wide range of DCC standards, so it seems to me to be a very versatile system. I also found the price to be reasonable given the versatility of the unit. It can even emulate the Roco Z21 system, and as a result can be operated from the Roco Z21 app on a mobile phone if the system is set to operate in this mode.
Since I purchased this unit, I have added 24 channels of servo controlled points, 32 channels of DCC current sensing feedback, 32 channels of switch type feedback inputs, and 24 On / Off type outputs (for lighting control) to my DCC system. I also plan to add a few more feedback modules for ease of use. The system is able to handle all these easily, and I suspect it could handle many more in practice.
The model railway club I am a member of uses JMRI running on a Raspberry Pi, and connected to a Sprog DCC controller via USB cable, to control our main demonstration layout “Portland” (or “Greater Portland” where space permits). The DCC from the Sprog is fed through boosters, and some DCC Specialties PSX circuit breakers on this layout to allow for automatic resetting of the DCC if a short occurs on the tracks.
Although I have not been involved in the setup or maintenance of this system, from a user’s perspective it has not given any major problems during our exhibitions, usually this is being used to operate 4 locomotives running on the main lines, and a few others in the yards.
If I was looking for a simple inexpensive commercial DCC controller I would certainly investigate the Sprog system.
UPDATE: Our club was starting to see a number of odd problems intermittently, that often required the DCC to be shut down and restarted. On occasions, an error message was shown in JMRI that it was unable to communicate with a specific hardware port, but this was rare.
Eventually I built a DCC++ EX system for the club, and those problems have disappeared. I have since seen information on the internet that suggests the Sprog system might only have 12 ‘slots’ for DCC locos. At times our club would have more than this on the layout, and we speculate that this might have been an issue (absolutely unproven by us at this time). The DCC++ EX system, on an Arduino Mega, allows for 50 slots so this shouldn’t be an issue for us.
Although this unit is not intended as a full DCC Contoller, I have also used the Zimo MXULFA Decoder Update Device as a DCC controller.
The MXULFA is primarily designed to update Zimo decoders with new firmware and / or sound files for sound enabled decoders. Zimo also incorporated a few buttons and a thumbwheel on the MXULFA to enable the user to operate a connected decoder for testing purposes. Later updates to the firmware then added the ability to use the device as a simple DCC controller via a USB connection.
While I would not use this device as a permanent DCC controller, having the ability to use this device connected to a PC to run a small layout is a bonus. I plan to use it in this way as either a spare DCC controller for my portable layout, or possibly as the primary DCC controller for this layout due to its small size and hence portability.
However, please note that while JMRI is able to operate the MXULFA via USB connection, at the time of writing this article, JMRI has a bug whereby any locomotive driving command send from JMRI to the MXULFA has the direction information set incorrectly, so if JMRI is set to drive the locomotive Forward, it actually travels in Reverse, and vice-versa. I have been testing and discussing this issue with the JMRI developers, and it appears that a single line of code might be wrong. As I understand it, the developers are looking at implementing a change to fix this, but they naturally want to ensure they don’t cause any problems for any other Zimo control systems, so a fix might be a while off yet.
I am in the process of giving the DIY project DCC++ EX a go.
To quote from the DCC++ EX site itself:
DCC++ EX is an easy to use, do-it yourself and affordable, open source DCC CommandStation and suite of supporting products for running your complete model railroad layout. Based on Arduino technology, DCC++ EX is supported by many controllers and applications like JMRI, Engine Driver, WiThrottle, Rocrial and more.DCC++ EX Model Railroading — DCC++ EX documentation (dcc-ex.com)
So far I have put together the Arduino Mega with an Arduino Motor Shield Rev 3, and connected it to a Raspberry Pi 3b+ running Steve Todd’s Pi / JMRI image via USB. I then tested it using a DCC Sniffer and it seemed to be working successfully.
The setup of this system was very easy:
- Obtain the required boards (Arduino Mega, Arduino Motor Shield and Raspberry Pi)
- Download the files required for the Pi from Steve Todd’s page
- Flash the SD card for the Pi (I used Etcher to do this)
- Connect the motor shield to the Arduino Mega
- Download the automated installer for the Arduino from the DCC++ EX site, and run it
- Connect the Pi to the Arduino with a USB cable
- Power on the system and test
I’m using a 12 Vdc, 2.5A plug pack power supply for this system. The 12V is used to feed the Arduino motor shield, it also connects to a 5V step-down regulator, which then feeds the Raspberry Pi. The Arduino itself obtains its power from the USB cable connected to the Pi.
The Pi provides a WiFi Access Point to allow a mobile phone to connect to JMRI and run the Engine Driver app to act as a throttle, and it works well.
I’m also building this system into a small case to protect the modules, and I created my own simple decals for the front and rear panels to label the connections, as well as some indicator LEDs I decided to add (really just to jazz up the unit a bit, they aren’t required).
So far, using this system on a test track, I have found no problems with it at all, and it seems just as responsive as any of the other systems I have mentioned above.
24 May 2021
I’ve been testing the DCC++ EX system on and off for a while now. My first real test “in the heat of the battle” was when I tried to use it to read values from a decoder on a club member’s loco one day. Although the loco pulsed on the short test track as expected, JMRI (which was operating the DCC++ EX system) reported no response from the decoder.
Once I had some time back home, I repeated the test with one of my own locos. It worked perfectly first time. Thinking that the results were a bit odd, I tried a different loco that had a different brand of decoder – and it failed with the same error message as we had seen at the club.
More investigation followed, and I came across other people referring to this same problem. It appears that the problem lies in how closely to the NMRA standards the decoder manufacturers create their decoders.
The creators of the DCC++ EX system have followed the standards for how to interpret the pulses created by DCC decoders when the CV values are being read, but not all decoders respond in the time frames expected.
Changing some parameters in the code for the DCC++ EX software, and uploading the updates to the Arduino, greatly improve the issue.
While the full discussion isn’t relevant to my page, anyone that is interested can have a look here:
UPDATE September 2022: The DCC++ EX system I built for the club (see the section on Sprog Systems) has been working very well, except for 1 occasion. At a major model railway show one weekend, where there were so many WiFi systems in operation that the 2.4 GHz band became very crowded, club members were having problems connecting to the Raspberry Pi’s WiFi.
Replacing the WiFi system generated by the Raspberry Pi with a proper WiFi router resolved the issue, and no further issues have been observed.
All the above systems work satisfactorily as DCC Command Stations, what you choose would be dictated by your own needs. Here is my brief summary:
Roco z21: A simple DCC command station that provides the basic functions, as well as a very usable mobile phone app. Not the cheapest system available.
Digikeijs DR-5000: Plenty of industry standard connections available out of the box, as well as a built-in WiFi Access Point that can be used to connect mobile phones and other WiFi enabled devices. Reasonable price too, given the multitude of connection standards it supports.
Sprog: Very simple basic unit. It doesn’t include any additional interfaces for connection of feedback modules etc. though, so if you need these connections it won’t suit you. The cheapest of the 3 commercial DCC command stations mentioned here. Might not be the best system for clubs with large numbers of users / locos.
Zimo MXULFA: Not intended as a DCC Command Station, it’s primary role is updating Zimo decoders, however it can be used as a basic command station if the need arises.
DCC++ EX: If you like the idea of putting together a DIY open source based DCC Command Station, then this may be the project for you. The system doesn’t include any extra connections like Loconet etc., so it is similar to the Sprog in this respect. Cost of the system (Arduino + Motor Shield) is lower than a Sprog 3.
These are just my thoughts, you may have different findings and or needs.