sounds like you have a mix of old and new in your source tree, there should only be one file ending in ino. I would start with a clean source tree (from the master.zip) and go from there. If you have DCCpp.ino then that means you likely were on the master-2.0 branch. I can generate a diff for that if you prefer.
I don't understand the reason for wanting to do this, why not just use multiple standalone DCC boosters? Tam Valley Depot sales a 3 amp booster for $55. If that 's still to much, or you just want the satisfaction of doing it yourself, there are plenty of DIY DCC booster circuits on the web. The boosters would handle the overload shutdown of their outputs, there would be no need for any change in the DCC+ code, and there would not be a limit on the number of boosters imposed by the DCC+ board.
Thanks, since I prefer the code with the diagnostic command, I'll take your offer, and get rid of all the other versions I have.....
Well, the basic system uses MD boards, not external commercial boosters......plus the definition of booster and what it included varies much AFAICT. Plus $55 is a bunch more that the $12 I pay for a high current MD board. Do you know of anyone using DCC++ with an external booster instead of a MD board?
Because it is possible. But really the current code currently will cut out both PROG and MAIN if either ends up in an overload condition. If you overload the PROG track you would then take out the entire layout if you were to chain boosters off the MAIN DCC signal to various districts. A bit steep for me but for some that would be worth it since they can get support from TVD. I do like some of their products and see plenty of potential usages for them. Though, for $55 I would be spending more for a 3A booster than what my entire DCC++ setup has cost me so far! That is with 3 Mega 2650 and 3 motor boards and multiple power supplies (various voltages and usages). I also have on order a handful of the 43A capable motor boards (will be using a slightly modified @David Bodnar design to chain them off of the base station) If you run into problems let me know. I can pull in functionality from a different upstream branch back into master branch if you find something is missing or needed.
I'm using some of the 43A MD boards also..... I tested the code you changed, and it appears to 'work', but there are some things that need to be changed...... The primary issue is how the power on/off is performed.....essentially, the power is never off, but us continuously being turned on, even if there was never an overcurrent condition or the power was manually turned off. That on/off function would be needed for JMRI. Even if the JMRI function is returned, the function ONLY toggles power, so if a district is off, in order to restore the district power, the entire system power would need to shut down and restarted. The idea of automatically restoring power if the overcurrent condition is removed is good, but a flag is needed to determine the power status is off because there was an overcurrent or not. If not, the power should not be restored. If it was because of an overcurrent, automatic restoration is a fine idea.
You are very right, I hadn't tested it beyond "it compiles". I have a mega sitting on my desk with a cheap 2A woo woo woo on it. I have now added a condition flag that gets toggled when an over current situation has been detected. The else block has been modified to no longer use the output pin to toggle power on again, it will detect that we are no longer "over current" and that we triggered an outage and then clear the outage. Something else I was thinking on is we probably don't want the power to come back on immediately after the over current condition gets resolved (or at least it should be configurable to come back on after N seconds of clearing condition).
That makes sense, so I'd guess that 4-5 serconds delay would be adequate/reasonable. Adding the structure for X number of 43A MD boards (or other types) would also be nice, along with separate values for current smoothing to 'adjust' the overcurrent trip points would make the system completely flexible....having that in place would allow DCC++ to be used on most medium sized club layouts, which is the direction I think it needs to go to get a much wider appeal. BTW, do you have any details about setting those overcurrent parameters on the 43A MD or other boards? DCC++ could force many manufactures to lower prices to compete with such an inexpensive setup.
I will see if I can create that sort of delay, should be possible with a count down approach for the checks. If we get N sequential "good" reads we can consider turning power on and releasing the condition. Very doable and would streamline it considerably. Will be doing just that For the default board types that DCC++ supports there are known "trip points" of roughly 1A and 1.5A (per channel on woo woo woo). So these could be kept as a hardcode of sorts. For the 43A woo woo woo, the values are a bit subjective. You really don't want to have it trip at 43A (way too high for model trains) but something more sensible like 5A which we can provide constants for. I am thinking we should provide 5A and 10A constants. @David Bodnar did a lot of great work with the 43A woo woo woo here: http://trainelectronics.com/DCC_Arduino/DCC_Booster/index.htm. I haven't used most other boards but many are clones of the ones that are supported by default in DCC++.
I'm familiar with Dave's stuff....... I think that 5A and maybe 8A cutoffs would be better. The actual current maximum is limited by the source power supplies used.....I use old laptop supplies with 4-5 amp limits. Beyond that, they start to reduce the voltage available, so the total power available is still limited. The issue with the 43A boards is the way it 'reports' the current. On the standard MD, all the current goes through a load resistor used to generate a voltage that's speced as voltage per amp of current......the 43A board actually presents a voltage that's a percentage of the total current capacity of the device, which seems to be easier and more reliable. Other MD boards report the current similarly to the standard, but the voltage value is entirely dependant on the board design and the load resistor used. In my world, using only the 43A boards would make sense. I don not used the standard MD board, but use the same size current load resistor (15 ohm) mounted externally. I only use that board for the program output, and it works fine. Will the structure for the number of MD boards supported be a runtime or compile option? Either method would be fine.
I was considering making it runtime defined but that would be a bit more complicated than doing it at compile time. There is also a second issue that needs to be resolved for the multiple motor boards, right now the code in CurrentMonitor::check() only really works for the default arduino motor board (2A version). There was a fork on github that purports to fix this for the Pololu boards but the cut off is just recalculated to ~900mA whereas the channels on the Pololu board should support ~1.5A each. I will be pulling a slightly modified version of that fork into the code so that we have proper cut offs for the various boards at around 90% of the output capacity of the board/channel (43A board would be configurable cut off) I think I missed this in the datasheet for the h-bridge. That is certainly a lot easier to implement and will complicate the CurrentMonitor::check() method slightly. As part of the implementation for multiple boards I will be looking at extending the current code to have switchable implementation for check() somehow. I could convert it to C++ (its pretty close now!) and use virtualization but that adds some overhead, not sure how much of an issue this will be though.
FYI, I have the schematics for the IBT-2 MD board that is the 43A MD board......except for the large capacitor that isn't on the schematic, it appears as accurate.... It should be attached to this comment.
I may have overlooked this, but wouldn't the simplest way to get two power districts be to edit the Base Station code so there was, instead of PROG and MAIN, MAIN1 and MAIN2? Automatic two power dstricts. Use a second, standard Base Station on a little track for programming off the layout proper. (PROGTRACK on a stick?!?) Of course, the overcurrent would still need to only shut down its own district rather than the whole thing. Randy
I want to run the DCC++ on an Arduino NANO, which is functional to an UNO......Greg only setup the code to run on a MEGA or UNO because of his design goals of not fabricating or soldering anything together. BUT, the NANO actually has more I/O than the UNO (it has 8 analog ports vs 6 for the UNO), and with a simple PCB, the adaper(s) to connect to other MD boards are self contained. So, first, I looked at the code where he checks for the UNO or MEGA, but I don't understand where that data comes from...I assume it comes from the Arduino IDE, so I need to find out how to get the code part the checks.....it should work fine otherwise. Secondly, is any progress being made with the effort to setup a structure for multiple power districts and MD boards??
The values being checked are coming from the Arduino library headers. But before going into that, does the NANO support more than one timer with the precision required for DCC++? I haven't been able to make any progress lately, my day job has been extremely busy, I will be returning to this project Sunday to see if I can set this up for my layout and will push the changes for this to Github.
Try compiling a binary (hex actually) then upload with an avr programming tool. The file should go to the folder where the original .ino is located and is .hex file.
I found this reference for the text returned by the Arduino IDE for each board type, which Greg is using in his code, so I added an entry for the NANO with the same code as the UNO, and it gets further along, but fails in a section where it's obviously trying to setup the timers for the MEGA. I'll try from a fresh copy of the code tomorrow..... http://arduino.stackexchange.com/questions/21137/arduino-how-to-get-the-board-type-in-code
Any recent progress?? BTW, I've gotten the code to compile for the NANO by connenting out some code, but haven't tested it yet.......
Sorry not much progress lately, I have been swamped with my day job for the last couple months. I hope to get some free time to work on this in the next couple weeks. Getting the code to compile on the nano is a start, we would need to see that it can generate the required DCC signal. Hopefully you have a scope so you can check this.
