#1 is the way to go. Each repository contains a specific project that is separate from the others. You never mix projects in separate branches within a git repository.
This is the approach that will reduce confusion some, the ESP code should very likely be renamed as well to further reduce confusion as shown below: There are variants of both that now support on-board WiFi, the Uno in an "official" format that has a WiFi SoC on-board that we would have limited control over (effectively only usable like the Ethernet code is today, a replacement for the serial interface in classic code). The variants on the Mega are more interesting as some embed an esp8266 which makes it a lot more feasible to use as a single-board setup, you would need to flash each side individually and potentially reset jumpers to flash each one. The primary reason I moved up to the ESP32 instead of my original Mega+ESP8266 is consolidation of components. After exploring the ESP32 further though I found a few other ways to further optimize and expand on the capabilities of the platform that would be challenging to replicate on the Mega+ESP8266.
I like option 2 for the repo and if i start making the app i can check out desired branch they select via a drop down. Then build compile and upload easily they would also be able to rapidly switch between the branches as well. I think though that even with classic we need to have a better build platform than the arduino to assist with building. <-- IMHO
If I may I personally wouldn't like to see it go that way. Probably lots of people out there that have no problem sticking with the limitations of the Arduino Uno, myself being one. It would be nice to know though that you could load newer code that hopefully is bug free and stable. Also keeping the cost as low as possible will bring more modelers into the DCC world. I'm sure costs could even be lower than the Uno with one choosing a clone if they wanted to go that route. I like the idea that if they choose to spend a little more on the Uno that would be a proven path with no 'ifs ands and buts'. I built and sold hundreds of IBM clones running DOS in the 80's and there was always the concern will it work with this hardware or software. Probably the reason I spent a little more on a Uno now. In the end I'll bet there will be a large percentage that end up going classic and will be happy to end the journey there. Those that want to go further will have the advanced option to pursue. I'm happy that so far the group wants to pursue both paths, getting the classic online as soon as they can. Sumner
What I am saying is the build system also I think the ino file can be left in tact just add the platformio.ini as an optional build system other then the Arduino. The base code would remain the same, the main thing is implementing proper changes to stabilize the code. I am also wondering if it's worth us keeping a classic repo with us trying to update the project. Instead of just adding the classic repo directly why don't we just link it via git submodule so we are preserving the original code but still including it and a git command to init submodules will pull from the original repo. Since that code does work for the most part any changes we make are our own and not directly modifying the classic code everyone loves Sent from my Pixel 4 using Tapatalk
_________________ I am not sure where to Post these comments, so I will post them here and see what you guys think: Comments on current sensing that often are overlooked: 1 - Not all Motor Shields support Current Sensing - if a Motor Shield doesn't support Current Sensing, then it can never be used to program a decoder 2 - Different Motor Shields sense current differently - Example one Motor Shield reads 1 amp as a value of 850 value while another Motor Shield may read 1 amp as a value of 1200 - This is a causes a lot of the decoder programming issues people have with DCC++ 3- Not all Motor Shields will work with common Auto Reversers such as the Tam Valley Dual Frog Juicer because they have their own Current Overload detection circuit - The Pololu Motor Shield is one example that will not support an Auto Reverser, yet it is often mentioned as a viable Motor Shield for DCc++without mentioning this limitation - Is it really a viable option? Just some thoughts learned the hard way - Larry
P.S. FlightRisk: Thank you for pointing me to the DCc++ Ex GitHub repository.. You guys have been doing a lot of good work I have a lot to catch up on - Larry
Bravo Larry, bravo..... This is exactly why I was pushing to limit the number of "supported" motor shields to those trully tested and veted......
All you need is a max471 or similar very cheap module and you can do current sensing for the motor boards that dont have it or for those who its inconsistent. Yes as you point out each motor board handles and reports current sense differently. We need at a minimum a table in the documentation for the right settings per board and hopefully can move the current sense setting to be board specific through setup rather than hard coded for all motor shields as it is now. I am fine with us saying we dont recommend or support a motor shield but again it needs to be well documented and tested good or bad. There are at least 5 or 6 I know of that work perfectly well so I dont want the limitation or sticking to set a number. I do totally agree before we call something good it should go through a thorough testing protocol by several different people before we call it good. Autoreversers are tricky and technically create a short and then switch so it's all about the timing with that. It's a good point to test it for sure. Usually it's a timing adjustment issue on them so would be interested in looking into the issue more and possible implement some timing delay in the motor shield short protection to make it work. I know you have to slow the PSX circuit breakers down for the tam valley stuff.
@Keith Ledbetter Here is something I am kicking around for Auto Reverse... https://www.trainboard.com/highball/index.php?threads/dcc-dcc-ex-district-reverse-controller.130451/
Keith: I agree that Motor Shields should be tested as you suggest by multiple people using a well defined testing protocol. That is a task that may require a fair amount of time The number of boards tested and "verified" will probably be a function of how many boards we can test and not some predefined number. The Arduino Motor Shield is so cheap that I am not sure how much effort it is worth to test a large number of clone motor shields with varying degrees of current sensing support versus spending time upgrading and adding features to DCC++. I think that one of the issues with slow DCC++ adoption is that people buy clone Arduinos and clone motor shields which don't support current sensing the same way the Arduino Motor Shield and DCC++ does, can't get DCC++ to work and give up with a bad taste in their mouth. It is hard enough to have a non-programmer Model Train modeler use an Arduino and DCC++ and "write code" without adding issues with clones that each work a little different. As an example, I saw one well followed and "knowledgable" Model Train Website (that I troduced me to Arduinos and DCC++) suggested that if you were having issues with DCC++ programming a decoder that you should increase the Voltage when the real issue was a current sensing issue. And that was from a "knowledgable" modeler. As far as Auto Reversers, you are correct about timing, but that is not always adjustable The Tam Valley Dual Frog Juicers sense a short and reverses polarity in about 200 microsec per the Tam Valley documentation. The Pololu current overload sensing is hardwired and operates at 12 microsec., so without extensive changes to DCC++ it will never support Auto Reversers. For an extra one amp of power on the Pololu for about the same cost as the Arduino Motor Shield, plus the need to assemble the Pololu I don't see the value in trying to make it work. My goal with DCC++ is an easier and more powerful system to control and program my layout than an NCE or Digitrax system which which allows me to spend more time building my layout. Just my thoughts. - Larry
Fully aligned. I dont think polly is a great choice either and I wouldnt recommend it. My point is we should document that it "works" has these known limitations and is not one we would recommend but there are bunches of them out there being used successfully if you dont have a reversing loop so I would not be in favor of "pulling it" from the code.
Larry, I couldn't stop sharing my experience here. I get better results with Deek robot shield than original Shield. I never be able to program my BLi loco with Original shield but with Deek robot I am. I really couldn't figure out what is causing the original not to program. I thought it is limiting the current supply. Just a thought. Sent from my GM1901 using Tapatalk
Maybe so, though I think what is pushed into the repository should be just Ardino IDE format since we are freezing that as it is very shortly. There won't be anything but bug fixes once we stabilize it. The EX version will have both PlatformIO builds and Arduino builds just because non coders may already face a challenge with the arduino IDE, but can at least follow simple instructions. A non coder having to install and learn enough about VSCode/PlatformIO would just give up. And your installer may be the best of all for someone who wants to run one command and upload the sketch. Me too! I owned a medium sized computer company selling into all sized businesses. I left a Tandy computer center I opened for Radio Shack and sold what was available back when you had to sell people on why they needed a computer. When the IBM PC came out I sold those but quickly moved to clones because of IBM's draconian re-seller policies and prices. I settled on "Everex" computers. But my all-time favorite for it's time was an "Otrona" portable that didn't last long sadly. It was just the coolest computers I ever saw for the next 10 years. Amber screen when most were green, tilting monitor. It ran C/PM but you with an option could run MS-DOS. In every way it was better than a Compaq sewing machine luggable https://otakugangsta.com/image/61343125540 But I digress Yes, Agreed! Most of that code is finished, you will see that Atani had a head start on it. I've added and tweaked some things. I am adding a voltage reporting option too. The big issue is that the Arduino and the current sense reporting of some boards is far from multi-meter accurate. So there is no way but experimenting and fudging values to have it run for all those options. Even then, we have to make it easy for people to be able to tweak the settings. So just like you might want to set a motorshield to cut out at 1200mA instead of 890, you may have to change the ACK_SAMPLE_THRESHOLD to be able to sense the current pulse for reading and writing CVs (maybe the biggest source of "It's not working" issues). I'm thinking of moving that to config.h so you don't have to go searching through multiple files for settings. I have also written the code to change current in milliamps. Much easier to know what you are setting than trying to figure out what pin reading each particular board will give. That too though, is a bit of an experiment to arrive at valid "current conversion factor"; a constant to multiply against the pin reading to get milliamps. Also there is code for knowing board limitations and throwing a new output code so JMRI knows that feature isn't supported rather than wondering why it isn't working. I think it is "current_monitoring_supported". Anyway, here are some of the boards included: Code: switch(type) { case ARDUINO_SHIELD: // Arduino motor board: 890mA == 300 sensor reading triggerMilliamps = 890; maxMilliAmps = 2000; break; case POLOLU: // Pololu motor board: 1.493A == 160 sensor reading triggerMilliamps = 1490; maxMilliAmps = 3000; break; case BTS7960B_5A: // BTS7960B motor board: 5.133A == 11 sensor reading triggerMilliamps = 5133; maxMilliAmps = 5000; break; case BTS7960B_10A: // BTS7960B motor board: 10.266A == 22 sensor reading triggerMilliamps = 10000; maxMilliAmps = 10000; break; case LMD18200_MAX471: // LMD18200 motor board with MAX471 current sensing: 3.0A == 22*0.0049 // frightrisk - in testing triggerMilliamps = 3000; maxMilliAmps = 3000; break; and where we define things based on what motor shield they selected: #if MOTOR_SHIELD_TYPE == 0 #define MOTOR_SHIELD_NAME "ARDUINO MOTOR SHIELD" #define SIGNAL_ENABLE_PIN_MAIN 3 #define SIGNAL_ENABLE_PIN_PROG 11 #define CURRENT_MONITOR_PIN_MAIN A0 #define CURRENT_MONITOR_PIN_PROG A1 #define DIRECTION_MOTOR_CHANNEL_PIN_A 12 #define DIRECTION_MOTOR_CHANNEL_PIN_B 13 #define CURRENT_CONVERSION_FACTOR 2.96 // ((5/1024)/1.65) * 1000 #elif MOTOR_SHIELD_TYPE == 1 #define MOTOR_SHIELD_NAME "POLOLU MC33926 MOTOR SHIELD" #define SIGNAL_ENABLE_PIN_MAIN 9 #define SIGNAL_ENABLE_PIN_PROG 11 #define CURRENT_MONITOR_PIN_MAIN A0 #define CURRENT_MONITOR_PIN_PROG A1 #define DIRECTION_MOTOR_CHANNEL_PIN_A 7 #define DIRECTION_MOTOR_CHANNEL_PIN_B 8 #define CURRENT_CONVERSION_FACTOR 9.30 // (5/1024) /.525 * 1000
Also, if you check the repository now, I have added the "Classic" version and gotten through all of the renaming in that repo. It isn't DCCpp_Uno anymore, it is just DCCpp as Gregg intended before he went away. We will have to rename our BaseStation repository to "BaseStation-EX" or whatever we choose ultimately and do some renaming there too. I think Classic is ready for us to fix the NMRI compliance and current sensing issues (and maybe merging in some features Gregg was using, but didn't merge). Then move on to "EX". https://github.com/DCC-EX
Well i got started on some code this evening for the installer. I have created a new repo for it so i am not interfering with current work on main BaseStation repos. I will hopefully get more updated this is just a start it currenting will be using MVVM and Material design. Should be simple and straight forward. Best part is all dependencies should be able to be downloaded via zip file and able to be extracted into the executable folder. Any PRs or help is welcome its been a while since i WPF so you will have to bare with me as i get the Data binding working properly again. (Wont display my custom class fixed SOON™). As for that i hope what i did was ok and i hope we can get this working fully. I will let you guys know while i test it out. I have an Uno and a ESP32 so i can def test both those out. I may order me a Mega as well and i am still looking into another motor shield to use as well. Anyways the project should build and at least run but it has issues so its like pre alpha XD
If a motor shield does not support current sense it *CAN* be used *BUT* it will require an external current sense solution such as the MAX471. I wouldn't recommend this approach for most people since there are many options available that support current sense that are drop in solutions. Yes, this comes from the different current sense output values from the h-bridge circuitry. The current code is only suitable for the L298. I wasn't aware that *ANY* would work with auto-reverses without some code modifications. Do you have references to any data on the failing h-bridges with the auto-reverses? Yes, it needs to be simple for the users to consume and use. Arduino IDE fits this nicely for most users. On the ESP32 I took a dynamic approach to this by calculating the rough mA value for each step of the ADC values based on the max mA and max ADC steps (4096 on ESP32). This resulted in a reasonably accurate current sense in mA, the ADC in the ESP32 has a lot of noise issues and thus I take the average of multiple ADC readings.
I wonder if the "noise" is caused by the high speed switching. If I can find my oscilloscope that is currently packed away it would be interesting to look at both the DCC sig line and the current sense line and see what they look like.....
From what I have heard it is more of a design issue in most of the module boards and/or the SoC itself. It would be interesting to see your results on the scope if you are able to capture it. I do have an issue related to symmetry of the DCC signal being non-optimal at times (it is within tolerances in the NMRA spec)
