Hall Sensors'b'Gone

incememed

10 W
Joined
Feb 14, 2010
Messages
94
Location
Vasteras, Sweden
EDIT: Links to papers, appnotes or similar dealing with sensorless startup procedure (and especially of heavier loads) would be much appreciated.

Hi,

As many of you have experienced, fiddling with hall effect sensors for motor positioning can sometimes be quite annoying. I was affected to the extent that I decided to explore a sensorless controller alternative instead. Having first hand experience with the volatile nature of the R/C controller, and considering the kind of riding I do - trail riding - such controllers were ruled out. Further, considering the seemingly non-existance of alternative sensorless controllers, I opted to make one from scratch.

One major concern was its ability to maintain sync in critical conditions; for example during sudden load variations (roots, rocks etc) at low rpms, or just plain riding at very high rpms. I'm happy to conclude that initial tests show tentatively positive results in this respect, see vid for details.

[youtube]civcrAzjmsc[/youtube]

(Overcurrent protection is cutting out too easily, hence the careful throttling going uphill).

If things work out as planned, once rotating, I hope to see no difference in performance between the sensorless controller and a sensored one. However, recreating the awesome zero rpm torque of the sensored drive seems very far off.

The controller was implemented using a Microchip dsPIC processor. The power stage consists of six TO-247 size FETs.

Future plans include merging the controller and the power stage into one single circuit board. For the moment however, having the controller as a breadboard implementation facilitates testing new features, rewiring etc. The whole package also needs waterproofing. To be continued.

BR/Mattias Rahm


PS Nice job so far on saving the forum!
My wish for an improved forum: Controller Technology section. And in my dreams: a dedicated dirt/offroad/downhill section.
 
Some trailriding, pushing the drive.

[youtube]a6vVXin9l7I[/youtube]
(Weren't e-vehicles supposed to be silent?)

Effort has been put into a battery current regulation algorithm. Agreed, this is not a necessity per se; it is not the battery, nor the fuse, nor the motor that should be protected, it is the mosfets. But, as a way to get aquainted with the battery current response to throttle, speed, surroundings, it was done anyway.

The rules of the game were:

* A 40A fuse was to be kept happy
* Any current pulse (as detected by the external comparator acting on an Allegro current sensor signal) above 100A would start a timer in the processor. If the pulse remained above 100A after 800us, the drive would trip and stop, demanding a reset.
* No regulation by forced turn-off of mosfets, only posterior adjustment of duty cycle allowed.

The regulation finally turned out smooth above 5km/h. Below that, or uphill, the current spikes were huge and so was the regulation (a proportional regulator). It can be heard in the vid as a kind of short power interrupts, with 1-2Hz frequency, at low speeds and/or uphill. (Not the stuttering regen-like sounds at higher speed, that's due to some resonance thing in the motor, I get it w/wo gearbox, sensored/sensorless drive, it goes away at higher rpms)

Battery current was sampled and fed to the regulator four times each PWM-cycle, and duty cycle was correspondingly updated twice evey cycle.

No real take-home lesson here. It is noticed that it takes an awful lot of regulation to keep >100A spikes from lasting longer than 800 us, especially during low speed acceleration or uphill. Also, it does give some accuracy to what power was actually being used. With the regulator fiercly attacking any anything above 50A, no fuses being blown, no drive being tripped, and battery voltage being 30V (8S), peak power must have been 1500W.

A low side mosfet failure ended the 25min ride. No smoke or burn marks, thermal failure is the probable cause, due to the lousy heat sink. (a closer look at the heat sink in this post, mid-page, for anyone interested)
http://endless-sphere.com/forums/viewtopic.php?f=2&t=23350&start=360
It does reveal the limitation of this power stage, so further riding will have to be postponed until a proper power stage is in place.

BR/Mattias
 
The power stage was made in Eagle, busbars and heatsink are Autocad (the design will support solder trace beefing instead of separate busbars). The design is very far from perfect, and some component values in the schematic have changed over time, proper bypass capacitors are missing, etc so it should be used for reference only. For that purpose, I made pdfs of the Eagle files (irregular file formats like Eagle are not allowed to post). Anyone still think they need the original files, PM me or propose where to upload.

The code is very large, and not suitable for release without some kind of tutorial. It'll stay where it is for now. The core of the program is however a majority function filter, exactly as coded in the Microchip AN1160.

BR/Mattias
View attachment 1
 
I'm not exactly sure what you mean by 'motor terminal voltage sensing'?

To find the so called zero crossing of the unenergized motor phase voltage, I believe most applications use a comparator to determine when the voltage of this phase equals applied voltage (battery) /2. That's how the processor knows it is midways between commutations. The AN1160 approach is no different, except that it does not use a physical comparator. Instead, a motor neutral point is reconstructed in software using all three phase voltages. Unenergized phase voltage is then compared to this neutral point in search of the zero crossing.

/Mattias
 
incememed said:
I'm not exactly sure what you mean by 'motor terminal voltage sensing'?
/Mattias

I run an algorithm which measures the back-emf of the unconnected phase. To determine the
switching point of the (low side) NMOS I continuously measure until the unconnected phase drops
below the negative supply. Then I switch over to the next NMOS. I only measure w.r.t. the negative
supply, commutation point of the PMOS (or high-side NMOS) is done based on timing.

It's a bit more complicated than this as you also have to account for the voltage drop across the
series resistance of the windings but this is in essence the algorithm I run... Assembler
code for a PIC 16F88 is here (toward bottom of page):

http://endless-sphere.com/forums/viewtopic.php?f=2&t=30851&start=30
 
Outstanding! Great job! I would love to see more pic's of the circuits you built.
 
Awesome! Great job ;)

I'm thinking to build my own controller for low power (max 20A) sensorless bldc motor. I need a very very small size. I think I can adapt your board with smd and smaller cap (if I'm not wrong). Will you share the source code and eagle files ?
 
