You are correct. On the IBT-2 tie pins 3 & 4 together and then connect to pin 3 of the Arduino (Uno or Mega) for the Main Track. This should toggle the outputs of the IBT-2 on or off respectively. I do not use the DCC++ program directly to control the IBT's but a secondary Arduino Nano to control multiple IBT's for multi-block control and use IBT pins 3 & 4 to control the output from the Nano. Dan
New kid in the block https://www.infineon.com/cms/en/tools/landing/infineon-for-makers/arduino-shields/ DC Motor Control Shield with BTN8982TA
So what's the difference between their ifx9202ed vs. BTN8982TA boards? What's the difference in the chips. I'll try and read the specs, but that won't tell us everything in the application we are using it for. I know the BTN board is two chips and high current (11A), but has no power connectors. So you would have to create something for that. The IFX board has a single chip and handles 6A. Are the pinouts the same as the Arduino Motor Shield? And what other specs are there that are important, like its current sensing and short circuit protection. It would be nice if you could shut that off on these boards so they don't kick in before the DCC++ software senses the over current and shuts things down. I know the "auto-reset" doesn't work on at least one of the boards that cuts out faster than the software does and you have to power down reset to get working again.
Well honestly depends what you want. I like the btn chip as it has been shown as the cleanest wave but that shield only has ability for 1 h bridge so you couldn't do both a main and a programming on same shield. The fix is a new chip as far as I know which I'm sure works fine. As you say we need the spinouts and details to be able to test etc. I wish they made a dual h bridge based on btn. Again devil will be in details of underlying possible changes to dcc++ code if pinout is not the same as original motor shield or it will defeat the purpose of the shield having to connect between the pins of the arduino and different pins on the shield. If I was smarter than I am I would figure out how to do a dual h bridge shield based on BTN that would be plug and play like original motor shield. It's all open source so doable but would take someone with a bigger brain then me.
https://www.infineon.com/cms/en/product/evaluation-boards/dc-motorcontr_btn8982/ https://www.infineon.com/dgdl/Infin...N.pdf?fileId=5546d4624ca27d02014cb20b89867eed
This shield fits Arduino but has different pinout and control logic compared to 'classic' Motor Shield Rev.3. It requires two PWM signals, just like the 43A IBT-2 shield, and its current sensing outputs are routed to A0 and A1. So in a nutshell it cannot be used right out of the box. Still should not be difficult to design a compatible shield with a pair of BTN8982s and necessary PWM inverting logic. Perhaps a low power single chip H-bridge could be added for Programming Track, if PCB space allows. (In fact, I got a handful of BTN8982s right for this purpose, but then my IBT-2 arrived)
A pair of ibt 2s in a shield with same pinout design would be awesome. Again I only know enough to be slightly dangerous but I can't imagine a shield that is plug and play on top of uno would be that difficult but it would require some design. I personally did some on a proto board but then once Atani started his new command station I sort of abandoned further work since this is more outdated.
I might take a liberty to hack one some day, before I get distracted by ESP32 Programming Track can probably be served with something as small as L272.
WillemT mentioned full bridge chip from Allegro here https://www.trainboard.com/highball...ones-dcc-generator.115515/page-5#post-1089384 Looks like a good candidate to drive Programming Track.
Something like this: The 6-terminal connector block carries VCC, GND, and two pairs of Main and Prog outputs. Perhaps not enough copper for serious layouts, but should be sufficient for 3-5 Amp setups. A couple of DNF resistors allow for Uno/Mega configuration. Also I haven't figured how to inhibit Prog track properly, might take another design round. Attached is draft schematic, feel free to comment.
These particular parts are not well suited for easy heatsink mounting. Their bottom pads would have to be isolated from common heatsink, or two separate heatsinks would have to be used. Flipping might work if mounting the shield high over Arduino board, which I personally would escape. The original IBT-2 design has been tested without heatsink at 18V 5A (http://trainelectronics.com/DCC_Arduino/DCC++/), resulting in 66C temperature. Still a heatsink with or without small fan could be fitted with some thermo glue I guess.
https://www.cytron.io/p-10amp-7v-30v-dc-motor-driver-shield-for-arduino-2-channels Just happened across this no current sense though, unless i missed it when i scanned over the stats. Maximum Motor Current: 10A continuous, 30A peak
Nice start Tim. I would add current sense in designing with ACS712 current sensing integrated on both. Also I agree I would want to be able to add heat sinks. While to your point most will not need, if you can only run to 3-5 amps there are other alternatives. If you need to run over that this is your best alternative so I would want it to handle up to 10A for sure.
I'll take a better look at heatsink mounting Keith. Maybe going for through hole parts with screw mounting holes, like TO-220. Could turn out to be rather bulky for traditional shield sandwich approach though. For the current sensing, BTN8982s have sense output, and so does the Allegro bridge chip. Both bridges' sense outputs are fed to a couple of opamps. With proper resistor selection those should provide right voltage to Arduino's A0 and A1 analog inputs. Is ACS712 really that good?
the ACS712 is good and reliable but it's more that the BTN8982s that I have played with have been entirely unreliable and highly variable which is the biggest downfall of the chip. Everything else about the chip is basically perfect for our app.
Where do the numbers come from to determine the CURRENT_SAMPLE_MAX values? If the reading on the pin is 1.65V per Amp, what is the formula that figured out 300 is equal to 800mA?
I explained my understanding of the figures in this post: https://www.trainboard.com/highball...tion-and-interface.84800/page-86#post-1041300
Am I the only person who doesn't like the idea of current measured as an obtuse number instead of something in Amps or milliAmps? With everyone experimenting with other boards that may have different relationships of output voltage to current (like the 1:1 ratio in the Max471 current sensor board with LMD18200 board), I was thinking it would be nice to create a layer of abstraction instead of hard coding current sensing. Does anyone see a problem with this: In Config.h, create another type by adding "2" to the existing "0" for Arduino Motor Shield and "1" for the Pololu board In Currentmonitor.h make CURRENT_SAMPLE_MAX now hold actual current in milliamps and not a complicated computed value and change the structure: Code: struct CurrentMonitor{ static long int sampleTime; int pin; float current_raw; //change name from current to current_raw float current_milliamps; // add this variable char *msg; CurrentMonitor(int, char *); static boolean checkTime(); void check(); }; Change the motor controller board definitions in DCCpp_Uno.h like this: Code: #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 CONVERSION_FACTOR 2.96 // add this computed from ((Vcc/1024)/volts_per_amp) * 1000 // a board like the MAX471 would have a conversion factor or 4.88 Change these in CurrentMonitor.cpp: Code: CurrentMonitor::CurrentMonitor(int pin, char *msg){ this->pin=pin; this->msg=msg; current_raw=0; //change current to current_raw current_milliamps=0; //add current_milliamps } // CurrentMonitor::CurrentMonitor and Code: void CurrentMonitor::check(){ current_raw=analogRead(pin)*CURRENT_SAMPLE_SMOOTHING+current_raw*(1.0-CURRENT_SAMPLE_SMOOTHING); // compute new exponentially-smoothed current current_milliamps=current_raw*CONVERSION_FACTOR; if(current_milliamps>CURRENT_SAMPLE_MAX && digitalRead(SIGNAL_ENABLE_PIN_PROG)==HIGH){ // current overload and Prog Signal is on (or could have checked Main Signal, since both are always on or off together) digitalWrite(SIGNAL_ENABLE_PIN_PROG,LOW); // disable both Motor Shield Channels digitalWrite(SIGNAL_ENABLE_PIN_MAIN,LOW); // regardless of which caused current overload INTERFACE.print(msg); // print corresponding error message } } // CurrentMonitor::check and last, for case "c" in SerialCommand.cpp, make it look like this: Code: INTERFACE.print("<a"); INTERFACE.print(int(mMonitor->current_milliamps)); // changed to milliamps INTERFACE.print(">"); break; In particular let me know if you have comments on the CurrentMonitor::Check routine changes
Indeed, BTN8982 current sense output is rather sloppy. The application note proposes several methods to enhance tolerance: I believe current sense accuracy is more important for Programming Track, where Ack detection deals with current bursts of tens of milliamps. For Main Track, it might be more important to have robust overcurrent/overheating indication to quickly respond to. Of course decent current measurement over Main track would be great. It should not be difficult to fit ACS712 on the board afterwards, it's that I'd like to first see how big the BTN8982 current sense error is in reality.