RageBridge: The Next Generation

[David Attenborough’s voice]

It’s autumn at Big Chuck’s Robot Warehouse & Auto Body Center.

As the cold descends over New England, the supply of Mountain Dew and burritos becomes scarce…. and we see the Charles is busily preparing for his winter hibernation.

Deep inside his expertly crafted nest of meticulously hand-picked post-industrial waste, we see him studiously lining his abode with layers… of warm, insulating motor controllers.

The Charles will get his nutrients from these motor controllers for the rest of the winter.

He will periodically set them aflame, taking in both their radiant heat… and exacting sustenance from the magic smoke.

[end David Attenborough’s voice].

Anyways, what? I have no clue how it happened, but the entire first run of RageBridges is sold out! I am retaining a few units for legacy and warranty fulfillment, but other than that… It’s gone! I never actually expected this to be the case, by the way – RageBridge 1 was more of a crapshoot than I care to admit. I wouldn’t say it was pushed out the door, but I was definitely not confident about it.

However, it has proven to be a solid performer, and I have only ever gotten a handful of units back for failure analysis. That means there are several dozen healthy and working Rages in the wild. DOZEN!

I never said I was Foxconn.

The success of Generation 1 means it’s time to roll out the changes I’ve wanted to make since Generation 1, since even if I am involved something that’s in production, I still start thinking about version 2 before the version 1 is fully out the door. From the tales of experiences of Rage users, there is really not too much to change. However, I think there’s two big threads of “customer wishes”:

  • First, that dual power input setup is actually really tacky. I did originally design Rage to just drop into the wiring harness for two Victor 883s, and it just stayed that way up to “Ship It!” time. There was no good rhyme nor reason for making the power inputs on two sides of the board.
  • Wiring the two halves of the controller together into one more epic one. Hypothetically, Rage can drive up to 90 amps continously and 180 amps max current limit (or even more if you shut off the current limit!)
  • I’ve gotten a handful of reports that the board is spotty in functionality above ~33 volts. I highly suspect this is related to the inductor still being marginal in value, which was an issue I fought on the original board revision before it started working. The symptoms are the same – the regulator resets. I’m not sure why the original test units didn’t do this, but may it has to do with aging of the components? Hell if I know. However, at least I know how to fix it.

So, to the physical form factor of the board, I’ll have to do a better job at component verification, and play with the layouts some. Past that, in terms of part selection, there are some major changes I want to experiment with.

RageBridge 1, like many of my past motor controller experiments, uses several discrete half-bridge drivers instead of more integrated chips. It was great for learning layout and how these things work, but arranging 4 of them on a board is tedious and takes up more space than it needs. Their drive strength is also more suited for larger controllers, so I’ll definitely come back to them in the future. For months, I’ve been scoping out the market of integrated H-bridge gate drive chips which will let me wrap the functionality up into one chip (or at most two chips). I’m willing to try a few different H-bridge drivers, on different board revisions, if that’s what it takes, but I think many of the market options are equivalently functional.

I settled on the Allegro A3941K, which offered a good combination of reasonably easy to use package – TSSOP is my baseline for “pain in the ass electronic part packages I never want to deal with – drive strength (current), and lack of other fancy things like current sense resistors, since I’m still keeping the Hall Effect current sensors this time around. The thing that sold me on it was the retainment of the “PWM + Direction” input topology. While it actually has two inputs “PWMH” and “PWML”, one of those inputs can be held low and the other provided the PWM duty cycle to effect synchronous rectification if the “SR” mode, which stands for… guess what, synchronous rectification, is enabled. Then, the PHASE pin is basically the “direction”. This is the same effect that I had to add a 74LS08 logic chip to RageBridge 1 to achieve, since the IR21844s are only half-bridge chips and so the “direction” output is actually four selecting pins.

Next, it’s time to catch up with the latest in distressingly current-dense power MOSFETs. I’ve been drooling at the newest Infineon HSOF package units, like the IPT007N06. It’s so very beautiful and double-side heat sink-able….

