Brushless Hipsterism Intensifies: Returning to Brushless Rage. Brushless Mini-Rage!? And Trying Hub Motor Drive in a Beetleweight

Oh, Brushless Rage… how far you’ve fallen. It’s been standing idle since late last year when I got the first version running. Thereafter, it began having some rather obdurate power supply problems that I couldn’t resolve with a few different attempts, and with #season3 still unknown (TO. THIS. DAY. UUUUUUGGGGGGGGGGGH.) and having to pick up and move shops, I lost motivation. Now, with the spring and summer silly go-kart season coming up, me really wanting to pregame getting Overhaul back in shape ( *cries deeply* ), and my comrades over at Robot Wars screaming for assistance, it’s time to put my robes and wizard hat again.

The last time I really worked on Brushless Rage was in October. After tuning out the first one, I went ahead and made a 2nd one. I wanted to get Sadbot running on them for a few test drives.

Here’s my innovative housing for the two controller! Bolted back-to-back with drilled holes in the Ragebridge shipping box.

And that was all! It was retained by a few zip ties running through the bottom ‘breadboard’ baseplate. I didn’t take much test video of Sadbot running on them, unfortunately;really the only one that exists within easy reach is, uhh, this one. While it doesn’t show them getting whipped, they definitely don’t not work! Yay!

But not for long. I soon lost both of the units in further off-bot tuning of settings. They didn’t blow up, but simply failed to ever power on, with the LM5017 regulator simply sitting there getting hot. The only “fix” was replacing the regulator, and I say “fix” because that really didn’t fix anything, and they would die again within minutes or even seconds.

No problem… maybe it’s just an issue with the two boards. I’ll just try another one of the five total I ended up making….

Nope. Nothing. They died one by one, all to the same symptom. I tried redoing my math for the regulator for the 4th time, thinking maybe  I made a mistake somewhere. I even tried mimicking the reference design to try and get something running. I literally never do that.

At this point, I figured it must have been something incredibly dumb and simple I missed. But why would the first two have worked at all, even for a little while?! Convinced the solution might just suddenly invent itself, I stopped thinking about it.

And so here we are, a few weeks ago, when I’m slowly building up a new rev of the logic board that fixes up some trace routing problems and Little Blue Wire problems. Again, the logic regulators kept exploding, some times dramatically taking out the input trace like seen above. The little light is strapped across the 15V gate drive supply to give me a visual indication of it being on.

What is with me and being unable to use switching regulators!? I recalled the Ragebridge Diode Debacle of 2015, and decided to take one last Hail Mary run through the datasheet along with friends to carefully cross-check each other for boneheaded mistakes and…….

TI, you assholes.

So here’s what’s going on. The Vcc pin of this chip allows you to power it from its own output voltage, which is often fairly low, so it prevents a lot of heat dissipation in the chip since otherwise it would have to derive its own power from the voltage input (up to 95V). But what I missed is this only works up to 13 volts. My gate drive supplies were 15 volts by design.

Beyond that? Who knows?! It might work, it might not. I’m guessing my first two were just high enough in manufacturing overhead that they worked for a little while. Subsequent statistics were not on my side.

Okay, whatever. I cut off the 11.3kohm feedback resistor and threw on a 9.1kohm to drop the voltage from 15V to about 12.5V and let’s see what happens.

Ah, it wakes right up.

Of course it does.

So I decided to respec the gate drive for 12.5V. Why do this instead of go for the full 15+ volts? Because I’m really aiming to make this design work at high-for-robots voltages of 36-48v, possibly up to 60V nominal with a different power stage, so I’d like to save the power dissipation in the chip’s onboard logic power supply.

The change in drive voltage will slightly affect the drive characteristics and switching time. For now, I’ll keep all the power stage parts unchanged, but I’ll probably tune the gate resistor values later.


To get rid of the noisy ripples on the feedback network and to stabilize the switching frequency, I added some more bypass capacitance to the chip. This was not included in the design at first, since I figured my large ceramic input and output caps were nearby, but it really really wants its own little private capacitor on Vcc. Gee, I thought I was a princess at times.

So now this thing is pretty much bombproof. Here’s a video of it throwing around one of the 30-pound old MIT CityCar prototype motors (which I inherited 4 of after the project was dismantled):

In that video, it’s running from 36 volts. I tested it with a smaller motor all the way up to 50V input before getting too scared for my power supply’s life; I’ll need to try it on a larger high-for-robots voltage power system later, but nothing smelled imminently unhappy!

With the regulator death issue apparently behind me (again) I decided to push another board revision. This time, I added all the necessary bypass caps and changed the layout of the logic power supply, as well as take out some parts I decided were superfluous.

The logic power supply got a little smaller and more electrically optimal. The whole thing is just less messy now. I like it – it takes up around 1/3rd square inch of PCB space on one side. At the behest of a professional PCB engineer friend, I turned the inductor 90 degrees and joined it with the LM5017’s switching node with a small trace instead of a larger groundplane. This would prevent the switching node (a source of huge voltage swings in microsecond timescales) from broadcasting as much noise.

