FlightRisk

We can't keep up. At least 2 of the video bloggers have done stories on us, plus all the buzz generated from all the other boards (like Trainboard) and our website. I hope we can get a few more team members with skills to help with documentation and the installer. We need testers for the new Automation feature now. Fred DCC-EX

Hi Alan, Have you joined us on Discord where we have live support? We could have saved you a bit of time and also explained some features that are not really documented yet or are just alluded to, like the new way to handle functions. I did not see any name that started with "Pup" and we have only one Alan Keep up the good work! Fred DCC-EX

The issue is wasted time, among other things. If the specification says that an ACK signal is 60mA for 6ms, and a decoder pulses only 30mA or for 3ms or 6ms but with dropouts to 0 in that 6ms or pulses for 12ms, it is an annoying problem. For example, having to dumb down our ACK detection to work with the lowest common denominator means that page reads will be twice as long. We can turn that on and off, but having to create exceptions like this isn't the best solution. Fred

I can tell you firsthand that sadly in our loosely regulated hobby, many decoders do NOT follow the NMRA spec. You will find that for running trains on your main track, where the tight adherence to the timing standards is not so critical, any halfway decent decoder will work with any good Command Station. But when it comes to programming and reading and writing CVs, you will have issues if you buy lots of different decoders from different manufacturers because of their poor ACK response design. DCC++EX gets around this by loosening our default tolerances significantly from the specification and having detailed diagnostics that allows you to find out exactly why a decoder isn't working when you get the dreaded "308" error in JMRI. We then make it easy to change the settings even further to adjust to these poorly designed decoders. So you can get almost all of them to work with tweaking. We've been tempted to make a "beware of these decoders" list, but we don't want to get into a war with decoder manufacturers. I imagine many are very small businesses. They don't want to be out of spec, they have just never had anyone test their decoders to the level we have and report the bugs or their misinterpretation of the spec to them. Two manufacturers have already modified their firmware when we pointed out with scope traces why their decoders were causing users issues. But to be fair, a few of the specs are purposely vague and that leads to a lack of conformity between manufacturers where you could argue either was right depending on how you read the spec. Fred DCC-EX

You are right, we can't be all things to all people. Thought we do love to get input from as many places as possible before making a decision. There are usually caveats or snags we find out about during our research into things. I've added a roadmap to the main menu. It is a bit preliminary, some things are solid and other things might change as we firm it up over the next couple of weeks. https://dcc-ex.com/roadmap/index.html Fred DCC-EX

Do you mean new boards we or people we are working with are developing, or configuring Pololu, IBT_2, the 15A Chinese board, etc? Existing boards are under "motor controllers" in the references section. Going to figure out a way to have sub-groups since that section is getting large. To keep Discord from inundating people software and hardware development technical discussion between the developers is on a hidden development channel that people can be invited to. I'll try to make sure more updates go in for public discussion. There is the open #motor-shields channel under "Hardware" and there is a private "hdw" repository in GitHub where we store things, which I am happy to let anyone join who wants to be part of it. We are still trying to figure out how to make things easy and organized. GitHub has repositories, teams, discussions, projects.. Discord has channels. It can get confusing. I need to put the roadmap on the website in its own heading. That would probably be a big help.

Well Helllo Andrew! And thank you for all your contributions to the hobby, BTW. Actually, it is still faster than DCC++ (which is what I am comparing), there is a lot more we are doing that Classic does not do regarding packet sending and ACK detection, so even the 8 bit writes are much faster (maybe that's not 10 time faster, I think the data showed 6? ) And it is able to work with more decoders because of how all the new code works and because we can analyze the diagnostics built into EX and use it to tweak things to deal with bad decoders. We found 2 last week and with one, the manufacturer as willing to fix the bug. We could work around it in software (the decoder was modulating its ACK pulse), but great that their support was willing to issue a firmware update. I was also referring to the way the CS operates internally and not JMRI, our new <V> command that validates or verifies against our best guess speeds up the process. My understanding was that was then added to JMRI thanks to you working with our developers (Steve Todd and Harald Barth)?. So again, thank you! Cooperation instead of competition, how rare is that?

You may already be using DCC++ EX, but this is a reminder that the old DCC++ Project (Now called DCC++ Classic) has been replaced with DCC++ EX. The same commands work and many new ones, but the software has been completely rewritten from scratch. WiFi is built-in and there are many enhancements to it and to software like Engine Driver and JMRI. We update all three pieces of software weekly with specific DCC++ EX enhancements. There is direct support for WiThrottle and DCC++ compatible throttles (no coding and no JMRI required). Many more motor controllers are supported, there is no need for wire jumpers, and it is easy to expand with a config file, but also a mySetup file that is like an Autoexec.bat file to startup with custom settings and track commands, a user function override feature (aka filters) that let you intercept regular commands and route them to things like the new LCN accessory system or any custom hardware or software you want to create without having to dig through the source code of the Command Station. Also, EX-RAIL automation for layouts is in beta testing. There are new features like "drive-away" where you can drive onto a siding used as a programming track, program your loco, and drive off. We can program virtually any decoder and do it ten times faster which is important when reading a page of CVs or when using all of those decoders that do not follow the NMRA specification due to poor design. There are many other differences and enhancements. EX works on Nano Everys and Teensies now also. Two of our main software and hardware developers (new shields and an all-in-one CS are coming) are based in the UK. :) The best way to find us is via the web page and via chat on our Discord Server where you can get live support and discuss your needs pretty much 24/7. We try to get on all the boards and forums but other than Trainboard, Discord, and the "DCC++ and Arduino Model Railroading" Facebook group, it is difficult to check them all. https://dcc-ex.com Thanks to everyone for supporting DCC++ EX and "Classic". Fred DCC-EX