Alan B
100 GW
Jeremy Harris said:
Looks like that chip will make for a very low parts count! Nice!
DIY eBike BLDC Motor Controller
- Thread starter Alan B
- Start date
Looks like that chip will make for a very low parts count! Nice!
Alan B
100 GW
ZapPat said:...
I wouldn't think about spending more than 1-2% max per PWM period in the FET switching region myself!bigmoose said:It seems that it doesn't really take such a big driver chip to quickly switch 400~500nC or so of FETs (2X IRFB3006's). Using TI's UCC27201 driver rated at 3A peak I get switching times quite a bit under 500ns on+off combined under full load (from memory - I am setting up new diffferent FETs right now for new tests). This is using 10ohm gate drive resistors, so with bigger FETs the resistors could be lowered to try and maintain good switching times. I don't think we really need insanely huge gate drive chips for ebike sized applications, even for the more extreme ones.
Pat
It has been mentioned that there are some issues that come up when the gate drive is very high. EMI, voltage spikes from ringing perhaps. Can we elaborate a bit on this to understand it better?
rhitee05
10 kW
Alan B said:
You can break this apart into two almost-independent issues. Voltage spikes, ringing, etc - i.e. the transient phenomena - all have their root in the characteristic response of the circuit. EMI is somewhat influence by this, but is mostly due to the physical structure and layout.
The gate drive circuit is an RLC circuit (series RLC specifically, but it doesn't really matter). I'll suggest reading Wikipedia as background:
https://secure.wikimedia.org/wikipedia/en/wiki/Rlc_circuit
https://secure.wikimedia.org/wikipedia/en/wiki/Transient_response
https://secure.wikimedia.org/wikipedia/en/wiki/Damping
The inductance in the circuit is mostly the parasitics, the capacitance is mostly the gate capacitance, and the gate resistor is the resistance. We don't have much control of the L and C components, so we mostly have to tune the circuit by adjusting R. Normally, the goal is to tune a circuit for "critical damping" which has no overshoot and reaches steady-state in the shortest possible time. For a gate drive, there might be a slight advantage in tuning the circuit to be slightly "underdamped" which means there will be oscillations which decay over time. This is also called "ringing" and is the source of voltage spikes during switching. An underdamped circuit will rise a little more quickly than the critically damped one, even though the ringing will take longer to settle down, so that should decrease the switching time slightly. But if the circuit is too underdamped, the voltage spikes will be large, will take a long time to decay, and could even oscillate. In terms of the previous discussion about adding some inductance, the extra inductance will lower the frequency of the oscillations and also move the circuit more toward over-damping.
EMI is mostly a product of the physical layout - size, width, and position of traces, placement of components, everything. But the damping also plays a part. An underdamped system will tend to cause more EMI because the ringing contains more high-frequency energy. Adding some inductance will also help because it will lower the ringing frequency and thus decrease the frequency of any emitted EMI. Higher frequencies of EMI tend to be more troublesome than lower frequencies. Besides damping, the resistance also plays a factor because the magnitude of EMI is directly related to the magnitude of the currents flowing. You can solve EMI problems by reducing the current even if you have a crappy layout, at the price of performance.
Alan B
100 GW
Great background material. Thanks.
Can we factor out the specific issues to this application? What components need to be changed/upgraded or added if the switching rate is increased like that??
Another side of the issue is what are the quantitative benefits of going from say 5% to 1% switching? How much power savings does this yield??
A really rough calculation of power saved can be made by assuming that half the power is wasted during the transition time (if FET impedance = load impedance for the whole time). Power savings would then be (5% - 1%) * power / 2 which is 4% of half the power, or a net savings of 2%. This is probably a high estimate, so actual savings will be less than 2% of the motor power.
I'm not advocating doing, or not doing this, but it would help readers of this thread to understand the tradeoffs in making the choice. Adding parts, increasing transients and potentially generating more EMI saves power wasted in the FET transition time. EMI itself is a waste of power (as well as a major source of RF spectrum pollution).
Can we factor out the specific issues to this application? What components need to be changed/upgraded or added if the switching rate is increased like that??
Another side of the issue is what are the quantitative benefits of going from say 5% to 1% switching? How much power savings does this yield??
A really rough calculation of power saved can be made by assuming that half the power is wasted during the transition time (if FET impedance = load impedance for the whole time). Power savings would then be (5% - 1%) * power / 2 which is 4% of half the power, or a net savings of 2%. This is probably a high estimate, so actual savings will be less than 2% of the motor power.
I'm not advocating doing, or not doing this, but it would help readers of this thread to understand the tradeoffs in making the choice. Adding parts, increasing transients and potentially generating more EMI saves power wasted in the FET transition time. EMI itself is a waste of power (as well as a major source of RF spectrum pollution).
rhitee05
10 kW
Alan B said:
It's hard to give any specific answer here. One simple way to look at it: the gate capacitance and parasitic inductance together determine the minimum gate resistor required to give a reasonably damped response and thus the minimum achievable switching time. Since we can't change the gate capacitance, in order to achieve faster switching we need to reduce the parasitic inductance. That's assuming a circuit is already optimized for the minimum stable R, which isn't usually the case.
Alan B said:
A good explanation of gate drive circuits can be found here:
http://focus.ti.com/lit/ml/slup169/slup169.pdf
The power dissipated during switching is E = 1/2 * Vbatt * Iphase * (ton + off), and you can multiply by PWM frequency to get the switching power: P = 1/2 * Vbatt * Iphase * (ton + toff) * fPWM. The document I linked has a very thorough explanation of FET switching. Basically, the current rises from zero to 100% before the voltage drops from full battery voltage to the small I*R on voltage. That results in a huge amount of power but for a very brief time. Note that this formula uses the phase current, not the battery current. You'd need a lot of other parameters to determine specific power savings, but it could be very significant in terms of the total power being dissipated by the FETs. It's more useful to look at this as a substantial decrease in cooling requirements, rather than a small increase in net system efficiency.
Alan B said:
The amount of energy actually radiated in EMI is trivial. Probably milliwatts if not microwatts. You won't save any measurable power if you manage to reduce EMI without changing the circuit waveforms. It's more important to reduce EMI to avoid causing havoc in and around the controller.
There have been a lot of posts lately about people killing their batteries by leaving their controllers on while the bike is not being used. An auto-shutoff circuit sounds like it would be VERY useful to add.
Another issue that nags my paranoid bone is the design of Ebike throttles. They are single point of failure items where a possible failure mode leads to stuck wide-open-throttle. I would like to see a throttle design that uses two independent sensors (ideally with complementary outputs, even better using two different technologies - like pots and hall-effects). If the two throttle signals do not agree, the bike shuts down. This technique is used in car fly-by-wire throttles.
Another issue that nags my paranoid bone is the design of Ebike throttles. They are single point of failure items where a possible failure mode leads to stuck wide-open-throttle. I would like to see a throttle design that uses two independent sensors (ideally with complementary outputs, even better using two different technologies - like pots and hall-effects). If the two throttle signals do not agree, the bike shuts down. This technique is used in car fly-by-wire throttles.
oldswamm
100 W
The first of Texaspyros complaints is another reason for a battery contactor that I had thought about before, but hadn't mentioned. If the battery gets low, the controller can disconnect itself, and the human would have to push the 'start button' (precontactor resistor bypass switch) to get power back to the controller.
To the second, it's a good idea, but more for the mfgs than us! (they just need sued) For us, adding a second hall sensor would be fairly easy, at least in some throttles, and would provide all the data needed for virtually 100% dependability (of that aspect). Good idea, at least something to think about.
To the second, it's a good idea, but more for the mfgs than us! (they just need sued) For us, adding a second hall sensor would be fairly easy, at least in some throttles, and would provide all the data needed for virtually 100% dependability (of that aspect). Good idea, at least something to think about.
Alan B
100 GW
rhitee05 said:
That is a good point. Heating in the FETs is a small fraction of total power so even small changes in total can make large changes in FET temperatures.
Alan B
100 GW
texaspyro said:
My plan was to reduce power consumption of the controller when NOT operating the motor to a lower level than is usual, in which case leaving it on would have very little impact on the battery and take a very long time to run it down. Having it turn itself off even further is a good suggestion, if it can be done with little or no impact in hardware complexity and parts cost. The easiest way to do this is shut down the microprocessor, but that does not save much power. The voltage regulators are still running, plus the various leakages and voltage sampling dividers.
Another way to do this is provide a high side FET switch that feeds the voltage regulation system that can be disabled by the CPU. This would require a few components to implement. The leakage of the high voltage system - capacitor bank, power FETS, etc would still be present. A more effective solution would require a contactor or massive FET switch in series to cut the whole load. This can be done outside the controller with an off the shelf contactor.
On the subject of throttle runaway, I think we can do a pretty decent job of that with a little thought and no changes to the existing throttle hardware. By electrically biasing the throttle input gently toward zero, and rejecting out of range high voltages we can make most failures go to throttle off. The only case we cannot easily recognize is a failure of the throttle that sends a valid voltage output. Of course the ebrake input overrides the throttle and I would suggest that after an ebrake input that the throttle be ignored until it is cycled off and back up, so tapping the ebrake would disable a stuck throttle and it would not just come back on when the brake was released.
Yeah, a rather common failure mode of those cheap hall effect throttles seems to be the magnet comming loose. I had one where it jammed at max thrust... didn't help that the ebrake switch was a bit wonky at the time (looks like water got in it). Made for an interesting few moments of impeding brown trousers.
Still, BLDC motors/controllers are a LOT better than brushed controllers. Brushed controller standard failure mode is "damn the torpedos, screw the brake signal, full steam ahead!" When I had a brushed motor, the failsafe was a kevlar lanyard epoxied to the fuse.
Still, BLDC motors/controllers are a LOT better than brushed controllers. Brushed controller standard failure mode is "damn the torpedos, screw the brake signal, full steam ahead!
" When I had a brushed motor, the failsafe was a kevlar lanyard epoxied to the fuse.
Alan B
100 GW
I like the fuse approach. Very positive. A cord to my Anderson SB-50's would work well...
What do the throttles do when the magnet comes loose? Can the software detect that somehow??
Should we advocate epoxy on the magnets??
What do the throttles do when the magnet comes loose? Can the software detect that somehow??
Should we advocate epoxy on the magnets??
rhitee05
10 kW
Another option would be to use a Hall throttle with 2 magnets (where the sensor moves between the magnets). That should improve the action of the throttle (make it more linear), and it would also still work if one of the magnets were to fall off.
It's difficult to make a system truly failure-proof. In this situation, you can protect against some of the more common failure modes and keep the "big red button" handy in case something unusual happens. Some of those failure modes might be too difficult or too expensive to design out of the system given how unlikely they are to occur. (Not specifically referring to any one issue that's been discussed, just speaking in general)
It's difficult to make a system truly failure-proof. In this situation, you can protect against some of the more common failure modes and keep the "big red button" handy in case something unusual happens. Some of those failure modes might be too difficult or too expensive to design out of the system given how unlikely they are to occur. (Not specifically referring to any one issue that's been discussed, just speaking in general)
Alan B said:
Back in the early days of computers (when people thought that they might take over the world) IBM designed an emergency cutoff into all their mainfames. Basically a big red button you hit (actually, you pulled it) and a guillotine sliced through the power cables. And then fun was had by all
oldswamm
100 W
But what if the Anderson welds? I think you should consider the guillotine approach Alan.texaspyro said:Alan B said:
Back in the early days of computers (when people thought that they might take over the world) IBM designed an emergency cutoff into all their mainfames. Basically a big red button you hit (actually, you pulled it) and a guillotine sliced through the power cables. And then fun was had by all
:lol: Bob
bigmoose
1 MW
texaspyro said:
Son of a gun... I haven't heard that since the 80's when it was General Dynamics' Super Zip!! Gotta love det cord and frangible al-u-min-e-um... for a perfect zero moment separation.
Alan B
100 GW
For those actually interested in Motor Controls 
, there are a number of useful papers linked from this page:
http://www.atmel.com/dyn/products/product_card.asp?part_id=4307
There are data sheets on the ATMega32M1 Motor Control optimized AVR Microprocessor, and then a number of application notes on sensored and sensorless brushless DC motor controls, as well as documentation and schematics on their demonstration board set. If the schematic of the demo board is used as a template for the design insofar as using the same inputs/outputs for the same purpose, the demonstration software available for download from this page will work in the design with little or no modification. So a first order motor controller could be made to work quickly and without a lot of software development.
More AVR motor control application notes here:
http://www.atmel.com/products/avr/mc
, there are a number of useful papers linked from this page:http://www.atmel.com/dyn/products/product_card.asp?part_id=4307
There are data sheets on the ATMega32M1 Motor Control optimized AVR Microprocessor, and then a number of application notes on sensored and sensorless brushless DC motor controls, as well as documentation and schematics on their demonstration board set. If the schematic of the demo board is used as a template for the design insofar as using the same inputs/outputs for the same purpose, the demonstration software available for download from this page will work in the design with little or no modification. So a first order motor controller could be made to work quickly and without a lot of software development.
More AVR motor control application notes here:
http://www.atmel.com/products/avr/mc
Alan B
100 GW
Waking up my old Controller Design thread. Lots of good stuff earlier in the thread.
I made a schematic for this controller in DipTrace. I'm still tuning it, but it is fairly complete design.
I noticed recently that Newark has the ATmega64M1 version of this chip on sale for under $4. I have a few of the ATMega32M1's which are 32K parts, the Newark deal is on the 64K parts.
Why make your own controller?
It is NOT to save money. We can buy very cheap controllers these days. If your goal is to save money then making the controller is not going to help.
To Learn about Controller Hardware and Software, and how BLDC motors work.
To Experiment with ideas you have about hardware, software and control algorithms.
To add Custom features that you might not find in commercial controllers that fit your setup.
Features like Torque throttle, where the throttle controls the motor torque rather than the PWM duty cycle.
To get variable regen and electric braking which is not available in very many controllers, and when available may not work the way you would like.
To get AWD coordination for 2WD (or more) motor control synchronization.
To have more control over Multiple configurations, such as what happens with the 3 speed selections.
To make the controller better fit your desired form factor - Small, a particular shape perhaps, such as inside a bicycle tube.
To increase Efficiency and make a cooler running controller.
To have a controller with very Low Standby Power.
To build Security Features in for some degree of Theft control.
To make the controller more Robust, adding things like Temperature monitoring to protect motor and controller.
To get compliance with local regulations which sometimes have complex requirements for speed, power, throttle and pedaling.
To experiment with Pedaling assist algorithms.
To get more Control over your controller, and do things with it that you want to do.
What can you think of?
I made a schematic for this controller in DipTrace. I'm still tuning it, but it is fairly complete design.
I noticed recently that Newark has the ATmega64M1 version of this chip on sale for under $4. I have a few of the ATMega32M1's which are 32K parts, the Newark deal is on the 64K parts.
Why make your own controller?
It is NOT to save money. We can buy very cheap controllers these days. If your goal is to save money then making the controller is not going to help.
To Learn about Controller Hardware and Software, and how BLDC motors work.
To Experiment with ideas you have about hardware, software and control algorithms.
To add Custom features that you might not find in commercial controllers that fit your setup.
Features like Torque throttle, where the throttle controls the motor torque rather than the PWM duty cycle.
To get variable regen and electric braking which is not available in very many controllers, and when available may not work the way you would like.
To get AWD coordination for 2WD (or more) motor control synchronization.
To have more control over Multiple configurations, such as what happens with the 3 speed selections.
To make the controller better fit your desired form factor - Small, a particular shape perhaps, such as inside a bicycle tube.
To increase Efficiency and make a cooler running controller.
To have a controller with very Low Standby Power.
To build Security Features in for some degree of Theft control.
To make the controller more Robust, adding things like Temperature monitoring to protect motor and controller.
To get compliance with local regulations which sometimes have complex requirements for speed, power, throttle and pedaling.
To experiment with Pedaling assist algorithms.
To get more Control over your controller, and do things with it that you want to do.
What can you think of?
Alan B
100 GW
I updated the schematic above a couple of times in the last day. I've yet to renumber components, it is rather scattered. Further review and optimization of some pinouts will also occur. I have just added CANbus and maintained the 3 speed switch. There are still a few CPU pins available. Perhaps I'll try to add sensorless sampling inputs, that would require 3 pins and some reorganization.
Why choose this particular CPU chip (the ATMega32/64M1)?
This processor is designed for automotive brushless motor control. To this end there are special purpose modules included for Motor Controls, CANbus and LINbus. The Motor Control module is called the Power Stage Controller and includes hardware for three phase control, sensorless operation, current measurement, and fast reacting emergency shutdown hardware that bypasses the CPU and reacts quickly to selectable conditions. Compared to the Infineon chips that are used in the common ebike controllers, this chip requires fewer external components and is more readily programmed with freely available software tools.
The AVR series of processors is well supported by the excellent (and free) GNU C compiler that is the basis for everything Linux plus a lot of other operating systems.
The ATmega32M1 is a member of the ATmega32 series, which has become very well known in some of the popular Arduino boards. While the Arduino was unknown to me when I selected it six years ago, it offers the potential to make this board an Arduino, or at least to use the libraries and tools that are used for Arduino development.
So what do we have in the schematic above?
The ATmega32M1 CPU it the core of this design, which could also be replaced by the ATmega64M1 CPU. They are the same except the flash program memory increases from 32K to 64K in the part that Newark has on sale at a lower price. The RAM memory doubles as well. It is not clear yet how much program memory we might need, but more is good, especially on a test prototype. In one of the Atmel papers the ATmega32M1 was doing hall sensored brushless motor control with something like 5K of program memory of the 32/64K available, and a CPU utilization of 5%. The specialized hardware really helps in an application like this. Of course we will want to do more so it will take more resources, but there's a lot of room in either chip. The larger 64K chip will be more useful in the handlebar display, the graphics LCDs take more code to operate.
Returning to the schematic, we have a Battery input on the upper right, and the three motor phase connections along the right edge. The intent is to leave these connected to the battery and make the leakage current very small so it won't drain the battery.
On the upper left we start with Control Power input, this should be routed through the keyswitch and/or kill switch and feeds battery plus to the regulators that power the board. A pre regulator reduces the higher battery voltages to a safe range for a small switching regulator producing 12 volts, and a 5V regulator produces CPU power from the 12V.
The 3Speed switch pulls down one or the other or neither of a couple of lines to the CPU. The software can read this switch and determine how it is used in the program.
The Throttle is supplied 5V and ground, and provides an output voltage back to the controller within that range, just like other controllers.
The Ebrake is expected to be fed with a contact closure or transistor to ground. There is a blocking diode so 12V from an LED brake light return can be fed to this pin without damaging the controller.
The CANbus will be used to communicate with other elements of the bike and/or programming variables. In the past I have not been too interested in CANbus as it seems to be overkill for an ebike. But it does have some very nice properties like only needing 3 wires and it has a nice priority resolution, and the hardware it built into a number of CPUs including these ATmega parts, so it is easier to use it than invent something else.
The Motor connector provides 5V, ground and reads in the 3 hall sensors. It also provides for a motor temperature signal to be read by the CPU.
The Programming connector is used to load code into the ATmega32/64M1 chip.
There are the usual three driver chips containing six drivers, and six FETs. This is a lot fewer parts than the usual inexpensive controllers use, and they have higher performance and more safety features designed in than the usual discrete devices. There may be options for expanding the number of FETs, the FET/drivers will likely be split off to a separate PCB for modularity, and a mechanism that will allow using more than one FET board per controller. At least that's the thinking at this point.
Ebike Control System
I am envisioning this motor controller as part of a complete ebike system based on CANbus. A Display Unit will go on the Handlebars and attach via CANbus, providing readouts and controls, and take inputs such as Ebrake and Throttle as well as a 3 Speed Switch. The goal here is to minimize the wiring from the handlebars to the bike. There will be 12 volts supplied from the controller (or some other 12V supply) and the two wires for the CANbus signals. So a small cable with four conductors will (hopefully) be the only wiring to the handlebars, at least this approach minimizes wiring by replacing wires with CANbus messages. The wires will be much shorter this way, with a nexus at the handlebar display.
I will leave throttle and ebrake inputs on the motor controller board for standalone applications, but the 3 speed switch may or may not remain, it depends on what pins remain when sensorless inputs are added as well as keeping the hall sensors in the design.
Why choose this particular CPU chip (the ATMega32/64M1)?
This processor is designed for automotive brushless motor control. To this end there are special purpose modules included for Motor Controls, CANbus and LINbus. The Motor Control module is called the Power Stage Controller and includes hardware for three phase control, sensorless operation, current measurement, and fast reacting emergency shutdown hardware that bypasses the CPU and reacts quickly to selectable conditions. Compared to the Infineon chips that are used in the common ebike controllers, this chip requires fewer external components and is more readily programmed with freely available software tools.
The AVR series of processors is well supported by the excellent (and free) GNU C compiler that is the basis for everything Linux plus a lot of other operating systems.
The ATmega32M1 is a member of the ATmega32 series, which has become very well known in some of the popular Arduino boards. While the Arduino was unknown to me when I selected it six years ago, it offers the potential to make this board an Arduino, or at least to use the libraries and tools that are used for Arduino development.
So what do we have in the schematic above?
The ATmega32M1 CPU it the core of this design, which could also be replaced by the ATmega64M1 CPU. They are the same except the flash program memory increases from 32K to 64K in the part that Newark has on sale at a lower price. The RAM memory doubles as well. It is not clear yet how much program memory we might need, but more is good, especially on a test prototype. In one of the Atmel papers the ATmega32M1 was doing hall sensored brushless motor control with something like 5K of program memory of the 32/64K available, and a CPU utilization of 5%. The specialized hardware really helps in an application like this. Of course we will want to do more so it will take more resources, but there's a lot of room in either chip. The larger 64K chip will be more useful in the handlebar display, the graphics LCDs take more code to operate.
Returning to the schematic, we have a Battery input on the upper right, and the three motor phase connections along the right edge. The intent is to leave these connected to the battery and make the leakage current very small so it won't drain the battery.
On the upper left we start with Control Power input, this should be routed through the keyswitch and/or kill switch and feeds battery plus to the regulators that power the board. A pre regulator reduces the higher battery voltages to a safe range for a small switching regulator producing 12 volts, and a 5V regulator produces CPU power from the 12V.
The 3Speed switch pulls down one or the other or neither of a couple of lines to the CPU. The software can read this switch and determine how it is used in the program.
The Throttle is supplied 5V and ground, and provides an output voltage back to the controller within that range, just like other controllers.
The Ebrake is expected to be fed with a contact closure or transistor to ground. There is a blocking diode so 12V from an LED brake light return can be fed to this pin without damaging the controller.
The CANbus will be used to communicate with other elements of the bike and/or programming variables. In the past I have not been too interested in CANbus as it seems to be overkill for an ebike. But it does have some very nice properties like only needing 3 wires and it has a nice priority resolution, and the hardware it built into a number of CPUs including these ATmega parts, so it is easier to use it than invent something else.
The Motor connector provides 5V, ground and reads in the 3 hall sensors. It also provides for a motor temperature signal to be read by the CPU.
The Programming connector is used to load code into the ATmega32/64M1 chip.
There are the usual three driver chips containing six drivers, and six FETs. This is a lot fewer parts than the usual inexpensive controllers use, and they have higher performance and more safety features designed in than the usual discrete devices. There may be options for expanding the number of FETs, the FET/drivers will likely be split off to a separate PCB for modularity, and a mechanism that will allow using more than one FET board per controller. At least that's the thinking at this point.
Ebike Control System
I am envisioning this motor controller as part of a complete ebike system based on CANbus. A Display Unit will go on the Handlebars and attach via CANbus, providing readouts and controls, and take inputs such as Ebrake and Throttle as well as a 3 Speed Switch. The goal here is to minimize the wiring from the handlebars to the bike. There will be 12 volts supplied from the controller (or some other 12V supply) and the two wires for the CANbus signals. So a small cable with four conductors will (hopefully) be the only wiring to the handlebars, at least this approach minimizes wiring by replacing wires with CANbus messages. The wires will be much shorter this way, with a nexus at the handlebar display.
I will leave throttle and ebrake inputs on the motor controller board for standalone applications, but the 3 speed switch may or may not remain, it depends on what pins remain when sensorless inputs are added as well as keeping the hall sensors in the design.
Alan B
100 GW
A few updates. The CANbus connectors have been changed to RJ45 to work with standard network cables, with 5V and 12V provided. Two connectors are provided for in/out, and the bus termination will be provided with a plug containing the 120 ohm resistor between pins 1 and 2. This connector is a standard for CANbus, though I am proposing to put 12V and ground on the unused pair. The 5V is used for powering the bus side of isolated transceivers which will be needed on BMS boards and could be used elsewhere if desired. The 12V would be to power modules that need a little more than 5V.
I've been reviewing FETs and am torn between TO220 4110's and TO247 4468's. To keep it simple I'm planning only six, but properly driven these should be capable of a useful level of ebike power, likely at the 12 FET standard controller level at least, perhaps more, especially with the TO247 FETs. [2017 update - consider the TO220 AOT290L (used in PhaseRunner), 3.5 mOhm 100V 140A 500W $2.80 in 25 qty at Digikey (note to self - order some)].
I wonder who else has experimented with the ATmega32M1 (or the ATmega64M1). It would be nice to hear their comments. These chips may be marginal for FOC but they should be fine for Sensored and Sensorless and even SineWave Sensored controls, as well as torque throttle and a number of other things. For full FOC it probably makes sense to go to ARM processors, but I think a lot can be done with the simpler CPUs.
Alan B
100 GW
Found Arduino support for the ATmega32M1 and ATmega64M1. So added the Arduino Serial connector that will work with the various Arduino to USB serial adapters that have a 6 pin inline connector. This should make experimenting and development a lot easier.
Added the connector for the Cycle Analyst.
Split the Hi/Lo motor phase outputs. This makes it easier to test and do experiments. These dual wires will be paralleled somewhere, but separating them can make troubleshooting and testing much easier. Using a pair of wires is also a good way to increase current handling capacity without using stiff and hard to manage heavier conductors.
The ATmega64M1 chips from Newark came in. Amazing value under four bucks. Even if not used for a motor controller, they have CANbus and LINbus hardware built in, and are Arduino compatible.
Still to go -
Working through the design details for sensorless operation and programmable fast overcurrent tripping using the ATmega32M1 DAC and four fast comparators.
Alan B
100 GW
Sensorless BLDC Control for the ATmega32M1
There are many different variations on the process of sensorless BLDC motor control. The hardware available on the microprocessor and on the controller board has a large impact on how this may be done, and how well it works. At this phase of the design I am reviewing many different documents on this process. My goal at this point is not to write the software yet, but to make the hardware, but to do that I need to understand what hardware support the software needs. Ideally I would like hardware support for several different software approaches to sensorless control, that way they can be evaluated.
The fundamental component to the process of synchronizing commutation with the rotor in a sensorless setup is to find the zero crossing of the voltage on the winding not currently being driven. The two windings being driven clearly have PWM voltages on them, but the third floating terminal undergoes a voltage transition and this transition crosses zero in the middle of the rotor's rotation between the commutation points. So we need to sense that moment, and then time from there to the next commutation.
There are many documents on the web that describe this process, and it's implementations on different processors. Perhaps the best one is written directly for the ATmega32M1, the processor we are working with now in this thread:
AVR172: Sensorless Commutation of Brushless DC Motor (BLDC) using ATmega32M1 and ATAVRMC320
http://www.atmel.com/images/doc8306.pdf
The ATAVRMC320 is a $300 demo/test FET driver board and motor kit that works with a companion ATAVRMC310 $100 ATmega32M1 CPU board. I'm not going to purchase these boards, but it is worthwhile to look at their design and insofar as is practical to make my board compatible with their software libraries. The demo boards tend to be designed to work with multiple processors and so contain hardware that may not be required for the higher integration of the ATmega32M1 in particular. Note that this boardset is capable of being configured for sensored, sensorless or field oriented control with jumpers.
There is an app note for the ATAVRMC310 board together with the ATAVRMC300 board, which is the driver board component in the 320 kit:
ATAVR470: ATAVRMC310 Hardware User Guide
http://www.atmel.com/Images/doc7802.pdf
If you want to get started with this hardware quickly these boards are a good way to go. Ultimately they are not very appropriate for direct ebike usage (as they are limited to 40V 6A 240W peak), and they are fairly costly, so I'm bypassing them and moving on directly to my own board, which might get to 85V at 100A peak if we do our part.
In any case we want to review the documents for these boards and see what we can learn from it, and how it helps us guide the hardware design for the same CPU chip.
Just going through ATAVR470 to re-review what's there.
I'm going to skip LINbus, we are using that port for Arduino Serial.
On CANbus, one thing I just noticed is they have a 10K pullup on the CAN Tx line from the CPU, I should add that to my board. They are using 8 mhz xtal, I plan to go with 16 mhz. That might affect usage of their software or examples, so remember it. We could change to 8 mhz without affecting the PCB, but I would rather have more MIPs if possible.
I have already shown the ISP programming connector. This is needed for loading the Arduino (or other) bootloader, or all the software if the Arduino (or some bootloaded) environment is not used. I selected the 6 pin variety of this connector which is compatible with the majority of programmers and takes less board real estate.
I'm not doing JTAG or RS232.
The Jumper table (section 2.4) contains a wealth of information about how they wire the boardset for the ATmega32M1. One thing that is clear from this table is they configure the hardware quite differently for FOC mode as opposed to Sensorless mode. Since the goal of my board is to do a blended sensored and sensorless control we won't be set up for FOC this go-round. That will be a future project, perhaps.
Some of the CPU pins needed for programming are also needed for serial, my board has them wired to both places. We will need to remember to use either serial or ISP programming (at one time), and avoid having both hooked up at the same time.
They have a jumper to terminate the CANbus, we are using two standard network RJ45 jacks and an RJ terminator plug. This way a diagnostic CANbus device can be added at any time and the terminator moved.
They use the same pins for bringing in the Hall signal as for bringing in the Sensorless zero crossing signals. This precludes doing both at one time. We will bring the hall sensors in elsewhere, which makes their sensored library unsuitable to directly run on our hardware.
The schematics for these boards are available from the Atmel website.
They have an LED on PC7, the DAC out pin. I plan to add an LED, perhaps this is a good pin choice. We'll see.
Enough for now, more later.
There are many different variations on the process of sensorless BLDC motor control. The hardware available on the microprocessor and on the controller board has a large impact on how this may be done, and how well it works. At this phase of the design I am reviewing many different documents on this process. My goal at this point is not to write the software yet, but to make the hardware, but to do that I need to understand what hardware support the software needs. Ideally I would like hardware support for several different software approaches to sensorless control, that way they can be evaluated.
The fundamental component to the process of synchronizing commutation with the rotor in a sensorless setup is to find the zero crossing of the voltage on the winding not currently being driven. The two windings being driven clearly have PWM voltages on them, but the third floating terminal undergoes a voltage transition and this transition crosses zero in the middle of the rotor's rotation between the commutation points. So we need to sense that moment, and then time from there to the next commutation.
There are many documents on the web that describe this process, and it's implementations on different processors. Perhaps the best one is written directly for the ATmega32M1, the processor we are working with now in this thread:
AVR172: Sensorless Commutation of Brushless DC Motor (BLDC) using ATmega32M1 and ATAVRMC320
http://www.atmel.com/images/doc8306.pdf
The ATAVRMC320 is a $300 demo/test FET driver board and motor kit that works with a companion ATAVRMC310 $100 ATmega32M1 CPU board. I'm not going to purchase these boards, but it is worthwhile to look at their design and insofar as is practical to make my board compatible with their software libraries. The demo boards tend to be designed to work with multiple processors and so contain hardware that may not be required for the higher integration of the ATmega32M1 in particular. Note that this boardset is capable of being configured for sensored, sensorless or field oriented control with jumpers.
There is an app note for the ATAVRMC310 board together with the ATAVRMC300 board, which is the driver board component in the 320 kit:
ATAVR470: ATAVRMC310 Hardware User Guide
http://www.atmel.com/Images/doc7802.pdf
If you want to get started with this hardware quickly these boards are a good way to go. Ultimately they are not very appropriate for direct ebike usage (as they are limited to 40V 6A 240W peak), and they are fairly costly, so I'm bypassing them and moving on directly to my own board, which might get to 85V at 100A peak if we do our part.
In any case we want to review the documents for these boards and see what we can learn from it, and how it helps us guide the hardware design for the same CPU chip.
Just going through ATAVR470 to re-review what's there.
I'm going to skip LINbus, we are using that port for Arduino Serial.
On CANbus, one thing I just noticed is they have a 10K pullup on the CAN Tx line from the CPU, I should add that to my board. They are using 8 mhz xtal, I plan to go with 16 mhz. That might affect usage of their software or examples, so remember it. We could change to 8 mhz without affecting the PCB, but I would rather have more MIPs if possible.
I have already shown the ISP programming connector. This is needed for loading the Arduino (or other) bootloader, or all the software if the Arduino (or some bootloaded) environment is not used. I selected the 6 pin variety of this connector which is compatible with the majority of programmers and takes less board real estate.
I'm not doing JTAG or RS232.
The Jumper table (section 2.4) contains a wealth of information about how they wire the boardset for the ATmega32M1. One thing that is clear from this table is they configure the hardware quite differently for FOC mode as opposed to Sensorless mode. Since the goal of my board is to do a blended sensored and sensorless control we won't be set up for FOC this go-round. That will be a future project, perhaps.
Some of the CPU pins needed for programming are also needed for serial, my board has them wired to both places. We will need to remember to use either serial or ISP programming (at one time), and avoid having both hooked up at the same time.
They have a jumper to terminate the CANbus, we are using two standard network RJ45 jacks and an RJ terminator plug. This way a diagnostic CANbus device can be added at any time and the terminator moved.
They use the same pins for bringing in the Hall signal as for bringing in the Sensorless zero crossing signals. This precludes doing both at one time. We will bring the hall sensors in elsewhere, which makes their sensored library unsuitable to directly run on our hardware.
The schematics for these boards are available from the Atmel website.
They have an LED on PC7, the DAC out pin. I plan to add an LED, perhaps this is a good pin choice. We'll see.
Enough for now, more later.
LewTwo
1 MW
Happy to see this thread being picked up again .... 
Alan B
100 GW
Thanks for the encouragement LewTwo.
I ran across these integrated power bridges from MTI. Very impressive parts. I don't think I will use one of these right now, but they are quite interesting. The MTI 85W100GC is about $24 from Mouser. The lead time is fairly long. It would make a very small package. However if one FET becomes damaged the whole module is trash, and there's no way to separate the high and low drivers for testing.
I ran across these integrated power bridges from MTI. Very impressive parts. I don't think I will use one of these right now, but they are quite interesting. The MTI 85W100GC is about $24 from Mouser. The lead time is fairly long. It would make a very small package. However if one FET becomes damaged the whole module is trash, and there's no way to separate the high and low drivers for testing.
Similar threads