Besides some other minor trace chasing, what’s going on down below on the board is also something experimental:

That there is a bidirectional optoisoated I2C bus for transmitting data between two microcontrollers which should never meet directly. I had a single-direction opto input on the board revisions so far, but this prevents updating of settings via the SimonK/BLHeli type bootloaders. That means tuning the settings require busting out my chip socket every time, which is annoying. I reviewed a couple of bidirectionally isolated bus schematics and decided to try this one out first, since it involved diodes only, not transistors.

The problem is, the I2C bus is a open-drain configuration with pullup resistors and ‘1’ bits transmitted by pulling the line down to 0v. I kind of wanted to try keeping the opposite polarity, so to speak (even though SimonK supports an inverted input setting) just because I’m used to thinking about things this way. So I tried flipping the circuit over…. pullup resistors became pulldowns, and common-emitter became common-collector, and so on.

It makes sense in my head, but I’m sure excited to see this work!

On the board, this is the layout. It doesn’t consume much more space than my previous 1-direction optocoupler setup, and can be bypassed for testing with 2 wires if needed. That’s the nice thing about keeping things upright signal-wise.

So before I sent this board revision out, I stopped for a moment to think who would really be wanting to use Brushless Rage. I’d designed the 12-FET board to effectively replace Overhaul’s 250A DLUX controllers (with more realistic ratings, mind you). I’d say the majority of people who would buy such a thing won’t be running motors that big.

Recently, the thought of a “Half-Rage” has been coming up in my mind as something worth pursuing. This would be a board with about half the footprint of a RageBridge 2 and supporting about 1/2 of the amperage. As some curious question-askers had innocently drilled into my mind, this would be an Actually More 30lber-Sized controller.

> mfw "When are you going to make a 30lber/12lber version of RageBridge?


With this in mind, I decided to make a copy of the power stage and began downsizing the hell out of it.

Step 1: Reap what I sow when it comes to the sheer number of vias I deposited under the FETs.

After bunching the FETs together, I referenced one of the earlier abandoned Brushless Rage layout ideas for the output wires. This board is now short enough that I’m comfortable pulling the phase outputs all the way to the right with the power. Keeping all my wires on one side is something I prefer.

Somewhat final routing of the fat bus traces here. I had to move a few gate drive traces, as there was no longer an opportunity to swap sides in the middle of the FET bank. Power+ runs straight from the bottom right corner, through the bus capacitors, into the high-side FET. Power- emerges from the current shunts and then has 3 paths to return to the buscaps before being slurped up by by the wire hole on the upper right.

Here’s an overlay of the signal board design on the power stage, showing roughly the size of things. The final power stage is 2″ x 2.75″. Not the tiniest thing, but I have more capacitors than you!

This board shares a lot of thermal characteristics with RageBridge, so I’m pretty comfortable calling this a 50A continuous class controller. 50 real under-partial-throttle amps, so that’s what, like 1,200 Hobbyking Amps?

In all likelihood, this controller will be able to handle an average 63mm SK3 motor in continuous duty applications like a silly go-kart. Robot-wise, it will probably be stressed handling the same in bidirectional drive mode.

Fast forward a few days and….

OhmygoditssocuteIjustwanttohugit and then make it run a 80mm outrunner on 12S violently. I’ve ordered parts to make a handful of these, and two are going on Sadbot ASAP to be driven until something blows up!

Direct Outrunner Hub Drive for Your Little Bot

Next up, something even smaller!

So I’ve long been a connoisseur of fine handcrafted hub motors. I got curious recently on using direct-drive small outrunner motors in an ant or beetle after thinking a while on the redesign of Roll Cake. Version 1 of Roll Cake was honestly just a braindump of a vision I’ve had for years for the shape of the bot, and everythng else came second to that. On the beetle scale, the multi-pulley serpentine pulley drivetrain simply had too much friction for the Fingertech motors (which were severely underpowered for the task) to overcome.

For the next version, I’m ditching the triangular cheese wedge shape for something more straightfoward. The cheese wedge will be back for a heavier weight class. Roll Cake’s design really wants to have the middle of the bot kept clear for the flipper linkage. I’m sure I could work around it with low-mounted drive motors and similar, but this was an excuse to play with brushless things!

I based my thoughts off Jamison’s mini-gimbalbot which used camera gimbal motors for drive with a small Hobbyking R/C car ESC. It drove “okay”, certainly capable of a weapon delivery platform. So naturally, I wanted to put some SimonK-capable controllers on it and see how the handling would change. I got a small selection of motors: A pair of DYS and Quanum 28mm motors as well as a pair of Multistar “HV” 460kv motors. 460 RPM/V is reeeeeally slow for that size of motor that isn’t a gimbal motor, so I was quite interested in them.

