# I built the dcc++ open source base station and it works!



## Severn (May 13, 2016)

A couple of years ago I stumbled upon the open source project dcc++. it's on github. the base station marries an arduino and motor control board and software to produce dcc command code signalling on the track.
well I assembled the pieces a few weeks back but just got it all together and the track out etc...
and with a bit of careful soldering and compiling and upload of code, I can report ... it works!

https://github.com/DccPlusPlus/BaseStation/wiki/What-is-DCC--Plus-Plus


----------



## Shdwdrgn (Dec 23, 2014)

They also have a forum on Trainboard where you can get a lot more info about the project. Also note under that group is another group for DCC++ESP32, which adds wifi support so you can run your locos from a cell phone or other handy device. That's where I started out because 1) I really prefer the ESP32 over the arduino anyway, and 2) I didn't have any sort of DCC equipment to start with and throttles would have cost me more than the entire cost of my DCC++ setup including the loco decoders.

Check here under both the Technical group and the DCC group, there have been previous discussions about DCC++.


----------



## Severn (May 13, 2016)

I noticed the trainboard reference. I did briefly look at this site but I just wanted to do my own thing. It turned out be easy and I had no problems but I already had familiarity with arduino, and I'd used the motor controller on something else before as well.

I meant to take some pictures of it all but somehow it's not happened.

Generally speaking I'm using the traditional arduino uno with the headers. It came this way in the box. For the controller, the pololu mc33926 I think it is... that comes with headers so you have to solder those on.

Then stack them together.

I also soldered on a header to the front control lines so I just jumpered as described on the dcc++ webpage but no soldering to the control lines. Cutting the traces was the most "harrowing" part of it but I manged it without slicing more than needed or cutting myself. I had to use a magnifying glass to see it though.

Finally compiling the code, you have to set the value in the config header to tell the compiler which motor controller board you are using -- so I had to do that 2 times, to get the right value there which I only saw buried in wiki area after the fact.

But once that uploaded and I connected my power supply and the wires to the tracks -- I was able to fire up my test engines.

Sending commands is primitive through the serial interface of the ardiuno but it works.

The author includes a controller software package which I only glanced at, and there's others -- jmri being often mentioned but I haven't tried that either.

Wifi would be of interest to me or blue tooth "serial boards" could be added I think with relative ease although I've never done this.

I have one of them from sparkfun, but I forget the name of it and I yet have to try it.

Still, I'm ok with the serial line or laptop interface for experimentation for now.


----------



## Shdwdrgn (Dec 23, 2014)

The Trainboard link is the home of the people writing the software, so if you need to do any troubleshooting that should be your first stop. That's why I mentioned it.

The ESP32 also has a bluetooth radio onboard, but I don't think any of the software uses that (yet). Basically the ESP provides its own web service, so it gives you a throttle (plus other controls like for turnouts) in the form of a web page that you just load up in any browser on your phone. In my case, I'm using a raspberry pi as a WAP to create a local isolated wifi network for my train, and the USB connection to the ESP32 provides power plus an easy way to send code updates to the ESP if I want to upgrade. DCC++ESP32, since it is already network-aware, also provides a port you can connect to with telnet to send commands directly... I want to use this feature to write code on the RPi to control things over DCC.

My own setup uses a BTS7960 H-bridge driver (up to 43 amps but it only controls one channel). I have a 16V power supply and include a 5V 5A regulator to send power out to other arduinos -- currently that is one which drives servo motors for my turnouts. I've been working on a model for a 3D-printed box to mount everything in, but haven't had a chance to move everything from the proto board to a through-hold board.

JMRI is a very popular package which apparently handles a lot of automation among other things, but I haven't actually looked at it myself yet. Too many projects, too little time...


----------



## Severn (May 13, 2016)

Back when I first bought a PI and the version of the mc33926 for it from pololu. I was fiddling around with making DC motors turn. Anyway, one wonders if the PI itself couldn't be hammered into making the PWM signalling for the dcc control box. then you've have linux, anything that runs on it and wifi, etc...


