Fun, Learning, Friendship and Mutual Respect
START  HERE


Unregistered
Go Back   HeliFreak > R/C Electronics Support > Eagle Tree Systems


Eagle Tree Systems Onboard data loggers, telemetry, and OSD support


Reply
 
Thread Tools Display Modes
Old 08-18-2012, 01:45 PM   #1
DannyvG
Registered Users
 

Join Date: Apr 2010
Location: Breda, The Netherlands
Default Brushless rpm log accuracy?

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?


__________________
2x Logo 600SX
DannyvG is offline        Reply With Quote
Old 08-18-2012, 02:32 PM   #2
DannyvG
Registered Users
Thread Starter Thread Starter
 

Join Date: Apr 2010
Location: Breda, The Netherlands
Default

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...

__________________
2x Logo 600SX
DannyvG is offline        Reply With Quote
Old 05-22-2013, 09:29 AM   #3
FR4-Pilot
Registered Users
 
Posts: 1,856
 

Join Date: Mar 2009
Location: USA
Default

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 ...
__________________
Flyzone Sensei | Swift NX 550 | Swift 16 550 | Mini-Titan E325 SE | Mini-Titan E325 Pro (x2) | Blade 400 | Quark SRB (x2) | Blade mSR | Blade mCX

Last edited by FR4-Pilot; 05-23-2013 at 11:17 AM.. Reason: spelling
FR4-Pilot is online now        Reply With Quote
Old 05-22-2013, 09:34 AM   #4
DannyvG
Registered Users
Thread Starter Thread Starter
 

Join Date: Apr 2010
Location: Breda, The Netherlands
Default

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?
__________________
2x Logo 600SX
DannyvG is offline        Reply With Quote
Old 05-22-2013, 11:27 AM   #5
FR4-Pilot
Registered Users
 
Posts: 1,856
 

Join Date: Mar 2009
Location: USA
Default

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?
__________________
Flyzone Sensei | Swift NX 550 | Swift 16 550 | Mini-Titan E325 SE | Mini-Titan E325 Pro (x2) | Blade 400 | Quark SRB (x2) | Blade mSR | Blade mCX

Last edited by FR4-Pilot; 05-22-2013 at 01:17 PM..
FR4-Pilot is online now        Reply With Quote
Old 05-22-2013, 01:25 PM   #6
DannyvG
Registered Users
Thread Starter Thread Starter
 

Join Date: Apr 2010
Location: Breda, The Netherlands
Default

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.
__________________
2x Logo 600SX
DannyvG is offline        Reply With Quote
Old 05-22-2013, 06:43 PM   #7
extrapilot
Registered Users
 

Join Date: Aug 2010
Location: AZ
Default

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.
__________________
"The problem with quotes found on the internet is you have no way of confirming their authenticity." - Abraham Lincoln
extrapilot is offline        Reply With Quote
Old 05-23-2013, 12:23 AM   #8
DannyvG
Registered Users
Thread Starter Thread Starter
 

Join Date: Apr 2010
Location: Breda, The Netherlands
Default

Quote:
Originally Posted by extrapilot View Post
The converse is also true. If you average over time, they are very accurate- but external governors dont 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.
__________________
2x Logo 600SX
DannyvG is offline        Reply With Quote
Old 05-23-2013, 12:59 AM   #9
extrapilot
Registered Users
 

Join Date: Aug 2010
Location: AZ
Default

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.
__________________
"The problem with quotes found on the internet is you have no way of confirming their authenticity." - Abraham Lincoln
extrapilot is offline        Reply With Quote
Reply




Unregistered
Go Back   HeliFreak > R/C Electronics Support > Eagle Tree Systems


Eagle Tree Systems Onboard data loggers, telemetry, and OSD support

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


Copyright © 2004-2011 - William James - Helifreak.com