Totally agree. So lets leave in edit mode as we fix. I will attempt to do research and fix but like I say not a coder so may need help with that one. Agree, lets get our first stable release version and then Dax knock yourself out but I agree don't expect it to be an easy one but agree would be extremely useful if you could pull off
It should be possible to do something like this: Code: loadPacket(0,resetPacket,2,1); loadPacket(0,bWrite,3,4); loadPacket(0,idlePacket,2,1); .... for (...) { ... analogRead(CURRENT_MONITOR_PIN_PROG) .... } loadPacket(0,resetPacket,2,1); Something like this at least. This would bring it closer to compliance in that it starts with a reset packet, sends the read/write CV packet, sends an idle packet (any packet can be sent at this point simply as a delay for the queue and idle is ignored by the decoder), reads the ACK from the decoder and lastly sends a reset packet to the decoder. The last reset is not 100% required but is not a bad practice.
@Dex I've always thought that an installer that elminated an IDE completely with defaults or prompts for the changes would be a great addition. Nobody is saying don't do it if you have a passion there, just that the rest of us need to focus on documentation and the framework for handling development going forward
@Atani is the CV fix above with "loadPacket" the only thing out of compliance with the NMRA DCC spec that you know of? The current version is configured for PlatformIO. How should we handle having a project folder for the Arduino IDE version? I think we need that because we may include just that in one of the download zips, or at least have it as one of the builds in the project since many people will just use the Arduino IDE to edit the config file and/or upload the sketch. And is there a way to automate this? On my local repo, I just copy the changed files into a project folder called DCCpp_Arduino_IDE (with renaming the DCCpp.cpp to ino) Seems like there should be a way to automate that.
It is just one area, I can't remember the others off hand but there are a few areas. Arduino IDE has a few requirements, the biggest being directory structure. The top level directory name must match the project name. Another requirement (at least it used to be) is all cpp files need to be renamed to ino instead. It should be possible to have a script that converts the repo content in bulk to "Arduino IDE" compatible but that will be a problem for anyone trying to work on the tip of a branch rather than use a release version. I don't see an ideal solution for this currently.
I agree totally if you want to get more non-computer people involved in DCC++ this is critical and don't see why he can't start on it now. I'm not having a problem with the version that I got off of github last year using these instructions .... https://github.com/DccPlusPlus/BaseStation/wiki/Getting-Started-With-DCC---Hardware ... is there a major problem with it? Couldn't he use it to start with and add whatever you guys keep coming up with. Those instructions work fine but again the problem is there are 19 steps and that is a huge turnoff to many and some of the steps require at least some computer knowledge. An installer would bypass all of that. The same on the image file for the Pi. It isn't real hard to get onto a card from Steve's site but still daunting to some. An installer where you only had to connect a card reader to the computer would be wonderful. Take the card out of the reader when done and insert it into the Pi and you are up and running. At eight pages and growing maybe it is time to split this thread into a couple different ones. Possibly.... 1. Working on an installer for what is there now, a Windows installer for the Arduino and JMRI and likewise for the Raspberry Pi. What is there now might not be perfect but it is working for some of us just fine and will fill the gap till you guys make it better. 2. Fixing what is there now. 3. A non-installer set of instructions for what is there now and the master that will be updated. 4. Group working on modifying/expanding DCC++ Sumner
I'm a little late in joining this thread - been away for a few days and on return another member prompted me to take a peek IMHO, the DCC++ "Project" has evolved into three main "forks":- 1. Gregg's original, grass roots, very complete DCC system ideally suited to entry level users, but also allowing for pretty sophisticated automation and multi-train operation. As many others have indicated, I feel this system must be nurtured and maintained as the Grandfather of the concept Gregg sporned. Bugs (if any) should be fixed, and any additional features which ADD to its basic requirement of an Arduino UNO can be developed, but the UNO platform as a minimum MUST remain. I'd suggest this fork is named "DCC++UNO" 2. As we know, the use of the Mega opens many new doors. Another member of the DCC++ group has already added S88 bus support for up to 3 channels (limited use on the UNO), and I believe many further additions are possible. I'm certain there are many other extensions already developed. I'd suggest this fork is called something like "DCC++Mega" 3. Then there is the extensive work @Atani has done using the ESP32. Whilst Mike has embarked on a very ambitious project he has called "ESP32 Command Station", my feeling is that a project dubbed "DCC++ESP32" could be developed which offers a (Source?) compatible version which could run (after compilation of course) either of the two previous versions, but offer growth to the point of implementing everything @Atani has already implemented in his design. Just my few cents. I'll certainly be following developments whichever way they go Best Norm
This is effectively available today via https://github.com/bjorniuppsala/BaseStation. Though I do not know how well or if it works correctly.
@NormHal I'm hearing your thoughts on forks/versions and wondering if the UNO/Mega can just be handled as it is now, with Ifdefs. The IDE knows what board it is compiling for and only the code for that board gets linked in. Let's make sure we are making the distinction between Atani's DCC++ ESP and his ESP32 Command Station for those "listening" The ESP32 is an entirely different animal and not compatible with what we are doing. However, a version compiled for an ESP32 processor board could be forked and attempted. As Atani said, bjorniuppsala had been working on just such a version. The code will be very different because a completely different processor and completely different libraries. If we could start with bjorn's code, that would help, but not sure then how to implement changes made in the Uno forks into the ESP32 fork. In any case, we can put it on the wishlist, but for now our focus it the documentation and working on the current codebase.
Where should we coordinate the outline for what the readme.md, Wiki and the Github Pages website? Here? On the "Projects" boards on github? Something else? I posted previously trying to get help on a vote for the outline and format for the readme and to decide how to use these 3 resources (or just the first two) to handle everything we need for users to download what they need, coders to know our procedures, and user/coders to have full instructions on how to use DCC++. Once we know what each location will hold an agree on an outline, we can fill in the content. I white board would sure be nice to just shotgun all the ideas and then move them around to a cohesive list. If we are having quickstart guides, we need to know where they go. Are they projects alongside the other repos? Are they PDF files, Wikis?
Can we clean up the extraneous forks (master-2.0, master-slave-2.0) and have the structure we want? We need master and development. Did we decide we are going to have feature forks like "new-current-monitoring" and "hotfix-100" as we come up with those items? I removed the Controller repository. For now this is just the BaseStation project. I do want to look at Geoff's stripped down version of this controller to see if that could be modified slightly and be a cool controller. He was using it to control accessories, but it could be a nice test or simple controller. https://model-railroad-hobbyist.com/node/27318
As far as a controller i was also looking at potentially doing that in C# as well using WPF but that would be down the line. I would love to help with both the Installer from what i have been seeing via reading should be simple enough to get a baseline code set and a nice WPF UI. As for the other code i am really good at troubleshooting, debugging and other things so if chagnes are made let me know what has been fixed i may be able to help fix some issues. Also all code would be published as a separate project under the DCC-EX group I totally agree with you on starting now i will see what i can come up with
They can be deleted via the GitHub UI, if you want to give it a go you can or I can clean them up. As for the other branch naming etc, I would suggest we do follow that so we can review and get it right before merge. Sent from my ONEPLUS A5010 using Tapatalk
Just a thought here. Do we want to create a new repository "DCC++Classic" or some such to put Gregg's repo clone in, possibly add some bug fixes where appropriate, but leave it in original Arduino IDE format. Clean up its branches and manage it also as master/development/feature/hotfix branches. This could be the entry level Uno/Mega that simply runs trains well and people can get their feet wet with it. Also keep the current BaseStation repo as the latest and greatest PlatformIO based, ESP version with support for more varied add-ons?
I have been thinking a lot about the topic and do agree with Norm (by the way glad you chimed in Norm as you have a lot of knowledge) I think the classic is the correct name and the uno and mega can be one as the code already can handle both. Though honestly do we need that or can we just copy Gregg's original over and call it good? I guess what I envision is we build on that and this is probably a bad example but a bit like jmri in the sense it can handle almost anything. I would hope we could build the code so it can handle potentially a dozen motor boards/shields, could be wireless or not, could add support for things like LCC, potentially loconet,etc etc. and potentially correct and have better performance than the original. I think on classic we need to decide if we give that a true update fixing it to conform to NMRA standards,. playing with current and ack thresholds with different boards to find best set points etc or we leave alone and just fork latest and greatest. My opinion (you get what you pay be for) would be to make very minor fixes on classic and have that as the base that is documented and sort of sits there forever that would be super quick start but not be actively worked. Then our working version should be constantly tweaked, tested, improved, and add functionality without taking away ability to use tried and true uno plus original motor shield. Since Norm chimed in I think that we should also fork off or possibly start a new org around throttles (a special interest of mine) ,a third for non jmri control/throttles, and potentially a 4th around other accessories like boosters. Those are out of scope for this thread and org in my opinion but can and should be developed and documented as well just not in this GitHub. I also agree ESP32 stuff is out of scope in one sense as it's totally different hardware and software having said that think when that hooks to JMRI it recognizes it as DCC++ or am I mistaken in that @Atani if it does I think there is a tie in we shouldn't ignore.
Esp32 is based directly from the original DCC++ it's just been optimized and altered to run on that hardware. Honestly I would love to see DCC++ run natively on a raspi via virtual serial or server directly using the available gpio. But that's probably way too ambitious . Anyways the tie in for esp32 is very good as it has pretty much the same functionality as the Arduino boards with more pinouts and of course Bluetooth(which could be used for block detection) and wireless
I went to clean it up and compared the branches. master-2.0 and multi-serial have code that can be merged. I didn't take a long look at it but I think we need to review it and see if we want it. For one, Gregg had intended to rename the DCCpp_UNO fork to just DCCpp to reflect that this runs on UNO, MEGA (and my addition of the NANO) and to add another unit called "server". For some kind of master/server setup and the addition of a <J> command. Also something to handle multiple serial connections between 3 Arduinos, and a <u> command to blink the led on pin 13.[ Not sure I caught you here. Follow which? What's the action item here? I can get it started if I know what to do.
Since we are focusing on code in the current base code are there any known issues that can be replicated that we can attempt to debug and fox
My ESP32 code is *NOT* based on the original DCC++ code, it is a ground up rewrite with compatibility in mind as a migration path to newer hardware. There was a fork of DCC++ that supported a DCC Hat for the rPi and did exactly what you are after but unfortunately the designs for that I believe are long gone now. You might find it via the forks tree on GitHub from the original DCC++ code base though. Bluetooth has a lot of overhead on the ESP32 and it would likely interfere with the DCC signal generation. My ESP32 code does offer DCC++ support for JMRI interfacing *BUT* it is considered legacy support at this point and migration to LCC instead would be highly advised. I think the rename can be brought in safely but we would likely want to do a bit of minor restructuring of the code at the same time to make it clear that the current BaseStation repo contains two distinct projects (esp8266 and AVR). I'm not 100% certain on the right naming though. This was only supported on the Mega and was not completed. It's purpose I believe was to extend the IO capacity of the Mega. This may be useful but I don't know for certain that it should be part of the base code. I was meaning follow your proposal on the branch naming that you had posted with master, development, hotfix, etc... We should aim for stability and completeness before things are merged to master/development. There are a few fixes floating around on this forum for various decoders which do not work correctly on the programming track, most of which I believe were timing/sequence issues.
I should have looked at these branches before. I had started to do something similar to drive relay boards from a second mega for atlas snap switches. I agree, not needed in base code, but possibly add as feature to the new one. Do we have contacts with JMRI folks on approaches to extend the dcc++ command set? ie version number response or some sort of "capabilities" response? Another thought I had was to add to the config commands to tell the base station what motor shield type you were putting on it, and store in eeprom rather than having to recompile.
