Atani, thanks for including the links. In the draft specification for S-9.1.2 , chapter 3, page 8 and 9, the wording 'from twisted pair to coaxial' seems ill defined, in that it implies some ordered scale or grading of wiring methods. If it's supposed to mean 'twisted pair, coaxial or any other wiring method', then it should say that. Atani, regarding booster control, if I understand correctly, what you are saying is Power Stations (boosters) have no channel as feedback link to the Command Station defined in S-9.1.2. All one could do is use Railcom (or a separate channel outside of S-9.1.2) to send a signal back (I still have to read up on Railcom, to find out whether boosters are supposed to send their own signals)? A quick search for 'booster feedback' seems to indicate that L.NET (first time I'm coming across that [update: or is this just shorthand for loconet??]; seems to be a proprietary standard) allows feedback of that type (https://www.digikeijs.com/en/dr5033-adj-dcc-booster-3-amps-power.html ). So in DCC itself there is no way foreseen to reset a Power Station from a Command Station if the Power Station goes into overcurrent shutdown?
On the topic of boosters. Are support for CDE boosters considered? They are commercially and as DIY projects available. A CDE connection is included as standard in some command stations. Some manufactures also provide an adapter for CDE boosters if their CS lack a CDE port. For DIY so far I came across some using L6203 and one using ITB-2 and all of them include Railcom cutout and control over voltage output. There is a project (owner put it in public domain) where up to 4 CDEs can be connected to an Arduino an then to a L.Net network. Probably can be adapted for DCC++ as the boosters connects to a shield.
CDE would require supporting S-9.2.1 (linked above). The C and D pins carry the signal and E carries feedback if I remember correctly. This is the problem with RailCom currently is there doesn't seem to be consistency between manufacturers of how they receive feedback from the boosters and in turn it somewhat locks you into only using certain brands of CS and boosters together when the primary goal of standards is to ensure compatibility between devices. There are other similar instances (CDE as example). File an issue here to track it please. Make sure to tag the bug in the subject as S-9.1.2 and add the label as well if you can. Stuart who is working on the spec should be able to take care of clarifying it in the next draft revision. Correct. The power station interface is a one-way channel with the bitstream leaving the CS to any connected boosters. Correct, as noted above CDE is one example of extending the power station interface to support feedback from the boosters. Note that the feedback is only the RailCom data and not guaranteed to be more than that. S-9.1.2.1 is being proposed as a means to document and standardize a working approach that will allow distributed boosters with feedback coming back to the CS for processing of channel 2 data (channel 1 is typically used only for occupancy data whereas channel 2 contains POM responses among other data). Correct and the CS shouldn't concern itself with external devices. The CS has two primary jobs: generate a DCC signal and detect over-current/short on *IT'S* track output connection. What happens outside of those shouldn't concern the CS itself as it has zero control over it.
Atani, thanks for the detailed answer! Willem, I hope you don't mind that I'm replying to your post to try to explain a bit better what I am after. Your plan seems to be the best starting point. What I'm looking for is a simple affordable (sub-$10) power district controller with current monitoring, that can feed back status and occupancy to JMRI. Ideally these power district controllers could be told to either put DCC or (pulse-width modulated) DC on the track section they control. If one can make the power districts cheap enough, then there is no need to further divide into blocks, since the cost for block current monitoring would be comparable to the cost for a power district. If the districts (blocks) can be configured to either supply DCC or DC, then a mix of DCC and DC engines can be used on the same layout. If the block structure can be made fine-grained enough, the setup could be completely DC/DCC agnostic, except you couldn't combine DC and DCC engines into the same multiple unit consist. if I understand the hardware underlying DCC++ correctly, it shouldn't care whether it sends DCC or (PWM) DC; to the motor driver it should be the same. I don't know whether it's more convenient to make independent units from off-the-shelf Arduino Nanos and motor shields, or go your way to design a custom board around a chip with more I/O pins that can drive and read back several motor driver bridges. I assume your approach can be made to be more cost-effective. Alternatively one could also switch to really cheap (sub-$1) processors, but it might be nice to stay within the Arduino family, to reuse the existing DCC++(EX) code as much as possible. A related question regarding the driver chip: a bit more current and dissipated power capability might be nice. Could one use the Texas Instruments DRV8871 driver chip instead of the L298? It's about $2.50 at DigiKey.
Totally forgot about Railcom in the above. Of course the power districts need to relay Railcom data back to the Command Station; see e.g. https://groups.io/g/openlcb/topic/74128658#13262 . Maybe this all belongs more in the DCC++EX hardware thread? Although maybe it is not DCC++EX.
@S t e f a n Since you are using JMRI, check out the use of CMRI for accessories. JMRI provides for simultaneous connection to DCC++ and CMRI. Here's a link to some of my notes. https://www.trainboard.com/highball...-out-card-for-jmri.116454/reply"e=1141569 Whether I want to connect another turnout, occupancy detector, button, light, relay, etc., I connect the accessory to an open pin on the appropriate MCP23017 or PCA9685 board. Then I go to JMRI to define it and do logic setup as needed. No changes to the Arduino sketch have been needed (so far).
Thanks for the link, Ash. I think I must have read that thread before, but I'm still working on how it will all go together. So JMRI will talk to these I/O boards via a USB-RS485 interface, and I can just put more boards on the RS485 wire pair if needed? Neat. A hardware question: am I seeing it right that integrated CMOS switches for the DCC output (track signal/power) won't work, because of the limited current capability of these chips, and putting discrete FETs does not make sense, because then one might as well put a motor driver bridge ? It still seems wasteful to put a motor driver bridge per block, but so far it seems the most appropriate option. And another question: Is there a good motor driver bridge in the 3 ampere range (I'm just thinking 3A would be a good number for N scale) with a package that I can bolt to a 'normal' heat sink, as opposed to surface mount to a board that doubles as heat sink? Like, the L6203, even though it seems a bit pricey? I don't think I can just stop by my old workplace and run a board through the reflow oven, and even if I could solder a chip to a PCB thermal pad, the thermal characteristics of the few chips I have looked at (e.g. L298) seem more suitable for low duty cycle operation, and not DCC. Or am I just fine with the L298 for a few N scale locomotives, even with sound decoders and keep-alive capacitor packs?
@S t e f a n -- regarding CMRI One more thing in terms of using RS485 to connect accessories, is that it is independent of DCC. -- regarding motor boards I expect that more boards will be supported and documented on the DCC-EX website: https://dcc-ex.com/hardware/motor-boards/ I started with the Arduino motor board (clone); it was good to get up and running quickly. Also good to have something standard -- one less variable in the system. More recently, I have tried a couple of others. Identified as L9110S at Locoduino, my present plans are to use the 15A IRF3205 motor board, 15V-10A power supply and separate current sensor. The lack of sensitivity of the current sensor can be problematic for the program track. I have yet to test this setup with the most recent DCC-EX/CommandStation-EX. This prior post might give you some ideas, and this one. The external current sensor I have tried is the Pololu ACHS-7121, but it is +/-10A; 0A is a 2.5V / 512 reading on pin A0. A zero-based sensor such as the 0-10A version of ACS724 should be a better choice, but even that only provides 20% of the sensitivity of the 2A motor shield. I also did some testing with 43A BTS7960. While it has an onboard current sensor, I had better results with the external sensor. A second motor board would be needed for the programming track -- another BTS7960 could be used, but the better option might be to use a standard 2A motor shield with its current sensing and then the onboard current sensor of the BTS7960 should work for the main track. Remember that if you use a non-supported motor board, there will be setup and/or code changes required to ensure that you will have valid overcurrent protection settings, in addition to having the programming track functional. [I understood how to do this in an earlier version (DCCppEX).]
Sorry it appears that way. We have just been responding to a lot of comments that are from people who already use DCC++ Classic and are excited about the changes. We are almost doing too much in that there aren't enough people to put everything together that basically amounts to the same effort a commercial product would have to write, document and launch. We are lagging behind on documentation, but there is no release yet. We are just in beta test and hope for a Nov 1 release. The quickstart guides, website, pdf manual all have to be changed or finished based on changes we had to make to the code. Our main goal was to make something simple and affordable. That is why Chris and Harald had the genius idea to find a way to eliminate jumper wires. Just stick one board on top of the other. That is why I created the exWebThrottle with Mani Kumar and asked Dex write an installer. So a user who "just wants to run trains" as we say (we call them "Conductors in DCC-EX lingo), can now do something in 3 steps or less (that is my motto because I am lazy 1. Download an installer or a zip file to use with the Arduino IDE 2. Install the software 3. While the computer is still connected to the Command Station, open exWebthrottle. You can even just run it from our web page. https://dcc-ex.com/throttles/ex-webthrottle/ (to just run the throttle without the instruction page first or downloading the zip file to run it locally, check this out: https://dcc-ex.com/exwebthrottle. You do have to enable what we cover in the instructions for it to run) That's it, in literally 5-10 minutes, you can run trains. You will find on the glossary on Discord an entire language we speak to stay on track. "Three Steps" is a big one. We took it one step further and have a WiThrottle Server build into DCC++ EX, so if you want to add a WiFi Board, you stick that on top, run 2 jumper wires, and then connect with Engine Driver on your phone and again, you are running trains. Other than installing Engine Driver on your phone, there is NO INSTALLATION and NO CONFIGURATION! We sense that you plugged in WiFi and on what port and enable it automatically as it's own AP (Access Point). So you connect your phone to that in its WiFi settings instead of your home network. You will see a network that begins with "DCCEX_" in your list of devices. If you want to connect to your home network instead, you add your login and password to a config file and load it again or type 2 commands we give you into the serial monitor without having to upload anything. As always, thank you Sumner for your support and advice. You helped get us here!
@Atani Mike, are there other proposed things beyond this power paper related to he DCC signal, turnouts and accessories I should be aware of?