These are the gimbal motors. I like them for their pancakeyness – the Quanum motor is more 30mm and has a bigger stator.

Playing around in the CAD model a little for component placement. At this point was when I realized Roll Cake in this incarnation might end up looking a lot like The Dentist :P

I designed up a few hubs that bolt to the face of the motors and have a tapped middle hole to sandwich a wheel. The wheels are spare 1.625″ BaneBots wheels that I originally bought for Candy Paint & Gold Teeth.

Shown with those motors is a ZTW Spider 18A controller. My typical SimonK ESCs, the Afro series, were out of stock when I placed this order, so I took recommendations from people on what I should use. The Spider series are fairly popular these days among small bot folks.

The issue is, they come with BLHeli firmware, the other other open source drone racing / vaping rig development path. It’s a newer effor than SimonK and has a more polished interface. I’d read about it before, but not worked with personally. Other builders have said it doesn’t run robot drivetrains as well due to being much more optimized for propellers. So hell, why not – this was a chance to explore that side of things.

Here’s some real life CAD layout, featuring the Multistar motors.

I really wanted to use the gimbal motors, but they disappointed me in bench testing sufficiently that I didn’t even end up installing them. Basically, they can’t draw enough current to make torque at typicall little-bot voltages. With phase resistances of 10-20 ohms, they can really only draw ~ 1amp or so. I mounted one in a vise and could stop the motor with my pinky finger at full radio stick input.

These motors might be better at 6S and up, but for the time being, since all of my small-bot batteries are 3S, I decided to pursue making a test platform using the Multistar 460kv motors.


The platform of choice was…… one of Candy Paint’s spare weapon pulleys. I literally spilled my “preformed robot spares” bin on the ground and tried to see what was good to use as a base. Hey, it’s round and has convenient wheel holes in it already! All I needed to do was quickly whip up some motor mounts (3D printed) and I was in business.


Here’s everything hooked up. That nut is for a counterweight on the front to add some friction against the ground while turning. Otherwise, it had a tendency to keep spinning and spinning if you even thought about turning.

Communicating with the ZTW Spiders was a hell of an adventure in its own right, and I am putting this post under Reference Posts because I’m 99% I will need it again or someone else will randomly find it while needing the information. If there was any industry that continually pisses me off with how undocumented and tribal-knowledge focused it is, it’s the R/C anything industry.

So, here’s how everything went down. I lost my AfroESC USB communicator, so I purchased the Spider SPLinker advertised as working with the controllers. I also bought one of these stupid things:

That’s a “SimonK/BLHeli compatible” dongle called the ESCLinker. It allegedly can talk to either kind of ESC, but there was nothing remotely resembling a manual or operating guide; all of the search results for this brilliant device were people complaining that there was no manual.

So I’m writing the manual now: This thing does not want to talk to KKMulticopter Tool (my go-to for flashing SimonK ESCs). It will only talk to BLHeli Suite. As a matter of fact, I couldn’t get the Spider SPLinker to talk to ANYTHING. For all of my tuning here on, I used the ESCLinker tool.

Here is BLHeli Suite, which is hosted on the sketchiest possible website that is one tier above compiling it from the Git repository yourself.

Notice how I’m connected to the ZTW Spider now. The ESCLinker (and SPLinker) install as virtual COM ports.  The necessary baud rate is 38400 baud, not 19200 (Afro/Turnigy USB dongles, to my knowledge)

By the way, once I realized this, I tried to talk to the SPLinker and ESCLinker on KKMulticopter Tool again using 38400 baud; no dice.

Further investigation revealed that the ESCLinker needs these options to communicate to the ESC – both options 2 and 3 will work. So if you’re listening, people mystified by the ESCLinker: Talk to it on 38400 Baud and ask it to communicate to your ESCs with BLHeli/SimonK 4-way-if bootlader.

Ugh. One of my selfish reasons for wanting Brushless Rage is so it’s one known quantity and I never have to dick around with other people’s open-source bullshit again.

So with all that behind me, I decided to try out BLHeli drive on the little pulleybot. I went with intuitive settings based on my SimonK advice, which included “Damped Light” mode, a fancy euphemism for synchronous rectification/complementary PWM, medium to low timing and maximum start power. BLHeli also has a “demag compensation” feature which appears to delay commutation to compensate for current decay in the windings. Who knows!? I wasn’t given the imprssion that its users actually understood what it meant, nor does the manual really say anything useful.

I found that Demag Compensation turned all the way up gave the best performance, along with maximum start power. However’ it still couldn’t compare with my SimonK experience. It seems like even maximum start power is much weaker than what SimonK permits you to do.

Here’s the final test drive I made with the BLHeli Spider ZTWs:

I’m honestly not very impressed. I think BLheli is very much optimized towards multirotors and helicopters (hmm, maybe it’s even called BrushLessHeli for a reason!) and the settings are more high-level and mask the underlying mechanicals of the firmware. I think this makes it much more accessible to hobbyists, though. In the end, I’m not very enamored by it.