@Lebowski: A lot of ways to do this, great to hear your algorithm is working, and always nice to see some assembler code. I chose to leave that for C when migrating to 16-bit devices. Hope to "re-learn" assembler in the future though, to mix it in when execution has to be extremely fast.

@lfp: Thanks! If the pictures attached are not what you're looking for, let me know. A schematic of the breadboard circuits is however nonexistant.

@evaleto: Thanks! About files, pls see post above. You are probably right the main caps could be smaller for your needs. Consider using more than two though, to share current. Main cap currents in this controller using only two caps are very high.

BR/Mattias
 
@incrémented,
Future plans include merging the controller and the power stage into one single circuit board. For the moment however, having the controller as a breadboard implementation facilitates testing new features, rewiring etc. The whole package also needs waterproofing. To be continued.
If you want, I can help to draw the eagle board. Btw, Do you think it can be imp. with an arduino pro mini board?
Olivier
 
Thank you, help is always welcome, especially if I decide to go into SMD. Right now, properties such as robust, replaceable and thermally forgiving weigh more than size. I hope to be able to do some preliminary design within the next few weeks, will appreciate your comments on that.

Regarding arduino I hope someone can answer that, I don't know anything about it. Arduino and AN1160, anyone?
 
I'm working on the next revision of this controller. Main features to be implemented

- More heat capacity (6mm alu bar to serve as intermediary heat storage)
- Less main busbar inductance
- Chip, 5V/12V supplies and power stage on the same board
- IP65 enclosure

Specs remain the same: 80V supply voltage, >100A cont. motor current.

The intention is to feed the 3D-models below into a PCB software. Pls alert if you see something you don't think will fly.

Overview
The two circular pads to the left are for battery leads, the three pads to the right are for phase leads. 12V and 5V conversions are lower right. Pinhead to the left is for throttle, indication LEDs and 12V on/off switch. 6x330uF main supply capacitance.
View attachment 120x80_1.pdfView attachment 120x80_2.pdf

Side view
Note the battery +/- busbar on opposite sides of the substrate. They will be joined by 3mm polyamid screws.
View attachment 120x80_3.pdf
 
I'm preparing to replace the power stage + breadboard with a single controller box. The last parts should arrive next week. It's almost fully assembled though, so I thought I'd post some pics.
Controller.jpgKapsling.jpg
The present controller - equal to the new one in most aspects - is running at 62V(16S)/25A, so about 1500W. It's very happy at this level (as is the driver :D ), will do long and severe gravel uphill hauls, heavy trail duty etc under constant battery current limiting without getting worringly hot to the touch. It will be subject to testing to find out how much further a single row of TO-247s such as this can be taken.

Here is a shot at an analytical way to predict how far it could be safely taken. Without any forced cooling, ie a normal e-bike controller box with some wind, assume the mosfet can continuously handle half of the datasheet current, in this case 195/2 =~ 100A. Continuously meaning at a time scale several decades higher than what is used in the Safe Operating Area curve, perhaps several tens of seconds of very steep climbing or similar.

