All posts by Nathan Holmes

High Current DCC Accessory Decoder

One of our customers was trying to build an accessory decoder using our I2C-RELAY16 to drive a bank of relays for high current loads, and they were having a bit of trouble.  So, I thought I’d sit down and work through the issues tonight, as I’ve always thought having an accessory decoder with isolated, high current relay outputs might be nice. 

The Hardware

The basic hardware is really simple – it’s just an ARD-DCCSHIELD and Arduino Uno connected to an I2C-RELAY16 and a cheap Chinese 16-relay module.  I’ve also added a decent (supposedly) UL-listed 2A switching power supply from Amazon, though in reality you likely don’t need 2A.  The relay board should only draw ~500mA@12V, and the Arduino maybe another 100mA – you could definitely use one of our high quality Triad 12V 1A switching power supplies.  in order to  power the whole thing, and a cheap voltmeter module to verify that the supply is on and putting out the right voltage.

The ARD-DCCSHIELD is configured as follows:

  • JP1 – both jumpers on to provide I2C pull-ups
  • JP2 – connect /IORST to VIO
  • JP3 – no jumpers
  • JP4 – DCC on D2
  • JP5 – no jumpers (isolation between DCC power and local power)
  • JP7 – both jumpers on to provide DCC programming ACKs

The I2C-RELAY16 is configured with J5, J6, and J7 all jumpered low.

The Software

Both of these sketches require two libraries:  Alex Shepherd’s fantastic NmraDcc library (available from the Arduino library manager now) and our Relay16 library.  Sorry, ours isn’t available through the Arduino library manager because of some limitations on their part, but the documentation page above describes how to get and install it.

After that, you’ll need the actual application code.  I’m storing it as examples in the ARD-DCCSHIELD’s src/ directory.  Go download the latest zip file of source and design files from Github,  unzip it, and look in the src/ directory.  I actually built two different accessory decoders that serve slightly different purposes:

  • NmraDccAccessoryDecoder_Relay16 – The first version is just sixteen high current outputs that can be switched on and off.  (The relays are rated for 10A at both 125VAC and 30VDC, though those are Chinese amps, so I’d trust it for 3-5A in reality.)  This would be great for turning staging tracks (or roundhouse tracks) on and off, or turning lights inside structures on and off.  Each one is accessed by a single output address (aka turnout) number, starting with the address programmed into the CVs in the Arduino and going for the next 16.  So, for example, if you programmed the decoder to address 32, your outputs would be on accessory addresses 32-47.   Setting the “turnout” to normal will turn the relay on, and setting it to “reverse” will turn it off.
  • NmraDccAccessoryDecoder_Pulsed_Relay16 – The second one is pulsed, for driving up to eight twin coil switch machines a capacitor discharge supply.  Each “turnout” gets two relays, one for normal and one for reverse position.  To throw the switch machine, one of the two relays will turn on briefly and then automatically shuts back off, assuring that the coil won’t burn up.  In this case, the decoder works on the next eight addresses from whatever is programmed in the CVs of the Arduino. 

Just pick the one you want, open up the appropriate sketch in your Arduino environment, and download it into the Arduino.  That should be all there is to it to get started.  Either sketch will default to accessory address #1, so if you want it somewhere else, you’ll need to set the appropriate CVs with your DCC system. 

What CVs are those, you might ask?  CV1 and CV9 deal with the accessory decoder address.  See below – “A Note on Accessory Addressing” – for the brain pretzel the NMRA has left for us there. 

The Relay16 on/off decoder doesn’t have any additional configuration options.  The Pulsed example, however, has two additional CVs of interest that can be configured:

  • CV2 = Coil activation time in 10 millisecond units.  By default, it’s set to 50, which gives you an on time of 500mS or half a second.
  • CV3 = Capacitor discharge unit recharge time.  If you’re using a CDU to drive your turnout coils, this is the amount of time (in 10mS increments) that it takes to recover from driving a coil.  By default, it’s set to 30 (aka 300mS, or roughly a third of a second).

(Alternately, given that you have the source code, you can change the default CVs right in the source and not have to mess with programming them through your DCC system.   You’re looking for CV_ACCESSORY_DECODER_ADDRESS_LSB and CV_ACCESSORY_DECODER_ADDRESS_MSB, right near the top of the Arduino sketch.)