These were my final settings:

For a direct comparison, I decided to replace the ESCs with my old SimonK Afro 30 amp units. These have been on quite a few bots now, starting with the original Stance Stance Revolution, and they were completely beat up. But they still worked!

A direct replacement into the existing wiring harness later… we have SimonK!

I found myself in the awkward position of using KKMulticopter Tool to compile a customized SimonK formware, then uploading it via BLHeli Suite because my USB dongles didn’t talk to KKMulticopter Tool; I’d lost my AfroESC USB dongle a long time ago.  BLHeliSuite doesn’t seem to have a firmware editor window that I’ve found yet.

Here it is. I found the SimonK version so much more responsive that I actually needed more counterweight on the front. So, a non-fitting bolt gets zip tied to the nut! Now the bot’s a lot more controllable:

I like it a lot. It might even be worth doing 4WD to give me more yaw damping, or I’d have to design the bot to be well balanced enough on front skids, or something. I used my typical SimonK parameters: complementary PWM, maximum braking power, maximum braking ramp speed, and adjusted start PWM limits to something like 50%.

I’m aiming to get Roll Cake and maybe Colsonbot running for this year’s MomoCon in a couple of weeks, so hopefully I’ll post up some design news soon!


A Brief Interlude from BattleBots with Brushless RageBridge

Brushless RageBridge alt. Brushless Rage (n): A magical piece of robot hardware that everyone wants to exist, and whose developer keeps promising “eventually”. Kind of like the Duke Nukem Forever or  Deadpool of motor controllers. “I’m going to use Brushless Rages in my robot when Charles releases them.”

in a world

My own brushless ESC design has been a bit of a white rabbit project for years. While it’s lead me into learning a lot about motor control and power converter design, I’ve not actually made a working one. Melontroller version 2 came close in 2010, and it actually did run Razer Revolution (version 1) for a short while before consuming itself enthusiastically and being retired. It also required the now-legendary Common-Mode Nut to work properly. My next attempt, Tinytroller, was basically a miserable failure all-around, but my discoveries made during the testing of RageBridge meant it might not have been a total loss design-wise, just hampered terminally by a connection error in the schematic (that story can be found here).

In the era beween that and the last time I talked about Brushless Rage in 2014, shortly before I had an unexpected robot pregnancy for BattleBots Season 1, I tended to make do with mass-market EV controllers and R/C motor controllers, like a regular person. I don’t like to talk about those times, trying they were. Man, that post was a while ago. BattleBots Season 1 also pushed back regular-old-RageBridge basically a full year.

where brushless ESCs all suck

With the few months prior to the BattleBots Season 2 build kicking off devoted to hacking up HobbyKing controllers, it basically rekindled the flame that I had with my own brushless ESC bloodline. After Season 2 action wound down, I spent some of the intervening period before the premiere thinking about the next steps of the Brushless Rage project.  I didn’t want to keep modifying hardware not designed to do something I wanted it to, in order to get something which mostly works. Having chopped up dozens of models of R/C controllers, I was getting sick of dealing with them. An ESC of my design would mean I can account for all the variables that were cost-optimized out of the bill of materials, and they could be tailored to my specific application of getting the shit whipped out of them every time they are powered on. I wouldn’t need to worry about the global supply chain for #season3 either.  Furthermore, the robot market is slowly shifting brushless basically as I’m typing. And with the discovery of SimonK and other firmwares by the community, suddenly the bar was significantly lowered for the part I hate: firmware development.

It seemed to me that it wasn’t very difficult to get a SimonK compatible basic Brushless Rage put together, and I was in fact about to pull the trigger on the original board design (with a few changes) a few weeks into the build when the Great DLUX Famine of 2016 occurred, a go-for-broke move that was one of the failure mode branch analysis decisions of last resort. Overhaul 2 was a trailblazer in many ways for #Season2 (No, these things will never come without hashtags), so since I’ve reached a point where I’ve stopped caring about R/C hardware, it’s time to move on.

one man

It’s also interesting to see that my desires for a brushless ESC haven’t really changed – something that performs well in roughly the 2 to 5 kW range typically 48V and up to 100 amps. This segment of the market is still poorly served for the casual roboticist or hobbyist. Most Inexpensive Chinese equipment for e-bikes are 1kW and under, otherwise you’re looking at unreliable R/C controllers or really expensive industrial ones. This is where I come in.

But first, let’s rewind all the way back before BattleBots ruined my life yet again and see where this first model of Brushless Rage ended up.

Recall that this was the “component splattering” I first put together in late 2014. I do a bunch of trial layouts without schematics just to see if there’s enough space to do what I want. The form factor is still “RageBridge”. This board is based off the Arduino Leonardo, which has since been discontinued anyway.

