BLDC controller, highly advanced.

I've got a lot of ideas, some i realize, and some I don't. Given that i now have access to a IR-oven, cnc-pcb manufacturing equipment and many skilled teachers - I've began drooling over building an advanced controller.

I need a place to store all the information, maybe others will find parts of it interesting too

Features: (I'll elaborate on all of these points later)
- SMD mounting with some through hole
- Separate power stage(s)
- Accelerometer/gyro for real time feedback, fault controll and efficiency monitoring
- Current sensing on all phases
- Hall/sensorless controll
- Arduino compatabillity
- Test mode: System inductance and resistance

As of this date I do not have sufficient knowledge to build this, I like learning through failure

Power stage.

I find great difficulties building this, there is so much information - I will try to break it down into easy steps.

I'm building a highly efficient controller, heat generated in the mosfets really shouldn't be high in the first place. Switches will be hard and inductive backspikes will be nasty. Measures to decrease inductive spikes include making my own motor wire. It will be the kind of 155C enameled copper wire and braided in a way such that the wires come really close, reducing inductance. Further on the controller will be fitted close to the motor (20 cm ish), to decrease it more.

More calculations on inductive spikes will come here.

IRFS4115 mosfets will be used. There are other candidates, but given the fully characterized capacitance and avalanche data, this is nice to calculate on.
IRLML6344 is a small SOT-23 mosfet, (I think) ideal for driving the power mosfets. More research.

I want to outfit every power stage with individual drive mosfets, so that adding more for more power is easy. I've planned on a basic 12fet setup - power should already be plentiful only with one board.

IRFB3077 mosfets, 75V, low Rds on, high current rating and appropriate casing. - maybe I'll use this

Aluminium heatsinks (connected directly to Drain) will work as "DC+" and "A", "B" and "C" for easy connection and minimal pcb current transport. Ultiboard, paint and later on solidworks sketches will come

Voltage regulator: To be done

Cap choices: to be done. This document explains why I'm not going "1F" electrolytic with crappy ESR. Maybe higher switching frequency will be used to lower capacitance needed. Trying to find good data on motor inductance, anyone care to give me a ball-park figure? This topic gives me a ballpark figure of about 20uH for big outrunners, but I guess hubbies are another story?

Low ESR, Fact or Fiction, nice paper on film and electrolytic capacitors. Interesting to see that a "low inductance" cap would probably work better than a "low ESR" one.

Current sensing: SMD Vishay, new stuff. Good for 1W and 0,005 ohm. Op-amps and stuff will be covered later.

reserved

Why did you choose those fets??????
Can't somebody just finishe thier controller already lol

Arlo1 said:

Can't somebody just finishe thier controller already lol

Click to expand...

Seriously.. been on this forum for about a year and a half now. I've seen a few dozen people start a controller build, then never complete it.. BLDC control must be a huge pain in the ass.

neptronix said:

Arlo1 said:

Can't somebody just finishe thier controller already lol

Click to expand...

Seriously.. been on this forum for about a year and a half now. I've seen a few dozen people start a controller build, then never complete it.. BLDC control must be a huge pain in the ass.

Click to expand...

LOL Im working a lot on mine. But im at the Code stage to make it all work. I have got V1 controller and V1 powerstage to make noise in the motor. But because they were both such a mess Im on to version 2 of each. I will hopefully get a motor to turn soon then onto the more complex parts of the code.

neptronix said:

Arlo1 said:

Can't somebody just finishe thier controller already lol

Click to expand...

Seriously.. been on this forum for about a year and a half now. I've seen a few dozen people start a controller build, then never complete it.. BLDC control must be a huge pain in the ass.

Click to expand...

It is, mostly because it needs a mix of diciplines. It is both quite exotic electronics beeing both analog and high power and fairly advanced software , beeing embedded and realtime. Not many have all thoose skills and noone who does has the time...

Maybe the way forward is to raise a big pile of cash and have a Endless-Sphere controller X-prize (or even just pay Shane Colton to build us a kickass one )

Arlo1 said:

Why did you choose those fets??????
Can't somebody just finishe thier controller already lol

Click to expand...

They have about half the switching losses of your IRFP4668, half the switching time (lower gate charge), higher avalanche robustness and half the price. I'm looking into lower voltage ones. 100V might be an option. I'm going to write more about it later.

About finishing it- I'm going to go easy logic circuits to actually complete it. Surveillance of the circuit through a fast IC will be the easiest implementation.

neptronix said:

Arlo1 said:

Can't somebody just finishe thier controller already lol

Click to expand...

Seriously.. been on this forum for about a year and a half now. I've seen a few dozen people start a controller build, then never complete it.. BLDC control must be a huge pain in the ass.

Click to expand...

Been on the forum for a little over a year now too. Many started BLDC projects, none really ready yet. I decided to do my own power stage and try to work on just that one single aspect since it doesn't seem many people had much going on in this area. I'm also a micro controller guy and wanted to learn more of the power side.

It is a pretty big task to take on all the tasks required in designing a controller and getting a power stage to live seems like the hardest part so I thought I'd tackle that hurdle first. Digital guys tend to lack some of the disciplines needed in power design such as managing the heat properly which is more of a mechanical engineering issue. Since I'm a jack of all trades I thought this might be good for me since I've tackled several ME issues before with success. I've also got a little background in RF from doing Ham radio, building some low power RF amps and have built several DIY audio amplifiers.

Now that I'm waist deep in power stage design I see why it's so hard to make them live, lots of variables that need to be taken into account in the design, then you need to empirically test the setup to find how close your best guess was and tweak it.

Your IRFS4115 mosfets choice has a high RDSon and are much more difficult manage heat wise, I'd reconsider and go for TO-220 minimum, but the fun starts at the TO-247 size. IRFP4568 is what I'm building around.

Teh Stork said:

Arlo1 said:

Why did you choose those fets??????
Can't somebody just finishe thier controller already lol

Click to expand...

They have about half the switching losses of your IRFP4668, half the switching time (lower gate charge), higher avalanche robustness and half the price. I'm looking into lower voltage ones. 100V might be an option. I'm going to write more about it later.

About finishing it- I'm going to go easy logic circuits to actually complete it. Surveillance of the circuit through a fast IC will be the easiest implementation.

Click to expand...

I got my 4668 fets for just over $4 cdn each how much are the ixys fets? The 4668 fets also have lower rdson. But im just in testing stages...

Arlo1 said:

I got my 4668 fets for just over $4 cdn each how much are the ixys fets? The 4668 fets also have lower rdson. But im just in testing stages...

Click to expand...

The 4115's are 2,2 dollars each. Look below for a comment on rds-on rating.

zombiess said:

Your IRFS4115 mosfets choice has a high RDSon and are much more difficult manage heat wise, I'd reconsider and go for TO-220 minimum, but the fun starts at the TO-247 size. IRFP4568 is what I'm building around.

Click to expand...

The RDSon is a useless stat. Dissipated heat in mosfet - conducting at 60A: ~40W
Heat dissipated through forward diode voltage drop at 60A: (fig 7 in datasheet): ~60W
Current rating are also a useless stat.

As you can see, heating in the mosfet when it's blocking current is higher than when it's not.

I'm considering a DirectFET because of the nice cooling advantages of it, but we'll see

Teh Stork said:

The RDSon is a useless stat. Dissipated heat in mosfet - conducting at 60A: ~40W
Heat dissipated through forward diode voltage drop at 60A: (fig 7 in datasheet): ~60W
Current rating are also a useless stat.

As you can see, heating in the mosfet when it's blocking current is higher than when it's not.

Click to expand...

You're not supposed to use the reverse diode, you're supposed to switch on the other FET of the half-bridge

pelle242 said:

Maybe the way forward is to raise a big pile of cash and have a Endless-Sphere controller X-prize (or even just pay Shane Colton to build us a kickass one )

Click to expand...

yes PLEASE !

Lebowski said:

Teh Stork said:

The RDSon is a useless stat. Dissipated heat in mosfet - conducting at 60A: ~40W
Heat dissipated through forward diode voltage drop at 60A: (fig 7 in datasheet): ~60W
Current rating are also a useless stat.

As you can see, heating in the mosfet when it's blocking current is higher than when it's not.

Click to expand...

You're not supposed to use the reverse diode, you're supposed to switch on the other FET of the half-bridge

Click to expand...

Hmm, are you sure? I might mess this up based on earlier mosfet based power converters.

Teh Stork said:

Hmm, are you sure? I might mess this up based on earlier mosfet based power converters.

Click to expand...

In power converters (I'm assuming you mean buck-boost type DCDC ?) the diodes are used
(instead of a FET) because it's a big no-no to have the currents reverse direction. This is no
issue here with motor controllers.
In power converters as build into mobile phones again no diodes are used but low-side FETs, this
because as long as you stay on-chip everything is lightning fast. A detector is build-in to detect
the onset of current reversal, this shuts down the low-side FET.

Lebowski said:

pelle242 said:

Maybe the way forward is to raise a big pile of cash and have a Endless-Sphere controller X-prize (or even just pay Shane Colton to build us a kickass one )

Click to expand...

yes PLEASE !

Click to expand...

I am sure you would like that. We will just have to make sure one of the requirements would be "implemented in a understandable and maintainable high level language"

Joking aside your project is one of the most interesting and definitely the most innovative of all the controllers on the sphere. Keep up the good work.

Reading up on FOC controll once again. Labview with xilinx FPGA or a dedicated microchip IC. I'm not sure what to go for. The documents also say little about torque off the line, something that is important in ebike-applications. Maybe a combination of hall for startup and then foc after xx mph will be a good tradeoff?

FOC with FPGA and labvieW.
MicroChip application note on FOC.
How to implement this into a uC.
Atmel uC "how to implement".

If you're considering reading one of these, I reccomend the last one and the second one.

Just bundling these links here to save them somewhere. I hope to find something more fitting for my application.

I've changed my goals for the controller, I'll dump the "lightning fast reflexes" and go for more efficiency and ease of construction - something to fit the "still insane" ebike-application.

AT32UC3B0256-A2UT seems to do the job for me. 6 pwm outputs. 60MHz clock speed. RISC architecture. I can program it to deliver output based on hall sensors at startup - then to run FOC controll once some speed is achieved.

Teh Stork said:

Reading up on FOC controll once again. Labview with xilinx FPGA or a dedicated microchip IC. I'm not sure what to go for. The documents also say little about torque off the line, something that is important in ebike-applications. Maybe a combination of hall for startup and then foc after xx mph will be a good tradeoff?

FOC with FPGA and labvieW.
MicroChip application note on FOC.
How to implement this into a uC.
Atmel uC "how to implement".

If you're considering reading one of these, I reccomend the last one and the second one.

Just bundling these links here to save them somewhere. I hope to find something more fitting for my application.

Click to expand...

The control is some what different from an induction motor to a BLDC or permanent magnet synchronous motor.

FOC can be used with BLDC motors. The last app note from Atmel is an example.

I wonder if the benefits are worth the complexity though. A system that works with Hall sensors at low RPM and then smoothly transitions to and from back EMF sensorless control might be a better choice, at least for trapezoidal back EMF BLDC motors.

Alan B said:

FOC can be used with BLDC motors. The last app note from Atmel is an example.

I wonder if the benefits are worth the complexity though. A system that works with Hall sensors at low RPM and then smoothly transitions to and from back EMF sensorless control might be a better choice, at least for trapezoidal back EMF BLDC motors.

Click to expand...

Updated my previous post to reflect on this Halls at low speed is definitely a must. The atmel could be programmed to run all these different modes. Isn't is so that FOC and Sinewave controll is silent compared to Squarewave controll? (Not 100% sure on the appropriate terms here xD)

You guys should look to lebowskies controller build and it is what I will be using as well. His starts in sensored with hall sensors then switches to sensorless.

Noise is caused partly by torque ripple. If the back EMF is a sine wave then a sine wave drive will produce minimum torque ripple. If the back emf is a trapezoid then a trapezoidal drive will produce minimum torque ripple.

There are other sources of noise and commutation may produce more noise with trapezoidal than sine wave, so at the end of the day it is quite possible that sine wave is quieter, or at least the noise is lower frequency which is less noticeable.

However driving a trapezoidal back EMF motor with a sine wave will produce less torque given the same peak drive voltage. Perhaps ideally a combination would be used. At low power input use the sine wave and transition to trapezoidal when max torque is needed. So you have a quiet motor until you really pour on the acceleration.

Alan B said:

However driving a trapezoidal back EMF motor with a sine wave will produce less torque given the same peak drive voltage. Perhaps ideally a combination would be used. At low power input use the sine wave and transition to trapezoidal when max torque is needed. So you have a quiet motor until you really pour on the acceleration.

Click to expand...

I got this in my controller (for the sensorless part, in sensored mode it supplies the motor with its own back-emf). In
sensorless the motor is driven with a pure sine wave. There's an 'amplitude' variable in one of the menus, set at 100%
means it will up to an amplitude where the sine wave just fits in the supply. The variable can be set to up to 200%. Anything
over 100% will introduce clipping, a 200% clipped sinewave is practically a trapezoidal. There's a video here

http://endless-sphere.com/forums/viewtopic.php?f=30&t=34231&start=30#p504676

when I press the button the amplitude rises to above 100%, you can clearly hear this

What was the back EMF waveform on that motor? More sine like??

Alan B said:

What was the back EMF waveform on that motor? More sine like??

Click to expand...

yes, 96% fundamental, 3% third order ....

Reading this application note from IR (IR2110) on mosfet drivers. This seems like an ideal solution. Working with multisim atm, firstly to make a ultiboard sketch - secondly maybe to do some simulations. (This will take substantial more work tho, adding all the components to the library). Still, simulations will give nice "ballpark-figures" on gate resistance, capacitor needs and more

Will post the schematic later when I've added all the stuff to it - probably needs some fault proofing :|

Edit: turns out, need to do simulations first to know what caps and stuff to get - so this will take longer than expected...