# Basics of DCC++EX



## afboundguy (Jan 10, 2021)

Can someone dumb down DCC++EX for me or link me a good descriptive YouTube video? I've been searching for 15+ minutes and all I find are how to make the setup videos!

My biggest question is would it replace my current DCC system (MRC Prodgidy Advance 2) or does it work in conjunction with it?

I think I know you need a computer hooked up most of the time and with the newest versions you can add wifi and use your controller or tablet as the throttle and that it can integrate with JMRI but above that I'm clueless!


----------



## Dennis461 (Jan 5, 2018)

Why replace the MRC Prodgidy Advance 2 ??


----------



## Severn (May 13, 2016)

It's based on the original project which might appear with a "dcc plus plus" search.

It's basically an Arduino (like an Arduino uno) a so called motor shield coupled to a PC or similar running jmri.

The software of the project running on the Arduino makes the motor shield put out the appropriate dcc track signals.

The jmri merely commands the Arduino software which takes commands through a serial line.

I'm using the original project, with some of my own mods, an Arduino uno, a pololu motor shield and an adafruit current senior.

I'm also back a few releases on the jmri. It does work.

But that original project author seems have permanently left the scene.

Eventually another group of people based dcc++ off it.

I have nothing specifically to do with either.

I mentioned some hw above but a reasonable place to start is the Arduino uno and Arduino motor shield. I don't use this combo but I'm led to believe arduinos motor shield's built in current sense works. It doesn't work on the pololu. You need some kind of current sense to detect the so called "ack pulse" for reading engine CVs.


----------



## afboundguy (Jan 10, 2021)

@Severn thanks for all the info! Can I do as much programming and basically the same stutf with my MRV Prodigy Advance 2 if it's hooked into JMRI?



Dennis461 said:


> Why replace the MRC Prodgidy Advance 2 ??


Curious if I can have the same programibility and customization. I'm assuming JMRI would work though the Progidy Advance 2 but I really have no clue about DCC++EX and I'd prefer to keep the setup I have now if it can do essentially the same stuff through JMRI or at least close enough stuff!


----------



## Severn (May 13, 2016)

I really don't exactly know. Jmri supports, that is it can interface to a wide variety of commercial products -- you should definitely check that it's supported. When I use it, I just use a small part of it's functionality, the decoder pro. In this I've listed my engines and associated a graphic image with each. This is a table just to be clear. In terms of programming engines, all I've done is turn the sound volume down on several by setting CV values. And that's it. Yet this is what I need right now and I can run my engines with it 

Because the jmri source code is available, one could in theory make any modifications to it's function as desired. Totally possible, I've never done this.

Then over on the base station, we'll call it. For commercial products I assume there's limited access to the "internals" but they probably provide numerous settings and configurations otherwise. Well whether that is done through jmri somehow or through their product interfaces I don't know, but suspect the latter.

There's other aspects that could be considered programming. For example adding a new engine not yet supported. I've never done this but jmri has its own configuration files for this and I believe this can get somewhat involved.

Likewise adding new or unsupported base stations is I would guess somewhat involved.

Perhaps in a way this is something to consider because while jmri is free, that's great. And it seems to have plenty of functionality ... And that's great. You may find it's you adding it. And this may be frustrating or not something of interest.

Did I answer your question? I'm not sure I did.


----------



## afboundguy (Jan 10, 2021)

@Severn you answered it well enough for my limited amount of knowledge. I do like that JMRI has the ability to lower sound values. I'm sure my MRC setup could but I really need to lower the volume of my various BLI engines they're too loud for my liking...

I'll have to do some more digging to see if it would be easier to add the automation I'm looking to try and do with the MRC and JMRI of maybe I could encorporate it with a DCC++EX add on... Time will tell as the whole automation is a ways away...


----------



## Severn (May 13, 2016)

What is the automation?


----------



## afboundguy (Jan 10, 2021)

