Question to the group and/or Dex. Is the version mentioned here what would be downloaded from Dex's latest installer? I've had problems with the original DCC++ reading and writing CVs also and this sounds real encouraging. I have a loco or two that I would like to go back to and see if there is now no problem (if I can remember which ones were having a problem). Thanks again guy for what you are doing, Sumner
Yes I updated the installer. It now has the ability to compile both Classic code with our modifications and the Extended code with better modifications. It should still upload and I believe everything should be working as before just now u can compile both versions of the project which will allow for further testing of the newer platform that the guys have been working on. More to come later with LCD support and wifi support with esp8266 I believe for the mega. Sent from my Pixel 4 using Tapatalk
With the installer from Dex you don't get the code from my fork. You get the DCC++Classic or DCC++EX. My code is at https://github.com/habazut/dcc-ardu/ If Dex wants to install an option to pull down that instead, be my guest. To get stuff from github: If you don't feel comfortable with the git command you can find a green button on that page where you can download a zip file. Unpack the zip and then you have to tell the Arduino software to pick up the project, compile it and put it into your Arduino hardware. Probably Dex' installer is more comfortable for the Windows folks, but I don't do Windows (if I can avoid it). Regards, Harald.
I said there was no DCC++ that did a RailCom cutout. YET. Well, I did some programming tonight and there is now a branch https://github.com/habazut/dcc-ardu/tree/digitalwritefast where you can have a look on what might be a 465us cutout. I don't know if the digitalWriteFast(BRAKE_PIN_MAIN, HIGH) (and later LOW) has any effect but I see a pause on the scope at what I think is the right place. If you want to check, a tigger signal for the scope is on pin 4. Hm, I don't have any RailCom detectors. Now sleep, Harald.
Can someone tell me what protocols are available for reading sensors on the DCC++ command station as it stands right now. I'm using S88 on mine with my own S88 Shield, but I'd like to know what else is available.
I did some code on branch railcomtest and I might have seen some current spikes that could have been railcom data: https://habazut.github.io/dcc-ardu/SDS-railcomdata2.png Yellow: DCC Voltage. Purple: Current = Voltage over 27 Ohm (that happened to be near) current measurement resistor. So if you want to test use the newest code on the branch railcomtest. Regards, Harald. PS: Enabling the right pins and reading the truth table of the L298 helps. ENA must be high and BRAKE must be high which results in DIRA=#DIRA through the XNOR gate on the motor shield.
I don't have extra hardware today. Actually I don't have railcom reading hardware at all, but I think if you would put it into the current loop (the connection beween Arduino and track) it may be able to read the bits with a Zimo decoder on the track I see alternating bit patterns between first and second half of the cutout which might be the two railcom channels. Regards, Harald.
@ChuckB , hello chuck are you looking for this https://github.com/DccPlusPlus/BaseStation/wiki/Commands-for-DCCpp-BaseStation ? greetings Michael
I got a little sidetracked experimenting with two branches. My question to myself was which way to go in handling the current detection and controlling each track separately. One method is much like Haba's, strip out an entire section of code that deals with motor boards (and can even allow more than one motorboard) but have to add extra power commands (1-on, 0-off, 2-main on, 3-prog on, etc) or use the method we have now, but enhance it. I'm looking at memory usage, speed, etc. DCC++ EX goes beyond DCCpp in that it creates a separate "motorboard" for each "channel". The channels can be on 2 or 3 different boards if you wanted. But for me, just the MAIN and PROG channels on ONE board are what I care about. So right now, we can enter <1> and turn on both channels with a response of <p1>. But we can also enter <1 MAIN> and turn on just main with a response of <p1 MAIN> or turn off prog with <0 PROG>. You could also name them whatever you wanted to create shortcuts, but the full names would be what we would standardize on for front ends like JMRI. The changes as they are now maintain JMRI compatibility because <1> and <0> still work. But, we would like to modify JMRI to take advantage of new features, or at least internally intelligently manage the programming track because the NMRA spec says the programming track should only come on when you are programming.
I've just about finished porting DCC++ EX to the SAMD21. It was a fairly simple port, but it added a lot of lines of code. The codebase seems to be getting more and more complicated, and if we want to add more motor drivers and more board support in the future, the code is going to be get hard to maintain very quickly. My solution was to gut all of the references to the Arduino Uno and Mega in the code, but that is clearly not a good way forwards. I am a proponent of focusing on platformIO for development because we can specify multiple environments with one board and the dependencies for that board in each environment. What is less clear to me is how to structure the code so that there aren't endless #ifdef statements all over the place. Any help?
I'm not sure either. At some point it seems we are trying to be all things to all people. I'm not sure how much more complexity we can add though. At some point we have added all the features that would increase the code size by much. I had wondered about an include file that would be customized for each configuration and you include than in the main .ino file at compile time. I thought of using EEPROM to store and change settings. Some people call it ifdef hell, but if it doesn't get too much bigger, it is still maintainable. If we write up a technical manual and keep it updated with what each unit and routine does and how things are structured, that would help. I really like the current changes and he way motor boards are supported in EX. But unless I can get someone to help change JMRI, those changes break it. Example, I want to change current to report this: <a 200 700 1500 2000> instead of <a 200>. I am going to turn it off in 1 line of code for now, but it reports pin reading, actual current, trip current, maximum current. Could throw in voltage there too, or just have a separate command for that as Haba added to his fork. Also, EX is capable of handling track power separately, though JMRI cannot. So right now you can do this:' <1> power on prog and main, returns <p1> <0> power off prog and main, returns <p0> <1 MAIN> turns on main, returns <p1 MAIN> <1 PROG> turns on prog, returns <p1 PROG> same for turning things off Now we could add this to JMRI, or just have JMRI continue to just know about 1 and 0, but internally turn the programming track on and off base on criterion for how programming should work on the prog track. What did you have to change to run a SAM D21? Is this the Seeduino board? I know nothing about it at this point. Other than what you would have to change for other Arduino boards like the pin numbers and timing values, what needs changing? We HAVE standardized development on PlatformIO, however we are trying to maintain compatibility with the Arduino IDE. People should be able to download the code, open the Arduino IDE, and upload it to the board. Now we could supply a HEX file, and we have an installer too. But if anyone wants to change anything, especially just a config file, people are going to want to simplest method.
True, but we also need to look to the future. A balance must be struck. That's the direction that I was heading in. If I'm going to work on this, what's the best branch to start in? Master, development, or something else? The timer is a bit more complex on the SAMD21, the pin numbers are different, and the biggest difference is that there's no EEPROM onboard. I am remedying that by adding an I2C EEPROM chip on my board. Overall though, it wasn't a huge deal of work. Now I want to bring it back into DCC++ EX though, and that will take some more work to make it play nice with the existing boards. I've designed the port for my custom DCC++ hardware that I'm working on, but the port should work on other boards as well.
Development would be the best starting point. Dev is tested and working, just still thinking through when to merge it to master. I would create a feature branch off development and work from there. As you say, if something is a lot of code to pigeonhole in, where is the line between a different build, fork, or even product. For example, Atani's ESP32 product. That is too different a platform to have probably been worked into this code, thought it could have been a fork. As it turned out, he took some of the code but pretty much wrote it from scratch since so much would have to change anyway.
I tinkered with this for a couple of hours tonight, and I think I'm going to go with offering the SAM port as a separate product. The code gets too gnarly trying to support that many boards, and I couldn't figure out a good way to keep it clean. David
Atani, I'm not up to speed on your ESP32 project yet, but I came across this device today and I was wondering if it would help you build upon and communicate to other products with your ESP32 project. If not, and your way past this device, forgive my current lack of knowledge, I will catch up. M5Stickc Internet of things Iot https://docs.m5stack.com/#/en/core/m5stickc Here is a short video of a some of its capability and uses. Best Regards, Kevin
The only problem I see with all of the M5 Stick devices is the lack of usable IO pins. I do like the direction that Hans has taken with the devices, but I am very hesitant at the idea of using one of these for a CS project outside of a single track output and even then the functionality will be very limited. With the 8 pin connector on the one end you have three usable IO pins of which one is analog input capable. On the other end you have two usable IO pins and both are analog capable. With only five exposed IO pins options are very limited unfortunately, but if you could pair it with an I2C/SPI device it may be usable.
I will check that out in combination with my current railcom detector build, you'll hear back from me! As soon as i solve the problem of disappearing tabs in JMRI :')
To whom it may concern & ALL; Were you aware of this previous thred 'Links for DCC++'. https://www.trainboard.com/highball/index.php?threads/links-for-dcc.95220/#post-980191 It was created to be the place to post finished DCC++ projects and in the future posting all Tested and Completed DCC++ projects there for first time user to pick out their projects. (i.e. DCCppEX when finished) The Site Administrator/Manager may want to consider placing the Links for DCC++ as a sticky thred at the top of DCC++ board. Regards, Kevin
Thanks, I have seen David's pages, I didn't realize they were trying to coordinate things there too. I'll look more closely