After the component splattering is established, I then make the schematic (not shown here, but plenty of other examples abound). This is the final layout I decided to use, since it provided a clean U-turn path for DC current and three straight traces for the motor phase current towards the right side of the board.  The gate drive passives have been arranged around the A4910 chip for its own local sanity checking, and otherwise the micrcontroller and logic power supply are already arranged (and basically identical to RageBridge 2’s known good setup)


I enjoy a good game of “detangle the gate drive traces” every once in a while. Brushless (3 phase) makes this more entertaining since there’s an extra set to route!

Here’s the hilarious way I ended up routing those traces. What’s with the little curly offramps?!  Well, the traces all had to turn 90 degrees, but 90 degree hard turns are less desirable than 45s or straight lines. I could have gone with simple 45’s, I suppose, but decided to get cute with things and use the spline routing method instead.

This is the bottom layer of the board, looking the most “circuit board” of anything I’ve ever designed. There’s 6 gate driver lines logic pins from the microcontroller (three high, three low) to detangle, plus numerous other control pins and feedback pins. It also showes the layout of the power traces.

Finally, this is the completed version 1 board as of December 2014 or so. I actually had several boards made along with the version 1 of the RageBridge2 boards, but never did anythng with them.  Knowing what I do now about RageBridge 2’s design though, there’s a few things I’d change about this board before populating and trying to use it.

but now

Fast forward to about two months ago, and my desires to try again were high. Seeing the HSOF-package FETs used in the Vex BB controller at Season 2 also spurred me to try that package, which I had only speculated out before and whose high price per unit in low quantity kept me from buying a rail to blow up. However, I found that other companies besides Infineon also made parts in the package, such as the Fairchild FDBL0150N80, which were priced much closer to my favorite D2PAK-7s.

The HSOF package has very short legs, which enabled tighter packing than the D2PAK-7 devices. This was both a blessing and a curse, since I usually ran traces under the ‘overpass’ of the legs, but the tighter packing would potentially allow FET packing in parallel for more current. A lot of new leadless packages for all sorts of devices really want you to use them with 4 layer boards, and I openly admit that moving to 4-layer would have made life a lot easier and added current capacity.

I also did some more look-ahead for the architecture of the controller. One of the things I wanted to do with RageBridge2 was finally move to a split signal board and power board architecture, which is fairly common the higher amperage R/C controller market. This would allow me to finally use 4+ ounce copper on the power board, which the fine pitch packages and traces of a signal board wouldn’t usually permit. The signal board could also be designed with tiers of components to drive differently sized power boards…. just look at my dreams of this from tinytroller (That’s a 600V, 200A, 3-phase IGBT module…)

So here we go. I decided to play with placements first, once again. I basically just imported a RageBridge outline to start with, to see if I could keep the controller in the same size class, rather than define a new physical form factor. The hidden agenda of this is that I have 1000 RageBridge 2 heat sinks and only 250 RageBridge 2s, so I’m gonna use those damn heat sinks!


One thing I was unclear on at the time was whether I wanted the gate drivers on the board or not. Having the drivers on the board would make the logic-power separation even more strict, as the only thing passing between the boards is command signals, not even the (relatively, compared to logic) high powered gate drive signals. This took up more space on the board, of course, so I had to get to a point first where I could judge the space requirements. You could really make an argument for both approaches, but the gate drive on logic board is more common in R/C-world.

I also made this crazier version which is basically just a block of MOSFETs. This was a complete “out there” concept, as there’s too much semiconductor to be useful – the rest of the board won’t really be able to support the current, and those two lone capacitors will become depressed quickly.

It also left zero space for things like current sensing resistors or really any gate drive parts. But it did show the potential of the HSOF package if I decided to make this board even slightly bigger to permit these components.

Another musing was if I could use the D2PAK-7s that I already have. The answer is “barely”. It also really needs a bigger board to work out. This specific layout, for instance, would make adding current sensing really difficult.

There was another version which I did not take a screenshot of where the FETs are spaced closer together after I played with gate drive routing, which left space for current sensing resistors on the left where they are picture now.  This version was actually a candidate worth pursuing if I did not end up using the HSOF packages.

Getting a little more serious now as I start actually listing the signals I need.  This is now back to the first configuration.

While I don’t intend to make current sensing a priority (as SimonK doesn’t support it), I made sure to add all the possible signals I WOULD need, which includes current sensor feedback pins and a thermistor, for instant.

(Kelvin refers to a Kelvin connection, by the way)

At this point, I also started thinking about what signal header to use. The 20-pin wide through hole header row was not the final selection. I looked around first in the libraries of parts I had to see if anything tickled my interest. While the common 0.1″ spacing single row headers would have worked, I wanted a more production-ready solution and also wanted to browse what the latest offerings on the market were.

Off to Digi-Key and Mouser for some window shopping. Connector manufacturers will often sample parts for free just to get you hooked on their product, so you keep coming back wanting more, and eventually you’re standing on a street corner with a baggie of mezzanine headers.

