Sensorless BLDC motor driven synchronously.....hrmmm...

Fish4Fun · Feb 8, 2015

So I have been playing with some small sensorless BLDC motors (hobby small, not industrial small, lol)......I have read tons of white papers and application notes and certainly understand the how and why of sensing the zero crossing point and all of the caveats, foibles and pitfalls therein....but I like to test theories....so I decided to see if I could simply drive them synchronously.....truly sensorless as it were.....and it works amazingly well....as long as you take the time to "tune" the code to the motor....

For the preliminary testing I dumbed it all the way down.....I used a CC/CV bench power supply and an Arduino to drive the H-Bridges....Like a traditional ESC, low RPM lacks torque, but in the "mid range" and right on up into the "upper range' self-starting is reliable and RPM is by definition exactly what it is suppose to be.....

What's my point? I guess I am a little curious why there is absolutely no mention anywhere of running these cute little motors synchronously....yes, it requires a little bit of "tweaking", but is that really a huge deal? Take the quadcopters for example.....trying to use servo pulses to adjust each motor just doesn't provide fast enough // accurate enough results....so there are "special" quadcopter speed controllers that require sophisticated programming of pretty robust micro-controllers to do what an ATTINY can do if the motors are driven synchronously....maybe I am missing something???....I know it isn't what they are designed for, and it certainly isn't a "drop-in replacement" for ESCs, but I can think of a whole host of things that these little motors would be great for if there were a simple way to DIY an ESC....

Anyway, I am sure there is a good reason why I can't find anything to read on the topic....but it sure is easy to make them spin......By all means feel free to correct me//comment...

Fish

Arouse1973 · Feb 8, 2015

A few things I am thinking of is Jerky start up, not knowing if the magnet is north or south, getting the phase right so you push the magnet at the correct time. If you are just energising the coil in one direction will this not limit your speed.
Adam

Fish4Fun · Feb 8, 2015

If you are just energising the coil in one direction will this not limit your speed.

Hey Adam! I am a bit unclear what you mean by the above....By definition synchronous implies an AC signal, in this case a psuedo-three phase ("Trapezoidal-Three-Phase") AC output from discreet H-Bridges states....the rotor magnets absolutely DO follow the resulting stator fields....for higher speeds, obviously there has to be some concessions made for acceleration, but these are trivial compared to more traditional zero crossing algorithms....At the end of the day a permanent magnet sensorless BLDC motor is much like a stepper motor....You can absolutely force the rotor to "step" from stator to stator (albeit with very little torque) so by increasing the three-phase frequency it is quite easy to both start the motor and "lock it" to a particular frequency without ever knowing the rotor position. What is a bit more difficult is determining when the motor is "slipping" or determining if the rotor has "locked"....but in an application where the motor speed is "bounded" between some minimum RPM and some Maximum RPM and the code is "tuned" for the motor//application then a vastly simplified speed control scheme can be employed with what appears to me at the moment to be very few downsides.

I guess I should point out that I am not suggesting that synchronous control of BLDC motors is in all ways preferable to the traditional sensor or zero-crossing-point sensed control algorithms, only that for some applications the simplicity of synchronous drive would seem to make sense.....Much like brushless fans designed for 3Vdc to 36Vdc generally employ sensors to trigger commutation forgoing any type of "smart" electronic controller....a properly chosen BLDC motor driven with a properly "tuned" synchronous driver would give extremely precise speed control within a defined torque range with a very simple, low-cost driver....

The primary disadvantage to synchronous drive I am concerned about is that "optimum performance" will likely require a slightly higher "no load current" to prevent the motor from "stalling" under load.....with zero rotor feedback the current/voltage has to be a bit higher to ensure the rotor advances far enough for the next phase to take over (...of course, not so much higher that it will accelerate to the "lock" position before the phase change) ....but still considerably less than a true DC motor with an armature and brushes....Mathematically this would seem to indicate a very narrow voltage/current range, but experimentally it turns out there is a great deal of room for 'error'.....One test run yesterday had the motor starting and running very smoothly at a fixed frequency (no "acceleration", just "off" to set speed, somewhere around 75% of the motors rated RPM) with Constant Voltage from ~16.5V to 22V or constant current from ~700mA and up....once the target speed was achieved, the constant voltage could be dropped as low as 14V and still maintain RPM with light torque variations introduced by applying friction to the rotor.....on the constant current setting, current could be reduced to ~450mA and the voltage would settle around 14.5V....my point being that with some fairly trivial testing of a particular motor it would be easy to optimize the code for a particular rpm range to maximize performance and minimize power consumption....Again, perhaps not the "best answer" for all applications, but the lack of complexity and the potential for lowering system cost would seem to at least warrant a mention somewhere.....

