As a EE, I do understand the PWM signaling, but I have been confused by lack of a better method to send back acknowledgements. I am still learning about all the other systems out there and how people use them like Railcom, Digitrax, boosters with cutouts, etc. I saw code from someone with a name like aysili where he modified or created Arduino code with the cutouts for Railcom. I know for backward compatibility and all the other reasons mentioned, trying to use the rails was the easiest solution. But the more I think about it, it just seems wireless directly to the decoders is the future. Network packets. Bi-Directional. Unlimited Addressing. Again, having to have a radio in an N or smaller decoder increases size and cost. But everything sending bi-directional signals over wifi sure seems like the ideal design. Guess I will have to do more reading to see if there is a standard for "Wireless DCC". I know Lionel's blutooth system and "legacy", and am reading about Loconet. I imagine there are other proprietary systems and a host of issues that have to be considered. A wired network would be the most reliable under the table, but wireless the easiest. But then how would it co-exist with everyone's home network? It would probably have to be a private network or at least a subnet. I did see this which I will be following: https://tcsdcc.com/commandsystem. We still have our niche, but I'm interested in the future. Oh well, in another year I'll catch up with what's happening in this area unless it moves faster than I can keep up. Which may be the case Back to working on DCC++ EX...
LCC covers this via the Traction Protocol extension. I'd rather not derail this thread about DCC++EX to cover LCC functionality but LCC will expand what is capable today with standard DCC decoders (even those that use RailCom to send feedback to the CS). RailCom would be a great addition to DCC++EX but I do not know that it will work reliably on the Arduino UNO but it should on the Mega. It would likely require a custom motor shield that exposes the required pins on the h-bridge chip to effectively short the rails together for the ~487 microseconds. During the "cut out" period the DCC decoder can send back 2-6 bytes of data to the CS, both on MAIN and PROG tracks. The detector circuit and the CS would need to decode this data and process it however it chooses to. If RailCom is implemented in DCC++EX I would not expect it to come anytime soon.
As it relates to RailCom and DCC++EX, I think the best case scenario in the short term is to facilitate RailCom, as that basically just comes down to ensuring that the preamble is of sufficient length. As an example, DCC4PC offers a stand-alone cutout device (scroll down on the product page; this cutout device is also advertised as being able to "correct" anomalies in the generated DCC signal it is receiving and passing through). To best facilitate add-on devices such as that, though, the preamble needs to be long enough (16 bits). By way of product comparison, as of ~2 years ago, the SPROG preamble was only 14 bits. While 14 bits meets the minimum threshold of the DCC spec, RailCom needs at least a 16-bit preamble for a long cutout. Thus, SPROG (unless its preamble sequence has since been updated) is not the best candidate for those wishing to add-on RailCom support. In short, ideally DCC++EX would implement at least a 16-bit preamble to facilitate users who might wish to add RailCom support via other add-on devices. Some code in Classic refers to a "22-byte preamble"; however, it appears those might be incorrect code comments that should perhaps instead read "22-bit preamble." At any rate, if DCC++EX is sending a 22-bit preamble, that should suffice for facilitating RailCom. That's where ideas like the following try to fill the gap, but I am not presently aware of any open source projects for either type of wireless control. Those can do away with a command station altogether, if one so chooses—just power the track and connect directly with a smart device throttle.
No changes will be required with DCC++EX to support that, it sends 22 preamble bits *ALWAYS*. As noted a minimum of 16 is required for RailCom cut-out. Having the detector split from DCC++EX is fine but will prevent DCC++EX from receiving the OPS track responses (OPS CV Write can generate an ACK on OPS track via RailCom). This isn't a major problem though.
That's what I thought it looked like; this seems to confirm the code comments need to be corrected, then?
Most likely yes, if there are comments that refer to bytes instead of bits for the preamble it should be corrected. Please send a PR for this if you can.
DCC++ Classic is updated and could use more testing. The CV read and write routines are changed to be NMRA compliant. We can look for any fixes (like bits referred to as bytes, etc) and then lock that release. DCC++ EX has these changes as well as quite a few things @Atani has added the last couple of years. The latest FrightRisk branch adds current in milliamps and adds more motor control boards. We need to verify the values reported by the boards match what we think they should report. I'll make a table here so everyone can comment on the correct settings.
At this point I'm confused on the naming and which ones are now downloaded by Dex's installer. When I used it the other day there were these two choices Base Station -- Dex's notes the other day "Base Station is what we're using for DCCEX is not actually working because it requires platform IO" Base Station Classic -- I thought this was Gregg's version with current fixes and is what I loaded onto the Arduino Maybe list most of the different versions names in a post here for reference like show above or a link to a location where you could update the names and a description with more about them where you could edit them over time as here one's post times out after a while. I could host a page like that if it is needed. Let us know which are available with his installer at this point that you would like us to use with JMRI programming a decoder and running. If this is what would help. If the testing that you need is to only be done by those working on the project let us know that also. Thanks and you guys have evidently gotten a lot done in a short period of time.........thanks, Sumner
@Sumner, First, it depends what time you tried the installer Also, I haven't looked at all of Dex's code yet, but was assuming it grabs everything at the time you run it to get the right code from the right repositories, compiles it and uploads it to your Arduino. Why timing is critical is that "BaseStation Classic" was just updated 6 hours ago from the time of this post. I'll try to clarify. DCC++ "Classic" is Gregg's original code with some important but minor additions. Because the repository where it lives is called "BaseStation-Classic" that is what Dex called it. It will install whatever is here: https://github.com/DCC-EX/BaseStation-Classic/tree/master/DCCpp "Classic" was written using the Arduino IDE. It is a very basic editor with upload capability and a serial monitor as you have seen. It has a very simple folder structure with all the files dumped into one folder and expects to find a .ino file to know where to start. Dex uses commands in his code to basically call an Arduino library to run through the steps. "BaseStation" is the name of the repository that holds DCC++ EX. It lives here: https://github.com/DCC-EX/BaseStation/tree/master/DCCpp_Uno. We will probably rename it to BaseStation-EX or somesuch. Because of the limitations of the Arduino IDE (like code completion, formatting, debugging, etc. that make life easy for more complicated projects), we needed something better. Enter PlatformIO. This is a plugin or "extension" to Microsoft's "Visual Studio Code" or VSCode. Simply put VSCode is a powerful integrated development environment (IDE) that adds a piece (PlatformIO) that extends its capability to handle programming in C++ to Arduino boards. It brings all the libraries and board configurations to the party. But, it uses a different folder structure and a different compiler. So the "main" file doesn't have a .ini extension and PlatformIO adds configuration files and separate folders for things and puts the code in a subfolder called "src" So far nothing major. But the commands necessary to interface to PlatformIO and tell it how to compile and upload are different. One method is using Python. But the bottom line is how to write an installer without YOU having to install anything. The installer has libraries it can use to compile code using a runtime version of each compiler/uploader(Dex can correct me on how this works) . So Dex is working on the PlatformIO version. However, the actual files that need to compile are all just text files with code in them as you know. It is irrelevant what you used to write them with. You could use notepad if you wanted to. The only difference is that one of them is named different by PlatformIO. There could be some things inside the files like and include file order that a particular IDE would need to get it to compile, but I didn't see any of that. So an easier solution might be for Dex to look in the EX folder, rename the file and then use the same process he uses to build and upload Classic. It should work. So one way or the other, I'm sure he will get it working.
@Sumner. Here is the repo: https://github.com/DCC-EX You can see "BaseStation" and "BaseStation-Classic" and a repo for Dex's installer project and one for our web page. The DCC++ EX repo will probably have 2 folders in it. One for the PlatformIO version and one for an Arduino IDE version. They will be identical, code wise, but make it easy for people to put into whichever IDE they like. For anyone who doesn't code, that would be the Arduino IDE. You can just click on the "clone or download" button and get a zip file. On the web page we will have a link for download and that will be easy. But easier still for people who don't want to code is the installer. No one would even need to know about GitHub or any of that. But for you, my friend. Grab what code you like and play with it. If you want, edit the web page. There is also the Wiki and README.md files in each project. So you can provide input on how we can use the and what can go where.
Ok guys i have done my research. I can easily install python system wide for users and prepend the path without any issues. The question is should i as i would be installing python 3.8.2 which is the latest version. I know some people still use 2.7 personally i have both on my system. I am wondering if this would cause issues for some users or if it is something i may be overthinking. Please let me know what you guys think so i know how to proceed
@Dex. I don't see that installing the latest Python should cause issues. Give it a try. That's why we test Great work, BTW.
Python 2.x is end-of-life status already and is part of why PlatformIO moved up to 3.x as part of their build process. You may not need to actually install it but instead use a portable install approach, ie: self-contained and no actual install just an explode and run.
I have tried the embedded approach it is what I am doing now the problem is pip is not supported. Since that is the case installing PlatformIO is not possible. I am not even sure how to get a portable version of PlatformIO as the only way to get it is via pip and that's on all platforms. Anyways I may try the installer for python system wide via msi installer on Windows. Sent from my Pixel 4 using Tapatalk
Thanks, I think I've got it. I added the following to my page about the installer. Under 'Select Base Station Type' you will have two choices as of 3-16-20. Base Station and Base Station Classic. For now pick Base Station Classic as it is working as of this date. The other choice 'Base Station' is under development at the moment. ------------------------------------------------------------------------------------------------------- Let me know if that isn't correct and if possible down the road when Base Station is up and running and more about the differences that an end user would see between them. I don't know how large the group I'm in is but I'm looking for a simple, inexpensive DCC alternative that will work with JMRI and that I can control trains with and program decoders. I'll not be building boosters and such and will be using commercial ones for that aspect myself considering how much time I have to pursue the many aspects of the hobby. Same goes for turnout control and other automation of the layout. I'll do that via means that are somewhat simpler for me to understand. I can still see the need though for a system with greater capabilities for those interested in going down that road. Sumner
There is no such thing as a portable PIO install unfortunately. It will always "leak" out to $HOME/.platformio. Using Python 3.x would be the best option at this point and if there is a long-term-support release I would stick with that version.
If you have not seen it yet, look at https://www.trainboard.com/highball...tion-and-interface.84800/page-92#post-1127683 and we will continue the discussion here. If there are yet more folks looking at my code I'll have to comment better ;-) https://github.com/habazut/dcc-ardu/ Let's continue here. Regards, Harald.
This is just a "touch" to make sure we are all still on the same page. We are still open to changes. So comment if necessary. Vision Statement - The DCC++ EX project exists to provide an open source, Arduino based, NMRA compliant alternative to commercial DCC systems that is simple, affordable, expandable, and allows for a fast and successful out of box user experience to control model trains and accessories. DCC++ EX is designed to work in conjunction with other projects such as JMRI and RocRail. Further, the DCC++ EX project is designed to be the standard DCC++ respository for information and future development, and endure into the future independent of any one contributor. Scope - The system is a basic, affordable, yet expandable model railroad control system. It is designed for beginners, converts to digital command control, and electronics/software hobbyists and to take those who wish to grow in the hobby to an intermediate level. While most people will never need anything beyond the ability to run trains, and indeed may never even use more than just a small subset of the capabilities of the system, it is nevertheless able to work with JMRI and RocRail for more advanced capabilities as well as allow direct control of accessories through pins on the Arduino. DCC++ EX cannot be all things to all people. Where there are features or functions that diverge from this scope, there will continue to be other forks independent from DCC++ EX that will be maintained by their individual creators. Mantra: Keep it simple, keep it cheap Projects: DCC++ maintains two projects, the original Gregg Berman DCC++ (now called DCC++ Classic) and the new DCC++ EX DCC++ Classic - Out of respect for the original developer, history, and to maintain a stable release for those who want it, we will maintain a repository for DCC++ classic. The only updates to this software will be bug fixes if found. The last updates were designed to bring the software up to NMRA standards for digital command control and to fix minor issues. DCC++ EX - Designed to be the future of DCC++. Planned improvements include changes and additions including better current sensing, support for more motor boards, easier configuration, and more support for JMRI, RocRail, LocoNet and perhaps LCC. In addition, we are creating and compiling quick start guides and and more detailed user manuals and technical documentation. These materials will take a model railroader from a quick plug and play to run trains through advanced setups with high current motor boards, turnouts and accessories. Systems: The systems consists of the following parts: DCC++ Classic Arduino Uno Arduino Motor Shield rev3 Rail Power Supply Computer or Raspberry Pi USB Cable JMRI DCC++ EX Arduino Mega Arduino Motor Shield rev3 (or another supported board) Rail Power Supply Computer or Raspberry Pi USB Cable JMRI Wireless Capability through the Computer/Pi Cell Phone, tablet, etc for remote desktop and throttle Let's update this as we continue to refine the project and keep them in mind with all our decisions. With new forks and features being requested, we need to determine if they are within the scope of the project and update our project list on GitHub. And when something isn't in our scope, for example where Gregg added automation features, we can point people to that branch.
This looks great. My only add would be I think part of it is trying to capture links and documentation in one place that stays maintained around these out of scope things like throttles, automation, boosters multiple power districts, etc. Fully agree they are out of scope but to me essential if we do want to be sort of the "go to" DCC++ resource.
Completely agree. That is what I was going for with the last paragraph. I need to make that more clear. I'll make some notes over in our documentation thread.