A Note on Accessory Addressing

DCC accessory (turnout) addresses are a bit non-standard.   At its core, the DCC standard allows for 2044 different accessory addresses, where each one can either be set on or off.  (The remaining addresses, 2045-2048, are reserved for broadcasting commands to all accessory decoders.)  The gory details of this come from NMRA standard S-9.2.1, section D, “Basic Accessory Decoder Packet Format”. 

This is where things get a bit weird.   2048 different addresses are  really 11 bits of information (2047 = 0b11111111111).  The upper 9 bits of the address are used as the “decoder address”.  That means that decoders naturally get groups of 4 accessory outputs.  This is sort of wasteful and confusing, but that’s the way it is.

Of that, it even gets weirder.  NMRA standard S-9.2.2 defines the standard “configuration value” (aka CV) numbers.  For accessory decoders (as defined in table 3), the middle six bits of the 11 bit address go in CV1.  The upper 3 bits of the address go in CV9.  The lower two bits are just transmitted as part of the packet, and therefore a single 9-bit “decoder address” must deal with up to four accessory addresses.

Confused yet?  Yeah, so am I, and I read these sorts of specs all day at work.   Here’s the basic address pattern and where the bits go:


0b is just a prefix reminding us that this is a binary number.
UUU is the upper 3 bits.  It goes in CV9.
MMMMMM is the middle 6 bits.  It goes in CV1.
LL is the lower two bits.  It doesn’t go anywhere, as accessory decoders always get 4 accessory addresses.

Let’s work some examples.  That’ll make this hopefully a bit clearer.

Let’s say we’re going to give our 16-channel decoder from above accessory addresses 17-32.  We always use the starting (lowest) address for the calculation.  If we convert 17 to binary (literally type “17 in binary” into Google is probably the easiest way), we get:


Now, make that 11 bits long and line it up with our pattern from above:


That means that for this example, we’d program

CV1 = 0b000100 = 4
CV9 = 0b000 = 0

See, that wasn’t that bad, right? 

Controlling Relays with a Raspberry Pi

Ever wanted to control some real world hardware with your Raspberry Pi?  Every now and then, we get questions about using either our I2C-RELAY16 or I2C-XIO boards from the Pi, and it’s been on my eternal backlog list of “I should do a quick article on that…”   So let’s break this logjam and get down to controlling a cheap Chinese 16 channel relay board with a Pi (available from SainSmart and others).  Because this provides 16 relatively high current, isolated output channels, this seems a great place to start, and it’s an easy hour project.


A Raspberry Pi 3 controlling a 16-channel relay module on my bench

Continue reading

Introducing Modular Signal System Components

You may have heard about the Modular Signal System – it’s been slowly gaining support in the Free-mo modular community for about a decade now.  If you haven’t, read on – it’s an exciting new (well, somewhat new) option to bring ABS signalling and more to your model railroad.

The initial Modular Signal System (MSS for short) proposal was put forth by Gregg Fuhriman in the February 2005 issue of RailModel Journal.  He’d developed the idea along with others to bring simple signalling capabilites to Free-mo modular meets.  Traditional solutions, using pieces such as C/MRI or Loconet-based systems, are impossibly cumbersome to deal with in an infinitely-reconfigurable modular setup with participants coming from all over.  What was needed was an acceptably realistic signalling system that was plug-and-play – no reconfiguration required for the myriad of ways their modules could be put together at each meet.

Continue reading

3D Printed MRServo Brackets

While I’m still a firm supporter of the tried-and-true industrial foam tape method we’ve sold for MRServo servo switch machine mounting since the beginning, there’s always room for improvement.  Several customers have asked about alternate, mechanical mounting methods, and there’s definitely places that would be useful.  I always have a machine or two that keeps getting knocked loose as I accidentally catch the wire with a tool, or sometimes a spot on the plywood that just refuses to adhere well.

The “conventional” solution would be to have injection molds made, and then have a run of several hundred or thousand parts produced.  This is obviously expensive for us, highly speculative that somebody will actually buy them, and beyond what the meager profit margins on servo switch machines justify.  Fortunately, we live in an absolutely amazing time in terms of manufacturing processes, and nothing is more exciting right now for manufacturing complex plastic parts than 3D printing.