I found what I liked in a Samtec product, the HLE series. This is a “pass through board” header. My qualifications were basically…

  • 0.1″ pitch, so it is easy to use as an extensible standard – anyone with some perfboard could potentially work with this design in the future
  • Two row, since 1 row takes up too much boardwidth and three rows is more painful to route
  • Pass-through-board (connector on top side) because I did not want to pay extra for double-sided SMT assembly for ONE PART (the connector) which would be necessary for a non PTB design.

So I sampled a handful of HLE connectors and matching male-side dual row terminal pins, their TSM series. After getting these in hand, I decided to move on with them.

I generated the footprint for this part according to their datasheet, but the pads are a little shorter than specified to give me more space to work with. Check out the current working arrangement now. The decision to move the gate drive offboard was made, so this freed up space for more capacitors as well as current sensing. I realized that even two FETs in parallel was going to cause a massive capacitance shortage. Cue a day of shopping for the latest in capacitors…

In the end, I’m only able to get around 2,600uF of bus capacitance at 63V ratings – two 820uF large cans and three 330uF smaller ones. This ought to be sufficient, and is on par with RageBridge 2 which was easier to buy caps for due to its lower voltage operation.

This board is also about 0.25″ longer than RageBridge 2, accomplished by exploiting Eagle’s 100 x 80mm board limits by using the “Well, technically, it just limits where your COMPONENT CENTROIDS can be placed” method.

So I honestly tried for a while to put all the outputs on the right side for convenience. The narrowness of this board wasn’t very conducive (hehe) to it since it left very little space for power traces. This would limit the current capacity due to trace resistance, and ruin the point of two devices in parallel.

Again, a matter that a 4-later board can help fix, and so I might try a 4-layer version in the future.


In the mean time, to keep life simpler for initial testing, I moved the motor phase outputs to be next to the FETs. This also let me push everything to the right a little and give more space for routing.  Pictured above is the first shot at the power board, which was, uhh, rage-routed in my typical fashion.

This screenshot also shows the working project name for Brushless Rage, which is “ThreeBridges”. I honestly don’t know, because it sounded reasonable. Technically, you could argue it’s only three half-bridges. Go away.

Now that the power board is settled, time for the signal!

I set the signal board size constraint as being no wider than the two mounting screws on that end of the power board such that I could still unscrew them. The length was dictated by hitting the phase wires. This is after the “initial scattering of components”, where I was routing the logic power supply little by little at the top. For now, I put a row of right angle headers on the left side to make sure I leave space for routing signals, even though the SimonK board would only need one R/C servo input.

The gate drivers are all new – the FAN7390, which is like my old favorite the IRS218x4, but with a little more crank and with independent inputs. I went on the hunt for gate drivers that offered Vss-COM floating capability (kinda-sorta isolation) that were higher current than the IRS218x4, and found these quickly. Sure, why not!

The logic regulator is also a new addition to Charles_Favorite_Parts.lbr that I hope to learn to love. I decided to leave my good ol’ LM2594 behind and explore the higher voltage market a little. The LM2594HV is my go-to for all up-to-50v solutions, but I eventually wanted to go higher with this controller.

From looking at the DLUX 250, I know it used a LM5009 regulator, so I shopped in the same family of DC/DC regulators to start with, while also letting DigiKey show me what worked for my specifications. Ultimately, it seems like the easy one-chip converters stop around 100 volts. Makes sense – the higher you go in voltage, the less standard/well characterized the loads tend to be (e.g. every consumer electronics device hovers around 5-24 volts for power so there are many one-chip ready to go solutions).

I settled on the LM5017, which has roughly the same operating voltage range, can switch near 1Mhz (which I wanted to do in order to reduce passive size), and is higher current, for in the future if I want to drop this design on a more powerful gate drive.

This chip is a little………..special. I’ll get to that in a bit.


Moving more components in now – the microcontroller’s support passives have been added, the resistive sensing network for phase voltages has been added, and a new challenger appears at the bottom… what’s that? It’s a TLP2160 2-channel optocoupler in a SOIC-8 package.  I wanted to get into the habit of opto-isolating the logic signals, since it cuts another point which noise from coupled EMI or ground loops can be injected into the logic, so I explored the space of small optocouplers a little, most being the larger wide-DIP size. This part is another “Digi-Key, are there any in-stock parts that match these peculiar spoiled brat needs of mine?”


Version 1 of the signal board is complete after some more routing! This board was almost theraputically easy to route for some reason. The joys of having ONE INPUT and no giant MOSFETs next to you…

A quick synthetic image showing the stackup of boards.

These boards were sent out for fabrication through my current favorite shady Chinese PCB source, 3pcb (not to be confused with 4pcb, or really any of the [1:10] places). The signal board was to be fabricated in regular 1oz copper, and the power board in 2oz. I could have went for the full 4oz, but it was more than twice as expensive as the other options, so for a test board, it was not justifiable.

In the intervening week, I ordered a load of BOM parts from Digi-Key. First up is the HSOF package FETs!

