Team Lazy Gecko

For code development, and possibly races, I think a motor controller with custom code that costs $70 and maybe two hours of soldering would be really nice. Makes blowing one up a lot less painful, and easier to get into more vehicles. I've got some amount of a plan for doing this. I think I can get at least 15% more efficient than dumb controllers, and do better with fuse current control too.

The basic idea is to use one of the $30 China controllers as the power part. Seems like they're reasonably robust, and can handle a fair amount of current at 48V.

A custom PCB with a real MCU and hall effect current sensors seems like the way to go for the actual logic. I'm thinking of sticking with the Kinetis-K chips on the Teensy and my previous custom motor controllers. That should be a ~$40 PCB quantity 10.

Plan A is minimal modifications to the China controller. Seems like it should be possible to move the data in and out using some of the various wires that already come out of it. If that works out, then the only modifications would be possibly some attachment points to program it and then actually programming the MCU. Current thoughts on how to move data back and forth are either analog values (noise tolerant, should be able to easily get sufficient bandwidth, but ends up being a lot of signals) or some digital protocol (it has SPI hardware; 20kHz * 8 bits * 3 phases = 480kHz, which is totally achievable as a ballpark).

Plan B is to pull the MCU off the China controller and solder in a custom PCB with castellations on the pads from it. Should be doable, but a lot more work for each controller. From there, either a connector to another PCB with the custom logic or to wires out to the main PCB are options. Pulling the MCU off with hot air and then dropping another PCB in its place isn't all that hard, but it's way more than just plugging stuff in, so hoping to avoid this option.

First step to derisking plan A is to figure out how to program the MCU. Looking at the datasheet, it has an I2C programming interface. That should be pretty easy to poke at, if I can get some idea what commands it recognizes. There's a reference in the datasheet to a "programming guide" which should have that info. Didn't manage to find a copy of that online, but haven't given up searching yet. I suspect any generalplus programming guide will have the info I'm looking for (basically, what bytes to send to read and write from the flash).

This sounds really promising. Getting full control over the cheap controller would really make it a nice piece of hardware. Keep us up to date!

At some point, cloning the trace design and spinning a PCB seems worthwhile. When removing everything that you don't need, it'll make the package pretty tight and you get to design around the MCU you like from the ground up. With proper jlink connector or what ever programming layout you want. PCB's are fairly cheap and we probably only have to BOM the pcb and components and not the labor part. I'm not sure which Fets these use, but you can get IRF3205PBF FET clones from Aliexpress for like $0.28 a piece. Which are 110amp drain to gate @ 55v. That will keep the cost down.

I'm not familiar with the Kinetis-k, but I'm betting an external ADC will be needed for a hall effect sensor. I'm still trying to wrestle with a ACS770KCB-150U-PFF-T for current sensing, (150 amp with 26mV steps per amp) The MCU I'm using has a 12 bit ADC but it's not as clean of a reading as I would like.

I only understand the theory of bushless controllers, not sure If I could implement one. I'm more than willing to try some things and help you out though.

Craig wrote: ↑Wed Nov 14, 2018 4:04 pm At some point, cloning the trace design and spinning a PCB seems worthwhile. When removing everything that you don't need, it'll make the package pretty tight and you get to design around the MCU you like from the ground up. With proper jlink connector or what ever programming layout you want. PCB's are fairly cheap and we probably only have to BOM the pcb and components and not the labor part. I'm not sure which Fets these use, but you can get IRF3205PBF FET clones from Aliexpress for like $0.28 a piece. Which are 110amp drain to gate @ 55v. That will keep the cost down.

The problem with doing a PCB for the power side is it takes forever to assemble and everything ends up expensive in low volumes, which makes development hard. You also end up with custom mechanical parts, which just adds to all those problems. I've done that already, and am looking to get away from it at least for development. With low-resistance low-inductance motors things tend to go poof if you have code problems, and $300 + two weekends a piece makes that very unattractive. On the BOM it's only ~$100 (parts in quantity and ignoring labor), but still. Doing a full custom PCB again is definitely something I'm planning to do eventually though.

A lot of the cost difference between my boards and these China controllers is caps, FETs, and gate drivers. Those are all places which I think my choices give some performance benefits, but I don't know how much. I'm curious to see how much current it's possible to drive with the FETs in one of these things, and how hard they're driven. If it's enough current, that would be a good place to start for cheaper choices on a full custom one.