The 3D model of the MRServo-2 / MRServo-3 Bracket

The 3D model of the MRServo-2/-3 Bracket

Continue reading

Introducing the CKT-BD1 DCC Block Detector

I’d like to introduce you to ISE’s latest model railroad product – the CKT-BD1 single channel DCC block detector!


The CKT-BD1 – our brand new single channel DCC block detector

This little DCC current-based detector is designed to be highly sensitive while being resistant to false triggering, robust, and very easy to install.  All you need to do is pass one of the bus wires to the block to be detected through the current transformer and provide 5-18VDC to power up the detector.   It can run on as little as 5VDC at 15mA, so it’s perfect for connecting to digital logic such as Arduinos or C/MRI systems.   It has open drain outputs for both detecting and not detecting states, so it’s compatible with a wide range of other model railroad products such as the Modular Signaling System, C/MRI, input modules for systems like JMRI, standalone signal sytems, or even just seeing if there’s something in that hidden section of track on your layout.  It also has adjustable sensitivity, so you can tune it to ignore leakage current through your trackwork while still picking up minute currents from rolling stock.  Precision current measurement circuitry and a little digital microcontroller onboard helps filter the response so that you achieve maximum sensitivity without false triggers.

Continue reading

Block Detectors – An Epic Tale

The development of ISE’s block detectors has been a fairly long adventure, so much so that the long, drawn-out development cycle through six or seven iterations has become a bit of a running joke between Michael and myself.  It’s served as a bit of a high water mark in terms of design revisions and major overhauls, and every time Michael and I have to rev something, there’s usually a comment of, “well, at least it’s not the !@#$ block detectors again…”

With today’s introduction of the CKT-BD1, I thought it might be interesting to let you all in on how this evolved, and how we arrived where we are today – a rock solid design that I believe in as much as our bulletproof IR sensors.   It’s the sort of thing that no sane manufacturer would do – sort of like running the corporate dirty laundry up the flagpole and waving it around.  But then again, we’re a different sort of electronics company, and Michael’s been arguing for years that I’m not quite sane…

Continue reading

Modelling Time Locks on Switches

Time Locks – An Introduction

In the real world, manual switches within signalled territory are protected by devices called “time locks”.  The purpose of these is to prevent a switch from being opened in the face of an approaching train.  When the conductor wants to open the switch, he unlocks it and starts the timer running (how this is done depends on the model of time lock).  The time delay gives any train too close to stop – or sometimes too close to even see a restricting signal – time to safely pass over the switch before the points are changed.  It also triggers the signal system to display restricting aspects around the block, so trains that are further out are alerted to the presence of an open switch.

Once a programmed amount of time has passed, the timer indicates to the user that it has expired (often by a white or green light) and then releases a locking mechanism that allows the points to be moved manually.   (This is commonly done with a locking pin through the throwbar that is retracted, but there are other mechanisms.)

Time locks aren’t just a good idea – they’re required by law here in the US.  Under 49 CFR 236.207, either approach or time locking is required of manual switches in signalled territory.

Continue reading

Interfacing With ISE’s Fast Clocks

The idea of a clock that runs faster than real time to compensate for the compression in our model world is nothing new.  The idea has been with us since at least the 1960s.  It provides a way to schedule our operating sessions, providing a sense of real time passage and urgency without needing literally thousands of feet of track to represent the vast distances covered by our prototype railroads.  Aside from being a display on the wall, guiding operators’ train movements, fast clocks have remained an isolated system, our model world unaffected by the passage of scale time.  Think about all the things in our daily lives that are linked to the time of day and you’ll quickly realize how odd that is given all our other technological advancements, and how much potential is in that idea.  I believe fast clock integration is one of the huge, unexplored areas left in the hobby today for added realism.

In this article, we’ll show you how to build an inexpensive device that allows you to synchronize items on your layout to fast clocks by using MRBus, the networking protocol that connects the Iowa Scaled Engineering Networked Fast Clocks, in conjunction with the popular Arduino prototyping environment.

Continue reading