Two inside tracks of the Horseshoe Curve goes down into one track from the left tight corner in the first picture (ignore the lines) and after that bottom right turnout it goes into a curved turnout back to two tracks. 2nd picture on the right side there is a double slip switch where the 2 tracks go back down to the 1 behind the back of the chimney.

I'd want to have two trains running continuously and have one stop if they get at the same spot and switch the double slip switch and the curved turnout so they just keep running on both loops... I'd want to put a 4 track PRR signal bridge on both sides of the chimney with lights that would light up as well...


----------



## Severn (May 13, 2016)

So you want either to pause until the other goes by including all cars. Right? (In particular yellow now that I stare at it a little... )


----------



## afboundguy (Jan 10, 2021)

Severn said:


> So you want either to pause until the other goes by including all cars. Right? (In particular yellow now that I stare at it a little... )


Yep at the spot it goes from 2 tracks to 1 and once it makes it through the other can start and the 1-2 throws on the double slip switch and the curved turnout to change accordingly as well


----------



## Severn (May 13, 2016)

This... could be hard. Dcc provides 0, zero, zed info back to the base station except for that oddball ack pulse thing which has to do CV values.

The trains on your track know nothing really about themselves. The base station commands in the blind. The direction on the track, track position, speed, length of train. None of that is known...

Yet it seems possible. There might be 100 things or ways to go about this but here's two things that might help in your ruminations..

From Iowa scale eng again. This "spotter" which one imagines it or something similar could be brought to bare on the problem.






CKT-IRSENSE: TrainSpotter







www.iascaled.com





And...






Train Detection using PN532 RFID Modules


O-Gauge Train Layouts




www.silogic.com





I've actually worked in a minimal way with him on his sound program. And this guy is one smart cookie...


----------



## sid (Mar 26, 2018)

dcc++ex and an arduino would replace the entire system and it works flawlessly . with JMRI you have much more control and adjustments of all aspects of dcc locos very easily . i used to run NCE and still have it in a box someplace but im now 100% DCC++EX on Arduino and deeks motor shield all under $50


----------



## gregc (Apr 25, 2015)

afboundguy said:


> Yep at the spot it goes from 2 tracks to 1 and once it makes it through the other can start and the 1-2 throws on the double slip switch and the curved turnout to change accordingly as well


so what kind of system are you imagining will do this for you?

there are a couple DIY approaches


----------



## afboundguy (Jan 10, 2021)

gregc said:


> so what kind of system are you imagining will do this for you?
> 
> there are a couple DIY approaches


Whatever can prevent both trains from going through the "gauntlet" and throw the switches accordingly would work and I am a big fan of the DIY approaches so I'm open to any and all possibilities...


----------



## Severn (May 13, 2016)

This is going to be a home brew solution overall. You'd need some sensors maybe ir for example to detect the approach, do various calcs and slow the train down until the other clears. The lengths and time each takes to slow might be a configuration value. Perhaps an emergency stop in case all goes wrong.

I'd envision the "brains" on a PC or similar, the dcc just being commanded. Getting the sensor info back into the PC or similar might be a different Arduino. 

Possibly instead of the PC a raspberry pi or similar.

You'll be writing software mainly.


----------



## gregc (Apr 25, 2015)

afboundguy said:


> Whatever can prevent both trains from going through the "gauntlet" and throw the switches accordingly would work and I am a big fan of the DIY approaches so I'm open to any and all possibilities...


one approach is to have relatively short blocks on all trackes leading to the switch that both detect and with a relay can be de-powered. obviously also some means to control the turnout(s) (i.e. switch motors)

even something as simple as an Arduino can implement the logic to detect a train on either side of the switch and align the turnout appropriately