Anyway, thanks for the reply!

Fish

Arouse1973 · Feb 8, 2015

Ok I thought you were using the stepping mode by just switching the coil with one polarity. So your not even using BEMF then. Out of interest how are you driving the motor coils, how do you ensure the coil moves the rotor magnet at the right time. I would love to see a circuit diagram.
Adam

Fish4Fun · Feb 9, 2015

Hey Adam....Thanks for the continued interest!

I will draw up a schematic at some point, but it is really straight-forward.....three Full H-Bridges with "High", "Low" "Disable" inputs....One Full H-Bridge connected to each of the three stator coils.....The switching sequence is as follows:

Code:

  |  A  |  B  |  C  |
------|------|------|----------------------
1 --> | Alo  | off  | Chi  | <== Sequence 1
2 --> | Alo  | Bhi  | off  | <== Sequence 2
3 --> | Off  | Bhi  | Clo  | <== Sequence 3
4 --> | Ahi  | Off  | Clo  | <== Sequence 4
5 --> | Ahi  | Blo  | Off  | <== Sequence 5
6 --> | Off  | Blo  | Chi  | <== Sequence 6

(Tried to put an ASCII-ART of the timing, but the formatting didn't translate in the preview)

Anyway, there isn't anything magic about it....I am just more than a bit amazed at how well it works....I was really expecting complete failure....instead I am encouraged enough that I am now considering more in depth testing....I need to stress that I am not suggesting this is in any way a "better" driver than either a senor based approach or a zero-crossing-point approach...simply that it appears to be a viable low-cost//easy to implement approach especially if the application would benefit from absolute speed control.....

Thanks for the reply!

Fish

Fish4Fun · Feb 9, 2015

k, so just playing around, I wondered what would happen if I decreased the "dead time" and allowed all three phases to be active simultaneously as follows:

Code:

                                 |    A    |    B    |    C    |
      |  A   |  B  |   C   |     | EN | Ip | EN | Ip | EN | Ip | Hex
------|------|------|-------  -----------------------------------
1 --> | Alo  | off  | Chi  | ==> |  1 | 0  |  0 | 0  |  1 | 1  | $23
2 --> | Alo  | Bhi  | Chi  | ==> |  1 | 0  |  1 | 1  |  1 | 1  | $2F
3 --> | Alo  | Bhi  | off  | ==> |  1 | 0  |  1 | 1  |  0 | 0  | $2C
4 --> | Alo  | Bhi  | Clo  | ==> |  1 | 0  |  1 | 1  |  1 | 0  | $2E
5 --> | off  | Bhi  | Clo  | ==> |  0 | 0  |  1 | 1  |  1 | 0  | $0E
6 --> | Ahi  | Bhi  | Clo  | ==> |  1 | 1  |  1 | 1  |  1 | 0  | $3E
7 --> | Ahi  | Off  | Clo  | ==> |  1 | 1  |  0 | 0  |  1 | 0  | $32
8 --> | Ahi  | Blo  | Clo  | ==> |  1 | 1  |  1 | 0  |  1 | 0  | $3A
9 --> | Ahi  | Blo  | Off  | ==> |  1 | 1  |  1 | 0  |  0 | 0  | $38
10 -->| Ahi  | Blo  | Chi  | ==> |  1 | 1  |  1 | 0  |  1 | 1  | $3B
11--> | off  | Blo  | Chi  | ==> |  0 | 0  |  1 | 0  |  1 | 1  | $0B
12 -->| Alo  | Blo  | Chi  | ==> |  1 | 0  |  1 | 0  |  1 | 1  | $1B



*Edit to fix formatting & Attempt ASCII-ART, which was a fail, lol

**Please ignore the Binary//Hex they are just there because my dyslexic brain requires notes....

The running torque increased dramatically, the current remained roughly the same....reliable starting required a higher initial voltage/current but could be lowered immediately after synchronous operation was achieved....and stable operation had a much wider voltage/current current range than previously....with more available torque in the higher voltage/current range....

Wish I had longer to play, but I really have to make an appearance at work tomorrow and it is getting late ..... very interested to hear thoughts on this approach....

Fish

Arouse1973 · Feb 9, 2015

This is getting interesting now. Have you tried to load the output shaft? without feedback would you expect to see torque ripple under load, e.g. how do you slow down your control when the motor is loaded, because wouldn't it become a bit jittery?
Adam

Fish4Fun · Feb 9, 2015

Hey Adam! While I assume YOU understand 'how' a traditional synchronous 3-Phase motor operates, I think this may be causing more confusion than illumination.....obviously if the BLDC motor were strictly behaving as a traditional 3-phase synchronous motor then it would more closely manifest the same starting problems inherent therein....Since it does NOT APPEAR to be manifesting these problems, then something else must be going on during at least the start-up period......so lets treat the start-up as a separate and distinct type of operation from "running" operation .....This would appear to make sense because experimentally the start-up requires higher Voltage/Current....without the higher Voltage/Current the motor behaves as one would expect a synchronous motor to behave at start-up...it just oscillates between two poles w/o gaining enough mechanical inertia to commence rotation.......So perhaps during start-up the motor behaves more like a stepper motor long enough to gain enough inertia to begin synchronous operation....I really don't know at this point....

I should also mention that while I have numerous BLDC motors, All of the findings in this thread are reported from a single motor, by far the smallest motor I have on hand (the motor is typical of the 2208-80KV series motors popular for GoPro gimbal drives)....primarily because the H-Bridges I am using for this test are simple SN75441 BiPolar H-Bridges (One chip per phase, all inputs/outputs from each chip in parallel (ie each chip is configured as having 1 output, 1 input and 1 enable) with current capabilities limited to < 1.5A per chip)....I have some H-Bridges I built from discrete components that have much more robust capabilities, but I haven't done any testing with them yet....as I mentioned I really expected my theory//efforts to fail, so I wanted to keep the collateral damage small, lol. I bread-boarded these chips up in a matter of minutes without even a sketch....just using the datasheet...... I will, of course, repeat the tests with several different BLDC motors.....perhaps the "easy starting" is directly related to the very low mass rotor of this particular motor and when I attempt the same tests on larger motors I will find my anticipated failure

Obviously if the approach is not scalable then it is reduced to an idle curiosity rather than a viable method of operation......

I hope to do a bit more testing this afternoon.....I will report back with any new findings...

Fish

Arouse1973 · Feb 9, 2015

Ok let ignore the start up condition for now. I think most of the designs using BEMF feedback use an alignment phase first and then ramp up to full speed then the BEMF kicks in. But you are not using any feedback at all. I guess we need to ask ourselves why is feedback used and what are the down sides to not using it.
I don't know my Onions like you do but I would have thought it was paramount you knew when the rotor was. This allows for correct firing of the coils as I remember for the highest efficiency.

Maybe I don't quite understand your driving sequence but what I can't work out is if you are driving the coils in a set sequence that makes the motor turn. what happens if the more slows down due to load but your still firing the cols at the same speed. Won't it eventually get it's self in a muddle with the wrong pole from the coil being applied to the wrong magnet? As I said I am not an expert in motors and would love you to explain this.

cheers
Adam

Fish4Fun · Feb 13, 2015

Hey Adam!

Sorry for the silent period.....work and life have once again proven that time-sucking-vortexes are not only real but prevalent.

I haven't done any further testing, so I will explain the "theory" of operating w/o feedback....When a stator field is energized a magnetic field is created....the permanent magnets in the rotor respond to the magnetic field in the stator and create a force; the rotor responds to the force by accelerating toward the stator's magnetic field...the closer it gets, the stronger the magnetic force....if nothing changes the rotor will eventually reach the closest possible position to the stator, and will then be carried some distance past this point by momentum....(for our purposes we never want this to occur)...if the stator current is turned off prior to the rotor reaching the "closest point" the magnetic field in the stator begins to collapse and the rotor can pass through the "closest point" w/o reaching the "critical point" where the force reverses from one maximum to the opposite maximum.....so "some amount of dead time" is critical to both sensored and sonsorless operation....during this "dead time' the other two phases are still "pulling" or "pushing" at some position less than "the closest point"...thus providing enough torque to continue the rotation.

In all of the Sensorless BLDC controller code I have seen there is a great deal of effort expended to determine the zero crossing point, and in both Sensored and Sensorless code there is then more effort to determine when the actual switching should occur....in several white papers there are theories about how to approximate the best time to switch, some based on rpm, others on look-up tables some even use complex PID computations....when it is all said and done all of the worry is reduced to a PWM schedule dictated by feedback from the switching time....and ultimately the goal is to achieve uniform switching time because that equates to constant speed....So my very simple thought was, "well, if the goal is to achieve uniform switching time, why go through all the other bother, why not just mandate the switching time and let the rest work itself out as it will...." <<Please remember, I expected there to be a very good reason, unknown to me, why my approach would fail...there was no one more surprised than me that it actually worked, lol.>>

It seems that the "dead time" in the trapezoidal wave form universally used by BLDC motors is a "natural regulator"....if "too much current" is applied to the stator and the rotor "moves too fast" then it simply "pulls a bit harder" as it approaches the "closest point"....but as long as the current isn't so excessive that the rotor "cogs", the rpm will remain "constant"....

Something I am a bit unclear on is why the current "spikes" as torque is increased....Intuitively it would seem current should remain constant at a given frequency regardless of RPM, but that is NOT the case, and I don't have a good explanation as to "why"....My best "guess" is that when operated at a constant voltage some of the energy stored in the stator coils is returned to the supply rails when there is no load and less is returned when there is a load, but that is absolutely a guess. I certainly did NOT expect this.

OK, that is my jumbled logic...and here are a few potential pitfalls....

Obviously for true speed control there has to be some a priori knowldge about the motor.....not dissimilar to the same knowledge required for a traditional sensored or sensorless motor driver....The number of poles the motor has determines its speed at any given frequency....the maximum current the motor can handle and some guidelines on the acceptable voltage range....if the switching period is dictated by feedback these can be handled in various, well-documented, ways, but in the case of "synchronous drive" (as defined here, obviously different than traditional three-phase synchronous drive) there needs to be some means of determining the appropriate voltage/current range for any given rpm....regardless if this is calculated or determined experimentally the information is essential to reliable starting and operation....While determining these parameters for a particular motor on a test bench with proper tools and knowledge is fairly trivial, it would mean that a driver built using the suggested approach would NOT be "universal", but rather "motor specific".....Any theoretical cost savings achieved by simplified design might evaporate if production quantity were more than an order of magnitude or two less than a "universal driver".....

In a driver that uses feedback from the rotor position, if there is insufficient voltage/current to maintain enough torque at the desired rpm the driver will continue to rotate the motor albeit at a lower rpm....this is NOT the case for my approach.....if there is a sudden load applied that causes the motor to "lock" and the frequency is above the self-starting frequency, then the motor will go into a fault mode....While this may seem like a major flaw, in my experience with "traditional" BLDC drivers if the motor "locks" the drivers software either goes into a "protection mode", or the driver simply attempts to go through the entire "start sequence" again, if the rotor is still "locked" then the start will fail which is exactly what my approach would result in....

Perhaps the biggest flaw to my approach is that it is very likely to operate any given motor less efficiently than a motor that uses feedback....In the case of a tiny motor like I have experimented with the difference is likely trivial, but it could be significant in some applications/motors, especially larger motors.....I won't know much here until I have done a lot more testing.....

I have a few more thoughts, but I am out of time again, lol.

Thanks again for your interest!

Hunter

Arouse1973 · Feb 13, 2015

Cheers Fish, I have a read through over several ciders tonight. I won't reply then because I talk bollocks when I have been drinking, well that's what the misses keeps telling me

Adam

CDRIVE · Feb 14, 2015

Fish4Fun said:
Something I am a bit unclear on is why the current "spikes" as torque is increased....Intuitively it would seem current should remain constant at a given frequency regardless of RPM, but that is NOT the case, and I don't have a good explanation as to "why"....My best "guess" is that when operated at a constant voltage some of the energy stored in the stator coils is returned to the supply rails when there is no load and less is returned when there is a load, but that is absolutely a guess. I certainly did NOT expect this.

Hunter

While I claim absolutely no stepper motor expertise whatsoever; this finding doesn't surprise me at all. It seems like logical physics.

Chris

Arouse1973 · Feb 14, 2015

Fish4Fun said:
Hey Adam!

Sorry for the silent period.....work and life have once again proven that time-sucking-vortexes are not only real but prevalent.

I haven't done any further testing, so I will explain the "theory" of operating w/o feedback....When a stator field is energized a magnetic field is created....the permanent magnets in the rotor respond to the magnetic field in the stator and create a force; the rotor responds to the force by accelerating toward the stator's magnetic field...the closer it gets, the stronger the magnetic force....if nothing changes the rotor will eventually reach the closest possible position to the stator, and will then be carried some distance past this point by momentum....(for our purposes we never want this to occur)...if the stator current is turned off prior to the rotor reaching the "closest point" the magnetic field in the stator begins to collapse and the rotor can pass through the "closest point" w/o reaching the "critical point" where the force reverses from one maximum to the opposite maximum.....so "some amount of dead time" is critical to both sensored and sonsorless operation....during this "dead time' the other two phases are still "pulling" or "pushing" at some position less than "the closest point"...thus providing enough torque to continue the rotation.

In all of the Sensorless BLDC controller code I have seen there is a great deal of effort expended to determine the zero crossing point, and in both Sensored and Sensorless code there is then more effort to determine when the actual switching should occur....in several white papers there are theories about how to approximate the best time to switch, some based on rpm, others on look-up tables some even use complex PID computations....when it is all said and done all of the worry is reduced to a PWM schedule dictated by feedback from the switching time....and ultimately the goal is to achieve uniform switching time because that equates to constant speed....So my very simple thought was, "well, if the goal is to achieve uniform switching time, why go through all the other bother, why not just mandate the switching time and let the rest work itself out as it will...." <<Please remember, I expected there to be a very good reason, unknown to me, why my approach would fail...there was no one more surprised than me that it actually worked, lol.>>

It seems that the "dead time" in the trapezoidal wave form universally used by BLDC motors is a "natural regulator"....if "too much current" is applied to the stator and the rotor "moves too fast" then it simply "pulls a bit harder" as it approaches the "closest point"....but as long as the current isn't so excessive that the rotor "cogs", the rpm will remain "constant"....

Something I am a bit unclear on is why the current "spikes" as torque is increased....Intuitively it would seem current should remain constant at a given frequency regardless of RPM, but that is NOT the case, and I don't have a good explanation as to "why"....My best "guess" is that when operated at a constant voltage some of the energy stored in the stator coils is returned to the supply rails when there is no load and less is returned when there is a load, but that is absolutely a guess. I certainly did NOT expect this.

OK, that is my jumbled logic...and here are a few potential pitfalls....

Obviously for true speed control there has to be some a priori knowldge about the motor.....not dissimilar to the same knowledge required for a traditional sensored or sensorless motor driver....The number of poles the motor has determines its speed at any given frequency....the maximum current the motor can handle and some guidelines on the acceptable voltage range....if the switching period is dictated by feedback these can be handled in various, well-documented, ways, but in the case of "synchronous drive" (as defined here, obviously different than traditional three-phase synchronous drive) there needs to be some means of determining the appropriate voltage/current range for any given rpm....regardless if this is calculated or determined experimentally the information is essential to reliable starting and operation....While determining these parameters for a particular motor on a test bench with proper tools and knowledge is fairly trivial, it would mean that a driver built using the suggested approach would NOT be "universal", but rather "motor specific".....Any theoretical cost savings achieved by simplified design might evaporate if production quantity were more than an order of magnitude or two less than a "universal driver".....

In a driver that uses feedback from the rotor position, if there is insufficient voltage/current to maintain enough torque at the desired rpm the driver will continue to rotate the motor albeit at a lower rpm....this is NOT the case for my approach.....if there is a sudden load applied that causes the motor to "lock" and the frequency is above the self-starting frequency, then the motor will go into a fault mode....While this may seem like a major flaw, in my experience with "traditional" BLDC drivers if the motor "locks" the drivers software either goes into a "protection mode", or the driver simply attempts to go through the entire "start sequence" again, if the rotor is still "locked" then the start will fail which is exactly what my approach would result in....

Perhaps the biggest flaw to my approach is that it is very likely to operate any given motor less efficiently than a motor that uses feedback....In the case of a tiny motor like I have experimented with the difference is likely trivial, but it could be significant in some applications/motors, especially larger motors.....I won't know much here until I have done a lot more testing.....

I have a few more thoughts, but I am out of time again, lol.

Thanks again for your interest!

Hunter

Hi ya
I think your reasoning is justified for the small motors operating at low currents where the inertia of the motor is greater than the repulsive force given by a incorrectly switched pole. And yes the efficiency is going to be down.

When you start to increase the current in the coils to provide you with a more powerful motor I think your going to get issues this is because the force will be greater on the magnet now if an incorrect pole is switched in ,which can happen if your timings become different versus rotor position which you don't know the position of.

From what I gather you need to fire the coil at the correct time and with the correct polarity to push the rotor away north and north or south and south, If you select the wrong pole then you could slow the motor down momentarily reducing efficiency.

I wait in anticipation for more testing. Try increasing the current to the motor and see what happens. Load the motor and see what happens.

Adam

Fish4Fun · Feb 14, 2015

Hey CDRIVE thanks for the input!

"logical physics".....perhaps....but not the way I am looking at it (which very well could be wrong) ....if it were a brushed DC motor then as torque is added the rpm should drop and the current should increase...perfectly logical....from the perspective of "work", again, if rpm remains constant and torque increases then by definition work increases suggesting current should increase...again perfectly logical....But if we view all three phases as inductors of a particular value and the input is a constant frequency intuitively I would think there would be a constant average current....I guess if we view the inputs as transformers then this would explain the increased current, but if this is the case, then permanent magnets are the "secondary" and this would imply they react as a "variable load"...and this is NOT logical....so, this brings us back to the stators acting like field windings in an alternator, returning some portion of the input power back to the supply lines....the portion being returned having a peak at zero torque and minimized when the rotor is locked....If this is what is occurring, then there should be some evidence of this current in the "dead time" of each phase....I will need to look for this....if it is there, (and I DO NOT remember "seeing it") then a careful study of the period of the "dead time" might give some further insights into varying the "dead time" to increase efficiency...

Hopefully I will find some time in the next few days to get back to my bench....

Fish

CDRIVE · Feb 15, 2015

I'm looking at this with a far more basic but logical approach. If you apply an apposing force (drag) to the output shaft while RPM is maintained then the laws of physics dictates power dissipation had to increase somewhere. In this case it's outputted as increased torque delivered to the shaft and inputted as increased electrical power dissipation.

For me it boils down to "You can't get something for nothing in physics".

Actually, this holds true for government handouts too.

Chris

Fish4Fun · Jun 7, 2015

Soooooo....it is nearly four months since my last post in this thread....not for lack of working on the project, but for a complete lack of progress.....I built several prototype triple-half-H-bridge circuits using the IR2110 Mosfet Drivers with dismal success until I finally had an epiphany:

Having known for many years that my mother raised two complete idiots, NEVER ONCE did I consider the possibility she might have batted 1000, a trifecta or Hat Trick, if you will, of complete idiots.....At least until recently.....

I won't bother going into the details pertaining to my much deserved self-abasement, nor take any pictures of the piles of useless PCBs as visual proof of my conviction that if one simply repeats the same failed process the outcome will eventually somehow miraculously be different....suffice it to say that the reality is, "Until you correct the error in design every single attempted build will fail...." Who Knew? Obviously NOT ME, lol.

Now, onto an ad-hock report on the (now) resumed testing.....

First....my initial testing was done with a very small BLDC and some SN75441 quad 1/2-H-Bridge ICs.....this precluded testing on larger BLDCs I have on hand. I now have a fully-functional THB (triple-half-bridge) prototype bread-boarded up and currently have some fairly fast 200V/17A mosfets in the driver section.....I am using an Arduino with a PC interface to provide the signaling.....My initial testing used the following switching sequence:

Signal_Loop:
A = Lo...B = Off....C = Hi
Delay
A = Lo...B = Hi....C = Off
Delay
A = Off...B = Hi....C = Lo
Delay
A = Hi...B = Off....C = Lo
Delay
A = Hi...B = Lo....C = Off
Delay
A = Off...B = Lo....C = Hi
Delay
Jump Signal_Loop

**Note** The "Delay" is variable to adjust motor RPM, but "constant" for any given loop iteration....and theoretically forces RPM compliance.....at least that is the point of my testing...to prove or disprove this theory.....

While this worked fairly well with the SN75441 drivers, it was problematic with the new THB driver.....Watching the DSO it occurred to me that the "Off" time might need to be less than the "On" times, and that perhaps an over-lap of the "Hi/Lo" from opposing legs might create a wider voltage/current tolerance for any given rpm.....so I then tried the following signal loop:

Signal_Loop:
A = Lo...B=Off....C=Hi
Delay
A = Lo...B=Hi....C=Hi
Delay
A = Lo...B=Hi....C=Hi
Delay
A = Lo...B=Hi....C=Off
Delay
A = Lo...B=Hi....C=Lo
Delay
A = Off...B=Hi....C=Lo
Delay
A = Hi...B=Off....C=Lo
Delay
A = Hi...B=Lo....C=Lo
Delay
A = Hi...B=Lo....C=Lo
Delay
A = Hi...B=Lo....C=Off
Delay
A = Hi...B=Lo....C=Hi
Delay
A = Off...B=Lo....C=Hi
Delay
Jump Signal_Loop

And this works absolutely beautifully....Initial Start-Up current with Delay set to 512uS is ~750mA, once "Started" the little motor maintains smooth operation down to ~100mA at ~8V. Soooo, now onto the "biggest" BLDC motor I have on hand.....

This motor is a Turnigy G160, rated @ "245KV" and > 50A....PLEASE NOTE: Hobby BLDC Motors have a "KV" rating that has NOTHING to do with 1000 Volts....rather, in this instance, KV is an indication of the anticipated RPM per Volt......I have NO IDEA why someone chose KV as the abbreviation for RPM/Volt.....

I am using a "Bench Power Supply" for my testing, it is only rated to 5A @ 30V, so expectations that this motor could be driven synchronously were not high; however, after some "fiddling" I was in fact able to get the motor to run at relatively low speeds....required "a helping hand" to start, but once running ran smoothly.....@ 2.5A the supply Voltage was only 5.2V and the un-heat sinked mosfets got warm after only a few moments of operation....but that was to be expected.....this motor's rated power input is over 5kW..... I would need much more robust mosfets and a MUCH bigger power supply to properly test this motor, but the fact that it can be driven at all would seem to affirm that sensorless BLDC motors can be driven synchronously....

I have more BLDC motors to test, I but I am confident the results will be reasonably consistent with the two motors already tested. My next step is to do some performance comparisons between an off-the-shelf BLDC driver and my THB driver.....likely focusing on rpm stability...torque and input power.....I also plan to experiment a bit more with the wave form to see if it can be further "tweaked" for improved performance.....

Finally......

And Inquiring minds still want to know WHY I am bothering with this at all.......When I first heard about these hobby BLDC motors I posited the question, "Well if these are three-phase motors then why can't they simply be operated synchronously with a variable frequency drive?" I was scoffed at and told they wouldn't operate synchronously, but no one could tell me why they wouldn't.....if "driven with mechanical energy" they certainly "output" a three-phase voltage/current that is a direct function of the rpm at which they are driven; so I could not think of any good reason they would not operate synchronously....so I set out to test the theory.....building a viable variable frequency three-phase source proved a bit more challenging than I anticipated, (honestly it turned into a three or four year learning process, LOL) but now armed with a decent working prototype I am ready to spend some time exploring just what can and can't be done with these little motors.....No particular task in mind, but I suspect there might be some applications where a motor "locked" to a particular RPM has advantages over a motor that is constantly "seeking" a particular RPM....perhaps not.....perhaps driving these motors synchronously will allow them to operate slightly more efficiently within certain boundaries....likely not, but it doesn't take a lot of effort to "test" what the relative efficiencies between drive methods are.....At the very least driving these motors synchronously is simple....

Fish

Fish4Fun · Jun 12, 2015

I have changed the code a bit to include acceleration into the synchronous drive firmware....this vastly improves starting reliability and "top speed"....The smallest motor now ramps up to over 600Hz, but I haven't connected an RPM sensor to it so I don't yet know what 600Hz translates to in terms of rpm....but it is fast, lol.

I started some testing on a medium sized motor, but it is obvious I am going to have to upgrade the Mosfets and use a larger power supply. Even this medium sized motor has an input rating of slightly over 1kW....looking at it I am certain it wouldn't last long if it were attempting to dissipate 1kW, but a fairly large current is requisite for reliable starting.....more than my little 150W Bench Top supply is capable of....and more than these mosfets are happy with.....I have a 60V 10+ Amp analog supply, but I will need to implement some type of current regulation prior to unleashing it on these little motors....not to mention upgrading the mosfets....

All-In-All I am pleased with the proof-of-concept phase.....for now I am going to put the project aside and think on where I really want to go with it......this Fall//Winter when my work schedule isn't quite so crazy I will do some hardware upgrades and resume my testing.....

Fish

Arouse1973 · Jun 12, 2015

Sounds good Fish!
Adam

Categories

Platforms

Content