Man, these things really are like a D2PAK-7 with the legs cut off. Pretty sure I can get the same effect doing it manually myself and save some money…

But less facetiously, they’re much thinner than the D2PAK and so have less thermal conductivity problems from the top side. They’re still designed to be heat sunk primarily from the bottom, though.

Everything else! There were so many new parts involved this time…

A day later, the PCBs show up. I’ve worked out that if I hit “go” on the DigiKey order as soon as I get a shipping notification from 3PCB, my orders will make it here in roughly the same timeframe (+/- 1 day).

The first thing I wanted to try out was the board stackup height. I was correct in choosing the male header pin height here, since the signal board sits just barely a millimeter higher than the tops of the FETs!

Next begins the job of populating the boards. I started with the signal board, so I can quickly test “FET integrity” by manually poking the drive pins with 10 volts to make sure nothing is dead.

The capacitor farm on the right was going to be impossible to assemble unless I tried some trickery. For the pins in the middle of the aisle between the small and large capacitors, I ran a bunch of vias to the bottom layer and added a small square of solder mask stop. That way, I can solder the capacitors in from the bottom by holding the iron to the bottom side and feeding solder from the top side.

Not a production tactic, but good enough for now.

I built this assembly in stages, testing each ‘new thing’. For instance, the next family of parts to assemble was the 15 volt gate drive power rail supplied by the LM5017.

This is where things got exciting, and where you have to know how technical datasheets for chips are produced.

First, a team of engineers working high up in a mountaintop monastery like this one writes the specifications for the chip – its operating voltage range, logic input thresholds, current draw, and so on. They summon the Gods of Silicon Fabrication through magic-smoke-heavy ceremonies shrouded in secrecy, tradition, and middle management. Next, to bring the chip into the world, the datasheet must be written by a group of immortal, trusted unpaid-intern scribes. Unfortunately, as this modern electronics research facility is a mountaintop monastery, it has no Internet connection.

So the chip specfication and application & design notes are communicated via one of several methods: via magic-smoke signals, or by dropping smooth pebbles from the mountain in such a way that they bounce a specific number of times before hitting the ground, with the number of times being interpreted as a character or a vector graphic drawing command. This is, needless to say, not a lossless method of communication, as winds and weather can hinder the processing of the smoke signals or inhibit them completely, and the backup provided by the dropping of the pebbles could be corrupted by the law of probability and how many mountain goats are grazing on the way down.

What I mean to say is, datasheets often suck and have inconsistent symbolic notations and naming schemes that make it difficult to understand precisely what is being asked of the designer. I messed up a few passive part value calculations (such as the feedback network filter among other things) which meant NOTHING WORKED. AT ALL. GOD DAMMIT. until I ran through the design equations basically 3 times before I finally got that ohhhh, you meant the on time AT MINIMUM DESIGN INPUT VOLTAGE, not maximum like the last page was talking about.

Then I got it to work.

This was the culprit. What is shown here is the waveform at the feedback network. Essentially what’s going on with this regulator is that it uses the voltage across the output inductor as a feedback element.

Capacitors, specially the output capacitor, take a little time to fill up (voltage to build up – current leads voltage) after you feed current into it, and by the time the final output voltage – taken directly from the capacitor in the usual case – rises above the feedback threshold, shutting off the current in the inductor then takes a little more time (voltage-leads-current), which fills up the capacitor past what is desired. You can often get an unstable feedback loop going this way with the regulator always hurrying to do exactly the wrong thing, and your output voltage becomes unregulated. The type of feedback network used by the LM5017 is more complex, but it eliminates the capacitor as a source of lag in the response.

What’s seen in the waveform is the scaled inductor current (represented as a voltage) increasing (ramp up) as the regulator pushes current from the input side (battery) into it, the peak tripping the feedback threshold, and then ramping down back down when the regulator shuts it off. The peak shifts left to right depending on the duty cycle – basically how much time the regulator keeps the current on vs. off.

This is a small waveform imposed upon a DC offset voltage which is provided by the usual two-resistor divider, which is for large-scale changes; for instance, a sudden load might drop the DC voltage significantly, which means the peak of the triangle won’t reach the regulator’s shut-off threshold, basically sending a “NO KEEP IT ON LONGER FOR REAL” signal.

The astute electronics engineer would note that I technically didn’t have to do any of this, just implement a normal feedback circuit, because the gate drive power can be “dirty” since the microcontroller’s power is derived from its own linear regulator from that, but I wanted to get used to these kinds of feedback circuits since they’re more common on high voltage regulator parts.

This is the output voltage at the ‘switching node’ – the output pin of the regulator, before the inductor, doing what it’s supposed to do finally . Again notice how it matches up with whether the slope of the feedback voltage goes up or down.

Mystery number 2 of this chip was that it clearly did NOT want to run at 1Mhz. It just sort of went crazy and the output waveform was extremely unsteady and not remotely square like this one.

