Quote:
Originally Posted by MPaulHolmes
I think I've got a really good filtering scheme for sensorless at 0.5Rev/sec up to 15,000rev/sec.
|
That's quite the range .. all wrapped up in one scheme!
Quote:
|
It fits so well with the nature of the noise in the motor. The faster the motor, the more the waveforms look like fairly well behaved sine waves.
|
Matches what I've seen on industrial stuff. Control is good from 10ish Hz on up to 400 Hz
Quote:
|
The slower the motor, the more the waveforms look like crap.
|
Yep
Quote:
|
But the lower the motor, the longer the period and the more severe you can filter the signal. The goal is to find the derivative of the noisy current waveform.
|
OK. I sort-of follow.
Quote:
|
Well, it only looks random. Even at near zero rpm, that thing is a sine wave, if you do enough filtering. The trouble is, the filtered signal lags behind the one you want. Also, the magnitude is squashed just a bit.
|
I guess that makes sense. Filtering can grab the sine wave out of the noise.
Quote:
|
But in general, the RPM doesn't change super super fast. I mean, not microseconds fast. So, you find the shifted and scaled "peak of the last half cycle" and width of the last half cycle, and use that to construct a sine wave that is shifted back in time, and scaled up.
|
So do you need to cut off the filtering when you get up above a certain speed? Do you have the CPU cycles to filter at above 1000 rpm.
Quote:
|
YOu now know how the true sine wave looks like. You don't have to depend on the old news filtered sine wave. You can then take the derivative of the corrected sine, which then gives the derivative of what's happening right now! No lag! will post simulation pics soon.
|
The algorithmn makes sense. It also sounds like a lot of work - filtering, taking the period, calculating the filter offset, calculating the peak, figuring out where the last half-wave WAS and where the next one WILL BE.
If you can cram all of that into the CPU you have - that's AWESOME!