Also, expensive. The competitor I selected against it is the IRFS7530, which has all the keywords I’m looking for in its applications description (“Brushed DC motor! Brushless motors! Battery powered! Synchronous rectification! Half bridges, full bridges, and onion-ring power supplies!) so I assume IR made it just for me.  Plus, even though D2PAK-7 is a bit of a weird package, it’s not nearly as proprietary as Infineon’s HSOF right now. The switching characteristics, namely the gate charge, aren’t any worse (…not are they better) than the IRFS3006 units on RageBridge 1. However, in the end, it doesn’t even matter, as Infineon and IR will soon be the same. Geez, way to make me switch to Fairchild and NXP, guys.

I’m also making an effort to transition to all SMD parts this time to lower assembly cost and streamline the process. This includes the big electrolytic bus capacitors. I went on a capacitor shopping spree prior to starting board layout, too, and realized that they pretty much don’t make better caps than what I’m already using, at least in terms of my size constraints and high voltage demands – it’s a whole ‘nother world in low voltage land.

With no further changes planned except those parts, I started creating new devices definitions in Eagle and playing with the major part layout. Power board design is as much about layout as anything, and having the Big Power in locations easy to join with huge traces and power planes is critical.

One of the candidate layouts. This one has the advantage of keeping both the big power and ground planes in the center. Check out the big Panasonic J package 16mm electrolytic capacitor profiles there – each one, based on the one I specified, is 1000uF. That’s actually a healthy 25% increase from RageBridge 1, though it’s still not to my liking…

An alternative layout with three of those caps. Now I’m happier, but sadly I’m much less enamored with the layout in general. Looking ahead a little, the right side of the board will be difficult to route in terms of getting the current sense signals and rightmost two gates through.

Sadly, three-across on the Panasonic caps juts way out of the 2″ board width. I’m trying to keep to the dimensions of Ragebridge 1 so transitioning users will not have to make much of a change in mounting facilities… myself included.

Let’s start playing with this layout for now. I’ve added candidates for input and output pins and drawn in some preliminary power planes.

The wavy header layout to the left is courtesy of Sparkfun. I’ve found their wavy-header hole footprint to be very useful, since it holds the headers in place as you’re trying to solder one pin down. You’d think I was about to slaughter them by the way mine try to wiggle out of the holes.

RageBridge 2 will ship with headers in the kit, but they will not be assembled. This cuts down on the thru-hole processing time and cost. The single-line layout will also benefit those who are still into soldering cables in place.

I’ve gotten a little ahead here, so let me explain. First, I’ve fleshed out the power plane routing more. Next, and probably more importantly, I already found ways to break out both the gate drive and current sense lines using both the top and bottom of the board, in the alleyway between the MOSFETs’ drain tabs and source legs. This actually means everything else will be easy! I have also put down the logic power regulator, this time actually following the advice of the LM2594HVM datasheet for one-layer layout.

I’m slowly growing the schematic as the major power routing occurs, so the jumble of parts on the left side is growing.

With all the passives and accessory parts loaded in… Well, at least there is physical space for everything, so that’s a good sign. In keeping with Rage tradition (and to keep fabrication easy), I’m putting all components on the top side.

One of the challenges in routing ICs with many required peripheral passive parts is you can get almost to the end and discover the rest is actually impossible. Hence, the starting configuration is important. The patterns that look the best might not be the best placement. In this trial layout, I’ve put all the gate drive resistors and bootstrap capacitors off to one side, and the logic side passives on the other. It seems promising!

Trying to play a game of snake…

There’s always that one trace you forgot about. At least this one wasn’t bad!

After getting pretty far into it, I decided to start over with the chip in a different orientation. I’m used to routing using SOIC packages and 1206 passives, where I can plop a via down and change layers whenever I want. Here, in the TSSOP package, the center pad really prevents me from doing so. I’m tempted to stray from the manufacturer’s recommended land size so I can squeeze some vias in the gap between the pins and the pad.

This new orientation ended up working out much better. However, it meant that I had to move the mounting hole closer to the left edge as a compromise. That’s fine, since this Rage version cannot share the same heat sink design anyway.

After another few evenings of playing the game, this is pretty much it. It might look daunting, but the rest of it actually went quite smoothly due to the severely reduced discrete passives count. The only reason I was able to devote far more space on this board for FETs and capacitors (the meat and potatoes of a motor controller, I might add) was because of the new gate drive ICs.

