With a pile of BLDC controllers lying around, and none that do exactly what I want: better to re-use the parts than start over from scratch!
So, with the magic smoke released from those controllers, I won't be reverse engineering them any more.
What, exactly, was the point here again? Is there more to do?
Why yes, there is. The reason I was reverse engineering these was to be able to control two controllers as one unit - so that they move at the same speed. I thought if I could hijack the built-in logic, I'd be able to build replacement firmware that would do that.
This, I guess, is the moment when I decide how I'm going to move forward on that given that the original plan didn't work out.
New plan: using two *new* controllers, which are admittedly slightly mismatched, let's tap in to the sensors and see if we can build an external controller that can both sense and control the speed of them. Together.
I have two of these:
... perhaps I can tap in to the sensors as they're entering the controllers, and be clever enough with the logic driving the two controllers to get what I want.
There's a slight hurdle. I need a reverse. That's a showstopper, because they don't have a reverse. Let's open it up and see what's in there...
Well, well - that "CCW" that I've badly soldered looks good. Pull it to ground, and guess what happens? Reverse. Sweet. So, some quick soldering in both and we can start testing...
Add an extra set of wires coming from the hall effect sensors, to see what we can sense...
... with this teensy 3.1.
In theory, the teensy should be able to read the pulses from the sensors and interpret them to assess speed of each motor. Then with some control circuitry, it should be able to adjust the speed of each to achieve whatever result it wants.
And, eureka, it mostly works!
In that last image, you can clearly see the succession showing which direction the motor's moving. And the pulse length is the amount of time that sensor stays active, so it's inversely proportional to the speed. (Slower? Longer pulses.)Some judicious application of booze, and add one digital potentiometer, and it's time to start thinking about PID controllers...
That durned magic smoke got out. It left behind some black soot and melted connector.
So how did that happen, you ask?
Well. From the last entry, it only took 6 more wires - PWM and commutator control lines - to test whether or not I could make the motor move. So, of course, I wired them up.
Then I realized that the PWMs weren't on PWM pins on the Teensy. "No matter," thinks me, sipping gently on a Jade cocktail (champagne, midori, curaco, lime juice, bitters). "I'll just run the PWMs at 100%, and we'll watch this run up to full speed." Warning bells go off, but I'm ignoring them. "It just won't run by itself." Sip. "I'll code it to move to the next phase from the previous, based on the sensors." Sip. "I'll pull the battery when I want to stop it from running full out." Sip.
"P1" it exclaims! The motor jumps.
"P44" and "P43" follow quickly after. The motor jumps again!
And then it stops.
Just long enough for me to think about what it's doing, and for me to realize I should really give it a push. Right now. Quickly.
*Poof* goes the magic smoke, as the FET trying to power phase W gives up the ghost, having valiantly tried to move the damn motor in the wrong order. Rest well, FET; you'll always be remembered. Because I wrote this log entry about you.
Yesterday I spent significant time drawing out the schematic of this nameless controller. (Yes, I should probably stop calling it "nameless" because it clearly has a label. In Chinese. But as far as I can tell, its name is "potted plant; not fermenting jug but similar; some sort of house; one" which doesn't do it justice either. So until someone translates it for me, "nameless" they shall remain.)
I stared with some web searching - has anyone reverse engineered this controller before? - which is a bit difficult when you're searching for "schematics for the potted plant not fermenting jug but similar" nameless controller. But I did wander across a reverse engineered ku63 controller, which is certainly along the same lines. As the guy says on his web page: "Here is the schematic of the KU63 motor controller which may also give insight into other Chinese motor controllers." Because, as he says, it seems common to have multiple very similar products coming from China that share just about the same schematic. So how close is it?
In some ways, it's fairly close. Eventually I'll import what I traced out in to Eagle and draw it up properly. Until then, this textual description will have to do.
The power stages use a different MOSFET but the design is very close. There are a couple places in the power system where this newer controller has obviously tried to improve reliability. There are other places where they've clearly optimized for cost (reducing part count, particularly around the throttle). And this nameless controller doesn't have the back-EMF circuitry that the KU63 does.
Overall, the KU63 work was good enough to give me a head start. It only took about 6 hours to trace out the majority of the circuitry; when I started wondering what the mystery circuitry was for (seriously, there are pins on the CPU that have capacitors directly to ground and naught else - why? - and then there are the transcription errors that show transistor bases connected to other transistor bases for pieces of circuitry that I have no clue why the exist!) I decided to stop decoding and move on to "can I get this to do anything?"
[Fig. 1: this circuit makes no sense.]
So, if I want to be the CPU, then I guess I gotta get rid of the CPU, eh?
A little soldering and prying later, some minor repairs and re-seating the caps I pulled out, and...
... not too bad. Two resistors came up with the desoldering, but (a) they're part of the mystery circuitry and (b) I fished them out of the desolderer and put them back in place anyway.
The worst damage is the traces to the CPU. They look okay above, but that's only because I put them back where they belong. They're no longer adhering to the board - par for the course with me desoldering. I'll manage. I think.
So I clearly don't want to jam current down the motor until I know what I'm doing. So let's start with the hall sensors, shall we? I have 5 pins related to said, and I've got a Teensy 3.1 lying around that I want to use to control two controllers simultaneously (keeping them in sync). Looking at the schematic for this piece of the circuit, I think it should work with a +3.3v drive instead of a +5v drive, and the Teensy is 5v tolerant of the return. So the controller is wired back up to a motor; some enameled wire comes out and is soldered to the right pads for the CPU, then soldered to the teensy; and a quick program is whipped up to just read the sensors and report when the one on pin1, pin44, and pin43 changes state.
Apply +36v to the nameless controller - no smoke, that's a good sign - and watch the terminal output while spinning the wheel. First in one direction:
... damn, that's satisfying. 1 -> 44 -> 43, very reliably; and it's really easy to feel when the motor is changing phases, so it's no problem to cross-check that it's doing the right thing. Feel the bump in the motor, see the output in the terminal. And does it work backwards?
Sweet! 43 -> 44 -> 1, exactly as I'd expect.
The other two pins look like they're some control...Read more »
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:
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...Read more »