Far from stalling at version 1.2, MechEtroller 1.3 boards arrived in early January 2015, While still full of problems, I'm happy to report that this version has been the most successful yet!
1.3 uses a similar D2PAK FET package to 1.2, but with a revised layout. I'm finally convinced I've got a pretty efficient FET configuration which maximizes power track cross-sectional area, minimizes trace length, and provides very convenient diode locations. Disadvantages include having no great location to put the hefty power rail capacitor, slightly more complicated heatsinking geometry, non-unified power input and output thru-holes, and a loss of symmetry.
There are also a number of other improvement over 1.3 besides fixing schematic mistakes.The series linear power regulators are much larger, not because the current draw has increased, but because I had serious reliability problems during debugging with the less robust smaller LDOs. Encoder input is now supported, and is now routed to the 328 interrupt pins, The logic side layout is also more clean in my opinion.
Soldering was uneventful and decently easy given the wide spacing of components. Power inputs worked right off the bat, as well as microcontroller bootloading and programming. Even gate driver triggering worked smoothly with no load. As soon as the drivers began triggering the FETs while they were under load, however, the board began experiencing an uncontrolled resetting symptom. For a week I probed, soldered, and desoldered, convinced that poor capacitive decoupling somewhere in the voltage regulation, logic circuitry, or gate drivers was causing a low voltage dropout (triggering a reset until voltage levels rose again). After going through a number of capacitors and inductors of various sizes, I eventually discovered a crucial schematic mistake.
The capacitors on the gate drivers were accidentally placed across the Vrail and output of the driver, instead of ground. I don't know exactly what kind of nonsense effects this had inside the driver, but it wasn't very productive. 4 point to point soldered caps later, and the board could actually drive a motor!
After powering a couple small test motors, I ramped up the testing to a more challenging 24 volt electric scooter motor, powered by a Lithium Iron Phosphate battery pack rated at up to 800 A output! Quickly, it became apparent that further FET heatsinking was required. At first, in keeping with the low production cost goal of the project, I designed a simple flat aluminum plate that mounted to the top of the controller.
After some testing with
a handy plate of copper, however, it became apparent that this was no where
near sufficient for the heat output! So in order to continue testing, I grabbed
some relatively cheap heatsinks and thermal epoxy off of Amazon and mounted it
on.
I'm pretty sure this represents the biggest heatsink that can reasonably be fit on a controller of this size. An absence of time and proper equipment limited the extent of testing that could be performed with this setup, but the results were pretty impressive. At least one chair in the lab now has a small hole where a vise-grip clamped motor used to be. Despite the much improved heat sinking, temperatures were still quite high everywhere on the FET side of the board (even when driving smaller loads). For an unknown reason not too after this, at least one FET shorted out and ruined the prototype. It could have been a random metal chip or maybe something about the heatsink itself, but the epoxy didn't allow much of an opportunity to take it apart.
It wasn't until much later that I learned why the bridge operated so inefficiently. For a long time I've read of N-channel MOSFETs described as being "low side" transistors. Blissfully unaware of the ramifications of this, I've been using the same transistors (and more importantly, the same gate drivers) for FETs used on both high and low sides of the h-bridge. The problem (if not obvious already) is that the Vgs or gate-source voltage of my IRFS7537PbF FETs needs to be approximately 12 volts to operate with the lowest possible on-state resistance. However, in an H-bridge, nearly all of the voltage drop occurs across the motor, meaning that the voltage at the source pin of the high side FETS is dictated by the raw battery voltage feeding into the controller. If I was feeding the controller with a 24 volt battery, I would need a 36 volt (relative to ground) gate voltage to produce the required 12 volt potential between gate and source. Talk about a big mistake.
But hey, it's all a learning experience. As a bonus, now I won't be forgetting anytime soon. Solutions to this problem include: using a p-channel MOSFET or finding a gate driver that can dynamically boost its voltage to activate a high-side n-channel FET. It turns out that finding p-channel FETs with the same power rating as my existing n-channels is difficult and expensive, So that leaves the more complicated gate driving circuitry as the winner. Fortunately, Digikey (and Allegro Microsystems) are happy to help with the A4940 full bridge driver. This awesome chip packs all four gate drivers needed for high and low side n-channel FETs into one package with a bunch of bonus features. This will be my platform for version 1.4.
The list of changes I'd like to make in the next iteration includes:
• Swapping out the four individual gate drivers for the A4940 chip
• Overall cleaner component layout, particularly with the capacitors for logic components
• Simplifying voltage regulation down to just one regulator (thanks to the A4940)
• Switching to a surface mount crystal (just to standardize)
• ICSP header (it's not worth the hassle of using a pogo ICSP programmer when I have the extra board real estate)
• Possibly using FETs with a lower Rds (at least on the high side)
• Larger reverse polarity protection diode on the voltage regulator
• More capacitance across the power input (to provide buffering for larger motors)
Version 1,4 will get it's own update when the boards arrive,
No comments:
Post a Comment