This is a great discussion, but we have to reach a decision. For development, I see a consensus towards the github "standard" method with my bullets a couple of pages back. Except we don't use a develop branch. Let's implement that and the GitHub actions starting now. "Take" was supposed to be "table". This is a DCC++ project. People fell in love with it and it still going on the power of the idea and all the materials that point to it and support it. Let's fix it and advance it. Done. There will be a "classic" version that we make easy to install and simple to configure and an EX version we add more to. This may even require the Mega if we think memory will be a problem. It could be that classic is "starter" or "legacy" and EX is pro. This can't be all things to all people. There is the Locoduino library and ESP32 just to name two. People have a choice. Let us just not let this choice die. We have a decent plan, we need to get started and adjust if necessary. We can create a roadmap of features as we go since the first step is fix what's there.
And just one my point in my sales pitch, remember the market. Cheap, fast, easy way to get DCC going. People with the standard config cut a board trace, stick it on top of an UNO, place a jumper wire or 2, connect it to a PC with USB, download the Arduino IDE, download the DCC++ sketch, compile it and run it and never touch it again unless they grow their system. Some like it because they are tinkerers and some because it was cheap. Let's keep that as our focus. And if you can find a way to remove any of these steps, that would be even better.
I feel this may be a bit of a stretch goal for the Mega DCC++ at this point, it will bring in a lot of complexities that may not be suitable for the average user of DCC++. This may be better left off in favor of the more advanced platforms (ESP32, Tiva, etc). It will also require some custom hardware and a few GPIO pins (CAN bus via SPI), this is doable and can be provided as an open-hardware PCB/BOM or kit if someone wants to manage that. This would make sense and simplify the code slightly, though it isn't a significant amount since it is mostly for the DCC signal generation that the code needs to know if it is an Uno, Mega, Nano, etc. It may also be beneficial to consider some of the newer platforms like the Due or the Uno WiFi. This exploration should be done *AFTER* having a stable core code base though.
Having been a part of open source efforts that have fallen by the wayside, I am going trying to ask questions up front to (hopefully) provoke thought and ensure that there is sufficient cohesiveness to the project to see it through to completion. I don't think anyone wants to be a part of a project that doesn't get seen through to its objectives. I'm not suggesting that every i needs dotted and every t needs crossed in creating, but I would suggest it might be good to at least agree on a vision. What might be the project's vision statement? For the sake of clarity— Yes, the hardware might be different, but as price point has been mentioned as one of the key considerations, is the end result (including both price point and functionality) sufficiently different? Yes, the software has been rewritten, but in the end, what might be the functional differences…especially after the other described features are built out? My sense, too, is that the language barrier is perhaps the biggest issue in this regard. Perhaps just some human-reviewed translation is needed? Arduino devices and Arduino-compatible shields are the target, so that part seems the same. Referring back to an earlier statement by @bocabob , what is the ultimate goal of potential end users? Is it the desire to get DCC going, or is it the desire to get trains going? If the desire is to get trains going, is there any rule or mandate dictating that the commands to locomotives must be sent via the rails? Some fledgling commercial projects are attempting to make the case that the answer is, "No." * WiFi: [WiFiTrax](http://wifitrax.com/) (Expressif-based) * Bluetooth: [BlueRail Trains](http://bluerailtrains.com/) These work with just a basic DC power supply and a locomotive "decoder" that is respectively either WiFi or Bluetooth enabled, which a user then connects to via a smart device or computer. At its simplest, there is no need for an intermediate waveform generator for the rails, no intermediate command station, no intermediate software suite (e.g. JMRI, RocRail). Just a smart device and a "decoder", and DCC needs a decoder, too; granted, though, this might not be completely plug-and-play on DCC quick plug locomotives without some type of harness. I have no connection to either commercial endeavor, and at the present I know of no open source projects supporting such wireless capabilities, but what I am trying to encourage and provoke though over is, what is this project's scope and what are this project's differentiators, including to existing solutions such as ESP32 CS and Locoduino? Again, as stated at the outset of this post, these questions are intended to promote thought and establish cohesiveness, so as to help this project sustain itself towards its goals. What might be this project's vision (statement)? What is this project's scope? What are this project's differentiators?
Well, yes, I think you have met your goal to provoke thought My statement on running trains was intended to be within the context of the thread DCC++ and would be synonymous with that of @FlightRisk . I think the best target is as stated by others, a solid base station implementation of DCC++ in compliance with NMRA standards. The second target would be to add feature/function to this, preferably in a modular / select-able way that promotes adoption. It would be helpful to lay this out in a typical product comparison grid something like this (just a format example):
The above graphic also covers point #3 from @RoadRailer for project differentiation and it will need to be expanded, as an example "DCC slots" is not universally applicable (ESP32 CS has no such concept), perhaps renaming that to "maximum active locomotives" instead? I believe the scope should be broken into a couple goals: Stable core code for DCC signal generation, active loco management (slots), IO (sensors, outputs). Documentation (MotorShields, Building, Troubleshooting, etc) Expansion options: OLED/LCD, WiFi, LocoNet, WiThrottle, etc #1 and #2 are the most critical and once those are accomplished then move on towards #3 where it makes sense. These are great ideas but sadly no widespread adoption across manufacturers and will likely remain a niche market item. Until a major manufacture (DigiTrax, Atlas, Athern, etc) picks up on these it is likely going to remain a niche market. That said, there are some emerging technologies that are being adopted: LCC (TCS, RR-CirKits, etc), WiThrottle (DigiTrax, TCS, a few others). The major manufacturers are starting to explore the WiFi markets a bit more as the costs are coming down for connectivity.
I believe that at one point, we discussed that for entry level we recommend a specific arduino board (uno or mega), a specific motorshield (?), a recommended power supply based on your gauge (Z, N, HO, etc). Add JMRI intro for Pi? ie buy these parts, put these jumpers on, cut this trace, turn power on and run your train.
I believe this would fall into the Documentation point I posted above. We can recommend X,Y,Z components as a base set and they can move up from there. This can be applied to any of the options that @bocabob has recommended.
I guess I didn't state that well enough. The question is: Have we decided yet on all of these recommended components for "Classic"? or do we stick with the original (uno or mega, you choose and Arduino motor shield or Pololu MC33926 shield) and have a matrix of how to set jumpers,etc? I think that matrix turns some beginners off.
I can agree on that somewhat. As the number of data points grows it will become confusing. We will want/need to set a couple options: Basic system (Uno, L298 motor shield, power supply) "Advanced" system (Mega, motor shield, power supply) The "advanced" system could swap the motor shield from a set of options or even add multiple shields and could support more expansion options (LocoNet, etc). I think the core supported options need to be defined and then we can move further from that.
My vote: Basic - Uno, L298 motor shield, PI with JMRI (image linked in documentation), 15V >2A power supply (can link some examples) This documentation is done as it's just the original besides us adding the JMRI PI stuff whichi is also already done. Power supply is simple. So really all this would be is putting the code up and then tweaking to meet NMRA standards etc. Advanced - Mega, L9110S motor board, ACS712 for current sense (though I would be fine if we go for a Max471), JMRI (figure on your own if you want to have a PI or serial to PC, etc) , For advanced figure your own power supply for your needs (we could keep a list of ones we have tested that work). This would be the base setup for now. It's already documented here and I am quite sure they would let us translate to English and put on our project. https://www.locoduino.org/spip.php?article253 This is certainly not the simplest setup but it is flexible, powerful and allows us to get the maximum from DCC++ as could handle basically any layout configuration. Lets get both and advanced and Basic working and documented as first priority, Agreed? Then Phase 2 is ability to use many different motor shield with the Advanced, BTS7960, Pololu, etc and have that all well documented as in some cases there is extra hardware and circuitry required Then phase 3 Peripherals and further developments (Boosters, WiFi, Throttles, multiple power districts, etc) Agree lets walk before we run. Can we start voting on the basic and 1st pass advanced and make a call this weekend?
Definitely, however on your advanced I would leave it simple as motor shield and then expand on that topic in the docs to state what is required for each type of motor shield (as your example uses ACS712 or Max471 for current sense since the h-bridge chip doesn't provide it). One thing I would avoid is saying that "advanced" is only L9110S. An advanced setup can be anything other than the basic setup (ie swapping motor shield or adding another to the setup). Yes, with the note above for advanced I think we are in agreement.
I am afraid we are running into paralyzation from "overchoice" or the "paradox of choice". Not that we need to go off half-cocked either. Vision Statement - Provide an open source alternative to commercial DCC systems that is simple, affordable, expandable, and allows for a an fast and successful out of box experience to control model trains and accessories. We can add "using the Arduino platform" And/or "through the rails" if we want to limit our scope to non-RF signalling. On my O-Gauge I use Lionel's Lionchief Plus 2.0. itnuses RF (Bluetooth) to control up to 3 trains in one handheld controller. I really like it, but it a different product. DCC++ could evolve into that, who knows. But for now, "classic" and "EX" (or pro or whatever) and we go from there. And I am thinking Mega also, though a lot of docs and links talk about the UNO. We will stillnrun on an UNO, but the default should probably move to MEGA now. We have a good group here and I think this can continue and evolve with us and beyond us.
Perfectly fine with that and is the quickest anyway. To me the beauty of advanced is it can be what you want, that's the code challenge of making sure it supports all the variants but yes starting with Mega and L298 makes sense then add on support for all the others as we go. Let me work this weekend on writing up what "Basic" and "Advanced" mean as I think that gets at the whole idea of our scope and differentiation.
Just like some projects have separate end-user documentation and contributor documentation, a matrix doesn't to have to be presented to end users. In working through project vision, scope, and differentiation, it can potentially serve a useful purpose internally in helping to visualize and establish project scope and differentiation, so I wouldn't necessarily suggest completely discarding it. At least to me, it seemed to provide a good starting point for consideration. At some point, yes, hopefully we will have a product for end users, and at that point we can certainly tidy up and simplify presentation as we approach that point. In the interim, I don't think it would be of harm to work through some of these pending considerations on a more technical level. This is a good start, but this could perhaps describe other project, too. For example, my impression is that there has been general agreement that this project would be designed for use in conjunction with other open source projects such as JMRI and RocRail.
+1 As @Atani stated above: Advanced - Mega + one or more motor shields from tested/documented list, network options, + power (maybe buck converter setups for correct power to pi/arduino )
Just had another thought on something to throw in to the purchase list for Basic and/or Advanced: https://smile.amazon.com/SunFounder...8?keywords=arduino+case&qid=1582921092&sr=8-8 Doesn't have to be this brand, but something I wish I'd have had when I started with DCC++. I think part of the reason first setup died was the parts sliding around/falling off of table, etc with bare solder joints open to touch metal table legs/hinges and such.
Firstly I want to say thank you to all of you for your time on this. Our project is thankless but I believe important. I also thank everyone for debating but being constructive and civil. Internet threads easily become divisive and great ideas and projects fall apart because of silliness on forums! Having said that I'm attaching 3 pages of brain dump that I think captures at least a version of what we've discussed. Totally open to comments, additions, edits, disagreements etc but hope this gets us to a readme or wiki as an intro to build out and on as we move foward. If there is general agreement I think we should start the Wiki fir the github site and post this there. If there is anyone out there who is good at formatting/comms this could certainly use it
I just read your document and have one question right now: Why do you only specify only the RPI 4B? Anything from RPI 3 to 4B will work. If a person already has a 3 or later version, then why have him buy a 4B? We are not talking about speed here. Dennis
Keith, Thanks for putting something down. Two comments, the first purely stylistic the second substantive. If this is meant to be posted for users I think the writing style should be less conversational. There are a lot of instances of wording that describe developer intent with future tense which would call to question the actual state of the offering in the mind of the prospective user. Additionally, I would suggest some bulleted lists to precede descriptive paragraphs for each major section. The other comment is that I think the Pi implementation of JMRI for the Base implementation should be an option. I believe that a good percentage would want to start with JMRI on a PC. Anyone considering this will have a PC and probably one that could be dedicated to trains if not the layout. It is a lower common denominator so I would recommend someone get it going with their PC (they have to load the Arduino anyway) and then layer on the PI solution if they find value in that.
