Introducing DCC++ ---a complete open-source DCC station and interface

Gregg Aug 25, 2015

  1. Jacekts

    Jacekts TrainBoard Member

    20
    7
    2
    Very Much a good point, aiming the information at a single platform like the Arduino motor shield.

    I'm not suggesting to remove or stop development on other driver options, but to have the default setup set to use the Original board that the project started with. I suggest this because people may find the old info first and buy that setup or have it already and be looking for up to date Code.

    Setup the rest as options that need to be edited, but make sure its commented well so its understandable to non-coders.
     
  2. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    252
    167
    8
    I don't disagree at all that a 101 type section is needed to get you up and running fast. Uno and original motor board and serial connection to windows computer.

    Having said that the real beauty of DCC++ is not just that but the fact you can use lots of different motor shields, you can connect boosters, you can have multiple districts, wireless throttles etc. all signicantly cheaper and open source compared to a typical commercial system.

    So while I totally agree the default should be very simple and the original setup. The whole point in my mind is to pull together all the great work that has been done since the original and get that into the code along with great documentation. The tough part with that is you really need a team of like a dozen people and at least 3 to 4 with really advanced coding knowledge to kepp it alive and growing as life happens. Jmri is the perfect example of this and I think we should go for it but we really need to try to make a real go of it or it will continue to be how it is today.

    As I said before I am more then happy to help. I have probably what I would call medium coding skills (meaning I can read a program and know what it's doing, make easy tweaks, etc) but certainly do not know enough to be on level with several on this board. I am more than happy to test, help document,. etc etc but we need a technical group of 3 to 4 committed to it's maintenance in my mind.
     
    cgsathome likes this.
  3. Jacekts

    Jacekts TrainBoard Member

    20
    7
    2
    I don't disagree, and want to see that continue to develop indeed. Merely saying that in a "out of the box" setup it should be the basic, and other features could be coded on by simply adjusting settings in the IDE.

    The basic un-adjusted initial IDE, would lend to a simple way of testing the setup prior to adjusting features.

    Program > wire > test = Work? Yes=Proceed, No= Hardware fault likely. Check wiring > Retest =Work?

    For guys that are not coders, that's a easier go.

    Now different drivers, makes it a little more complicated. Although i guess known drivers(shields) could be added and ALL of them commented out and all that would be needed is to simply remove // and they are set for a simple setup.

    I know a little code but, i think possible less then you Keith. i Can generally get the gist of whats going on unless its wildly complex. This FAR exceeds the "Hello World" serial print lol.
     
  4. Sumner

    Sumner TrainBoard Member

    639
    639
    15
    I'd think this would be a priority now, as getting a team together to do all of the other options will take time. Right now it you could buy an Arduino from someone with the sketch already loaded and the motor shield plugged into the Arduino with the trace cut and the couple jumpers installed the base station would be ready to go.

    They would have a train room dedicated computer running JMRI as soon as they turned it on if they could buy a SD card for a $35 Raspberry Pi computer with Steve Todd's per-configured image on it. By insert the SD card into the PI that had a $21 mouse/keyboard and an under $20 monitor they would be up and running as soon as they turned the power on.

    Add the Arduino base station and for a little over $100 (less if they had the keyboard, mouse, monitor already) and they would have a complete DCC base station with a dedicated computer for it, that all comes up by just turning on one power switch. It is what I have thanks to someone on here pointing me in the direction of DCC++.

    The thing I had going for me was some computer background, so I got through the steps of loading the sketch and getting Todd's JMRI/Pi operating system onto the SD card. There are lots of people out there that are daunted by those steps and even something fairly simple like cutting the trace on the motor shield. If a person without a computer background could get up and running like I detailed above I think you would find hundreds of more people getting into DCC++. Some of those people would go on, learning to code, using different boards and and helping to expand the DCC++ community.

    The key is, make it simple so they only had to make the cable connections between the Arduino and Pi. Only had to put a pre-programmed SD card in the Pi's SD slot and connect it to the monitor and keyboard. Those simple plug and play type connections, which most people are familiar with, would allow them to turn the power on and within seconds they would have a stand alone DCC++ base station with JMRI running on the computer monitor. The ability to program locos right away with Decoder Pro and connect as many phones as they want for wireless throttles all for around $100 with a simple plug and play system very comparable to much more expensive systems. It will work with commercial boosters/circuit breakers or they can build their own. The thing is now the DCC++ community is growing faster, with more members some of whom will branch off and add features for future owners like what you guys are talking about.

    I think the hangup for a lot of new comers to DCC is getting the Arduino/motor shield up and running and getting JMRI onto their computer. With a pre-loaded Arduino with the sketch on it and the SD card for the Pi it is now just a matter of connecting cables that people are familiar with and turning the power on. That is all I do now. Go to the train room and turn the power on and JMRI comes up on the monitor and the base station is providing power to the tracks. Simple as that.

    The next best thing would be simple step-by-step instructions in one place that would detail the steps that I and others have gone through by going to numerous different links, none of which are the complete process in one place. I have the steps on my site at the link in my previous post but it could be much easier/better for someone new who doesn't have a computer background than what is there.

    I see two different document approaches which could both be put in place independently of each other.

    One is the basic I don't know much about computers/electronics and will pay a few bucks more to get a DCC++ system where it is close to plug & play or will pursue a little bit more difficult approach as long as it is well document in a step by step process in one place. This path is for someone who wants to run trains and is not interested at this point in coding and electronic projects.

    The other which can be a separate path at the same time as the one above would be a more here is all the different paths and options that are available with DCC++ if you like exploring the endless possibilities of building a DCC++ system. This path is for the computer/electronics person who will take DCC++ to the next level for the rest of us.

    Sumner
     
    Last edited: Feb 17, 2020
  5. FlightRisk

    FlightRisk TrainBoard Member

    401
    125
    5
    I will follow up with all of you in the other thread. I'm starting with how to organize it all and hoping to reach consensus. We all know that people lose interest or go away for whatever reason and then a project languishes. Hopefully we can create something with enough mass to sustain itself. Having it live on after we are gone with others given access to storage locations, etc. is my hope.
     
  6. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    252
    167
    8
    Sumner if you have the time and inclination to do that (provide a fully functioning dcc++ basestation and motor shield and computer with Jmri) I say knock yourself out. I personally have no desire to order a bunch of stuff configure it, cut traces, test, ship, and give support to others directly but don't disagree there may be a market for it. I just have no desire to be in this business but if you or others do it's open source so go for it.
     
  7. Sumner

    Sumner TrainBoard Member

    639
    639
    15
    Didn't say I wanted to do it ;), I'm retired and have no interest in going back into the computer business, but surprised that no one has done it, wouldn't take that much time to put them together,

    Sumner
     
  8. haba

    haba TrainBoard Member

    70
    30
    6
    Well, I have a fork as well.

    * Did shave off a lot of RAM usage
    * Reworked the whole Register layout (no double buffering any more) to use less than half RAM
    * Made the number of registers configurable (Uno supports now approx 100 with the available RAM)
    * Read number of registers with the <#> command
    * Made JMRI use the <#> command if available
    * Commented out Sensors and EEPROM code to save RAM (can be added in again)
    * Rewrote the Ackdetect code to actually follow what's in the NMRA standard

    Currently my git master is at what I called 1.3.0
    https://github.com/habazut/dcc-ardu/
    and should work with newest JMRI for

    * Running om main
    * Programming with DecoderPro

    It would be good if we could coordinate efforts, especially so that we keep the interface with JMRI consistent. See discussion on the jmri-devel email list.

    On a daily basis, I frequent another forum: https://www.1zu160.net/scripte/forum/forum_show.php?id=993634

    Regards,
    Harald.
     
    Keith Ledbetter likes this.
  9. FlightRisk

    FlightRisk TrainBoard Member

    401
    125
    5
    Would love to. Check out the DCC++ EX GitHub here: https://github.com/DCC-EX

    And our discussions here: https://www.trainboard.com/highball/index.php?posts/1127644/

    I can add you to the developer list on GitHub. We can pull in your fork and try to see how to merge everything. There are PRs years old in Gregg's repo as well as branches he created that have one or two things we might want to add. "Classic" is just Gregg's code fixed to send NMRA spec packets and "BaseStation" is DCC++ EX that we have been moving forward with. Thanks for joining the team! (Assuming you volunteer ;) ) Will bookmark your links
     
  10. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    252
    167
    8
    Welcome Harald, had a quick look and indeed some great work. Hopefully we can join forces here!
     
  11. haba

    haba TrainBoard Member

    70
    30
    6
    It would be nice if someone who has a MEGA could take my code and test if it works.

    Another thing I'd like to know is how long my interrupt routine now takes. If anyone has an idea how to measure that? Maybe turn on/off a HW pin and boot up the scope and have a look. The micros() timer is not usable on the UNO as its underlying HW timer is used for DCC PWM on the prog track and I don't want to put micros() calls into the interrupt routine anyway as I don't know how long _that_ will take.

    Btw, in the inerrupt routine the "busy bit" is not used for anything (only diag) but the "invalid flag" is.

    Regards,
    Harald.
     
  12. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    252
    167
    8
    I'll try to take a look at it tomorrow and test with Mega and original motor shield. I also have a scope I could try to help. Suggest we continue this thread on the thread Flightrisk linked above as there are several others there who can test/look as well.
     
  13. FlightRisk

    FlightRisk TrainBoard Member

    401
    125
    5
    @haba - Harald, Grüße! Ich spreche etwas Deutsch, aber nicht perfekt. Ich habe einige Zeit in Süddeutschland verbracht. (Oder verbrachte zeit in Süddeutschland?) (Weil im Schönbuch)

    I will try to practice the language again by reading your forum with one window in german and one in english ;) Look forward to seeing you over on the DCC++ 2020 thread.
     
  14. kmcsjr

    kmcsjr TrainBoard Member

    1,702
    58
    30
    I like to blame these things on autocorrupt. I believe I coined the word and want it to be adopted as a real word meaning - what autocorrect really does. Esp when taking a perfectly good word and replacing it with a random word.


    Sent from my iPad using Tapatalk
     
    FlightRisk likes this.
  15. rva1945

    rva1945 TrainBoard Member

    111
    39
    7
    What a successful project this DCC++...I've been using it for years. I added a few mods to the original code because I send string commands for moving the servos that drive the turnouts (no stationary decoders in my layout). I'm using Processing where I drew the layout and send the string commands to the locos and for the turnouts. THANKS Sir!
     
    Jimbo20 and FlightRisk like this.
  16. ardsuppi

    ardsuppi TrainBoard Member

    24
    8
    2
    ...and more...

    Hi there. It would be very nice if in terms of making DCC++ more stable and efficient, different forks and mods efforts were unified under a single git repository project. In this manner, users like me could contribute with tests, fix, and feature reqs within 1 area of discussion, not much more.

    Ciro
     
  17. FlightRisk

    FlightRisk TrainBoard Member

    401
    125
    5
    We have tried to coordinate everything here. This is the largest group of people now regarding DCC++ and we have been moving forward. The DCC-EX GitHub is the one we are asking everyone to work from. I was asked about a groups.io message board and would like input on that.

    We can't force people to not go off on their own and have their own fork. Egos get involved or people decide they want to go in a different direction. It would be nice if we could handle this like JMRI does where things are coordinated, voted on and implemented with help from more than one person.

    We should have other forks or branches here. It is possible to keep the same basic codeset and features, while implementing something different like a new SBC that requires too many changes for the hardware. So feel free to offer ideas here. DCC++ Update Project 2020
     
    Last edited: Apr 26, 2020
    Sumner likes this.
  18. ardsuppi

    ardsuppi TrainBoard Member

    24
    8
    2
    Posted on DCC-EX software thread without answers. Now I re post here, maybe anyone reads more this thread.

    Hi all, I know that JMRI is the "preferred" controlling software, but as Rocrail also has implemented support for DCC++ base station, and I'm one of the thousands Rocrail users. here are my results of DCC++EX testings.

    So I downloaded the sketch and compiled/transferred on ArduinoUno/ArduinoMotorshield
    Launched Rocrail loading my test workspace configured for DCC++
    No OK! response from serial comm
    In the rocrail log (trace) file, got these lines about controller:

    ...
    20200429.091226.061 r9999I main OControl 2842 devices: ""
    20200429.091226.062 r9999I main OControl 2321 initDigInts lib=[dccpp] iid=[DCC++]
    20200429.091226.063 r9999I main OLib 0038 rocs_lib_load OK [C:\Users\Suppi\AppData\Local\Programs\Rocrail\dccpp.dll]
    20200429.091226.063 r9999I main OLib 0052 rocs_lib_getProc OK [C:\Users\Suppi\AppData\Local\Programs\Rocrail\dccpp.dll:rocGetDigInt]
    20200429.091226.064 r9999I 0000020C ODCCPP 1237 ----------------------------------------
    20200429.091226.064 r9999I tick0266 OSystem 0103 Ticker thread has started.
    20200429.091226.064 r9999I 0000020C ODCCPP 1238 DCC++ 2.1.0
    20200429.091226.065 r9999I 0000020C ODCCPP 1239 IID : DCC++
    20200429.091226.065 r9999I 0000020C ODCCPP 1240 nr.slots : 12
    20200429.091226.066 r9999I 0000020C ODCCPP 1241 sensor off delay: 0
    20200429.091226.066 r9999I 0000020C ODCCPP 1242 sublib : serial
    20200429.091226.066 r9999I 0000020C ODCCPP 0092 device : com4
    20200429.091226.067 r9999I 0000020C ODCCPP 1262 ----------------------------------------
    20200429.091226.067 r9999c usbreade ODCCPP 0019 DCC++ USB reader started.
    20200429.091226.067 r9999I main OControl 2388 send sensor list to digint...
    20200429.091226.068 r9999c dccpprea ODCCPP 1167 DCC++ reader started.
    20200429.091226.068 r9999c dccppque ODCCPP 1093 DCC++ Queue writer started.
    20200429.091226.071 r9999I main OControl 2407 initDigInts OK
    20200429.091226.072 r9999I main OPowerMa 0601 Power Manager instantiated.
    20200429.091226.072 r9999I main OControl 0188 Init short circuit sensor...
    ...
    20200429.091226.181 r9999I usbreade OSerial 0085 Opening serial[com4] [return code=0] [0] [OK]
    20200429.091226.181 r9999I usbreade OSerial 0106 blocking[1] directIO[0]
    ...

    On the practical side, no power on/off to track/prog on motor shield, so no loco controls at all.

    Maybe communication strings are mostly changed with DCC++EX. so there is no compatibility with DCC++ supported software other than JMRI.
     
  19. FlightRisk

    FlightRisk TrainBoard Member

    401
    125
    5
    Sorry, I didn't realize there was a third thread, the Update 2020 thread, the documents thread and the DCC++ EX Software thread for support issues. We will answer you over there. Thanks!
     
  20. ardsuppi

    ardsuppi TrainBoard Member

    24
    8
    2

Share This Page