We’ll see if that comes back to bite me.

The little cheeky label in the middle refers to the fact that the top power plane has to neck down to about 0.35″ wide to clear the set of TVS diodes next to it. This means the area is kind of marginal for the current levels I want to push through the left set of FETs. I said this was a revision 1 board… To try and mitigate the trace detonation circumstances, that area (and other similar areas) is getting a stop-mask rectangle (pictured) and likely also a rectangle of solder paste deposited for some metallic reinforcement in the area. Worst case, I will have to commission copper ‘trace boosters’ like a lot of motor controllers have.

With some minor adjustments and board art, this is it.

Wait…

After letting this design sit out of sight for a day or two, I came back to it to add a 5V rail TVS diode and to move a few traces to be less twisty and convoluted. Now we’re ready to send out…

Check out the extra “combine” option – this is directly in response to Consumer Demand™, for people who want to run a single larger motor. RageBridge v1 is technically capable of this, as both halves are driven off the same hardware timer, but the firmware was never updated to fuse the two current sensor readings and modulate the PWM as one.

RageBridge2 revision 1 should get back to me next week.

brushless rage

Uh oh…

Something that has been eating at me for a long time is I’ve technically never made a functional brushless motor controller.

Okay, to clarify, I meant “to my liking”. 6.131-troller (Face Vector Modulation) worked just fine, cementing my love of hardware and hatred of programming and software. Next, Melontroller2 did work in RazEr Rev for several months before I swapped it out. But it was very unfinished; the firmware was left in a crude state and I never went back to change it. After that, all of my controllers began suffering from the Great Bypass Capacitance Drought of 2011-2012 before I discovered the issue with Ragebridge the original.  TinyTroller, the last brushless I attempted, ended pretty much in miserable, abject failure.

Perhaps it’s time to try again. Like what motivated me to build RageBridge v1, I find myself often disappointed by the small brushless controller market. The physically small ones (Hobbyking et. al, model controllers) are bare-bones and lack features like torque (current) control and Hall sensor inputs (or even Analog inputs). The good vehicle ones tend to be very bulky (like Kelly KBS controllers) or functional but extremely power limited (Jasontrollers/Wangtrollers). Furthermore, the Kelly controllers seem to have a control discontinuity in regenerative braking mode, which manifests itself as the vehicle suddenly jerking.

Granted, Alien Power controllers do exist, but I haven’t personally used one to know what they’re made of. Anyone know more about them and if they have a good reliability track record?

Brushless Rage will therefore be my redemption experiment, and maybe a future product down the line. For now, the specifications I’d like to hit include:

  • Sensored to start with. Both idiomatically, for simplicity in development, and literally: One thing I really like about the Jasontrollers is the use of Hall sensors only at low speeds, where they make sense. At high speeds, fixed Hall sensors introduce problems in phase lag. In reversing scenarios, they have a pretty large hysteresis band.
  • HV inputs – up to 60v is my preference, since I like running high voltage and lower currents. 17-60v (nominal ratings being 24-48v) is a common input voltage band.
  • 50 to 100 amps, much like Rage, since it will be fairly similar in size and device usage.
  • Relatively simple – Kelly controllers are set up for several different kinds of throttle and brake inputs and have features for more complete vehicles, such as contactor drivers and reversing beepers and whatnot. Jasontrollers have cruise control. I’d like to have at most 1 throttle input, 1 brake analog input, one switch (e.g. ‘reverse’), a blinky LED, and a…
  • Small number of operating modes. Conventional “one throttle, one brake” with reversing switch; One-throttle-only (drag braking, non-variable braking or just complete coasting), and one-input forward and reverse (continuous control variable, like for vehicles under closed loop control). These are the modes I see most often in small project vehicles.
  • High-resolution torque control. It’s fairly easy to sense current every PWM cycle and manage it from the reading. This is not quite the same as RB’s current limiting, which does not occur synchronously with PWM.
  • Sinewave output. This one is a bit of a stretch goal, but I would like to make a sine output version. The interesting thing is, regular “brushless motor” driving (block commutation) almost requires a different architecture in code than a sine wave interpolator. It may actually be tacky to be able to switch from one to the other. Small sinewave controllers are starting to make inroads into e-bikes: I know of some that do, but they apparently suffer from slow maximum speed.
  • “Training” mode, which is featured on most Chinese e-bike controllers now. Spin the motor up open-loop (or tell the user to give it a whirl), record Hall sensor transitions, apply to your state transition table. This is definitely another stretch goal, but I really want to give this a stab.

