1 -Was it the RasPi or the bridges who reset? Yep, we better insulate them galvanically, although that ain’t simple. My opto scheme won’t do, it’s too slow and this protocol is too time-sensitive. To maintain a bi-directional protocol with a the clock line (like SPI or I²C) we need 3 lines with respective optos, so one extra line. The hardware on the bridge is committed with I²C. I can’t use the SPI machine because one of the lines is taken for controlling a FET. To use something like a UART we need a crystal and we don’t have one there, and can’t put it there.
So, either we insulate the I²C bus or we have to put in some sort of I²C<->something converter. I found a single chip solution for I²C insulation that has the extra feature of converting voltage levels. It requires power on both sides of the bus and assumes all devices are fully I²C compliant, which isn’t true on the bridge side but it will probably work. Actually these solutions are still oriented for “near range” connections; longer distance brings transmission line reflections and crosstalk, which makes the receiver interpret 1 clock cycle as several cycles because of ringing. But I don’t think crosstalk will be a problem here (I know how to minimize it) and signal reflection shouldn’t either because the clock is generated by the RasPi which is fully I²C compliant (it limits the dv/dt or slope). Specifically if we put the insulator near the bridge, it should improve on what we have now. The chip is expensive but I think it’s worth a try. In this case the I/O expander also hangs from the I²C bus and will just provide some output pins from the RasPi. We’ll see about using Amélie’s chip.
2 -Having an extra line between the bridges just complicates things, and I think it won’t be necessary. The implementation can be: both bridges must receive an I²C packet every X time or they will shut down. This mode is activated right after receiving their first command after power-up, or it may only be active when the motor is running. If the RasPi stops getting answers from one bridge, it stops sending to the other. The answer times from the bridges are relatively well defined, so the time-outs can be short. Will this do?
3 – Okay, we’ll make do with the shorting of the motors then. 🙂
4 – To clarify: we’re talking about dynamic braking (wasting energy to brake), not regenerative braking (which has intrinsic problems, besides the bridge not being able to read back the current like that). When you say 20Amp braking, I suppose that’s based on the experience with the MD03 bridges and braking by inverting the motors, right? The current limit is in the P type FETs. The one I chose back then (3 years ago when I was pretty ignorant about power bridges) was the P type state-of-the-art for this voltage. We only gain with a better FET with the same pinout (I checked and there is one now, half the Ron) otherwise we’ll have to change the hardware significantly. With what we have now we could get 20 or even 25A peak, but that’s peak and we should monitor the FET temperature to make sure we don’t fry it. It’s complicated to predict how far we can go, because the FET isn’t actually being used 100% of the time.
Vnevoa: Extremely approved on all fronts, Master! 🙂 If you draw up the PCBs and buy the components, I can assemble and test it all. In July/August, of course. 🙂
(to be continued…)