if another train approaches turnout on the opposite route, that block can be unpowered to stop the train (if it doesn't have long keep alives).

after the first train exits the block on the opposite side of the switch, the turnout is re-aligned and power restored.

probably not that complicated


----------



## Severn (May 13, 2016)

I wouldn't mix the Arduino dcc functionality with this. Keep it seperated. If I was doing it, I'd try ir to detect engine over and speed and plug in some values for length and time to slow down,I do that in another processor -- I call this the master controller.. I'd pick something friendlier than a Arduino for that. Getting the it back though to mc is another problem ... Those Iowa scales engineering have a occupancy detector although u might just try your own ...


----------



## gregc (Apr 25, 2015)

why not use a 2nd Arduino? are you suggesting 

if you want to slow down, you'll need something that knows the current DCC speed and can synthesis new speeds to slow it down and then speed it up later. wouldnt' that require that it's integrated with the DCC controller?


----------



## Severn (May 13, 2016)

Why not a two Arduino solution? Maybe in the end ... But just to experiment and get something working. I'd go for an more high level experience. I think this would be easier.

So my thinking is you'd need 2 or maybe 3 sensors grouped in such a way to detect the train in one direction ... With enough time for it to stop at the junction, per loop.

Well that's my thinking, doesn't mean it's right ...


----------



## gregc (Apr 25, 2015)

if you have detectors in opposite sides of the turnout, wouldn't you be able to detect the train approaching as well as leaving the turnout, in either direction?


----------



## Severn (May 13, 2016)

I think so but I was trying to simplify the problem for the original poster. In fact one might just start with a loop and get the train to stop or something simple like that, build up from there.


----------



## MidwestMikeGT (Jan 4, 2021)

Maybe this video might give you some ideas:

Granite Gorge video (https://youtu.be/Jy_X86HMFB4)


----------



## gregc (Apr 25, 2015)

the Pacific Southern RR has a sophisticated but custom software control system used to monitor block and control routes during op sessions. it incorporated stopping blocks which de-powered a short block between a signal and turnout if the train ran thru a STOP signal. later it tracked trains by IDs as they progressed from block to block and ultimately implemented automatic train control, slowing trains to a stop when they approached a STOP signal and resumed their speed when the signal CLEARed. 

to control train speed, it needed to know loco DCC addresses and had the means to issue DCC commands thru an NCE DCC serial interface

needless to say, this ATC took some time to implement based on existing layout hardware and capabilities


perhaps simplifying aspect for the OP, again based on the ability to depower blocks adjacent to the turnout is to simply depower the blocks on the opposite route when a train enters a block and restoring power on exit from the block opposite the turnout*. *

this avoids the need to detect a second train. a 2nd train enters the depowered should come to a stop without being detect and will be detected as soon as power is restored after the first train has cleared the turnout

so the control logic is reduced to simply detecting a train, aligning the turnout and depowering the opposite blocks


----------



## Severn (May 13, 2016)

That would be simpler I think although the same track would always depower which might be ok. The other just has right of way.


----------



## FlightRisk (Dec 6, 2019)

The EX-RAIL feature of DCC++EX is pretty mature and well-tested now with new features being added regularly. It is a simple scripting language that even a non-coder should be able to navigate, though there are many already written scripts from controlling a trolley to simulating an ARC welder with LEDs. Running trains from a throttle, handing them off to automation, and taking control again is easy. It uses the terms of "automation", "sequence", and "route" to plan your layout operations. If you use Engine driver for a throttle, routes in the CS can be automatically detected and populated to buttons. With sensors, like simple IR detectors or current sense (block) detectors, portions of track can be "reserved" when a train enters them. Other trains will automatically stop if need be. Signals, turnouts, lighting, and animations can all be configured. 
You define items and can control actions when those items are triggered. "Play this sound when this button is pressed", or "When the turnout is thrown, close the facing turnout and change the signal aspect", "run this crane loader animation when this sensor is tripped". You can do this with button control or with sensors to just let everything automate itself. The concept is that you are the driver. The train drives the layout, the layout doesn't drive the train. Each train just needs to know what is in front of it. It goes from point to point, following the route, and checking to see that it is safe. If you are manually controlling a train with others running routes, they see if you entered a block and they have to stop. There is a lot more information here with videos hopefully to come soon. Introduction to EX-RAIL Automation — DCC++ EX documentation

Fred
DCC-EX


----------



## Severn (May 13, 2016)

So this runs on the Arduino of dcc++/dcc-ex?


----------



## Erik84750 (May 2, 2017)

Just now found this interesting concept discussion.

An Uno or Atmega can be loaded with either DCC++ or ECC -EX.

I always is a good idea to study and think about electrical control concepts prior to building a layout. Con,verting an existing layout of course also is possible yet requires more often than not very extensive rewiring.

I am planning to start building a fairly large layout (about 5m by 6m) after next year. The past four, five years I have been reading up, studying, and designing/testing my own electronics hard- and software. Everyone should be able to do this by himself, but what is hard to find is a kind of "helicopter view" of possible electronics concepts overview; almost everyone in the hobby knows about "his" system and how "great" that is, but I never found a place where possible concept options with their respective pros and cons are discussed.

So what I am about to propose here will surely have detractors, but for me, after all these years of studying and reading, I consider this the best solution. And what is more, I will use logical arguments.

1. use DCC++. Because it is free, and fantastically engineered. Why not DCC -EX I will answer that at the end of my post.
2. use JMRI for decoder programming ànd for layout control (within limits).
3. use DCC++ for multiple locomotive control (speed, direction and light/sound on the loco)
4. use a separate bus for all other controls (turnouts, sensors, booster control, block occupation sensing, ...)

The reasoning for the last item is that DCC++ is to transmit across the tracks both power and data for mobile equipment (loco's). All other layout controls (ie fixed decoders, sensors, current sensing, detectors,..) should be relegated to a separate bus: purely as a design concept I prefer not to mix purpose and means.

After some research I found that RS485, as an industrial standard, is well proven, robust and fast. So I came accross a proven design, by dr. Chubb: the C/MRI standard for model railroading communications and interaction. But using my own hardware and software designs, particularly for IO (sensors, turnoutcommands, any other items apart from locomotives, requiring digital IO) across the layout.

So I designed and tested various projects the past few years:
1. a controller for multiple DCC++ boosters, with extremely fast and robust individual short-circuit detection.
2. reversing section controller (using presence detection, not using short circuit detection)
3. differential optical sensor module
4. current sensing block detector (based on dr. Chubb's design)
5. two MCP23017/MCP23S17 based servo turnout controllers (one with PCA9685 and one with microcontroller controlled servo's; all with slow protoypical turnout movement)
6. a Nextion based handheld throttle (A Nextion Based Controller for DCC++ and DCC-EX)
7. my own design for a C/MRI SMINI node, a 24IN/48OUT node based on nopxor's (a French model railroad enthusiast) design and development (hard- and software)
8. and JMRI for handling turnouts, inputs from panel buttons/switches, logical programming (LogixNG), mobile decoder (loco) programming, C/MRI and DCC++ interface. On Rpi when preferred, or simply on a pc connected with USB to the DCC++ controller; and with a USB-to-RS485 converter to C/MRI nodes.

And the reason for preferring DCC++ over DCC -EX is that there is not really added value to DCC++ except for handling a network environment, which i do not need. Also the design concept of DCC -EX where for example I2C is used as sensor interface over distances of more than 1 metre is technically speaking not correct. And the fact that the DCC bus is used for everything controlled digitally on a layout; which is not my idea of a well distributed control system.
But as I said, surely there will be detractors to my arguments yet this is what I feel best for my needs for a suitable fairly large scale layout.

All my designs, developments and software (all robustly tested and proven) are available on simple request, as on on the Trainboard forum.

But again, this is purely my opinion, although well researched, but still somewhat subjective.

Erik


----------



## gregc (Apr 25, 2015)

how do operators control their loco(s)/train?


----------



## Erik84750 (May 2, 2017)

A Nextion Based Controller for DCC++ and DCC-EX

A Nextion display coupled to either Uno, Nano, Pro Mini, ESP8266 or ESP32 controller (thje last two with wifi capability, can be connected to DCC++ EX).
And a battery if wireless is the preferred option. In a case.

Software has been tested and debugged by a little group of three men, including me, over the course of the past 12 months with the main contributor and software developper: Norm Hallard (see Trainboard forum).


----------



## gregc (Apr 25, 2015)

presumably you're using off-the-shelf code for these things

have you consider using WiFi capable processors for C/MRI?


----------



## Erik84750 (May 2, 2017)

gregc said:


> presumably you're using off-the-shelf code for these things


No. Every line of code has been developped and written, and debugged, by either myself, or (in case of the throttle) Norm Hallard, or in case of the SMINI node by nopxor.



gregc said:


> have you consider using WiFi capable processors for C/MRI?


That may be possible, but this is not 1. what I want nor need and 2. this bypasses the original C/MRI concept for RS485 communications. And anyway, the handheld throttle mentioned earlier, is capable of all interfacing with any layout digital IO (with fixed DCC decoders) over wifi (if ESP8266or ESP32 is used, it is just that I use C/MRI instead for that.

And C/MRI is a different concept from DCC: both work in separate "environments".


----------



## gregc (Apr 25, 2015)

what developement platform are you using? Arduino IDE and the libraries it provides?



> And C/MRI is a different concept from DCC: both work in separate "environments".


not sure what this means. C/MRI has always been separate from train control and it seems you're already using WiFi. WiFi node control would save wiring and the need to poll


----------



## Severn (May 13, 2016)

I have the old/original dcc plus plus with my own limited mods to support the adafruit current sensor and the pololu hbridge board. This seems to work with at least an old version of jmri. I can program and control my engines. But my use has been simplistic. I was just thinking of a phone based controller vs my PC mouse. .. possibly using the jmri web interface that I think might exist. Even if that worked it has no knowledge of my turnouts for example or any other thing that might take a command or even return status. Generally speaking while I have no issue with things like the Arduino being close to the real hardware I'd tend instinctively to some thing like the raspberry pi as a computational nose or even display driver. I prefer the idea of flat panel touch screens for some kinds of control, or possibly joy sticks or other game controllers vs say buttons and codes, versus tiny alpha numeric displays. Not sure any of that aligns with your discussion pts.


----------



## Erik84750 (May 2, 2017)

gregc said:


> what developement platform are you using? Arduino IDE and the libraries it provides?
> 
> 
> not sure what this means. C/MRI has always been separate from train control and it seems you're already using WiFi. WiFi node control would save wiring and the need to poll


Development platform: Arduino IDE
Libraries: mainly self written except for SPI, Wire and LCD
I personally am not using wifi for model trains, although this certainly is a possibility with the Nextion throttle we developped.
Saving wiring, so? I use radio communications without using wifi. Others may and will do differently.


----------



## Erik84750 (May 2, 2017)

Severn said:


> I have the old/original dcc plus plus with my own limited mods to support the adafruit current sensor and the pololu hbridge board. This seems to work with at least an d version of jmri. I can program and control my engines. But my use has been simplistic. I was just thinking of a phone based controller vs my PC mouse. .. possibly using the jmri web interface that I think might exist. Even if that worked it has no knowledge of my turnouts for example or any other thing that might take a command or even return status. Generally speaking while I have no issue with things like the Arduino being close to the real hardware I'd tend instinctively to some thing like the raspberry pi as a computational nose or even display driver. I prefer the idea of flat panel touch screens for some kinds of control, or possibly joy sticks or other game controllers vs say buttons and codes, and tiny alpha numeric displays. Not sure any of that aligns with your discussion pts.


Sure why not? I intend to use turnout control panels with switches/buttons on those places closest the the respective turnouts. Yet those turnout buttons will be read over C/MRI into JMRI which may or may not use LogixNG to control routing, or simple turnouts, or... 

Using a flat panel touchscreen does not detract from using JMRI; great software isn't it?


----------



## Severn (May 13, 2016)

Well.. it's free.


----------



## Erik84750 (May 2, 2017)

Severn said:


> Well.. it's free.


.. as is your comment


----------



## Severn (May 13, 2016)

I mean obviously it has a lot of functionality and probably 1000s or more hours into it and all that. But, I think it looks a little dated and wonder about that. I'd also like a sound decoder definition tool. Now, would I actually pay for any of that? I dunno. I haven't donated but maybe...


----------



## Erik84750 (May 2, 2017)

Severn said:


> I mean obviously it has a lot of functionality and probably 1000s or more hours into it and all that. But, I think it looks a little dated and wonder about that. I'd also like a sound decoder definition tool. Now, would I actually pay for any of that? I dunno. I haven't donated but maybe...


Sure I understood, my reply was in zest (or how do you spell that?).

JMRI is far from dated, there are continuous updates and there is a very active "member" forum: [email protected] | Messages

In my opinion it has so many possibilities that even I, after many years of exploring (keeping in mind I still have a full time job and a family ), still discover new functionalities.


----------



## Severn (May 13, 2016)

So I don't really complain because that's best taken to the code. It's more of an observation about what perhaps could be improved. Yet again, shut up or do it is really the right approach.


----------



## Erik84750 (May 2, 2017)

Severn said:


> So I don't really complain because that's best taken to the code. It's more of an observation about what perhaps could be improved. Yet again, shut up or do it is really the right approach.


Hi Severn, about the sound decoder JMRI functionality: it is there too.
JMRI provides programming for about every decoder on the market.

And if there is anything you have doubts or queries about, there always are plenty of very friendly and knowledgeable people on that board to answer your questions within hours, please do not hesitate. I myself am still learning and found that forum a very welcoming place.


----------



## Severn (May 13, 2016)

what i meant was a tool to make a sound decoder configuration file which is an xml file.


----------



## Erik84750 (May 2, 2017)

Hi Severn, JMRI stores decoder configurations in an xml file.


----------



## Severn (May 13, 2016)

I know -- I'm saying a tool to make the XML ... a more user friendly tool/helper, that outputs the file.


----------



## Erik84750 (May 2, 2017)

Apart from JMRI I have no idea. Sorry.
Erik


----------



## Severn (May 13, 2016)

I'm just saying that if there's a feature I think is missing from JMRI it would be a helper tool to create the XML config files. I think that'd be a nice a addition. Right now it appears that people ask for "Does JMRI support XXXX locomotive?" And then maybe a few weeks or even months later, they add the config file for that -- someone on the forum does it, etc.. It seems to be just enough of a "dark art" -- that the average user of JMRI can't approach it. Anyway, in my imagination -- a user friendly tool would allow you to fill in a few fields, tables and so on -- and then spit out the file for you.


----------



## MidwestMikeGT (Jan 4, 2021)

Would you be able to create that table and appropriate schema in Excel and convert it.


----------



## Severn (May 13, 2016)

the schema is here -- *


https://www.jmri.org/xml/schema/decoder-4-15-2.xsd



examples -- Index of /xml/decoders*


----------



## MidwestMikeGT (Jan 4, 2021)

It is quite straightforward yet in some sense, somewhat complex. Great documentation, though. It seems that one might be able to create a table out of Excel so that it might be modified easily. It will take some time but it looks doable. ...and there might be slightly more than a few fields.


----------



## Severn (May 13, 2016)

I'm only saying I think a specific tool would be nice. I'm not saying anyone can't make one with a text editor and little effort. Or various other techniques, etc ...


----------



## MidwestMikeGT (Jan 4, 2021)

Severn said:


> I'm only saying I think a specific tool would be nice. I'm not saying anyone can't make one with a text editor and little effort. Or various other techniques, etc ...


Got it. I understand what you are saying. This is the first time I am look at the schema and tables of JMRI. Someone should create an interface. It would be so much easier for people to modify features to tailor their kit-bashed creations.


----------



## Severn (May 13, 2016)

I have a vague interest and experience in similar but unrelated to jmri's schema. but .... don't really have the time is the problem. i believe i have an old hopefully not defunct gitlab acct with old defunct or at least untouched projects in it also ...


----------

