DCC++ Update Project 2020

FlightRisk Feb 16, 2020

  1. jbsorocaba

    jbsorocaba TrainBoard Member

    43
    33
    9
    IMHO I think that the best option is to use a arduino Mega with wifi on board. Mega is more powerfull then Uno and you will have a lot of IOs. With Uno you will be restrict for others connections.This way you will eliminate the use of ethernet shield and can connect to a computer by wireless. For a simple computer for JMRI or Rocrail ( all free ) you can use a Raspberry pi 3b+ that is enought.
     
  2. Roger Beschizza

    Roger Beschizza TrainBoard Member

    56
    8
    3
    I agree [he says cheekily - with very limited knowledge of these things, but from what I have read] that the Mega is a better board for future-proofing the functionality but I still think we ought to start simple.

    I think we also need to have some method of deciding what we are going to go with - and suggest that we select a lead person to make decisions, and personally I think that should be someone with a techie/coding background. How should we do that so that we make progress?

    R-
     
  3. Atani

    Atani TrainBoard Member

    966
    638
    17
    Sorry it should be <s><c>. This is what JMRI will send every ~30sec. The two <X> at the end are for outputs and turnouts stored/known by DCC++. Sensors are not printed from "<s>" but would be by "<Q>" (possibly by <S> but I don't remember off hand)

    DCC++ by default will monitor A0 (A) and A1 (B) and report the current draw as a 0-1023 value which is the raw ADC value. Only A0 (A) will be reported to JMRI by default. A1 (B) is used for PROG ACK sensing only.
     
    FlightRisk likes this.
  4. FlightRisk

    FlightRisk TrainBoard Member

    189
    62
    4
    @Roger Beschizza Well, since I started this project, I can be team lead, but happy to turn over the reigns to anyone who wants it. Roger, can you send me an invite to the Trello board you created? I think it is private and therefore one must get an invite. I am "flightrisk" over there too.

    @jbsorocaba I agree with you about the Mega though I am thinking that is a more advanced solution. The networking issues themselves add a layer of complexity and a point of failure. How about a "starter set" and a "professional pack" and "upgrade packs" or "options/accessories". An UNO connected with a cable to a laptop or Pi is the starter set. A WiFi Mega with a tablet or laptop or Pi is another. Keep thinking out loud and visualizing how this would work. How do we separate out where things diverge because all of the options? If the Pi is the "standard", then options would be to use your laptop or computer or use a touchscreen tablet (which is actually a pretty cool option). With JMRI (and maybe other configurations) your phone is your throttle. So that is an option or add/on, but could also be the main interface into the base station with no Pi! The Trello board can help us organize. BTW, Trello is very similar to the Github project boards. Those have the benefit of linking to the code and the rest of Github. It might be missing other things however. I'll look at both today.

    Everyone, any opinions about where Gregg's controller sits in the mix? Here is video 1 or 4 that covers it: https://steamtraininfo.com/for-modelers/model-train-control/dccplusplus. I think I'll run through the install from scratch and see how complicated that is. Both JMRI and DCC++ controller are more involved than a simple throttle.
     
    Sumner likes this.
  5. Roger Beschizza

    Roger Beschizza TrainBoard Member

    56
    8
    3
    Should be with you shortly. R-
     
  6. Sumner

    Sumner TrainBoard Member

    408
    339
    8
    With Steve's Raspberry Pi image you have WiFi ready to go for phone throttles.

    https://mstevetodd.com/rpi

    From his site:
    --------------------------------------------------------------------------
    I have built an image file which contains all software and config needed to autostart JMRI PanelPro on the RPi, as an access point, with WiThrottle Server, Web Server and LoconetOverTCP (or JMRI Simple) server included. Also included is remote access to the RPi via ssh (command line) and to the RPi "desktop" via VNCServer (at port ::5900)
    Download the latest image file [here] (1.6Gb zip, updated February 11, 2020) or a previous version [here] (1.8Gb zip, updated December 17, 2019)
    The image features:

    • AutoIdentify of attached hardware (Locobuffer-USB, PR3, SPROG, LENZ USB, NCE Serial, NCE USB (Note 1), DCC++, EasyDCC Serial, MERG USB, MRC Prodigy)
    • Autostart of JMRI PanelPro with WiThrottle and Web Server.
    • Creates network access point for device connection, or can be plugged into existing network
    • You can upload roster files and icons via the JMRI web server.
    • Web server extensions for restart/shutdown of the RPi, viewing the session.log, viewing JMRI tables, and more.
    • Access to GUI desktop via attached monitor or remotely via VNC client
    • Support for defining GPIO Pins as JMRI Sensors and Turnouts
    • Latest Raspbian Buster image
    • Secure file access via SCP or Windows file share.
    ------------------------------------------------------

    He has done a lot of work and I haven't even begin to explore all that his image does. It sure made it easy for me to get up and running by only having to put it on a SD card and inserting it into the Pi. At that point I was totally new to Arduino's, DCC++ and JMRI and it made it very easy to get up and running after configuring the Arduino/Shield. For some of you that are in the project and haven't used it I'd suggest at least doing the download and giving it a try and see what you think and while doing it consider yourself as new to the whole DCC++ experience.

    I agree about leaving the Mega out of the base setup. Maybe the base is computer/JMRI and Std Arduino/Shield. I'd for sure put the Pi with Steve's image download and the Std Arduino/Shield right after it as it is an easy approach and gives you a lot in my estimation as a starting point into DCC++.

    Roger get a shield and try going this route along with one of the videos on configuring the Arduino/Shield and let us know what you think and where the documentation needs to go to help someone that is a first time user. Sometimes it is hard once someone has something down to remember where the confusing parts were on the first go around,

    Sumner
     
  7. FlightRisk

    FlightRisk TrainBoard Member

    189
    62
    4
    I agree that this image is great. It is one of the things I played with after I set it up on a Pi myself from scratch. And it is probably the best way to get started with a setup if you want to use JMRI. And as a point for discussion (not arguing or disagreeing) what is the least complicated way to start? Just read Steve's discussion copied above:

    <quote>JMRI PanelPro on the RPi, as an access point, with WiThrottle Server, Web Server and LoconetOverTCP (or JMRI Simple) server included. Also included is remote access to the RPi via ssh (command line) and to the RPi "desktop" via VNCServer (at port ::5900)...</quote>

    Just that is enough to make your head explode ;) That said, it still may be the way to go with proper pre-configuration and instructions.

    Who are the people that would want DCC++? The main three that come to mind for me are tinkerers, experienced folks who want to upgrade to a DCC system, and people concerned with budget. Perhaps you could argue the rich feature set might attract some too. What is/are the market(s) to you?

    A tinkerer wants to do it themselves and "play", so what you give them doesn't matter much. They might even prefer to do it all themselves from our instructions. Flashing sdCards and the smell of burning solder flux gives them joy. Pros want the advanced features. Some of the budget folks may want as turnkey a system as possible. That brings me back to the question; Is there an option just using a cell phone, with little or no configuration, to be up and running with basic features? Frankly, I'm happy just running 2 or 3 trains in circles ;) I want to add control for switches and use my extra Mega pins to control things, but mostly I don't need a lot of the extra features. While options are great for expandability, they get in the way in the beginning.

    Think of the Lionel Lionchief system, you put power on the rails, turn on your handheld wireless controller, and push a button to make a bell ring. Turn a knob and the train moves. All bluetooth. I get that if people want that, they can go buy it, but a good out of box experience, and ease of configuration and use is what will get people talking about this solution and actually using it. But maybe we are a different market and Atani's board fills that "Lionchief" space (and the some). I don't know.

    Back to the Pi; your offer to sell the pre-imaged cards is great. We need to promote that. I don't know how to make money selling this and be cost competitive if we can't buy boards at a discount, but someone really should have a "kits". A pre-flashed Ardino something with wifi/bluetooth, a motorboard with the traces cut and jumpers installed and already piggybacked on the Arduino, and a Pi with the image on the card and card already in the slot. Now you connect up what's left, install a throttle on your phone and it will find your train and run it. You want to go further? Get a monitor, keyboard and mouse for the Pi and use it as a computer, or use it as a server and get a tablet and VNC into the desktop of the Pi. More discussion please :) Also, I wonder if Adafruit or Sparkfun could be convinced to offer a kit with all the parts including a flashed Arduino and things like the barrel to terminal connector adapter.
     
    Sumner likes this.
  8. Roger Beschizza

    Roger Beschizza TrainBoard Member

    56
    8
    3
    On it's way - from Italy - 5 days. R-
     
  9. FlightRisk

    FlightRisk TrainBoard Member

    189
    62
    4
    @Roger Beschizza The Trella board looks great! I hope we can coordinate there and fill it out and start putting together the guides.
     
  10. RoadRailer

    RoadRailer TrainBoard Member

    34
    11
    2
    Great discussion here! If I may, I'll add a few thoughts based on experiences I've had…

    Regarding the various branches of DCC++, I had posted an earlier analysis in a thread in the DCC++ subforum here. It appeared to me that the that the bjorniuppsala fork (which itself was forked from the atanisoft fork) was among the most active forks. This fork also incorporated additional updates to use PlatformIO as the IDE.

    As to a particular device, my personal inclination is towards the Mega over the Uno
    1. One less decision posed to unacclimated or less technical users
    2. Something for the project to grow into over time (i.e. the project doesn't need to try to support all of Mega's capabilities at the outset but can add additional capabilities over time without having to later change hardware. From a development commitment perspective, the project can start out supporting Uno-level capabilities, but by specifying Mega as the base hardware, the project can more easily grow into the more advanced capabilities without having to worry as much about leaving users behind and/or maintaining separate capability sets—thus accommodating simpler long-term maintenance of the project.)
    I don't have as much to add regarding a motor shield but agree with the approach of trying to keep things simple for end users.

    I do concur with the ease of use of the M. Steve Todd image of Raspberry Pi. My only caveat with that image is that—because JMRI is not installed as a package (the installation setup is manual)—"apt-get" does not update JMRI; the JMRI install needs to be updated manually. One could of course re-flash an update image, as M. Steve Todd does keep the images current, but that would obviously overwrite any configuration or settings changes a user might have made.

    Additionally, the M. Steve Todd image for Raspberry Pi is already setup to detect and use DCC++ if connected. Furthermore, the image is also setup to enable use of both web-based and WiThrottle-based wireless throttles (e.g. using smartphones, tables, or computers). Certainly a computer-based JMRI install could be configured to support these capabilities, but the M. Steve Todd image for JMRI on Raspberry Pi provides all of this without requiring any additional configuration on the part of the end user. (As @Mani alluded to earlier, while powerful, JMRI doesn't always seem to have the most intuitive user interface.)

    In addition to JMRI's built-in web-based throttle, software based throttles include the following:
    In addition to the above, there is also a collection of cross-platform (Windows 10, iOS, and Android) application throttle applications that interface via JMRI's web server rather than the WiThrottle server included in JMRI. (Both of these servers are enabled by default in the M. Steve Todd image.)

    Regarding GitHub, to help minimize risk from future situations where a key person might again become unavailable, I would suggest considering setting up an "organization" in GitHub. In turn, individual project repositories can then be associated with the organization, rather than someone's individual GitHub site. (Example: github.com/BrickBot [which contains a growing collection of software for the Lego MindStorms RCX] is a GitHub organization site I created and not my personal GitHub site. As an org site, it is thus not dependent on my maintaining my personal GitHub site.)
     
    John W Zerbe and Keith Ledbetter like this.
  11. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    237
    152
    8
    ya agreed. What we are getting into is the curse of open source and the flexibility. I agree we need to document all the possibilities they just need to be neatly organized. Maybe the suggestion works for the branches.

    Budget minded - Uno Clone, motor shield clone, serial connection to PC running JMRI

    Easiest - Pi with downloaded image, orginial UNo, original motor board, JMRI on Pi

    Most flexible/expandable - something with Mega

    Highest power output - one of the high power boards or a booster

    etc. Just a thought. Honestly documenting each one is not that much incremental time. I realize I'm contradicting myself a bit and I do still think the first should be quick start that is the easiest/cheapest. Complexity quickly kills adoption but is also what provides the flexibility that attracts a lot of us.

    The code is by far more important then these parts in my mind, not that the hardware setup isn't important but the code supporting it is the living breathing beast that has to be tamed.

    And @FlightRisk I do think probably makes sense for you to own the Github. I would suggest and you can take or leave but you clone the existing and have one for yourself and then one where you give several us us permission to edit the WIKI etc.

    One other thing we need to include is there is a DCC++ library in case you didn't know developed by a Frenchman @Trusty who is still active and I think should be documented as another link. It's a really nice piece of code. https://github.com/Locoduino/DCCpp and actively supported and probably truly is the easiest once you download the library as the sketch is tiny.
     
    Sumner likes this.
  12. Sumner

    Sumner TrainBoard Member

    408
    339
    8
    I've been in contact with Steve and he said he has no problem with us selling pre-loaded SD cards and giving the small profit of a couple bucks to TrainBoard or some other entity such as the JMRI group (I just did a PayPal donation to them myself after finding the link).

    He wanted to make sure though to give clear attribution that the software is open source provided by the Raspberry Pi Foundation and by JMRI, and that we are only providing a card and a service to load it.

    Again I'm welling to make some of the cards and ship them but not interested in doing hundreds of them if this takes off which I think it has the potential to do. I would send the small profits to this board or to one that reflected where the order came from.

    -----------------------------------------------------------------------------

    As to your question "Who are the people that would want DCC++" I think that if you had a bell shaped curved that the ones who would fall in the middle would be those who would like to get into DCC but might not have the money at this point to go with one of the commercial choices and are primarily interested in running trains to begin with. If they are going to do that they also probably need a way to program decoders and JMRI is great at that but that is hard to do without a monitor and keyboard.

    Again the Pi with a monitor and keyboard makes it easy to run JMRI's DecoderPro which is on that same SD card image. You can buy new wireless keyboard/mouse combinations for $20 and a refurbished monitor for about the same. I'll bet a lot of people have a mouse, keyboard and monitor laying around that they could use.

    The people that want to go further and that really want to explore what DCC++ and JMRI and/or other options have to offer such as turnout control and train control and more probably can get started already with what is out there and I would think be a smaller group. I think it is the people in the first group that I mentioned above that need the most help. Your thoughts on pre-configured hardware/software that they only had to connect cables to would probably be a big incentive to them but would need a business or someone pretty committed time wise to provide that.

    Does this board have a way to setup a survey on a subject? That might be helpful to see if there is interest and what that interest might be.

    Sumner
     
  13. RoadRailer

    RoadRailer TrainBoard Member

    34
    11
    2
    Yes, good mention. The project website (http://www.locoduino.org/) is in French, but online translators can be somewhat helpful in deriving information.

    It appears that implementation code would be needed for the serial connection portion, but it seems the library should be able to handle the rest. Building around that would help take advantage of the flexibility the library affords, combine efforts, and avoid duplicating work. In the post from the other thread I referenced above, I also linked to the following article (dated July 9, 2019) on the Locoduino website about using Arduino with JMRI as a command station. Of note is that that article reference using the the original DCC++ BaseStation repository on GitHub as the software, which between that and a look at the codebase is what leads me to believe that implementation code for the serial connection portion is needed.
    https://translate.google.com/translate?sl=auto&tl=en&u=https://www.locoduino.org/spip.php?article253

    By way of reference, the Locoduino project suggests the LMD18200 (c.f. link).
     
  14. RoadRailer

    RoadRailer TrainBoard Member

    34
    11
    2
    …there is also the ESP32-based project (https://atanisoft.github.io/ESP32CommandStation/ and https://github.com/atanisoft/DCCppESP32) that @Atani has been heavily involved with (c.f. this long, ongoing thread). At 47 pages, it is a bit of a challenge to jump in and digest the current status, but it appears to be quite advanced compared to the base DCC++ repo, and from what I have gathered, there are some ESP board that have Arduino-compatible form factors and similar price points. More advanced features (such as RailCom) will require special circuitry, but my understanding is also that the special circuity is optional.

    Someone who is more knowledgeable may feel free to correct the above.

    In a way, this goes back to the "curse of open source" challenge that @Keith-Ledbetter noted—there appears to be a lot of capability in the ESP32, so is the fragmentation of effort worth the potential benefit of supporting slightly different hardware options when the end capability is effectively the same?
     
    Atani likes this.
  15. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    237
    152
    8
    I'd volunteer to flash the Unos/Megas and add a motor shield donate the markup with the caveat that I would initially test but provide no support after and that they were genuine since that way it would support Arduino as well. Also that we could get enough demand that I could order in some quantity so shipping doesn't kill the cost. I could then knock a bunch out in one night rather then one here and one there. And yes same as Sumner if somehow volume really did take off would not be able to handle.

    @RoadRailer Great idea on the organization github. @FlightRisk can you set that up

    @RoadRailer very familiar with the ESP32 work by @Atani and it's great. That really has evolved though into a command station that is not even really DCC++ but it's own code. I think we can certainly link to it but thikn we should leave that development on it's own as it's totally different hardware and software.
     
    Atani and Sumner like this.
  16. Atani

    Atani TrainBoard Member

    966
    638
    17
    I would highly suggest opt out of mentioning the ESP32 CS code that I'm writing since it is not DCC++ but does offer a compatibility layer but that is very limited and mostly would be useful for wireless throttles that rely only on the DCC++ protocol. I will be adding native WiThrottle support and it uses/supports LCC natively (which also brings support for TCS UWT-100 which I just received my pre-ordered one).

    If the ESP32 CS is mentioned, it should be mentioned as a more advanced CS supporting more advanced features than DCC++ on the Uno/Mega support today.
     
  17. Atani

    Atani TrainBoard Member

    966
    638
    17
    The library is a derivative work of DCC++ and includes support for the ESP32 (it used to be based on an early version of my ESP32 CS code, not sure if it is now).

    The LMD18200 is a superior h-bridge device to the L298, the primary advantage being that it supports 3A output. I use the LMD18200 as part of the ESP32 CS PCB kit for OPS and the L298 for PROG (and LCC downstream boosters)
     
    RoadRailer likes this.
  18. FlightRisk

    FlightRisk TrainBoard Member

    189
    62
    4
    Maybe we should look at the bjorniuppsala fork. I downloaded this and Atani's and a couple of others and tried to look at what they added, where they were, and how many people were involved with it. It we can get him on board, maybe we could add to his version? Or we will have to fork. But it would be nice to pick up with whatever the best active fork is.

    The changes Atani and Bjorn have made are significant. While a learning programmer or someone who just likes to change code could understand almost all of Gregg's original code (minus the timers and interrups stuff), as the code grew so did the complexity (pointers and pointer math, more classes, more units etc.) It is quality, modern code, but a bit more advanced. That is one reason it went to PlatformIO. That IDE has a LOT more functionality than the ArduinoIDE, but is more complex itself. It allows for code completion/ intellisense (to hover over things and see what they are and where they were declared, etc.) So it is a much better tool for a project like this. But to give the code to users to change settings or make minor changes or just to upload the sketch, we need to also maintain the Arduino Sketch Version. It just entails renaming a file and copying all the other files over and make sure the Arduino has the correct libaries installed.

    I like the Mega +Wifi version, but there is only one company making that, right? So if that isn't a "standard" I'm worried about a clone board disappearing. It does use the esp8266, so that might work with any Mega and any ESP9266 with the same codebase. Not sure. We should research that option. It seems Wifi may be important for the "base" version. If someone doesn't want it, they can still just plug in a USB cable.
     
  19. FlightRisk

    FlightRisk TrainBoard Member

    189
    62
    4
    As just about any ensign on Star Strek says when there is an emergency, "I'm on it!" Should learn enough to set it up tonight. Also use Roger's Trello so see what we are collecting and email him things that should be added there.
     
  20. Atani

    Atani TrainBoard Member

    966
    638
    17
    Unfortunately, that fork will *NOT* work on the Uno/Mega. It is only suitable for running on the ESP32 as all of the DCC generation code has moved to be exclusively generated by the ESP32 RMT peripheral. He has based his fork on my previous Uno/Mega + ESP8266 code base and created a new variant that merges both code bases into one and I do not know how well or if it works. It also appears to not have been updated in over two years.
     

Share This Page