Consider further that the device is conducting 66% of the time; 33% as on-time, 33% as diode and 33% off. This means it could actually take the equivalent current of 100/0.66 =~ 150A during its on/diode time, since it gets to "rest" the remaining 33%. The battery current needed to drive that phase at 150A is I_batt = I_mosfet * (duty cycle). (This is making an analogy of the motor phase to a buck converter).

The load on the mosfet is at its highest during startup or low speed climbing, where they are at risk of blowing. The duty cycle is perhaps 10-20%, so any battery current would result in a 5-10 times higher current in the mosfet (according to the buck converter formula above). Assuming one were to stay in this mode continuously - as for example during a very steep climb - a safe battery current cap would then be 150 / (5-10) = 15-30A.

This lines up ok with what I know from a pair of Golden Motor controllers I once owned. They were capped at 20A battery current, using a single row of TO-220s. A reasonable cap for TO-247 - from a longevity perspective - would then be somewhere above that, perhaps at 30-40A. Testing will tell.

The software has been updated to enable higher rpms. It will now spin a seven pole-pair motor up to 13 000 rpm (90 000 e-rpm). This however has little practical meaning, since I'm using only 10000 rpm.
 
incememed said:
Here is a shot at an analytical way to predict how far it could be safely taken. Without any forced cooling, ie a normal e-bike controller box with some wind, assume the mosfet can continuously handle half of the datasheet current, in this case 195/2 =~ 100A. Continuously meaning at a time scale several decades higher than what is used in the Safe Operating Area curve, perhaps several tens of seconds of very steep climbing or similar.

Consider further that the device is conducting 66% of the time; 33% as on-time, 33% as diode and 33% off. This means it could actually take the equivalent current of 100/0.66 =~ 150A during its on/diode time, since it gets to "rest" the remaining 33%. The battery current needed to drive that phase at 150A is I_batt = I_mosfet * (duty cycle). (This is making an analogy of the motor phase to a buck converter).

The load on the mosfet is at its highest during startup or low speed climbing, where they are at risk of blowing. The duty cycle is perhaps 10-20%, so any battery current would result in a 5-10 times higher current in the mosfet (according to the buck converter formula above). Assuming one were to stay in this mode continuously - as for example during a very steep climb - a safe battery current cap would then be 150 / (5-10) = 15-30A.

Waw, awesome! I'm a newbie about motor controller and your post explains to me a long term question: What is the relation between the battery and phase current? Thank you so much for your answer ;)
Maybe you can answer another question. I have a castle icehv 40 controller pluged to my 250W HUB motor. To avoid the current overshoot (and burn my motor), I've implemented a pwm control (with the PID algo) based on the current in the battery (max 10A). I did some test on my home-training and the result seems quite good. But based on your formula it seems that current in the phase can easily overshoot the limit of the motor (and the controller)? What is the limit of my solution?
homework.jpg

red=current on battery, blue=throttle, green=current limit
PID.png


BTW, I have started a SMD fork of your power board for my low power specification, here is the eagle schematics,
View attachment bicyclelab-endless-bldc-SMD-v1.sch

There is only one channel and the emfback is missing. Any suggestion is welcome ;)

Cheers,
Olivier
 

Attachments

  • bicyclelab-endless-bldc-SMD-v1_brd.sch
    17.2 KB · Views: 36
Spacey said:
So would this controller work for Sensorless motors like say the HS3540 direct drive.

Lovely work you have done though.

From a BEMF perspective and from an rpm perspective there should be no problems. I don't own a hub motor though, so I can't verify this. The backside compared to a sensored setup is the loss of zero rpm startup torque. A sensorless controller will always run the motor as a stepper motor for a few initial commutations before switching to sensorless mode. PMDC motors are not designed for this, so the torque will be inferior to that of the normal running mode. On-road is no problem, but uphill or in the woods I will give it a push with the foot to start. When I was hall sensored, this was never an issue.

My main reasons for this pursuit was
- getting rid of components that can fail when I'm far away on some trail
- eliminate components and wires around the motor to be able to encapsulate the motor with a snug fit and protect it from mud and debris