Craig wrote: ↑Wed Nov 14, 2018 4:04 pm I'm not familiar with the Kinetis-k, but I'm betting an external ADC will be needed for a hall effect sensor. I'm still trying to wrestle with a ACS770KCB-150U-PFF-T for current sensing, (150 amp with 26mV steps per amp) The MCU I'm using has a 12 bit ADC but it's not as clean of a reading as I would like.

I haven't had noise problems using separate hall effects near bus bars, read with a MK22FX512AVLK12. Current motor controller (fet12v2) has 3x MLX91208LDC-CAH-000 mounted near copper bus bars, and the signal/noise ratio is fine. That has all the logic on a separate PCB, with fairly careful ground plane, bypassing, and layout of course.

Also, I don't think you need more than 5 bits or so of usable resolution to drive a motor perfectly well. By the time you get it up to full speed, you're only getting a few readings per (electrical) revolution anyways, so you need to have some kind of a pretty aggressive low-pass filter on top of a decent model anyways. The T20 I've been playing with is worse than the BOMA, but not by all that much. My (initial) plan for this project is using similar sensors (might end up with a different sensitivity) with the phase wires secured under them (other side of a ground plane to minimize capacitive noise pickup).

There are two ways I've seen to do that low-pass filtering of current/position/etc data, and corresponding slow loop on a current goal. Most people use FOC to do coordinate transforms and then do slow filters/controls afterwards. We've got some state feedback stuff instead which just uses an explicit model and feed-forwards to manage it all. That lets you drive arbitrary current waveforms, which opens up additional options for maximizing efficiency, but it also requires more math. However, all that math fits very comfortably on a reasonable MCU (I've done another controller which drives two independent motors off of it even).

Craig wrote: ↑Wed Nov 14, 2018 4:04 pm I only understand the theory of bushless controllers, not sure If I could implement one. I'm more than willing to try some things and help you out though.

Thanks for the offer of help. First hurdle I see is figuring out how to program the MCU on the China controller. If you have any luck finding some kind of command listing for the I2C interface, that'd be really helpful. Some way to buy a real programmer for it, so that we could snoop the communications, might work too. Even just software for one of those to disassemble would be somewhat of a starting point. Blasting bytes at the chip seems like it has kind of a big risk of locking it permanently...

Because I'm impatient, I'm also hoping for a listing of what pin each of the external wires hooks up to (along with any extra circuitry on the line). I can definitely poke at it and figure that out myself once I get one in a week or so though.

I made it about halfway through the datasheet for the MCU on the China controller. It has a timer (independent of the hardware driving FETs) which supports capturing input pulse widths on three channels, which makes for a nice communications channel if the correct pins are accessible. Specifically (note to self for later), using timer 2 with CRC capturing falling edge and CC[1:3] getting the rising edges, and have the other end drive them all starting at the same time.

Brian wrote: ↑Thu Nov 15, 2018 4:02 am I made it about halfway through the datasheet for the MCU on the China controller. It has a timer (independent of the hardware driving FETs) which supports capturing input pulse widths on three channels, which makes for a nice communications channel if the correct pins are accessible. Specifically (note to self for later), using timer 2 with CRC capturing falling edge and CC[1:3] getting the rising edges, and have the other end drive them all starting at the same time.

Can you link a copy of the Datasheet? Is it confirmed that it's programmable? most of the China MCU's I've dealt with are 1 time flash.

In other news, I smoked my "good" oscilloscope... One of these days I'll get an isolation transformer...

Craig wrote: ↑Wed Nov 21, 2018 12:37 pm

Brian wrote: ↑Thu Nov 15, 2018 4:02 am I made it about halfway through the datasheet for the MCU on the China controller. It has a timer (independent of the hardware driving FETs) which supports capturing input pulse widths on three channels, which makes for a nice communications channel if the correct pins are accessible. Specifically (note to self for later), using timer 2 with CRC capturing falling edge and CC[1:3] getting the rising edges, and have the other end drive them all starting at the same time.

Can you link a copy of the Datasheet? Is it confirmed that it's programmable? most of the China MCU's I've dealt with are 1 time flash.

Unfortunately, the pictures I was looking at are for a completely different controller, with completely different MCU. I can't find any info on the one I do have, but it does have helpfully labeled JTAG pins so I'm hoping to read an ID off of it. People on the Internet say similar parts are NEC/Renesas MCUs which look like they're programmable multiple times, but that's very vague. More details on what I found in this post on another thread. I'll post an update once I get a chance to hook it up on a power supply and try poking at it, hopefully this weekend.