Hi Folks. I've built a quad dcc buffer that works with the arduino 2560 plug-and-play, and the arduino uno with one trace cut and two jumpers. It has outputs for three power blocks and one programming block. There are analog inputs that will properly drive the arduino so that the overcurrent protection works properly with the various H-bridge drivers available. I have make KICAD files for the design and the files and a short writeup are here: https://dcc.wraith.sf.ca.us/ Spike Maul
Spike, could you explain how the buffering works, its value, and any implementation details (does this affect how you code). Thanks!
Hello bocabob--The "quad dcc buffer" simply takes the generated DCC signal off the proper pwm pins of the arduino and makes them available in a convenient five pin header that can drive the typical H-bridge for DCC++ use. The buffer board is designed to plug in on top of the 2560/uno. I'll put a couple of pictures on the web site to illustrate. The five pins on the header are signal ground, current sense input, the "enable output" pin, and the two (complementary) signals needed by the H-bridge power blocks. There are three separately available "main" headers available, along with a separate header for the programming track. Each main power block can be separately enabled/disabled and all four have the current sense inputs fed to pins on the arduino. The two extra "main" blocks are connected to "spare" pins on the 2560/uno and would need to have some code written to support them. The DCC++ code mentions the "free" pins available and I chose them after looking things over a bit. As it stands, no changes to any code is required to use the buffer board with the "main" and programming tracks. I like to throw away a $.99 26ls31 if I fry it, rather than the entire arduino if (when) I goof. BTW the enable can be jumpered active high or low on the board. Spike Maul
Thanks Spike! I use an ESP32 and once I get off the test bench plan a similar board which would be more of a motherboard than a shield. So I was specifically interested in the functionality of the buffering chips. I'd have to redesign my board as the pin out of the ESP32 is totally different. Also, it is 3.3v so would your circuit work or would there need to be a different set of buffering chips? You mention two complementary signals to each H bridge, is that the inverted PWM? So your H bridges are designed to take separate inverted DCC signals? I take it then that the function of the chips is the inversion.
Virtually every H-Bridge chip out there requires two signal pins (Left and Right if you want to call them that). They are the signal and inverted signal, same as you would see on the IBT7960 inputs. Spike's board is interesting in that it provides the outputs in a uniform format which is nice. I can see it being very useful when integrated into a larger package to provide multiple power districts. Spike, one thing I'd like to see is a way to use this as 4x OPS outputs rather than 3x OPS 1x PROG. Is it as simple as adding a few jumpers for ENABLE and SIGNAL?
Chips maybe, for modules the LMD18200 does not have two signal inputs but it doesn't have current sense output so you have to use the MAX471 (http://www.locoduino.org/spip.php?article187). The optimal driver may have to be built. The chip seems to deal with the single PWM input and does have current sense output, but it's only 3A. http://www.ti.com/lit/ds/symlink/lmd18200.pdf It is the preferred driver by Locoduino as they say the output is more symmetrical than other drivers. I like the idea of selectable OPS / PROG. I am thinking that PROG is best left on a separate system on the workbench and I think this is the practice of quite a few judging from the forums.
That is specific to that board type. The chip itself supports current sense but on that board it is wired to GND (similar to most inexpensive L298 based boards). If you use the chip directly though it wouldn't require the MAX471. I do like that it has a DIRECTION input pin whereas the L298 requires a split signal (virtually all other H-Bridge chips are like this). Now, as for the signal being split by the driver circuit, you should be able to just use one of the signal inputs as your DIRECTION pin on the LMD18200 board. At least that is my understanding from reading the schematics. Looking at the schematic for the driver-dcc and thor boards is interesting. I'm not sure how this might work for a RailCom enabled booster but it is an interesting approach and something that I need to explore a bit more as I do plan on enhancing the ESP32 code to support RailCom.
Hello Atani--the existing board could be hacked, for sure. One cut to sever the output of the dcc++ "programming track" output, and a jumper to the "main" track output. Likewise, cut the "programming track" enable and wire it to a free pin on the arduino. The current sense signals should also be rerouted in a similar fashion. My preference is for a separate enable for each "power block" driver, thus I have designed the board's three main outputs with separate enables, and likewise it has three current sense inputs that support the "main track" power blocks. BTW I've run the dcc++ code in an arduino uno, using a buffer board I modified, and it works well. I want to point out that *no* cuts or jumpers are needed on the uno or the 2560 boards themselves--all mods can be done on the quad buffer board. I could make a 2560 sized board that would support more power block ouputs and corresponding current sense inputs. The existing uno sized buffer board was as dense as I felt I wanted to deal with, given I was using my existing stock of through hole parts. Of course I could go to surface mount but that would cost me money as I don't have the parts needed in that form factor. Spike Maul
Hello bocabob--the 26ls31 is a five volt only circuit. I chose it specifically to minimize the "skew" of the two phases of the pwm signal that drive the H-bridge devices. There is another thread where concern is mentioned regarding the ability of some decoders to handle less-than-symmetrical DCC waveforms. Using the differential driver minimizes any possible skew. I think there are some 3.3v capable cmos versions of a differential driver available. I'd have to dig around in the data books a bit to find something. If you want to test a single device, you could take a 74hc151, wire the "select" lines and enable to ground, feed the dcc signal into data input zero of the '151, and use the complementary outputs to drive your H-bridge. There would be "significant" offset of the dcc signal (skew) due to the output configuration of the '151, especially as running at 3.3v makes for slower device propagation times. As a point, though, I used a similar ttl device (9309) that had the same kind of complementary output in my prototype, and I had no trouble programming my N scale decoders (digitrax and lenz). Spike Maul
I found this: https://www.ti.com/lit/ds/symlink/ds26lv31t.pdf The LM358 seems to be 3V tolerant, but I'm no EE - http://www.ti.com/lit/ds/symlink/lm158-n.pdf No need to alter any resistor values? It's been 40 years since I took shocks for jocks, so I'm flying pretty blind here.
In looking at the BOM to build this out, could you provide ratings for the below? Ref Qnty Value C101, C102 2 0.1 C103 1 10 R101, R108 2 4K7 R102, R103, R106, R107 4 10K R104, R105, R109, R110 4 1K