Brushless rpm log accuracy?

[DannyvG]

I did some logging today with a eagletree V4 micrologger and a hyperion phase sensor. But I am wondering if what I see is really the rpm variation or if it is some sort of measurement noise.
Is the rpm really changing this much or would this be considered a rather stable rpm?
Would lowering the sample frequency or applying a low pass filter on the data be helpful?

[DannyvG]

For example with a low pass filter it would look like.
But the question is am I fooling myself or is this a more reasonable result. There is a limit to how fast a motor could change rpm and 50Hz seems way to high.
The lowpass filter now is first order with 0.001Hz cutoff...

[FR4-Pilot]

I was wondering the same.

Perhaps a more "filtered" log would be obtained from an optical RPM sensor (monitoring a mark on the main shaft or 1way bearing) since there's no way those fluctuations would show up there.

The brushless RPM sensor is monitoring the input to the power system - I would think a more representative read would come from the output (shaft, 1way bearing, main gear, etc.) of the power system ...

[DannyvG]

the yge rpm signal output gives a similar noise level. I dont know if I could then conclude the problem is within the ET or if both the hyperion/ET sensor and yge output are both noisy.
as far as I know the brushless sensor gives a pulse each time the measured voltage crosses zero. so if the motor turns with 20.000rpm and is a 12N10P then how many times a second it needs to log a pulse? perhaps the ET has a slight clocking error causing the noise?

[FR4-Pilot]

I'm using a YEP 100A ESC (knock off of YGE) and I see the same thing that you do - in fact, your original RPM graph looks identical to mine (nasty).

I'm about to install the same eLogger/RPM sensor setup on another heli, with a non-YGE/YEP ESC - so we'll see if a different brand of ESC makes a difference. It will be a Century Electron 80/100A ESC (discontinued however).

I agree that it needs to be cleaned up, smoothed out, filtered, etc. regardless ...

Curious - I'm using both wires from the sensor hooked up to two of the motor leads. Are you using two or just one?

[DannyvG]

the yge has the possibility to send out the motor rpm over the programming cable so you can directly plug the programming cable into the eagle tree or fbl system. but this signal also contains a lot of noise in use.

[extrapilot]

Phase tachs are not precise in terms of measuring angular position for a lot of reasons. They tend to be looking for polarity reversal or 0-cross. But, there are multiple signals in question (commutation signal, PWM, BEMF, crosstalk, etc). When you look at the raw signaling from a phase or phase pair, you will see a ton of noise. The phase tachs implement some analog filtering onboard, but there are conditions that happen which appear to be valid phase changes which are not. So while they may accurately detect 99% of the phase changes, the point in the phase change at which they trigger has a ton of variability. It is the time between each pulse that defines RPM. If you have one pulse that is late, and the next is early, the RPM calculation will significantly high. The converse is also true. If you average over time, they are very accurate- but external governors don’t have that luxury- they need to react quickly to RPM changes.

Another problem is that lower-end loggers have basic hardware limitations. Hard to explain briefly, but it is analogous to a stopwatch with just a single hand. To have the ability to measure longer periods (i.e. 1 minute), your resolution is limited to just 1 second. And, scaled up, just consider the ratio of tach signaling from an idling gasser with one tach pulse per rev, vs a 60,000rpm EDF with a phase senor sending 3 pulses per rev. Hard to cover that range, and retain precision, with less capable CPUs.

In this stopwatch analogy, for events that are happening in say 3-4 seconds on average, the system reads either 3 or 4. Translated into RPM, that is a huge variation- sort of 25% between each read- which is just a function of limited resolution. Here, with a 16bit counter, at 1mhz, you would expect to see about 2% jitter regardless of the sensor stability. And, that is very close to what you show. The YGE signal output emulates the phase sensor- so errors in the logger timing apply for the same reason.

The spikes here appear to be real- as they all have multiple samples (steps) on at least one leg- it is not just a single bad read, and the probability of multiple sequential bad reads forming a linear ramp is near zero. This is likely governor windup (“I” term too high), but it can also happen when the rotor system dramatically reduces its torque demand even with a decent “I” term value defined. When you can drop torque from 100% to -10% in less time than the governor can send a correction signal to the ESC- this is going to happen.

[DannyvG]

Originally Posted by extrapilot

The converse is also true. If you average over time, they are very accurate- but external governors don’t have that luxury- they need to react quickly to RPM changes.

The spikes here appear to be real- as they all have multiple samples (steps) on at least one leg- it is not just a single bad read, and the probability of multiple sequential bad reads forming a linear ramp is near zero. This is likely governor windup (“I” term too high), but it can also happen when the rotor system dramatically reduces its torque demand even with a decent “I” term value defined. When you can drop torque from 100% to -10% in less time than the governor can send a correction signal to the ESC- this is going to happen.

Thanks for the reply, if I understand correctly I can obtain a smoother and fair result by averaging the rpm data x-samples before and after (x=2 for example) the current point in time.
I also logged the throttle output of the fbl system of which I used the governor but it seemed there is a lag between rpm rise and throttling down. Thats where all the overshoot seems to come from. But I cant say if it is a delay because they average or filter the rpm input or like you said something like integral windup or other additional control logic.

[extrapilot]

Perhaps moving average, perhaps something more like FIR or IIR- phase delay is not important for this sort of thing. Realistically, given hardware limitations, Id tend to look at this graph focused only on the clear ‘events’ that were captured.