mechEtroller v1.4 and v1.5

MechE-troller: the brushed motor controller that just keeps staying true to its namesake. Until now at least. The last update on this project was way back in last August (and even that post was months late), so it seems like time for the annual update. 1.3 made good progress, but reflected some fundamental goofs in designing with N-channel FETs. After the end of finals last year, I took some time to read up on a little more h-bridge theory. For any who haven't already discovered it, the H-bridge Secrets series of articles (by Andras Tantos) is a truly fantastic resource.

As referenced in my last post, I decided to move forward with a new unified gate driving solution in v1.4: the Allegro Microsystems A4940.

Reviewing the goals from v1.3:

• Swapping out the four individual gate drivers for the A4940 chip [check]

• Overall cleaner component layout, particularly with the capacitors for logic components [kinda...]

• Simplifying voltage regulation down to just one regulator (thanks to the A4940) [check]

• Switching to a surface mount crystal (just to standardize) [check]

• ICSP header (it's not worth the hassle of using a pogo ICSP programmer when I have the extra board real estate) [check]

• Possibly using FETs with a lower Rds (at least on the high side) [nope]

• Larger reverse polarity protection diode on the voltage regulator [uh oh]

• More capacitance across the power input (to provide buffering for larger motors) [check]

The lack of protection diode would come back to haunt me later. Besides that, this design and layout was a significant improvement. Upon receiving the boards, I went through my usual step-by-step approach to avoid immediately smoking expensive components. Voltage regulation worked well, as did bootloading and programming the microcontroller. All component footprints were fine too.

Problems began, as usual, when I tried to start switching the gates. Power levels seemed good, logic voltages were within range, but nothing would ever happen. A double check of the datasheet led me to try reading off the fault line. Sure enough, the chip was throwing a fault and locking its outputs. Another hour staring at the datasheet revealed the deal-breaker for this board: VDD was tied to ground. The above schematic reflects the correct VDD connection, after I discovered the error.

Version 1.5 started out as a simple correction to that one trace, but quickly grew in scope as I became more and more dissatisfied with the layout of 1.4. I think I nearly completely redesigned the board about three times before I finally cutting myself off, each change a few months apart. Issues I wanted to address were:

-The terrible capacitor layout that I'd been stuck with since the very first design

-The B+ solder point located right in the middle of the board

-The spread out locations of the logic headers

-The through-hole cap package

-The general mess created from the autorouted logic side

-The non-impedance matched lines going to the crystal

Here's how it turned out:

Pro-tip for the clueless like me: the frames library really cleans up your schematic

The long gate drive lines still make me wince every time I look at it, but that may have to wait for a future revision. I like how this layout could feasibly be built into a case, something I'll probably look into as the board gets closer to full functionality. So this is the design I'll be adopting in the future. The power capacitors are much closer to the action now (though still not quite ideal), and got converted to a slick SMD package. Similarly, I tried really hard to get the logic caps right where they needed to go. My linear voltage regulator and poorly isolated power and logic grounds probably aren't going to stop much noise, so I need all the decoupling I can get. Other notable additions include resistors on the gate drive lines, silkscreen that actually tells you how to plug things in, and (closer to) impedance matched traces (meander command in EAGLE if you're unfamiliar). Notable absences include a diode on the voltage regulator, which killed every single IFX27001 LDO in my inventory in a single night. After that point, I had to run the board's logic side off a separate 5v power supply.

So with new boards in hand, (and a new, very small workshop) I set about testing. The first board tested successfully for power and microcontroller bootloading, but kept throwing faults on the gate driver. With nervous flashbacks to 1.4, I chalked it up to hasty soldering, and began again on the second board. Frustration high from hours of debugging with the first, I managed to bodge the voltage regulator trace on the second board, rendering it useless. Coming back later, I finally put the third together, MOSFETs and all.

And it worked. For the first time ever. High side gates were boosted to the proper voltage, and switched with a clean waveform. The low side was flawless too.

A happy gate drive

With the hardware working, it was time to turn to the software side. I wrote a program designed to operate the bridge under a lock anti-phase drive scheme. Summed up very simply, this mode effectively runs the motor at each polarity for a different percentage of a set period. At a stop, the bridge drives the load forward 50% of the time, and in reverse 50% of the time, creating a brake effect. At full forward or reverse, 100% of the period would be devoted to driving in that direction. This can also act as a form of regenerative braking, where motor inductance forces current to keep flowing in the same direction even after the polarity switch occurs, charging the battery slightly during motor deceleration. Unfortunately, my efforts to duplicate this effect were only marginally successful.

Instead of working with the internal timer registers of the 328p, I tried to use a combination of Arduino functions and direct port manipulation to control the output pins. This worked, but only at a frequency of about 10kHz. Furthermore, that was only after removing analog signal reading ability and additional math used to produce more accurate outputs. It was possible to drive the motor, but not without a painful 10kHz whine and a strong vibration. Lots of current was wasted as heat, and control was basically non-existent. Finally admitting defeat, I went to go research some of the lower level functionality of the 328p chip, only to realize that one of my high side gate drive traces was not connected to a compatible pin. That effectively sealed the fate of lock anti-phase drive.

So after a few days of work on that control scheme, I decided to try one last option to get v1.5 working. That was sign-magnitude drive, or the method of only driving in one direction at a time, and switching the low side's duty cycle while holding the high side constant. This simply requires you to swap FETs when the time comes to spin in the reverse direction, and repeat the same process. What it meant for me was that I could cheat and just use analogWrite on the low side. As it turns out though, sometimes the easy route is pretty effective:

With the PWM pins effectively running in "parallel" with the rest of the code, I've had ample time to add in additional functionality without slowing down my switching speed. In my tests so far, I've been unable to even get the MOSFETs warm yet. Clearly I need to find a bigger motor and a battery with a higher discharge rate!

The next step for mechEtroller is getting the issues identified in 1.5 fixed for 1.6. Before sending out to the fab house, I'd also like to get current control and possibly encoder input tested, just to verify that it works. I think it may also be time to step up to 2oz copper on the next round to handle those higher currents. A final goal is to see if I can break the once annual cycle of mechEtroller updates.

Check back for more soon.