----------



## tankist (Jun 11, 2009)

Severn said:


> ...
> Then stack them together.


Well, yes, that's how arduino and it's shields work - connect together with proprietary pin pattern.

I would however listen to Shdwdrgn's note. As he said on other thread (and I really liked that comment) "try to look outside of the shields".

With author of original DCC++ MIA active development happens on the ESP32 branch and as I see it ESP is where it's at today. Works great with IBT2 motor driver


----------



## tankist (Jun 11, 2009)

Severn said:


> Anyway, one wonders if the PI itself couldn't be hammered into making the PWM signalling for the dcc control box. then you've have linux, anything that runs on it and wifi, etc...


Yes of course it can, PI can have Arduino code running in emulator. But I really don't see that much benefit to it. I think it comes down to what is it that you want to do on the PI. 
For me PI is going to provide route and signal logic and gateway for Android based throttles. I really Like the clear separation of DCC signal generation on a separate device with clean serial connectivity between the two.

Good luck


----------



## Severn (May 13, 2016)

I don't think I'd run the arduino dcc controller code in an emulator, while I don't know the timing needs exactly, I would guess it would be hard to get it to work that way or even user space. but i could be wrong. anyway i don't really have a stick in the game. Connecting lots of devices around the layout that do things though is an interesting problem. Lionel solves that with a serial bus called "LCS". I saw somewhere a similarly named standard? possibly from the same folks that brought DCC uses the CAN bus. I'm sure there are those that want everything to be wireless, etc... all good things I suppose.

I guess that's the beauty of it at least in the HO land -- you can pretty much do whatever you want really and many people are... eventually folks will like an approach and perhaps that will become a standard or at least a popular open source approach with many adopters.

i almost prefer that to the committee approach myself.