First, though, is getting a stable hardware base for development.

Component choice-wise, this controller is a bit beyond the capabilities of the ATMega328 I am fond of for DC RageBridge.The chief reasons are lack of timer compare outputs (for PWM generation), and the killer, a very slow ADC. I’m going to move up one tax bracket to the ATMega32U4, the current chip of the Arduino Leonardo, because it actually does have a “PWM6” output mode where it will generate three sets of complementary PWMs, all in hardware. This is common in new and motor control optimized microcontrollers, but I’m all giddy and stuff since it means I will not have to bother with external hardware to generate complementary PWM. The ADC is also faster – still quite slow by modern micro standards, but it’s workable. I calculated the (more or less) exact times needed to perform the analog read operations I needed to do per PWM cycle, and that result was what told me that 328s were hopeless, the 32u4 would be a logical step up, and that everyone uses ARM Cortex chips for a reason.

I also spent quite a few off-cycles perusing Allegro’s selection of 3-phase motor drivers. They come in all sorts of sizes and features for many different industries – some are clearly designed for automotive fans and blowers, for instance, and others for servo drives… I’m currently fond of the A4910, which is basically three half-bridge drivers and current sense amplifiers put into a box. TI has some very feature-packed chips in the form of the DRV8301 and its related parts, but in talking with Shane (who literally does this for a living now, not just figuratively any more…), I think they’re a bit beyond the requirements of this project right now, and could be facing End-of-Life in the near future.

Here is a “parts splattering” with one proposed layout of the components. The bolt pattern and size for Brushless Rage (name to be determined – suggest ’em in the comment box) is the same right now as for DC RageBridge2, but may not remain such if I find that another configuration is better suited to the task.

I suppose the “minimum viable product” of this thing is “Kelly KBS destroyer”.

One example implementation of the mode switches might be:

  • Neither jumper set: thr1 controls current up to imax, thr2 controls current down to imin (variable braking, negative current), rev controls… well, reverse. thr1 and thr2 both at minimum would just be 0 current (coasting).
  • Jumper mode1 set: thr1 controls current up to imax, no thr1 means a fixed drag brake where the imin potentiometer is interpreted as a percentage of imax.
  • Jumper mode2 set: thr1 controls current symmetrically between imax and -imax, and reversing is handled automatically (One-input torque control mode)
  • Jumper mode 1 and 2 both set: thr1 controls speed as hard as it can, with Vcc/2 as a center voltage (zero), using imax and imin as ‘acceleration limits’ only (One-input speed control mode with torque ceiling, kind of like how DC Rage is set up)

There’s a long way to getting this board better defined and routed. For instance, I might just go totally discrete with the gate drive (back to good ol’ half bridge drivers) and use my favorite Hall-effect current sensors instead of current sense resistors and amplifiers. I will have to decide how to balance “new things” with debuggability – the best case for which is only changing 1 major variable at a time.

Rage onwards!

7 thoughts on “RageBridge: The Next Generation”

  1. This is great stuff. I used the DRV8301 in my own BLDC controller (thanks to Shane), and some of your current control code from Tinytroller actually helped me a great deal. I’ll post a write up on my site (which is currently non-existent) when I get sensored FOC working on it. Can you post the schematics for these current RageBridge designs? I’m probably going to work on a second controller soon and I also get the feeling that the DRV8301 is nearing EOL.

  2. But what about the stm32F4XX series. has built in timers for driving with proper gaps etc and floating pt math…

  3. That would be my first choice if I were more legitimate. That’s what most of the current brushless motor hackers I know use, and it really is better suited for the task. However, in the interest of not changing too many things at once, I’m going to try and get a reliable hardware platform together before changing microcontrollers.

    Plus, the Cortex M4 chips are like modern BMWs compared to the Atmegas’ 80s dorky box vans. World of difference in features and complexity, one that I don’t think I’m quite ready to take the leap on yet.

Comments are closed.