Brushless rpm log accuracy? - HeliFreak
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
 
LinkBack Thread Tools Display Modes
Old 08-18-2012, 01:45 PM   #1 (permalink)
Registered Users
 

Join Date: Apr 2010
Location: Oosterhout, 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?


__________________
GAUI X5 with Eznov Neuron and T10J
DannyvG is offline        Reply With Quote Quick reply to this message
Sponsored Links
Advertisement
 
Old 08-18-2012, 02:32 PM   #2 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Apr 2010
Location: Oosterhout, 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...

__________________
GAUI X5 with Eznov Neuron and T10J
DannyvG is offline        Reply With Quote Quick reply to this message
Old 05-22-2013, 09:29 AM   #3 (permalink)
Registered Users
 
Posts: 2,468
 

Join Date: Mar 2009
Location: Lombard, ILL-Annoy
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 ...
__________________
DX6 G3; Blade mCPS, Inductrix FPV, 180CFX (x2); Thunder Tiger Mini-Titan E325 V1, SE & TT; Century Swift 16, NX, N4022E Jet Ranger; Hirobo Quark SRB (x3); Flyzone Sensei; E-Flite Apprentice 15e; Phoenix, RF7.5, Clearview, Heli-X;
Blog: http://tamingtheblade180cfx.blogspot.com

Last edited by FR4-Pilot; 05-23-2013 at 11:17 AM.. Reason: spelling
FR4-Pilot is online now        Reply With Quote Quick reply to this message
Old 05-22-2013, 09:34 AM   #4 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Apr 2010
Location: Oosterhout, 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?
__________________
GAUI X5 with Eznov Neuron and T10J
DannyvG is offline        Reply With Quote Quick reply to this message
Old 05-22-2013, 11:27 AM   #5 (permalink)
Registered Users
 
Posts: 2,468
 

Join Date: Mar 2009
Location: Lombard, ILL-Annoy
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?
__________________
DX6 G3; Blade mCPS, Inductrix FPV, 180CFX (x2); Thunder Tiger Mini-Titan E325 V1, SE & TT; Century Swift 16, NX, N4022E Jet Ranger; Hirobo Quark SRB (x3); Flyzone Sensei; E-Flite Apprentice 15e; Phoenix, RF7.5, Clearview, Heli-X;
Blog: http://tamingtheblade180cfx.blogspot.com

Last edited by FR4-Pilot; 05-22-2013 at 01:17 PM..
FR4-Pilot is online now        Reply With Quote Quick reply to this message
Old 05-22-2013, 01:25 PM   #6 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Apr 2010
Location: Oosterhout, 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.
__________________
GAUI X5 with Eznov Neuron and T10J
DannyvG is offline        Reply With Quote Quick reply to this message
Old 05-22-2013, 06:43 PM   #7 (permalink)
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 Quick reply to this message
Old 05-23-2013, 12:23 AM   #8 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Apr 2010
Location: Oosterhout, 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.
__________________
GAUI X5 with Eznov Neuron and T10J
DannyvG is offline        Reply With Quote Quick reply to this message
Old 05-23-2013, 12:59 AM   #9 (permalink)
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 Quick reply to this message
Reply




Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the HeliFreak forums, you must first register.
Please enter your desired user name, your REAL and WORKING email address and other required details in the form below.
User Name:
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself. Use a real email address or you will not be granted access to the site. Thank you.
Email Address:
Location
Where do you live? ie: Country, State, City or General Geographic Location please.
Name and Lastname
Enter name and last name here. (This information is not shown to the general public. Optional)
Helicopter #1
Enter Helicopter #1 type and equipment.
Insurance
Please select your insurance company (Optional)
Helicopter #2
Enter Helicopter #2 type and equipment.
Helicopter #3
Enter Helicopter #3 type and equipment.
Helicopter #4
Enter Helicopter #4 type and equipment.

Log-in

Human Verification

In order to verify that you are a human and not a spam bot, please enter the answer into the following box below based on the instructions contained in the graphic.



Thread Tools
Display Modes

Posting Rules
You may post new threads
You may 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
Trackbacks are On
Pingbacks are On
Refbacks are On




Copyright © VerticalScope Inc. All rights reserved.
 

SEO by vBSEO 3.6.1