DIY dynamic prop balancer?

[FinnFlyer]

Doesn't quite make sense. If sensor is overloaded how can the LowPassFilter handle that?
Seems to make more sense to simply disregard those samples unless they make up a significant part of all samples.
But then I don't fully understand how omitting samples affects analysis.
I do understand that the signal we're interested in is "hiding" or included in high-G samples and we can't exclude them all.
But until we're figured out the angle problem and don't need 0.01 IPS resolution, I guess that the +-8G range is fine.

Sure would be nice if fl-mike (post #228) could chime in with some advice. What is the secret to extracting a low-G signal of interest from noisy high-G signals?

Finn

 

[petehowell]

Shooting in the dark here.
Section 3...

1. Do we know that when the system spits out "90 degrees" that 90 degrees is the HEAVY SIDE? Some way to bench test and get confirmation?
2. Flight A spits out 92 degrees. So why do we add a weight at 150 degrees, and not 270? 150 is closer to 90 than to 270, and the balance improves? Shouldn't it get worse?

We are missing something obvious... old legacy balancers couldn't have had this level of calculation (could they?).
Maybe they just did a (physical electronic) filter around 2000 rpm (about 33 Hz) to toss out all the other vibrations.

Crazy(?) thought --- try testing in a gliding descent. That should get all the combustion shake out of the picture. On the same flight with same weights, same rpm if possible power on and off.

Another thought... move a know weight around to 4 different holes each 90 degrees apart. One should show improvement, is it the one that makes sense?

Flight B was actually prior to Flight A, it just happened to have some 2270 data in it - I should have corrected that. Flight A was a clean baseline and flight C was our trial mass. D was supposed to be the answer - but alas, it was not.

 

[petehowell]

Full write-up coming, but this morning we got the inflight balance we were looking for - Claude is managing the data and said this.

Bob IS your uncle!

Clean data — 1007 Hz ODR, zero clipping, hole1 throughout, cool morning air (0.5x mean only 0.193 IPS — much cleaner than last night). Here's what you're seeing:

The headline numbers are the best of the project:

Look at t=2111s: 0.0168 IPS @ 77.1° — confidence 44.3%, 0.5x only 0.176. That's essentially zero vibration.

t=2645s: 0.0538–0.0827 IPS @ 21–32° with 0.5x of only 0.020 IPS — the cleanest combustion of any flight and genuinely near-zero readings.

t=1916s: 0.0500–0.0506 IPS @ 342–348° at 52% confidence — another sub-0.06 IPS cluster.

It felt smooth!. Many lessons learned - lots of missteps, but it looks like it can be done. Amazing what can be done with 80 bux in hardware and some code. Not gonna lie - there was a lot of frustration, but I got to fly a bunch, so call it a wash. Still diving into the data logs, but I'm happy so far. I let out a Whoop! when the first precision balance numbers hit the screen in the cockpit!



Think most issues were driven by the laziness of my sleepy flight test engineer. She had one job! (post flight photo with muffs removed)

 

[CF86301]

Full write-up coming, but this morning we got the inflight balance we were looking for - Claude is managing the data and said this.

Bob IS your uncle!

But my question is, has your wife stopped laughing at you yet?

 

[petehowell]

But my question is, has your wife stopped laughing at you yet?

Hard to erase 40 years of abject failure with one lucky result, Chip!!!

 

[rv12is]

Full write-up coming, but this morning we got the inflight balance we were looking for - Claude is managing the data and said this.

Bob IS your uncle!

Clean data — 1007 Hz ODR, zero clipping, hole1 throughout, cool morning air (0.5x mean only 0.193 IPS — much cleaner than last night). Here's what you're seeing:

The headline numbers are the best of the project:

Look at t=2111s: 0.0168 IPS @ 77.1° — confidence 44.3%, 0.5x only 0.176. That's essentially zero vibration.

t=2645s: 0.0538–0.0827 IPS @ 21–32° with 0.5x of only 0.020 IPS — the cleanest combustion of any flight and genuinely near-zero readings.

t=1916s: 0.0500–0.0506 IPS @ 342–348° at 52% confidence — another sub-0.06 IPS cluster.

It felt smooth!. Many lessons learned - lots of missteps, but it looks like it can be done. Amazing what can be done with 80 bux in hardware and some code. Not gonna lie - there was a lot of frustration, but I got to fly a bunch, so call it a wash. Still diving into the data logs, but I'm happy so far. I let out a Whoop! when the first precision balance numbers hit the screen in the cockpit!

View attachment 119074

Think most issues were driven by the laziness of my sleepy flight test engineer. She had one job! (post flight photo with muffs removed)

Great job! Those are some good numbers. I'm looking forward to your write-up.

 

[petehowell]

Guys -

Here are the details in the PDF below. Do I understand it all, no. Do I understand some of it, maybe. Some notes - I spent a lot of time early cleaning up the tach signal - it is not an ideal trigger, but I had it and used it. I also wasted time trying to balance at 2080 rpm - It just did not work. 4000ODR did not work for me - 1000ODR did to eliminate the clipping. Averaging data over many revs( 3x 4096 rev windows) did help pull out the prop signal. I might try 2080rpm again now that I know a few more things.

Here is my adxl mount for reference.

It's been frustrating at times, but lots of fun and challenge!

 

[FinnFlyer]

Congratulations, I guess ...

My burning question is: How can the commercial balancers successfully do it on the ground?
The engine rocking must surely be present on most engine installations.
I don't understand what the "x0.5" is about.

With my relatively crude method I too see a vast difference on a calm morning (even given the prop interaction with the ground).
This morning two out of three samples were above 1G on X or Y and rejected yet results still converged to 0.47 ips @ 1,200 RPM, compared to 0.7 ips on earlier ground runs with ~ 5 mph winds and gusts.
Even though the prop RPM display is appears to be stable around 1,200 RPM, I found that allowing a tolerance of +-95 RPM allowed all 4,000 samples per sec to reach the 1G limit check. So there must be an RPM variance not noticed.

I guess I should stop fooling around and get a spectrum display working so I can see what's really going on.

 

[jackking123]

Cool thread.... Just finished my first to prop balances... C-152 with Sparrow Hawk O-235 (125HP) and STC Sensenich 72CKS6 aluminum prop. End results 0.04 IPS, started at 1.04 ips!!!!

Second was a RV-12iS. I decided since spinner was already off to balance with prop without spinner. Started 0.35 ended with 0.02 ips!!! Sadly the spinner made it jump up to 0.17. With some more effort got it back to 0.12 ips. That was good enough. I am sure you can try different things, balance front spinner bulkhead or aft, try to static balance the spinner... etc. At some point it gets to be diminishing returns. 0.12 ips is in the middle of the fair range of 0.07 to 0.15 ips. Good starts at 0.07 ips and less.

Clearly some of the magic of the professional balancers is in the software in how it figures out a final weight and location. It takes a few iterations, to arrive at best balance. The 1st and 2nd run is testing response of the weight and location you added.

I can tell you I saw old school helicopter guy balance my plane 30 yrs ago, with two accelerometers, one front of engine case, one on engine accessory case. He used old-school polygraph machine with needles drawing lines on scrolling graph paper. The machine did not tell him what to do. My RV-4 with conical mounts and Hartzell CS prop was sawing machine smooth when he was done. Before it vibrated. Before this balance I had another A&P with a automatic balancer, that told them what to do. It was not good. Engine is part of the "system" interacting with prop. The old school guy had me do full power, cruise power with C/S prop OFF the low pitch stops. The results were great.

The unit is a ACES 1015 Pro is a good unit. Is it better than DynaVibe? Again measuring vibration and clock position is easy. However how you balance is a bit of an art. That art is coded in software.

The ACES software is straight forward. Allowed split weights, but only after you tried single weight first or 2nd runs. It is looking at the affect and response of the weight you added. After a few runs if asks if you want to split weight. You give it the positions, it suggest split weight amount. Doing split weights on the C-152 O-235 was the KEY, was in rough range and went to 0.04 ips. Adding weights to the ring gear "flywheel" in the holes every 30 degrees was easy. The RV-12iS required temp weights and than moving the final weight to spinner backing plate. accounting for change in radius. With the C-152 the "temporary weights" were the final weights and locations.

ACES processor is not lighting fast. It takes at least 30-60 seconds to go through two pages: "stabilizing" and then "gathering data". It needs at least 3 tries for it to target a solution, 4 was typical. It has you add weight the 1st time to see the affect. Then it may add, or subtract, move or both for 2nd run. After the 2nd or 3rd time it may ask if you want to split weights and suggest location and weights. If you can NOT add in the exact location or weight you tell it what you did. Run again, get new results. If it has iterated down to best solution it will tell you, no further improvement. For fun I re balanced with permanent weights installed. It had me add weights, do a 2nd and 3rd run. After the 3rd run it said no further improvement add 0 grams at 0.0 degrees. There is some balancing logic involved.

 

[jackking123]

Congratulations, I guess ...

My burning question is: How can the commercial balancers successfully do it on the ground?
The engine rocking must surely be present on most engine installations.
I don't understand what the "x0.5" is about.

I wonder the same. Helicopters they do both ground and inflight balancing, light and heavy loaded. It is engineering, math, since, physics but the actual balancing is an art. With that said the spinning mass prop and engine are the main vibration. Variables I wounder about:

• Engine mount, vibration isolators are compressed compared to inflight.
• Fixed pitch prop static RPM tends to be less than cruise.
• Cowl off vs on, might affect vibration especially for engines that use upper cowl as plenum.
• Your comment, buffet of the airframe. I do not think it is adding much. But aircraft tied down, light winds the affect I think is minimal.

With my relatively crude method I too see a vast difference on a calm morning (even given the prop interaction with the ground).
This morning two out of three samples were above 1G on X or Y and rejected yet results still converged to 0.47 ips @ 1,200 RPM, compared to 0.7 ips on earlier ground runs with ~ 5 mph winds and gusts.
Even though the prop RPM display is appears to be stable around 1,200 RPM, I found that allowing a tolerance of +-95 RPM allowed all 4,000 samples per sec to reach the 1G limit check. So there must be an RPM variance not noticed.

I guess I should stop fooling around and get a spectrum display working so I can see what's really going on.

Doing prop balance inflight vs ground would be a fantastic experiment.

Model 1015 Pro Vibration Analyzer Balancer I just used worked fine (see post above).​

 

[rv12is]

From my MVib II on a RV12
(Can't balance the engine, just the prop)

View attachment 112990

Way back in post 66 of this thread, Walt posted a nice plot he had gathered using his MVib II on a RV12 with a 912 uls. It clearly identifies many sources of vibration.

Thought I would try to create something similar. Below are my results using the ADXL355, with Walt's waveform overlaid above for comparison.



The largest vibration on my 912is is at the engine frequency. The engine 0.5x and 2x are also plainly visible. The prop has a definite spike to it, and you can also see the prop 2x.

 

[FinnFlyer]

Sure sounds we're back to test weights as in the spreadsheet I attached to post #24.
I think that Pete also mentioned test weights were needed to really determine angles (placements).
That was the conclusion I came to some years ago during my first attempts.
Unlike tire balancing driven by a smooth electric motor, I think the signals we're looking for are deeply buried in relatively high-G combustion and other signals.
Had hoped that with the huge dynamic range of the 20-bit ADXL355 we would have had a chance of determining angle and weight in just one run as in tire balancing -- although with longer runs to average out noise and other vibrations. But so far it doesn't look like it.

Anyway, no reason we couldn't incorporate test weights and multiple runs into our software with the powerful processors we have. But just not as simple as I'd hoped.

Not having read Pete's report in detail, what would be the algorithm?

Do a run-up and look at spectrum as RPM is increased to identify RPMs with resonance and avoid those, note IPS and possible angle at suitable RPM.
Add test weight and rerun at picked RPM.
If inconclusive, move test weight 120 degrees and rerun.
Repeat until have 4 runs. Plug in placement angles into spreadsheet and place calculated weight at calculated angle?

I guess that none of us are likely to stick with it to the degree of developing a general DIY prop balancer and are more likely to bail once we've gotten our airplanes "good enough".

EDIT: @rv12is has gotten his prop vibration way below engine vibration levels and Pete's got his down to excellent smooth. I've got a lot more work to do but may bail after doing another static balance and some test flights with different weights. (I am getting a pretty consistent 230 degree angle but as IPS converge to lower numbers the angle appear to shift.)

Finn

 

[petehowell]

Sure sounds we're back to test weights as in the spreadsheet I attached to post #24.
I think that Pete also mentioned test weights were needed to really determine angles (placements).
That was the conclusion I came to some years ago during my first attempts.
Unlike tire balancing driven by a smooth electric motor, I think the signals we're looking for are deeply buried in relatively high-G combustion and other signals.
Had hoped that with the huge dynamic range of the 20-bit ADXL355 we would have had a chance of determining angle and weight in just one run as in tire balancing -- although with longer runs to average out noise and other vibrations. But so far it doesn't look like it.

Anyway, no reason we couldn't incorporate test weights and multiple runs into our software with the powerful processors we have. But just not as simple as I'd hoped.

Not having read Pete's report in detail, what would be the algorithm?

Do a run-up and look at spectrum as RPM is increased to identify RPMs with resonance and avoid those, note IPS and possible angle at suitable RPM.
Add test weight and rerun at picked RPM.
If inconclusive, move test weight 120 degrees and rerun.
Repeat until have 4 runs. Plug in placement angles into spreadsheet and place calculated weight at calculated angle?

I guess that none of us are likely to stick with it to the degree of developing a general DIY prop balancer and are more likely to bail once we've gotten our airplanes "good enough".

EDIT: @rv12is has gotten his prop vibration way below engine vibration levels and Pete's got his down to excellent smooth. I've got a lot more work to do but may bail after doing another static balance and some test flights with different weights. (I am getting a pretty consistent 230 degree angle but as IPS converge to lower numbers the angle appear to shift.)

Finn

I am using the inference coefficient method with test weights to give guidance to how much weight and where. It took me 6 flights, but I had a misleadng tach signal that led me off in the wrong direction

 

[CF86301]

I am using the inference coefficient method with test weights to give guidance to how much weight and where. It took me 6 flights, but I had a misleadng tach signal that led me off in the wrong direction

For those interested in the rotational vibration theory, the Claude and Gemini AIs mentioned the Influence Coefficient method in the spoilers in post 197 of this thread. As I understand it, the Influence Coefficient method provides a way of compensating for the unknown and RPM-dependent phase shift between the angle of the actual heavy spot in a vibration-damped rotating system and the angle of the peak vibration.

Regarding the P-Mag starter brownout situation that leads to 180-degree tach pulse phase error (if I interpreted that correctly), I had a lengthy off-thread conversation with a guy about a problem he was seeing where his P-Mag would sometimes lose its mind when he engaged the starter and subsequently advance the spark way beyond reasonable limits at high MP and high RPM, i.e. on takeoff and climb-out, resulting in high CHTs. I seem to recall that Hartzell asked him for a lot of details and asked him to send his P-Mag in so they could try to figure out what was going on. He had only purchased his P-Mag recently, so pretty sure the firmware was current. We discussed providing backup battery power to his P-Mag when the starter was running. His approach involved a backup battery and a relay that would provide power to the P-Mag (but not the starter) when the starter was engaged. My approach involved a couple of diodes with the main bus and a backup battery on the anode sides and the cathodes connected together feeding the P-Mag. Whichever source provides the higher voltage at a given time feeds the P-Mag, so the backup battery should be putting out a lower voltage than the main bus except perhaps when the starter is engaged. The backup battery will only supply current to the P-Mag when the main bus voltage drops below the backup battery voltage, so it doesn't need to have a lot of capacity in terms of ampere-hours. Supposedly, in an AOG situation where the main battery is dead, you can run a P-Mag off a 9V battery and hand-prop the engine. Not sure I'd want to try that with an IO-390, though, since the biggest engine I've ever hand-propped is a Cox .049 model airplane engine.