DC Simplicity with JMRI Sophistication

The introduction of very low cost microprocessors like Arduinos to operate DCC layouts and act as DCC base stations with free JMRI (Java Model Railroad Interface)  control, signaling, scheduling, and decoder programs has allowed modelers to achieve more, faster, than ever before. . I have written about such projects in  DCC projects using the Arduino in the March, 2017 issue of MRH  (http://mrhpub.com/2017-03-mar/online/html5/?page=204) and A modeler’s introduction to the Arduino ( http://mrhpub.com/2016-12-dec/online/files/132.html)

I have for some time, been using DCC not for train control, but for powering animation and lighting, distibuted over a large area, like a layout, based on the simple idea that the DCC bus delivers power and control using just 2 wires (or rails in the case of most model railroads). It’s easier to run two wires around rather than many wires to each building you want to light, or anmation you want to run. I also realized that simple, reconfigurable “throttles” could be redesigned to do more tasks than run locos. That led to the simplified WiFi throttle, described here: SMA30 A Simplified WiFi Throttle You Can Customize ( https://forum.mrhmag.com/post/sma30-a-simplified-wifi-throttle-you-can-customize-12211948) . Moreover, if you are going to power motors and lights all over, one needs more than just a little electrical power, so SMA31 - 15 Amps Plus of Raw Power for DCC++  ( https://forum.mrhmag.com/post/sma31-15-amps-plus-of-raw-power-for-dcc-12212047) was needed too.

DCC++ Two Board Stack-  Arduino Uno under Motor Shield

It occured to me while helping some modelers recently, who are running DC layouts, that some reprogramming and a perhaps a re-imagined veiw of cab control and throttles might open some new opportunities. I had already delved into the depths of Gregg Berman’s DCC++ project -- SMA25 Tinkering with DCC++ Base Stations: JMRI To Track Connections, Accessories & Fun ( https://forum.mrhmag.com/post/sma25-tinkering-with-dcc-base-stations-jmri-to-track-connections-accessories-fun-12204471) and the combination of all these influences fired up that one tiny brain cell that sometimes runs amok in me – why not make JMRI do DC?

Old DC is New Again with “ DC+ “

The basis of all this starts with the nature of the motor control on the Arduino add-on shield – the two “H-Bridges,” that are essentially a set of four coordinated switches used to genernate the DCC signal in the DCC++ project. Originally this design was used for bi-directional DC motor control. Pulse width modulation was used to control the effective power delivered to the DC motor, thus enabling speed and direction control with only a single DC power supply. With DC power packs, train control pulses were sometimes used to kick start motors. Their power pusles would help to overcome motor drive starting friction in locos. Pulse width modulation (PWM) is commonly used in most all DCC decoders too.

The essential integrated idea was to convert the throttle commands from JMRI to the Arduino DCC++ “base station” to control each of the H-Bridges on the motor shield, as if they were separate DC cabs. With isolated track sections, anyone could then run two DC locos/trains with an unmodified JMRI throttle. Because JMRI was using precisely the same communications, and JMRI was not modified, all the available features would still be available for use! “All the features” would include the use of JMRI’s WiFi throttle server, enabling (for the first time as far as I know) the use of WiFi throttles for unmodified DC loco control. Not bad!

Also what better mechanism, than using the decoder address selection in the throttle to specify which DC “Cab” the throttle was connected to? This is how I implemented it.

But there was more! In the Arduino hardware, there is a built-in mechanism to generate PWM signals. The same that could be used for motor speed control. And there were more than two of these in each Arduino! I wanted to try to preserve the use of the motor shield as is for two DC cabs. With the Arduino Uno there were two unused PWM pins available, once the “braking” feature was disabled on the motor shield. The Arduino Uno could control four DC Cabs via JMRI throttles! . I typically run the H-Bridge drivers with an external 12 Volt power supply. If you want to run the DCC bus at a higher voltage using the motor shield, follow the advisory here: https://github.com/DccPlusPlus/Documentation/blob/master/Motor%20Shield%20Pin%20Mappings.pdf

If you use more than a 12 Volt power source to the motor shield, you will have to cut the VIN jumper wire on the motor shield before applying power.

To create a total of four cabs,  beyond the two provided by the motor shield, two additional H-Bridge DC drivers would be needed. One of the best I found was already described in detail in SMA31 - 15 Amps Plus of Raw Power for DCC++  ( https://forum.mrhmag.com/post/sma31-15-amps-plus-of-raw-power-for-dcc-12212047) and is shown below:

 

15  Amp FET Dual H-Bridge

 

This FET H-Bridge can handle a lot of current! There is NO SHORT CIRCUIT PROTECTION on this board, and yes, I have already destroyed one myself.  Adding fuses, circuit breakers, or DCC power protection devices are all really good ideas. If you run this at the high end of its range, be prepared that those small metal fins are likely to get hot. You cannot simply add a common heat sink to them all without insulating all of the fins (on the FET’s). You do not have to use this with a high current supply. It will work just fine with a lower current (1 Amp) even lower voltage (8 Volt) supply too.

With the appropriate power supply, the new 15 Amp FET H-Bridge will power any DC loco. But one should remember that there is a larger Arduino, the Mega2560, with even more PWM pins, also compatible with both the Arduino motor shield, the new FET H-Bridge, and the DCC++ code. It can control up to 8 DC Cabs! To do so, it would need a total of 4 dual H-Bridges (remember the motor shield is a dual H-Bridge too). Interesting to some people (like me) the way the H-Bridge controls were actually reversed from the way they were use for DCC control. With DC cab control, the DIRection controls are actually used for loco direction, and the PWM control is used for PWM speed control. In DCC++ the DIR connection is used to generate the symmetrical, alternating DCC signal and the PWM control is used to turn the signal full on or full off.

Making It All Work

You can find the details of constructing a DCC++ hardware module and loading sketches in DCC projects using the Arduino in the March, 2017 issue of MRH  (http://mrhpub.com/2017-03-mar/online/html5/?page=204). The article includes a description of the connection to JMRI. It may be difficult to believe, but once  you have an operating DCC++ set of boards, connected to JMRI, then all you need do is load the new sketch (program) into your Arduino and you will have a dual cab DC control system, operated by JMRI throttles, including any form of WiFi throttle. The new code can be had here: 
http://mrhpub.com/files/users/geoffbfiles/DCp_Cab2_1.zip

The name reference is to DC+ (not a stretch I know!)

Remember to cover the entire folder and its contents in the zip file into your …\Documents\Arduino\ folder. Then load the sketch DCp_Cab.ino into your Uno with the Arduino IDE editor.

If you use the Uno/Motor Shield combo alone you will have 2 DC cabs capable of delivering up to 2 Amps each. If you want 4 DC cabs, you will need to cut the 2 Brake Disable jumpers on the back of the Motor Shield to free up the additional pins for the extra cabs.

 

For any JMRI connected throttle, simply address the DC cab by setting the throttle address (1-4). There are no “functions” in DC control, but throttle speed, and direction, as well as power control can be set and adjusted. To change cabs simply release (REL) the address and set the new cab address. You can operate four separate cabs with an Arduino Uno. Now it should be clear that you can use a WiFi throttle to control your DC layout too. Four throttles can be used simultaneously.

To connect the additional H-Bridges use these pins on your Uno:

PIN      Description

3          DC CAB 1 pwm           (Motor Shield)

10        DC CAB 1 dir               (Motor Shield)

11        DC CAB 2 pwm           (Motor Shield)

5          DC CAB 2 dir              (Motor Shield)

6          DC CAB 3 pwm           (External H-Bridge Module) Make sure to cut Brake Jumpers

7          DC CAB 3 dir              (External H-Bridge Module) Make sure to cut Brake Jumpers

9          DC CAB 4 pwm           (External H-Bridge Module) Make sure to cut Brake Jumpers

8          DC CAB 4 dir              (External H-Bridge Module) Make sure to cut Brake Jumpers

 

 

Wiring from UNO/Motor Shield combo (Uno Pins) to External H-Bridge for DC Cab 3 and Cab 4

Please note: These are NOT the same connections used for connecting this FET H-Bridge to the DCC++ motor shield in the DCC Application!

If you need 8 DC Cabs, you can use an Arduino Megaa2560 loaded with the same sketch listed above. Remember to cover the entire folder and its contents in the zip file into your …\Documents\Arduino\ folder,

Load the sketch DCp_Cab.ino into your Mega2560 with the Arduino IDE editor.

To connect all the H-Bridges use these pins on your Mega2560:

PIN      Description

3          DC CAB 1 pwm           (Motor Shield or External H-Bridge Module)

12        DC CAB 1 dir               (Motor Shield or External H-Bridge Module)

11        DC CAB 2 pwm           (Motor Shield or External H-Bridge Module)

2          DC CAB 2 dir              (Motor Shield or External H-Bridge Module)

6          DC CAB 3 pwm           (External H-Bridge Module) Make sure to cut Brake Jumpers

7          DC CAB 3 dir              (External H-Bridge Module) Make sure to cut Brake Jumpers

9          DC CAB 4 pwm           (External H-Bridge Module) Make sure to cut Brake Jumpers

8          DC CAB 4 dir              (External H-Bridge Module) Make sure to cut Brake Jumpers

2          DC CAB 5  pwm          (External H-Bridge Module)

4           DC CAB 5  dir             (External H-Bridge Module)

46         DC CAB 6  pwm         (External H-Bridge Module)

48         DC CAB 6  dir             (External H-Bridge Module)

45         DC CAB 7  pwm         (External H-Bridge Module)

47         DC CAB 7  dir             (External H-Bridge Module)

44         DC CAB 8  pwm         (External H-Bridge Module)

42         DC CAB 8  dir             (External H-Bridge Module)

 

These all connect in a similar fashion as designated in the previous diagram above.

You do not have to implement all the DC Cabs. (You can build as many as needed.)

 

Additional Project Notes:

Do not make connections or disconnections while any power at all is applied to any of the connected modules. The 12 Volt power will instantaneously destroy any of the control logic circuits if shorted to the wrong place on the boards. H-Bridges do not have to be powered with 15 Amp power supplies. They work just as well with 1 Amp power.

The four DC cab Uno configurations have been tested as described. I am still amazed that they work as well as they do. The 8 DC cab configuration with the Mega2560 has not been tested. If you build one, let me know how it turns out. All the software mods are already in place.

I have tried to minimize the changes to Gregg's original DCC++ code for DC+ in case some intrepid modeler might find a use for some of the remaining original functions. However most of the DCC signal generation code has been removed. No modification was made to JMRI, and no additional JMRI scripts need be run. This should enable the modeler to use DC+ for JMRI throttle control and even allow JMRI to operate with a different DCC system (like Digitrax) for signaling, sensors, turnouts, ops , etc. My bulk JMRI sensor interface: SMA28 JMRI Sensor Channels – Direct Arduino to JMRI Communications - Simple Support for Lots of Detectors https://forum.mrhmag.com/post/sma28-jmri-sensor-channels-%E2%80%93-direct-arduino-to-jmri-communications-simple-support-for-lots-of-12210793  and bulk JMRI turnout channel: SMA29 JMRI Turnout Channels – Direct JMRI to Arduino Communications - Simple Support for Lots of Data Out From JMRI  https://forum.mrhmag.com/post/sma29-jmri-turnout-channels-%E2%80%93-direct-jmri-to-arduino-communications-simple-support-for-lots-of-12210817  can be used with the DC cabs in DC+.

 

In my opinion, the fact that all this can work is a tribute to the genius and inventiveness of all the JMRI developers and Gregg Berman  -- the shoulders that this project is built upon. I hope you have as much fun with this as I have, and build your own projects, perhaps using a piece of two of this work too!

As usual, all relevant comments and suggestions are most welcome.

Have fun! 

Best regards,

Geoff Bunza

Similar system using Bluerail Trains Bluetooth boards

Great work, Goeff! I'm especially following your thread on the do-it-yourself DCC throttle. I run my HO stuff at the local club where we never seem to have enough throttles.

For my N scale railroad, I decided to stick with traditional DC due the fact that almost all of my locomotives are pretty ancient and it would take more time, money, and effort than I want to spend on upgrading them to DCC. I installed a system a few years ago that utilize Bluerail's Bluetooth boards as the "cabs" and two Raspberry Pis to allocate block power. Here's a link to more details:  http://new-ulm.us/?q=node/15 This setup would also work with any of the currently available Bluetooth and/or Wifi modules, such as Monocacy Trains, Wiftrax, and LocoFi.

By using a web server on one of the RPis, I'm able to control block power from my phone/tablet as well as run the locomotives. This eliminates the traditional control panel. The next update to this system is to add a graphical display of the blocks showing which are assigned to cab 1, which to cab2, and which are off.

Now that I've started experimenting with Arduinos, I see that I can use a couple of them to replace the relay modules. I might just do that one of these days.

Keep up the great work and I'm looking forward to your next contraption!

Some questions

Hi Geoff,

I really like the way you find alternative uses for existing products.  I too noticed when DCC++ came out that Gregg had used the Dir and PWM outputs opposite from their original design.

Do I understand correctly that each H-bridge output would connect to a separate DC block, meaning that a Mega with 4 dual H-bridges would connect to 8 isolated blocks?

One other question relates to SMA8 Sensors, will track power thru a 100:1 toroid coil (tombstone) create a strong enough signal for an Arduino analogRead pin?  Or is additional circuitry required?

Thanks for sharing all these great ideas.

@ Dave re: DC Blocks

Hi Dave !

Really 'glad you like these! 

'Hope this helps. Have fun! 

Thanks Geoff

Geoff, thanks for the prompt and complete answers and explanation.  Makes complete sense about the time required for analog conversion. 

On my multi-scale demo layout there is an HO and an OO train on the same 15" radius loop of track. DCC++ with RPi and JMRI are used to control them.  I am planning to divide the track into 8 blocks, add detection, and use JMRI for one train to automatically follow the other which is controlled by one of your new WiFi throttles.  

I have a Digitrax BDL16 that I will likely attempt to use the LED output as Arduino input to JMRI.  Should be an interesting experiment.

Regards,

Possible further improvement

Geoff,

I'm not well versed in the whole DC powered CAB control setup, but I like the idea you presented above. It still makes for a decent amount of wiring under a layout if I understand it correctly.

What if you used a DCC++ command station, a central DCC bus and DC power bus under the layout? Then control each CAB block with an Arduino DCC "decoder" under the layout connected to the DCC bus. The Arduino DCC decoder then controls the flow of power from the power bus into the CAB block by doing PWM? You'd dial up the DCC decoder address on the JMRI controller as the CAB block # you'd want to control. This would make wiring almost as easy as wiring DCC with short runs between DCC & power bus via the CAB bus Arduino to the CAB block rails. No more CAB block switches and multiple runs of bus wire to select between.

@Yaron

Hi Yaron,

You have my head spinning! But I am really glad this article might make you think even a little bit about all the myriad options you can use! 

Have fun! 

Block to Block PWM Phase Consideration and Design

Geoff,

Another great project, but a few words of caution for those who might want to expand the design to multiple blocks.

I have worked with DC layouts with several PWM drivers for multiple blocks, and it definitely can be more complicated than one would first think. One reason there is only ONE DCC Command Station per layout is to insure that track to track, block to block or module to module signals (DCC signals are essentially PWM) are in phase. If not things can get very toasty, fry or blowup. Ask those who have accidentally swapped booster inputs or outputs. The same thing holds true if you are designing a multi-block DC layout with PWM drivers. You have to assure that at each gap the signals are in phase, and that can be a real pain.

It has been a while since I looked at the DCC++ timing scheme, but before anyone attempts to put together a multi-block system I would suggest that you thoroughly review the design and measure the phase shift(s) of the various PWM signals before running an engine around the tracks. Geoff - have you looked at the timing? Most DCC boosters are overload protected and will usually survive such blunders, but for the unprotected, high power boards even a few milliseconds (or depending upon the power supplies used microseconds) of phase offset can result in very very high, destructive current spikes. In any case I would reinforce the recommendation to install good overload protection for any such installation.

@Ken

Hi Ken,

All good points. A couple of things to add, actually reinforcing your comments perhaps stronger than you realize.

None, repeat none of the DCC++ timing of phase are applicable as these PWM (speed) controls are hardware controlled and created and have nothing to do with the former DCC++ DCC timing. Further, from PWM pin to PWM pin on the Atmel processors there are some timing variations. Those  modelers that are ingratiated with DCC need to reset your thinking, as not much applies in this application. It is in fact much more similar to the old DC layouts with multiple "Power Packs" per throttle. Crossing cab districts where 2 different cabs were active on each side was inviting problems. Now aren't you glad we have DCC and auto reversing?

Have fun! 

Dear Geof thank a lot for

Dear Geof thank a lot for your DC cab suggestion.

I try the Arduino sketch and all is working well except than in one direction the loco stop for a second or two and then resume speed in the other direction the speed is fluently and the loco proceed regular.

Giorgio Calzoni

N scale Clinchfield Railroad in Bologna - Italy

Engines with chips inside

Very very interesting. We are currently upgrading our club layout to get ready for DCC and around 18 DC throttles. There is a major rewire going on but we have to keep the downtime to a minimum so this means a good 2-3years of rewiring to go.

My question is if we were to put 4 of these dc+ wifi controllers in place would it put out straight DC current to the track or a PWM to the track?

The main reason for the above question is would locomotives with DCC chips enabled in them still run or would they sit there awaiting DCC++ style addresses.

@Mike re: DC or ?

Hello Mike,

It uses PWM to control DC motors, just like the end stage of a DCC decoder.

Sorry Mike, I never tried running a DCC loco with strict PWM from any source, so I can't give you a definitive answer. DCC decoders typically will try to decode anything they receive, but are required by spec to discard anything they can't decipher. It may be that if they don't "see" any recognizable DCC messages for some period of time, they revert to DC operation. This is what I suspect would happen, as I did run DCC equipped locos on old DC power packs years ago which used added pulses at startup to jog the motors forward. ...That was over 15 years ago! Have decoders changed that much? I don't even try this anymore.

'Hope this helps. Have fun! 
Best regards,
Geoff Bunza

WIFI throtle

how about this setup 

- An old laptop connected to your DCC system via a USB interface, with JMRI on it

• we use a Raspberry PI that just starts up and works automatically

- a WIFI network (just an older router you could use for internet)

- the throttle then becomes a smartphone from cheap to expensive with engine driver installed

This system works a treat and most people may more than likely have a smartphone they can use.

@Mike Congrats

Hi Mike,

Congrats on your successes!  I'm really glad you can make use of these projects. I know that quite a few other modelers have used them too. There are many times I wonder if these efforts will draw any interest at all! 

Have fun! 
Best regards,
Geoff Bunza

operation of DC+ on Aurduino Mega 2560

G'day Geoff,

Many thanks for this excellent port of DC operations to a standard DCC++ Arduino rig, It makes life a bit easier when working on the odd model which isn't DCC in my case. I built it on an Arduino Mega as I had one to spare.

It worked first time "out of the box" and amusingly, the PWM frequency makes the motor "sing" rather like the full size version of the DB ICE 2 does!

Whilst compiling I get an error generated

" C:\Users\wilwa\Documents\Arduino\DCp_Cab\DCp_Cab.ino:49:59: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 CurrentMonitor progMonitor(CURRENT_MONITOR_PIN_PROG,"< p3> ");  // create monitor for current on Program Track"

But the program goes on to download and appears to run. Any idea what is causing this and how to correct?

Is it possible to raise the PWM frequency to say 25khz as in the case of a lot of DCC loco decoders? it would stop the audible singing of locos which are not models of electric trains.

One anomaly I have found in use. If the power is disconnected using the power on /off key in JMRI and the slider is used to increase the output in either direction on pressing the power button the software locks in an intermediate stage and power cannot be cycled either on or off. Releasing the loco than causes the power to switch and the loco runs away at the previously set level. This seems to indicate some issue with the feedback from the Arduino to JMRI. Any clue as to where I might look to rectify this? I have tried this on both Mega and Uno boards with the same result.

Bill

@Bill re: Comments

Hi Bill,

I just downloaded and compiled the DCp_Cab on the 1.8.13 Arduino IDE with no errors. Try upgrading your IDE and see if you still have the warning. These are compiler warnings not errors and will likely not affect your sketch.

Short answer, possibly yes, but it looks like it will break the delay() and millis() timing functions, and/or possibly the servo library, all of which share the internal hardware timers. Without a re-write of handling the throttle speeds, it doesn't look good, and even with a major re-write I could not guarantee the throttle timing would be stable for multiple throttles. This is not an obvious and easy change.

This sounds like a JMRI to DCC++ communication issue, and may require some changes in both. I would try to talk with the new DCC++EX developers and see if they have seen this and offered up a solution in their new code.

'Hope this helps. Have fun! 
Best regards,
Geoff Bunza

operation of DC+ on Aurduino Mega 2560

Hi Geoff,

Those were sort of the answers I was expecting. No problem. I am using Arduino IDE 1.8.13 and still get the compiling errors I just tried it again.

I'll see if the guys at DCC++EX have any info

Cheers

Bill

It works only in one direction.

I was able to compile successfully with no errors and to upload to my Uno. But it's only running in one direction ever after I switch directions on the throttle. Still learning Arduino and DCC++ as I just started into the hobby. But I have a basic electronics background and some programming skills.

Great project and having fun with this and everything else. 

Patrick

@Patrick re:One direction

Hi Patrick,

'Never saw this problem before. Are you using the same "address" without change?

Did you try physically reversing the model loco to see if there was any change?

Are there any other specific symptoms you have observed?

Does the same behavior occur with another loco?

What is the power source you are using for the motor shield? Amps and volts? Is there a common ground between your motor shield power supply and the power supply to your Arduino? to your computer?

Have fun! 
Best regards,
Geoff Bunza

It works!!!my mistake...

Reason it was not working was I forgot that the motor shield did not have wires as I had my Arduino/Motor shield configured for DCC++EX. Once I plugged in the jumpers onto the motor shield board, it works both directions.

This is awesome. 

I'm running JRMI on a RPI 3 Model B, connected to chinese Arduino UNO and Motor Shield. Power to Arduino is via USB from the RPI and I have a 12V 5A DC adapter feeding into DC boost to get 15V to the motor shield. I also have Mega configured with DCC++EX.

So now to order another motor shield...

Thanks for the quick response Geoff.

Cheers

New V3 shield, different direction pins

I haven't been able to change directions of my trolley using your program. I did some research and the new(ish) v3 version of the arduino motor shield uses different direction pins - for direction A it is pin 12 and direction B it is pin 13.  See here: https://store.arduino.cc/usa/arduino-motor-shield-rev3

So in the code I changed #define loco_cab1_dir from 10 to 12 and #define loco_cab2_dir from 5 to 13.  However I still can't change directions either using the motor output 1 or the motor output 2.  I can select speed and such so I have things hooked up right.  Is there anywhere else I need to change?

EDIT:  Sorry I found it.  In DCCpp_Uno.h you also need to change DCC_SIGNAL_PIN_MAIN from 10 to 12 and DCC_SIGNAL_PIN_PROG from 5 to 13 and it works.

Thanks

@cubbieco

Hi cubbieco (name?),

'Glad to see that you got that sorted out.  I've been pleasantly surprised at how many modelers are using this! I suspect there are still quite a few modelers running DC layouts.

Have fun! 
Best regards,
Geoff Bunza

Randomly semt OFF commands sent to DC+

I installed your DC+ and i love it.  I am struggling with a bug in the throttle.  Every 60 to 180 seconds the throttle sends a command to turn the power off.  I can move any of the throttle controls and it comes back to life.  I did add a pair of digitalwrite commands to keep the brake pins as low, but i domt think thats the issue.  Any ideas?

@Edabbott reowering Off

Hi Edabbott (name?),

The modifications to DCC++ to create DC+ don't change any of the commands the throttle sends to the base station (DC+). What you are describing sounds like the throttle goes idle, and the WiThrottle server thinks it disconnects, and then sends the speed 0/power off to the loco. What kind of throttle are you using? What version of JMRI are you using?

Have fun! 
Best regards,
Geoff Bunza