The elimination of imbalances due to imperfect hall mounting comes as a bonus. (It's not easy to get the sensors exactly 120 e-degress apart.) The price to pay is the downgrade in zero rpm startup performance.

@evaleto: Nice work with the PID. What is the time resolution of your scope curves?
Regarding the current limit, I don't know anything about the transistors used in the controller you are referring to, so difficult to make a prediction. There's a tread where they talk about current limiting of R/C-controllers
http://endless-sphere.com/forums/viewtopic.php?f=28&t=29846
EDIT: and here http://endless-sphere.com/forums/viewtopic.php?f=2&t=28935

I see you will be measuring phase current, looking forward to hear how that works out for you.
 
incememed said:
@evaleto: Nice work with the PID. What is the time resolution of your scope curves?
Regarding the current limit, I don't know anything about the transistors used in the controller you are referring to, so difficult to make a prediction. There's a tread where they talk about current limiting of R/C-controllers
http://endless-sphere.com/forums/viewtopic.php?f=28&t=29846
EDIT: and here http://endless-sphere.com/forums/viewtopic.php?f=2&t=28935

I see you will be measuring phase current, looking forward to hear how that works out for you.
I ordered 10mOhm resistor to measure the "buck convertor" effect on phase. I'm not expecting any good result ;)
About the time resolution of my plot, it's 5s.
 
A baby controller was born!
Birth weight 540gr, size 120x84x44mm.
Controller.jpg
It was tested for water resistance by an independent laboratory, known for its stringent adherence to aerospace, NASA and CERN procedural standards:
[youtube]fc8qtkY3kJI[/youtube]

Now it's time to focus on heatsink temperature to find out where the margins are. (-2C in Vasteras this morning, a definitive risk of biasing measurements :) )
 
Regarding the current measure on the battery since my last graph. I got a "current meter" to measure the right value directly on the phase. I was not expecting any good news, but I was curious to know the "duty cycle amplification factor". See the picture:
2011-11-09 14.40.32_modifié.jpg

Unfortunately I got the same current result as on the battery??? I still do not expect this as a good news. What did I do wrong?

Moreover, I read from ATMEL (AVR444 about bldc sensorless) a pdf document. They talks about current limiting and provides a schematic solution, see picture:
avr444-power-stage.png
Is this the safe way to measure current on phase ? I'm still confuse with current limiting on phase...

Cheers,
Olivier
 
evaleto said:
Regarding the current measure on the battery since my last graph. I got a "current meter" to measure the right value directly on the phase. I was not expecting any good news, but I was curious to know the "duty cycle amplification factor". Unfortunately I got the same current result as on the battery??? I still do not expect this as a good news. What did I do wrong?

did you try it under (mechanical) load ?

'duty cycle current amplification' only occurs under continuous mode, not under discontinuous mode (look for buck converter in wikipedia)
 
A few possible reasons to why no current multiplication was detected:

- Phase current is an AC-current, battery current is DC. I'm not sure how they compare, and the influence of the type of AC-measurement (RMS, effective value, average value etc)
- The duty cycle actually used by the controller is not known, only the throttle value fed to it
- Loading a motor with a bicycle break is not exactly a stable mode of operation, measurements might have been influenced by load variations etc.

This phenomena is more easily observed using one phase only. For example, if I program the controller to connect phase A and B (and not commutate), and then have the controller report to the screen what duty cycle it is actually using, the DC-average of the phase current is proportional to the DC-average of the battery current, the 1/(duty cycle) being the constant of proportionality. The accuracy is actually quite high (+/-a few percent) over a very wide range of currents and duty cycles. It's quite interesteing to feed some 5-10A to the controller and read >80A on the phase. Things heat up pretty fast!

The Atmel picture looks like the current is passed through a resistor in series with battery negative, hence a measurement of battery current.

Good luck with future measurements!
 
thank you for enlightening my mind ;) I'm in the dark with this subect. Can I ask you (one) more thing, what is the best schematic for sensing current, one, two, three sensors? And how the software must summarise the current value of N sensors??

BTW, It seems you are an expert in controller building? You did an amazing job, you are a king!!!
 
Well, thank you for the kind words. I will look to them for encouragement next time I blow yet another component:)

I can't give any useful input on how to capture phase currents, I don't use direct phase current measurement. I did however simulate the phase currents of the first few commutations during startup a while ago (PSpice), this way you get a visual on what patterns to expect. Violet is battery current, green, red and aqua are A, B, C phase currents.

(20kHz, DC 20%)
phaseCurr.jpg
 
Back
Top