[ i wasn't aware the original developer of dcc++ was not longer involved. i'm glad i downloaded the whole thing, although i've yet to even look at the code or anything... ]


----------



## tankist (Jun 11, 2009)

Severn said:


> I don't think I'd run the arduino dcc controller code in an emulator, while I don't know the timing needs exactly, I would guess it would be hard to get it to work that way or even user space. but i could be wrong. anyway i don't really have a stick in the game. Connecting lots of devices around the layout that do things though is an interesting problem. Lionel solves that with a serial bus called "LCS". I saw somewhere a similarly named standard? possibly from the same folks that brought DCC uses the CAN bus. I'm sure there are those that want everything to be wireless, etc... all good things I suppose.


I don't see timings as concerns, but perhaps we attributing different meaning to that word. My concern would be overhead.
Running code in emulator will make the PI see as if there is Arduino device loaded with DCC++ , exposed PI I/O pins ,connected to virtual serial port, JMRI probably will be able to connect to that virtual port. While the RPi packs quite a computing punch for the size with all the JMRI services running I'm not sure it's a good idea to load it with even more tasks . Not sure just how heavy is the Arduino emulator either. 


The open source CAN based connectivity solution you described is probably OpenLCB. Discussions about it happened on trainboard as well.

Good luck.


----------



## Shdwdrgn (Dec 23, 2014)

I have seen a couple projects where a Pi was used to generate the DCC signal, but there are some strict timing requirements and if you're trying to get the Pi to multitask other things at the same time... yeah it could get messy. As Tankist said, I also like having a clear separation of tasks. The nice thing about the ESP32 is that not only is the clock speed 10x faster than an arduino, but it is also dual-core. However it is not a multitasking environment so everything has to be accounted for in the software and interrupts are treated as hard breaks to ensure the signal timing remains consistent. I feel like that makes it more reliable than a Pi for this sort of application.

I enjoy working with the component boards individually rather than plugging a bunch of modules together. For one thing, the setup ends up being smaller, and you can pick components that fit your actual needs (do I actually need to spend a lot of money on a high-amperage board if I'm only running two trains on my layout?). It also allows you to be more creative with fitting everything into limited spaces. And of course using DCC++ over a commercial offering means not only are there frequent updates and bug fixes from the community, but I can also get into it and add my own code if I want to do something a bit different.


----------



## wvgca (Jan 21, 2013)

I set one up a few years ago, worked good ...I also did a high power pcb for the 43 ampere driver for that, and a stand alone booster that can be used for DCC++, and standard DCC ..
Haven't looked at it for a few years though ..


----------



## Severn (May 13, 2016)

"I set one up a few years ago, worked good " 

That was really the intent of the original post -- it worked with ease. very impressed. I should add pics. I'm getting to it.

As for PI or the other approaches. I'm not advocating, it was more of a passing thought. For example, I have the "PI version" of the Pololu motor controller.

This or similar: https://www.pololu.com/product/2756

I was using for it for something else, I have the software that goes with it or they provide as an example. I have some of my own but its not much there.

Anyway I could you know, look into and try it. Try to crib from the arduino code and make it work.

The context switching could be an issue for example, right in the middle of spitting out the encoding for a dcc command -- perhaps your process gets switched -- and one suspects this could be an issue, the command might be lost etc...

But that would all have to be ferreted out and there could be ways to address it ... 

Having said all that I was not advocating this approach although I like the idea of the base station being a linux box overall, it was simply an idea mainly because I have the parts laying around.

The ESP version also sounds great to me -- the board has a lot of connections on it (a can bus too) and could be a step up.

I'm certainly not against the work or anything like that.

What I want to look at now myself though is the operational interface ... something that will run on a desktop computer first. 

I don't mind sending the text strings but it's only good enough for playing around.


----------



## Shdwdrgn (Dec 23, 2014)

I'm actually surprised more people don't try this approach. I mean, I went into DCC++ with absolutely no experience of exactly what DCC was about (my last train was taken down in 1983 so I've missed a lot), nor any existing equipment to test out the setup and see if it was even working. And yet I still managed to hook everything up with ease, then put together a second unit (an arduino decoder) and get that piece also working with the help of folks online who aided in the troubleshooting. Model railroading in itself is a very hands-on DIY hobby, so the arduino approach to DCC seems like it would be embraced by more people. If nothing else, the cost alone scared me away from commercial units.


----------



## Severn (May 13, 2016)

Yeah, I'm right there. I had some HO when I was kid, found it in a box. Swapped out the wheels and couplers on all the cars. I bought a new working but reasonably low priced engine from a local dealer. Runs pretty good with lots of neat sounds with just the simple transformer operation but I really wanted to see or hear the DCC thing. Little complicated but I have another HO engine that I know has some kind of esu decoder in it, that's a friends really-- but I wanted to hear that too.
Anyway I've had the pieces sitting around for months, well a few years really in some cases and I just got around to it, put the track out [some bachmann which is kinda blah], tested what i had and really wanted to try the DCC aspects.
As for why more people don't try it -- well it helps to know a little about arduino, a little about software, a little about soldering... a little hands pre-existing goes a long way.
The hardest part to me is cutting the traces. I guess it's cheaper but why they couldn't just build the things with jumpers instead would help.
Likewise, I know it's not that hard to solder yet there's something of an art to it -- but pololu how about some pre-build boards with headers and the power connectors already soldered on?
After you do that, you have to put the jumpers in and most people don't have them -- of course one can just use little bits of wire but the prebuilt jumpers are a big help -- so you have to have those too.
My guess then -- to many people it probably seems insurmountably fiddly, error prone and probably not worth the build up kind of project.


----------



## gregc (Apr 25, 2015)

Severn said:


> My guess then -- to many people it probably seems insurmountably fiddly, error prone and probably not worth the build up kind of project.


what controller do you use as a throttle?


----------



## Severn (May 13, 2016)

Just the serial interface. I'm searching for a solution there. I looked at the JMRI throttle, just the gallery. While I may use it, it's not what I want. In fact, somewhere along the lines I realized DCC doesn't define a "horn command" but just the wire encoding. The rest is vendor specific or at least common practice. That would explain why all the DCC controllers (throttles) have these "F" function buttons! Duh. [at least this what i think is correct right now]

Anyway you see I actually have quite a bit of O stuff. It's a long story but the gist is I ended up with both some work here:

http://www.silogic.com/trains/RTC_Running.html

and then here:

http://www.lionel.com/lcs/

And I have some knowledge of their commands (more on the lionel side) but they define a set of specific commands -- a horn command, a speed step command, etc... [and a wire encoding]

Anyway given that I was actually looking for something more abstract than "F10" or whatever in a controller that is throttle... 

I did some work with author of the RTC above few years back, I had thought of porting it but there are some issues there and it's not really what I want to be working on either. 

Further it appears more complicated that I'd imagined, not just the port which I think could be easy but because as I see it the so called function codes would need to be mapped to the various existing gui widgets existing... but in a flexible way.

And that's all do-able but you'd want a configuration wizard and blah blah, blah... that's a lot of work for a non-paying gig!

So I'm flailing about right now...


----------



## gregc (Apr 25, 2015)

Severn said:


> Just the serial interface.


maybe that's why more people aren't interested. It's more that knowing something about Arduino or cutting traces.

they want a complete solution: base-station, booster and controller(s).


----------



## Severn (May 13, 2016)

well there's this but again for the DIYer type:

https://www.opendcc.de/elektronik/throttle/mft_e.html

Thought about it a little but I think I want to look at more software first. The DCC++ also has a operation application which I didn't look at closely yet either.

I guess I'd like to get away from the F-codes... 

Having said that, I always felt the Lionel and MTH hand controllers were ... terrible. I could never remember anything beyond the basics.


----------



## gregc (Apr 25, 2015)

Severn said:


> Having said that, I always felt the Lionel and MTH hand controllers were ... terrible. I could never remember anything beyond the basics.


"User friendly isn't powerful". where's the green button?

my NCE throttle.


----------



## Severn (May 13, 2016)

It's me really. I think they were fine for most. I just for the life of me could not remember the 3 letters on the MTH mean "this"... and I never bothered to try too hard with the lionel controller. To be fair I just about 90% of the time simply made the thing go around in circles, and tooted the horn. [hence remembering than F12 or whatever is you know the rear lights on this engine but not that one is never happening in my brain!]

But and this is a big attraction to the DCC++ wanted to know how it works and wanted something more to the metal so to speak. In way it's perfect. I do have a scope, I don't know how to use it very well but I could even -- egag look at the signals! 

Good luck with that with the lionel [or mth even worse!] -- although I bought a software radio dongle thing that read the low frequency from the base ... yet there's still a pile of proprietary encoding to get through there.

Anyway ... I just like the idea of turning on the LEDs when I want or making them flicker, which may or may not be be prototypical, but I don't care...

[oh hey, that's awesome!!! -- http://www.pacificsouthern.org/Members/Gregc/NceCab/nceCab.html]


----------



## wvgca (Jan 21, 2013)

You may want to consider the BTS7960 controller for higher power applications ... it's about 12$ compared to 8$ for the 2amp L298 version ..
For a controller I use the serial port [clunky] on cheap pc, for better [much better] I do recommend JMRI [that program is free],controller, again on a cheap PC or laptop, it's just easier than building a controller ..
As far as F keys are concerned, it's just a 'feature' of DCC, lol 



It's just a different way of getting there, easier on the pocketbook, but more head scratching intensive ..


----------



## gregc (Apr 25, 2015)

wvgca said:


> You may want to consider the BTS7960 controller for higher power applications


gotta wonder how many locomotives can be run and how much power is needed if they are all controlled via a single (?) PC (serial interface).


----------



## Shdwdrgn (Dec 23, 2014)

You could always build a DCC++ arduino throttle, since you're already familiar with the components. As for the motor controller board, the need to cut the traces is specifically because of the larger voltages being used for DCC which would fry the arduino. I have seen a version of the board being sold on TrainBoard which was specifically built for DCC++ operation, so no need to cut anything, just plug in the board.

The ESP version of DCC++ uses a standard HTML web page to provide its interface, so if you know how to design web pages you could custom-design your own throttle and specifically label some of the function buttons as horn, ditch lights, or whatever.


----------



## Shdwdrgn (Dec 23, 2014)

@wvgca -- I actually got my BTS7960 for about $9 off ebay. They're pretty common now I think. And for smaller layout you don't even need the heatsink.

@gregc -- The power doesn't go through the serial interface. DCC++ has its own text-based command set used over serial or wifi interfaces, but those are interpreted and pushed onto the rails using DCC encoding. The rails are where you push all the amperage to, not the serial interface. And I believe they've pushed the software up to 512 locomotives now? The only real limitation is DCC itself and how many bits it can push across the rails.


----------



## wvgca (Jan 21, 2013)

gregc said:


> gotta wonder how many locomotives can be run and how much power is needed if they are all controlled via a single (?) PC (serial interface).



the PC serial interface or JMRI is just for control ...not power ..
the power is supplied by seperate cards or modules on the DCC interface .. in the case of the BTS7960 , well, it can go to 43 amps with additional cooling and heatsinks ..
When the BTS7960 is used as a booster, it is usually set to between 5 amperes and 10 amperes


----------



## gregc (Apr 25, 2015)

Shdwdrgn said:


> The power doesn't go through the serial interface.


of course

but how many locomotives can you realistically control thru a single "user" interface?


----------



## wvgca (Jan 21, 2013)

gregc said:


> of course
> 
> but how many locomotives can you realistically control thru a single "user" interface?





dunno.. never tried to find out ..
and 'realisically' may mean something different to you than it does to me


----------



## Shdwdrgn (Dec 23, 2014)

*Realistically* you wouldn't be manually typing in commands to run your trains. That interface is meant to provide information about the current status of things or be used by a script that is reacting to events. However considering even on a low-end arduino you can usually get a serial connection of at least 115200kbps, I'm pretty sure it could easily handle more traffic than DCC on the rails can, so the limitation here is still DCC itself and not any of the other hardware.


----------



## gregc (Apr 25, 2015)

Shdwdrgn said:


> However considering even on a low-end arduino you can usually get a serial connection of at least 115200kbps, I'm pretty sure it could easily handle more traffic than DCC on the rails can, so the limitation here is still DCC itself and not any of the other hardware.


i'm asking about usability, the user interface ...

My understanding is that the pico-processors (pic) used in NCE or Digitrax command stations and controllers are the equivalent of the arduino (atmel) processor.

assuming the DCC++ arduino processor generates the DCC packets, there should be next to nothing on the PC serial interface to the arduino once commands are sent to tell the command station the speed/direction of all locomotive.

even from the dcc perspective, no additional DCC packets are required once the decoder receives a speed/direction packet. My understanding is the command station repeatedly sends DCC packet as often as it can, immediately updating any loco that it receives a new command from a controller.

of course, a decoder needs to receive a dcc packet to get the loco going again if the loco loses power (hence why the DCC packets are repeatedly sent.

in other words, DCC requires very little MIPs and bandwdith.


... but realistically, most layouts are operated with multiple operators, each having a controller, hence the need for multiple boosters and power districts.

unless you're doing automation or somehow able to run many locomotives w/o actively controlling them because they're on non-intersecting loops, how much power do you need to realistically operate your layout. (maybe you have a powered A-B-A unit)

it seems to me that DCC++ is well suited for the modeler trying to save money and having a relatively small layout and a need a couple locos.

i didn't see code for a polled multi-endpoint serial interface (e.g. NCE cabbus) when I looked over the DCC++ code.


----------



## Severn (May 13, 2016)

A pic of my dcc++... Attached.


----------



## wvgca (Jan 21, 2013)

looks good!


----------

