Some time ago I took delivery of my first batch of signals. These are generic 3-light signals made in China. They aren’t particularly prototypical – the aspects resemble a type of signal used here in Queensland, as well as some European signals. But the looks are very basic. However, for first experiments and wrapping my head around the subject matter, they are more than sufficient.
Of course I wanted to control them digitally, like everything else on my layout. As detailed in my post about servos for point control, I am using Arduino-based hardware and software provided by Dutch railway modeller Nico Teering under the name ArCoMoRa. Nico provides the DCCNext, basically a custom Arduino made for controlling model railway accessories. It can be set up with two different software options: MarDec for controlling standard accessories such as lights, point motors and similar; and ArSigDec, which is made specifically for controlling light signals with more complex aspects. Since I was already using MarDec, it made sense to give ArSigDec a whirl.
LED-based signals are usually equipped with a resistor allowing for them to be used with a specific voltage range. The signals I acquired are meant to be used with 9-12V. Since I was intending to use 5V provided by the DCCNext for the use of LEDs, I was prepared to change the resistor as recommended by the vendor, but a quick test with the signal on 5V showed that that wasn’t necessary – the LEDs were bright enough with that voltage.
Setting up the signals on ArSigDec was quite easy. The text-based interface is easy to use and an explanation for all options is always at hand. The software offers a number of standard signals, mainly European ones, which can simply be selected from a database. If that’s not sufficient, custom signals with up to 8 LEDs can be defined. Unlike MarDec, you can’t set up the decoder ports used by a signal – the first defined signal will use the first available ports starting from port 1, the second signal will use the next available ports, and so on.
I initially used the built-in UK standard signal with 3 lights and 3 aspects – the closest equivalent to these signals. That all worked fine when only testing with the DCCNext. However, the confusion started when I wanted to use my DCC central to configure and control the signal.
My new central, the ESU ECoS with built-in touchscreen, allows for the creation of a full track plan. Signals and other objects can be linked in the track plan and fully controlled from there. The ECoS has a limited number of predefined light signal types, as well as a generic light signal with up to 4 aspects. I picked one that was closest to the ones I am using – but the aspects were all wrong. While green was showing on my track plan, the signal actually showed red – and the yellow aspect didn’t work at all.
It took me a minute to wrap my head around this – well, actually I had to sleep over it. The following part of this post dives a bit deeper into the setting up of signal aspects on DCC.
Every DCC accessory gets its own address. Possible addresses are between 1 and 2044. Each accessory address can have two states, often referred to as red and green. This is most understandable when looking at a point, which can be either straight (red) or thrown (green).
When setting up a light signal on DCC, each accessory address can handle two aspects – one on red, one on green. A signal is commonly set up with a base address – this address handles the first two configured signal aspects. If a signal has more than two aspects configured, the accessory decoder automatically assigns the next address from the chosen base address. So if the base address is 1, then the first two aspects are handled by that address, the next two are configured under address 2, and so on.
ArSigDec assigns the aspects as follows:
Aspect 1 = Base address Green
Aspect 2 = Base address Red
Aspect 3 = Base address + 1 Green
Aspect 4 = Base address + 1 Red
And so on.
What I eventually figured out is that the ECoS flips the aspect assignment. For aspect 1, it sends the red command, for aspect 2 the green command, and so on. Unfortunately the aspects themselves and their switching order are fixed in the ECoS and can’t be freely configured. For the chosen 3-aspect signal, aspect 1 is the green light, aspect 2 is the red light, aspect 3 is yellow.
This means the configuration has to be done properly in the signal decoder – which may render some of the available standard signal configurations useless when using the ECoS. Ultimately, the aspects have to be matched like this:
ECoS aspect 1 –> ArSigDec aspect 2
ECoS aspect 2 –> ArSigDec aspect 1
ECoS aspect 3 –> ArSigDec aspect 4
ECoS aspect 4 –> ArSigDec aspect 3
This posed little difficulty once I had figured out this mapping. However, since I am using a signal with three aspects, I had to tinker a bit more, since an ECoS 3-aspect signal and an ArSigDec 3-aspect signal would never match up.
The solution was to create a 3-aspect signal in the ECoS, but a 4-aspect signal in ArSigDec. For the latter, the third aspect becomes a phantom aspect – it will never be active, so I configure it to turn off all LEDs. Aspect 4 is then the actual aspect 3 as shown in the ECoS.
The fun bit came in when I wanted to use the track route functionality of the ECoS to set the signals based on the state of the route. I installed two of these signals on a mainline and siding. There already are two track routes set up in my ECoS track plan, which set both the entry and exit point of the siding to match, so that a train can pass through either the mainline or the siding. All I had to do was to add the desired state of each signal to the track routes – it couldn’t be easier.
In the meantime, I have received my first two signals based on German prototypes. I was able to apply the learnings from the generic signals to these, and it took me considerably little time to set them up and make them operational. They are specced for operation with 10-16V AC or 14-24V DC, but again, 5V make them light up enough for my purposes. The below clip shows the signals in action.