DCC++ Update Project 2020

FlightRisk Feb 16, 2020

  1. RoadRailer

    RoadRailer TrainBoard Member

    41
    11
    4
    Appreciate the insight and background, @Atani. Agree that the bjorniuppsala fork has not been updated in two years, but when reviewing the network graph for DccPlusPlus/BaseStation, while not the most recently active, it did seem to have a greater overall level of activity. There are forks with more recent updates, but they do not have as much activity over time. Which to choose???

    As additional reference, a network graph based on the atanisoft fork is here. As to which one might be the most progressed, I'm not sure of a good way to determine apart from either making an educated guess based on activity or inspecting the code of each.


    Once upon a time, I tried to unite various and sundry forks of the abandoned BrickOS project…a very tedious and time-consuming endeavor. Some of the merged updates did bring DCC capabilities to BrickOS, so if anyone still has a Lego MindStorms RCX device around, there's another option, lol.

    From that context, though, the bjorniuppsala fork moving DCC signal generation to an ESP32 peripheral is understandable, as other processing and task scheduling and interrupt handling on the RCX could not be allowed to interfere with the timings of the DCC waveform generation output, if the DCC waveform was to remain compliant with the DCC spec (and in turn recognizable by standard DCC decoders).
     
  2. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    My own iteration of DCC++ is running the original code on a Mega clone with the Pololu mc33926 motor shield usb connected to a raspberry pi 3b+ running jmri with track power coming from a Mean Well RS-100-15 (15V 7A) power supply. I think this is about as simple as it gets. My first iteration was the same but with the arduino motor shield. Given that the whole purpose of going dcc in the first place is to run more than one or two locos at the same time, I think we need to use a shield that won't get toasted when you start expanding your layout and try to run 3 or 4 double or triple headed trains. I really like jmri to control the throttles and I view it as a solid requirement for easily programming your locos. I would have liked to have found a source for the motor shield that was already soldered up with its various jumpers and such though. I also have no idea why its fault signal pin was removed in the instructions. if you have a short with this thing, the board cuts the current before dcc++ notices it.

    Anyway, I also like the idea of using the mega (genuine or cheap clone) as the minimum.

    I like the idea of keeping the dcc track control code in a library to keep the code modular but still include a "sketch" that is the serial usb and /or networked interface and documentation on how to turn various "dials" to tune it for your flavor of decoder that you are trying to read on the programming track.

    I haven't had a need to add wifi to my base station yet but would be open to a simple "stack this shield on top and hit reset" type of option. I don't like the idea of using a single sourced mega clone that has wifi added in a nonstandard way.

    We should try to come up with an approach to expanding on functionality in a way that is always backward compatible as far as the <command> set goes.
     
    RoadRailer likes this.
  3. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    hmm.. makes sense. would also be a good argument keep dcc++ a lean as possible. Maybe stick to a Uno for generating the track signal and actually come up with a split off of code that uses /expands on the <a> type commands to create a jmri controllable "accessory" base station. Maybe base that one on the mega and load it up with various method of driving track switches, gates, lights, sensors, etc.

    example: I've been trying to come up with a clean way of adding dcc++ control Atlas snap switches. They require a momentary pulse of current for each direction you want to throw the switch. This implies something like driving a relay board using two relays per track switch. This uses two arduino pins per track switch. The code has to drive a pin high for about 100ms then drop it low again to energize the relay just long enough to trip the switch motor. This can be done via timer driven interrupt, but I'm worried about adding such things to an arduino that is already busy driving the dcc waveform. I know that there are other "stationary decoder" projects out there for such things, but they cannot provide feedback.
     
    Last edited: Feb 21, 2020
  4. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    There is also the official Arduino Uno Wifi boards to consider, these do not have a programmable co-processor for the WiFi that I can tell so it may not be as usable as the Mega+ESP8266 boards that are also available on the markets (all of which use one of the UART devices to connect the two systems together, much like I did for my original DCC++ fork).

    It is similar to the approach I have used on ESP32 CS, though I do not use a task to fill the RMT buffers and instead do direct processing inside a "tx complete" ISR callback to kick off the next DCC packet (or read RailCom responses).

    Each one of those forks adds/fixes various pieces of code and after about 15 minutes of scanning the various commit nodes in the tree I found only a handful that would be meaningful to include:
    With each of the above the target repo/branch needs to be considered as a whole to ensure the complete feature is picked up. There were a few other forks that added other motor shields but I couldn't find them again now.
     
    John W Zerbe and RoadRailer like this.
  5. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @Atani Thanks Mike, your help is invaluable.
     
    Atani likes this.
  6. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Which page are you referring to in what link? Thanks!
     
  7. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Noted. We will reach out, I'm sure. I am a UI evangelist. We can follow the Arduino example. Part of their success is the simplicity we are trying to create, that is is very organized, and that everything from their web page, to the IDE, to the boards themselves are "pretty". JMRI badly needs a UI and graphic design overhaul. Not knocking it, that is the nature of open source sometimes. But all it would take is the right talent to add that piece to the project. On this project, we may need help with visuals for the documentation of the controller app.
     
    Mani likes this.
  8. Roger Beschizza

    Roger Beschizza TrainBoard Member

    58
    8
    3
    This is how the DCC++ Trello board is looking at present - it is evolving daily [hourly even]. I am happy to maintain it. Please submit suggestions on this thread. R-
     
    Last edited: Feb 22, 2020
  9. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    how do I get access to see that Trello board? I just signed up there as John Zerbe (johnzerbe1)
     
  10. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    There have been a few discussions within the JMRI community about an overhaul and even some attempts at such. There are a number of hurdles that will need to be overcome to change the UI since JMRI has a lot of dependencies on the current behaviors of the Swing UI implementation. Complicating this further is the cross-platform nature of the project and the OS dependent customizations (and in some cases fixes likely). A complete overhaul/modernization of the JMRI UI will not be an easy undertaking and will require a rather large Java UI expertise. While I do work in Java I do not work in the Java UI (Swing) side of things, I mostly now work on backend code (headless, web interfaces, etc).
     
  11. RoadRailer

    RoadRailer TrainBoard Member

    41
    11
    4
    To JMRI's credit, too, there is documentation, but the steps one might need to go through at times are not the most intuitive.

    An alternative project that had more of a European genesis is Rocrail. I have been favorably impressed with its UI design, and it similarly provides support for a wide array of command station and base station types (including DCC++); however, in my (granted, isolated) experience, part of what has kept it from gaining traction is that while it is open source, use of the Rocrail wireless throttles follows the pay model. It is their project, so that is fully within their right, and certain expenses might need to be covered somehow.

    Rocrail and JMRI both support SRCP (Simple Railroad Command Protocol), so if a smartphone throttle were to be written that implemented SRCP, it could work with Rocrail. An alternative approach would be to use JMRI in the middle, with wireless WiThrottle-implementing throttles connecting to JMRI and then JMRI connecting to the Rocrail SRCP server. An SRCP client would likely not be as "data rich" as a native Rocrail client, though.

    Anyway, without getting too far off topic, JMRI is not the only software providing built-in support for DCC++; Rocrail does, too.
     
  12. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Implementing SRCP should be a lower priority item if it is on the list at all. There are multiple protocols to possibly support between JMRI/RocRail/DCC++. There are also commercially available wireless throttles coming out that only support LCC and WiThrottle. I do not see SRCP becoming more than a niche market unfortunately due to no major manufactures supporting it outside of RocRail, multiple manufactures support both LCC and WiThrottle today.

    For DCC++ I would suggest only supporting DCC++ protocol to communicate between JMRI and DCC++ and let JMRI handle all interfacing with wireless throttles or other technologies. This will ensure the DCC++ codebase remains simple and does *ONE* thing really well (generate the DCC signal for the track).
     
  13. Roger Beschizza

    Roger Beschizza TrainBoard Member

    58
    8
    3
    At present access is restricted to FlightRisk who is acting as project lead and myself as Admin. so that edit control is maintained. I have not as yet found a way to allow “read only” which is why I will regularly [weekly?] post the link so that folk can see what has been added, has moved forward or remained static. All contributors are asked to please post any other thoughts or ideas on this thread and one of us will incorporate them. R-
     
    Last edited: Feb 22, 2020
  14. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @Roger Beschizza see what Board Menu > More > Settings > Commenting Permissions does. Otherwise, we have run up against their limitations to make money. It is $10 a month per person to upgrade to "business class" that allows read only permission. Maybe 1 or 2 more dedicated types could have access. I need to see if this has a backup option
     
  15. Roger Beschizza

    Roger Beschizza TrainBoard Member

    58
    8
    3
    Hmm.... I think I've got it. I'm pretty sure I have disabled editing by all except you and me. Can you confirm you can still edit? R-
     
  16. RoadRailer

    RoadRailer TrainBoard Member

    41
    11
    4
    To clarify, the SRCP reference was only in the context of a way to use "non-Rocrail" software throttles with Rocrail to DCC++ and not a reference to anything DCC++ potentially might need to implement itself.

    As use of Rocrail's mobile clients require the presence of paid support key on the Rocrail server, a potential alternative mobile throttle approach would be to connect a WiThrottle to JMRI and then configure JMRI to essentially just be an intermediary communicating with Rocrail via another protocol. (If a software throttle implemented a given intermediary protocol, then the JMRI-in-the-middle part of the setup could be eliminated.)

    Yes, I think we are on the same page. I mentioned Rocrail because it is a legitimate potential alternative to JMRI that has a user interface some might find preferable to JMRI, while also noting the caveat that exists if one desires "free" smartphone throttle functionality with Rocrail that would be similar to what JMRI offers. It can be done with Rocrail, albeit with a little more "creative" setup. SRCP was mentioned because it is one of the available services Rocrail list on its services page. (While MQTT is also listed, use of "rocrail/service/client" also requires the paid support key.)

    A few of SRCP clients exist already, though I am not currently aware of any modern mobile implementations.

    Anyway, I hope that helps make things a little clearer… :)

    [​IMG]
     
  17. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    NOTE ON DEVELOPMENT - For any of us making changes, there are several development environments that will work with Arduino's. It is a given we need to have a version that will compile and run on the Arduino IDE because it is simple and well supported. Many people will never need to code, or worst case, will only need to open a config file to make minor changes.

    We willl also support, and do primary development on VS Code with the PlatformIO plugin. Code completion, Intellisense, integration with the local Git repository and the Github cloud version, etc. make it pretty ideal.

    If you have a favorite editor, we can still accept your files, but we are going to have to update and distribute them them as PlatformIO projects or Arduino IDE sketches.
     
  18. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    I was just poking around in Github trying to come up with an Organization name that is still open for this project. A few that I was thinking about that are not yet taken are "TrainBoardDCCPlusPlus", "DCC++2020", or "OpenDCCPlusPlus". I agree that we should keep the main project streamlined/simple to do train control very well, but also envision future, separate, expansions to include things like an accessory controller that would use an expanded <?> command set. Possibly create an open source protocol to use tcp/ip as a "loconet" type accessory bus. Wiring for that would be either wifi or hard wired network switches with cat5e cables.
     
  19. Roger Beschizza

    Roger Beschizza TrainBoard Member

    58
    8
    3
    If it is a voting thing I’d go for DCC++2020. R-
     
    Softec, John W Zerbe and Atani like this.
  20. Roger Beschizza

    Roger Beschizza TrainBoard Member

    58
    8
    3
    I see on Go Daddy that DCCplusplus2020.com and DCCplusplus2020.co.uk are available for less than £1 for the first year. Just saying. R-
     

Share This Page