Commutation cycles in BLDC motor ESC

[Rusttree]

I'm looking at the output of a commercial ESC for a BLDC 3-phase motor. This particular motor has a 6:1 gear ratio to a propeller shaft.

Because of the gear ratio, I expect the ESC to complete the full 6-cycle commutation sequence 6 times for each full rotation of the propeller. If I were to monitor, say, just one of the 3 wires on the ESC, I'd see activity 6 times per propeller rotation. When I hooked everything up to my oscilloscope, I was hoping for nearly-exact synchronization between the ESC and the motor. Instead, they didn't quite line up.

See the attached figure. The yellow line is a photocell I held underneath the propeller as it spun. The voltage dips every time the propeller passes over it and blocks the light, so two dips equal one full rotation. The blue line is directly from one of the 3 wires on the ESC. I expected the two lines to "synch-up" every 6th commutation cycle. They're close, but it's clear from my scope that the dip above the first pulse doesn't hit at the same place as the dip above the 6th pulse. The "error" amounts to about 1.4ms of drift.

How can an ESC that keeps a constant RPM drift its commutation sequence relative to the physical rotation of the motor?

Thanks!
-Dan

 

[shortbus=]

Is the difference in pulses do to "propagation" delay of the devices your using in the circuit? All components have a certain delay to them, the more components, the bigger the stack-up of delay.

 

[Rusttree]

I suppose, but it would seem like any delays would be accounted for in the software on the uC in the ESC. Either way, I guess I don't understand how the ESC can spin the motor smoothly when there's this drift between the commutations and the rotor. Seems like I'd notice a slight jerking because of the misalignment.

 

[dknguyen]

It's not propogation delay. The electrical signal (and thus magnetic field) leading the mechanical rotation of the propeller that you see is the advance timing of the ESC.

When the permanent magnets are aligned with the electromagnets in the motor the torque is zero so having perfect sync would make it jerky and not have constant torque. The electrical pulses are advanced so that the stator field leads while the rotor field lags behind. The result is that the stator's electromagnetic field always drags the rotor behind it without ever letting it catch it (like the carrot hanging in front of the horse). The goal is to maintain a fixed distance between the fields so that torque production is constant and that they never align and lock to produce zero torque.

The ESC estimates the amount of advance required by assuming that RPM changes smoothly and stays constant between commutation cycles. It constantly measures the time intervals between commutations and uses the previous measurement to calculate the timing advance required for the next commutation.

The higher the advance timing is set to be, the more power the motor outputs and consumes (within reason before it de-syncs and just stops working).

Try varying your ESC RPM and measure the percentage/ratio of the lead-lag time difference against the period for a single rotation or commutation cycle. I think it should be a constant ratio unless you have change the timing settings of the ESC.

 

[Rusttree]

Thanks for your detailed explanation, dknguyen.

If the ESC is generating an electrical field in the stators to lead the rotor, wouldn't it maintain a consistent lead time at a set RPM? In other words, the electrical and mechanical timing of the whole system should be repeatable rotation after rotation after rotation (assuming constant RPM). Therefore, the timing at which the propeller passes the same point in space would correspond to some phase in the electrical timing sequence - whether it be just before, just after, or during an electrical pulse. But from what I see on my oscilloscope, the mechanical and electrical timing sequences appear to randomly walk relative to each other. Is that just the ESC readjusting its timing to maintain constant RPM?

 

[dknguyen]

At constant RPM the stator field should maintain a constant lead ahead of the rotor field.

I assume you are using a sensorless ESC. Because it might just be the ESC's timing estimation algorithm at work since the RPM always fluctuates throughout the cycle but the only time the ESC can sample the RPM is whenever the BEMF zero-cross occurs. It does so by measuring the time between the previous two zero-crossings, calculates the equivalent RPM and then assumes RPM is smooth and unchanging within the small commutation time interval and uses this to determine when to commutate the next cycle. So the ESC does constantly readjust...but i there's no load changes going on with the propeller there shouldn't be anything that changes the adjustsment.

The problem is you are using the propeller RPM right now to check. To really find out you need to compare the PWM signals to the BEMF zero-crossings of the motor.

Is there any pattern appearing across many cycles like patterns between the 0/360 degree timings, and then between the 180 degree timings? If it is, it might be that your propeller is imbalanced and causing periodic load flucations.

But...it could be any number of other reasons. Could it be mismatches in magnet strength? Mismatches in the phase inductance/resistance not being accounted for the in the applied PWM signals and the sensorless BEMF measurement circuit (which usually assumes all phases are identitcal). All of these last few would be hard to hunt down and you'd have to figure out how many cycles it would be before a particular magnet or phase would be renergized the same way, and search for them on the o-scope.

 

[Rusttree]

To really find out you need to compare the PWM signals to the BEMF zero-crossings of the motor.

Glad you mentioned that. I'm actually trying make my own ESC, so I was probing a commercial one to gain some insights. My current design is almost working. I can get a little over 10000 rpm, but there's something not quite right. I can hear a slight grinding sound which gets worse as I increase the duty cycle. There's nothing really mechanically grinding, but that's the closest description of the sound I'm hearing.

I'm wondering if my commutation algorithm is adequate. Here's the sequence I'm using:
1. Energize coils for the current commutation cycle
2. Start timer
3. Wait until zero crossing on floating coil detected
4. Record timer value
5. Wait the amount of time recorded in step 4
6. Go to step 1

This sequence repeats until it gets through all 6 commutations cycles, then starts over again from the top. Any obvious improvements I should make?

Thanks for taking the time to answer my questions so far, dknguyen. You've been a great help.

 

[dknguyen]

Could that grinding sound be the rotors and stator fields aligning and locking making it jerky? What would happen if instead of waiting for the recored time interval to commutate, instead commutate it 10% earlier (I'm just pulling a number out of my ass, I don't know what the typical advance timings are). You could go onto RCgroups.com into the DIY forum and ask them.

 

[Rusttree]

That's kind of what I was thinking too. But adjusting the time a little faster didn't seem to fix it. What I really need is a high speed camera so I can see what's going on in there! Even with an oscilloscope, it's impossible to tell the exact angular position of the rotor relative to the commutations that I'm commanding.

I'll check out that RCgroups forum that you suggested.

 

[dknguyen]

It could also be a poor sensorless BEMF circuit. That's very hard to check though without an encoder to so you can compare the position of the magnets to what the BEMF sensign circuit sees.

 

[Rusttree]

I'm assuming my BEMF sensing circuit is good because I'm getting nicely formed trapezoids on my scope as the motor turns. I have the source pins of the high-side MOSFETs going into a low-pass filter, which goes directly into the ADC ports on my uC.

But my assumption could be totally wrong.

 

[alec_t]

Could you adjust your opto setup to include a shaft-driven disc with radial markings or cut-outs, so that you can get info on shaft angle?

 

[Rusttree]

alec,
Not a bad idea. I like the idea of getting feedback of exactly where the rotor (when the motor doesn't have build-in hall sensors).

I did figure out my problem, though. Turned out, my commutations were happening at the wrong time. Based on an app note I was using as a model, I misinterpreted one of the figures that showed the commutation sequence. I was activating each new commutation some timed delay after the zero-crossing was found. Once I removed that timed delay, it worked perfectly. Having a position feedback loop would have made that a lot easier to troubleshoot!