Before 2016, I'd not worked with brushless DC motors. Being very aware of the Dunning-Kruger effect, I assumed that I would need to learn quite a lot, and that I'd come out the other side thinking myself an idiot. Which is mostly true; I made some ridiculous mistakes along the way. But the flip side of Dunning-Kruger is that it doesn't take much knowledge in a subject to start to get a handhold on it. Once you know just a few bits of the fundamentals, you start realizing what the right sorts of questions are; and once you know the right questions to ask, it's easier to find the answers.

This translates directly in to my engineering mantra: if you want to bootstrap in to technology that you haven't worked with before, you can follow one of three paths.

1. You can spend time working with someone that knows what the heck they're doing;

2. You can spend time researching on your own, which takes substantially longer;

3. You can spend (often quite a lot of) money to flail about until you figure out a tiny bit, and then iterate.

Well, not knowing anyone that works with BLDC motors; and not having a lot of time to spend researching; I went with path #3. I needed to rebuild the motorized base; I needed it to use more powerful motors than I'd been able to find as brushed DC motors; I knew that hoverboards existed and were able to move a person. So we bought a hoverboard, disassembled it, reverse engineered a little, and that's when I learned about brushless controllers. By reverse engineering bits of that hoverboard controller I learned enough to be able to ask some of the right questions.

Which lead me to looking for replacements. The controller in the hoverboard is probably fine, but I found the idea of working around its firmware onerous and distasteful. Why would I want to write software to work around bugs in software? That's just going to cause more trouble later. So I went looking for reliable controllers. But what *is* a reliable controller? What makes a BLDC controller good or bad? I had no idea. Following rule #3, I went out and bought a few.

It turns out that quite a lot makes BLDC controllers bad. Well, maybe not bad - but not what you want. Some of my mistakes:

• I bought two brushed DC controllers by mistake. Whoops. I already know how to drive brushed DC motors, and I've got plenty of parts to do so.
• I bought two nameless brushless controllers via eBay which aren't reversible. I hadn't realized they wouldn't all just be reversible.
• I bought one controller from a bona fide eBay auction (you remember those? Y'know, before it was just a bizarre storefront?) - it's reversible, but I've only got one, and I need two matching controllers. Well, want two matching controllers. I figured if the others didn't arrive in time, maybe I could find a match for this guy later. And it was under $15 with shipping! (Which explains the state of my basement/workshop.)
• I finally wound up with two 36/48v brushless controllers (SPD-3648350BLDC) from electricscooterparts.com. These are literally the only brushless DC controllers I could find that were 36v and reversible, and were available in the continental US. Unfortunately, they also have a firmware ... glitch? feature? ... that makes them difficult to use. Again, I found myself writing software that guessed at what the controller firmware was doing so that I got the result I wanted. And in the end, it's okay. I can drive Dalek Bob reasonably well. It's just difficult for anyone else to drive him.

Now I find myself at the beginning of a build for Dalek Geo (pronounced "Joe") - at a point where I really don't want to be working on the GRP (fiberglass) pieces inside and it's just too cold outside. Which means focusing on the electronics. Which brings me back around to controllers.

Working backward from where I wound up on Dalek Bob: I don't want to re-use the same controllers, because I'm not satisfied with their firmware. The company says they don't have a copy of the firmware, and don't know if it's possible to re-flash them, so there's no good reason for me to buy more of them.

There's the relative unknown of the single controller I got from eBay. I found a supplier in China, and have another on the way so that I'll have a pair of these:

... but even with a pair, I'm not confident that I won't have the same problems. And I have to wait until mid-January for them to arrive. And I've got that other pair of non-reversible BLDC controllers sitting in the house. These nameless guys:

So why don't they have reverse? Seriously, "reverse" on a brushless controller is just software. The motor itself works by energizing electromagnets at the right time, and in the right order, to make the rotor spin. It's a waltz of U-V-W, U-V-W, U-V-W (the typical names of the three motor phases being "U", "V", and "W"). You want to go the other direction? Fine! W-V-U, W-V-U, W-V-U. Not much else to it.

It would therefore be logical to assume that, if reprogrammed, the non-reversible controllers could indeed be reversed. Or they might even have the capability in firmware already, just not wired up! Wouldn't that be grand.

One moment while I void the warranty, and then we can see what's inside...

The yellow, green, and blue wires are U-V-W. The big red and black wires are the +36v supply. All the other wires are various controls: throttle in, throttle out, brake high, brake low, what have you. After removing the big wires, we can get a better look:

That's the processor front-and-center - the GPM8F3116A. With a little bit of digging, I found the datasheets for it. It's clearly designed for brushless controller use; there are U/V/W pins labeled in the datasheet. It's also only a 24.5MHz device.

But can it reverse?

In a word: no. There are no exposed headers that enable reverse. I poked every which way at lots of possible connectors and got nothing.

This controller also requires Hall sensors on the motor for figuring out the physical position of the motor. Many controllers have the option of sampling the backward electromotive force from the motor to determine where it is in the cycle ("sensorless operation"). This has no circuitry to be able to tell; it relies solely on sensors. Which is okay, as the motors I'm using do have sensors.

Back to the processor for a moment, though: if I want this to start reversing, then I need to either reprogram it or replace it. Reprogramming doesn't look like an option - GP offers pre-programmed versions in bulk - which leaves me with replacements. To do that, I'm going to need to know exactly which pins are doing what, which will require significantly more information about what's happening in that circuit...