I backed down the design frequency to about 600khz, and all was good.

By the way, thesea re in fact all screenshots from my beloved DSO Nano Quad.

Okay, with everything populated, it was time to take it for a literal spin. I designed the signal board to be a directly compatible port of the SimonK DLUX settings I made for Overhaul, so this part was super easy!

Aaaaand…. nothing happened. Hmm…. Well, at least it didn’t light on fire instantly! I have created something that is more than just an elaborate firework.

First little blue wire hack time!

So I read the TLP2160 is an inverting output. Sure, makes sense, most optos are set up that way. So  I just wire the output in an emitter-follower configuration and all is fine, right?

Nah, it’s a push-pull output that can both source AND sink current, overriding your clever inversion by doing whatever the fuck it wants. Whoops. So instead of reading  1.5 millisecond long pulse from the ratio, the ESC was receiving a 20ms – 1.5ms = 18.5ms pulse and becoming very confused. Time to bypass it for now… On version 2 of the board, I’ll add a tiny transistor inverter to make up for this.

Okay, it’ll definitely work now! Right!?

Well, I can hear it trying to do something, but it’s obviously not driving anything. Scoping all of the low-side MOSFET pins showed they were being switched on correctly, but none of the high-sides were driving at all.  Perhaps the bootstrap capacitor arrangement was too low-value to pump those big fine MOSFET gates. Nope, the voltage at the bootstrap capacitor read just fine. Might as well double check the pinout connection and…


Oh dear.

Again, another “Electronics engineers might get this” reference, but take a look at the FAN7390M1X datasheet and let me know what I did wrong.

Alright, more little blue wires time. I fixed this issue in the chip footprint and symbol right away, and it’s also now queued up for revision 2.  The other two drivers also needed this same hack.





Whoops. Another transcription error. Who’s the unpaid intern monk scribe communicating via smoke signals and goat droppings now?! Fortunately, this was quick fix. Ahhh, software…

Without further ado, I bring you….


literally because i didn’t write the software.

Not shown was the test after this where I almost beaned myself with a SK3 63/74 outrunner when running from Sadbot’s 10S battery. It tore itself out of the crude clamp and alligator clips I set up on the table and proceeded to attack me.

There was one additional small hack I had to make, and it was that the bootstrap capacitance was indeed a bit low for how fast I was switching and the gate charge of two MOSFETs, plus gate-to-source “insurance resistor” leakage. It ended up that I need something like a 4.7uF and I had a 1uf installed from stock since I already had it. The high-side drive voltage was sagging pretty far during long slow commutation cycles. I intend to resolve this by installing the correct capacitor next time and also backing down on the Rgs from 10k to perhaps 22 or 47k – something to keep them happy under undefined drive states, but it doesn’t need to be that low.

Well, to keep things going for now, I’ll just DROP ALL THE BASS on it. How’s 101uF of bootstrap capacitance sound to you? Good? ALRIGHT!

Future revisions of the signal board, or a different signal board altogether, may see a charge pump or other kind of high-side drive supply added. For now, it’s fine if the high-side gate drive voltage sags a bit on longer switching cycles, which would happen with slower motor rotation near full throttle, such as if I drive a bigass hub motor instead of a small fast R/C motor.

Shown here is my DSO Nano Quad and a bunch of little blue wire probes that I was moving around to check my work.


Here’s what a gate drive signal looks like! Nice and clean, just uner 1 microsecond switching time. The small twangs are the complementary (high-side) transistors turning on and off, which shows that my deadtime could afford to be a little less, but I will probably keep it here for insurance purposes – transistors start switching slower as they get hotter, for instance.

Again, this is on completely unchanged SimonK DLUX settings from Overhaul.

Out of curiosity, I took a snapshot of the phase voltage divider output (going to the microcontroller, blue), and the virtual neutral point (star network, yellow) which the controller bases its switching decisions from. For more technical and whimsical info on this process, see Xo’s post.  The controller bases its switching decision on the last drive state of the motor and the “zero crossing” – actually the phase voltage crossing the virtual neutral point.

The signal is clean enough and my switching is fast enough (sub 1 microsecond) that I may try increasing the switching frequency even further. Right now it’s around 20khz, and I’m thinking of trying 32khz. The higher the frequency, the less work the capacitors have to do, the more opportunities the controller has to sample the zero crossing, the lower the magnitude of current pulses which could induce noise, and the less I and my friend’s dog hear it. Downside is increased heating of the transistors in the form of switching loss, because how happy would you be if someone slapped you 50% more times a second?

All of this is speculative. My goal is to build three to four working units and beat them up using the SADBOT vs. OVERHAUL method, which I know everyone has been dying to see, including me! The revision 2 signal boards, incorporating most of these changes, arrive later this week, and my BOM for making a few more power boards should also get here in the same timeframe.

In the mean time, it’s time for OVERHAUL VS. BETA this coming week of BattleBots! I have a post-match being put together for that too.