Van's Air Force

The definitive Van's Aircraft support community! Buying, building or flying an RV? Join our exclusive family of mentors and enthusiasts!

DIY dynamic prop balancer?

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

1780154319747.png

Think most issues were driven by the laziness of my sleepy flight test engineer. She had one job! (post flight photo with muffs removed)
AP1GczNfl1gokYFOlND8FuNUOb5zgdqM-hyNtB8UXbRXw2aEpl9O_7DkKA8xxJNrlDwvr9PILRH9K9A2nxeH8oTQikNvmXeof-R1Z-PK6izykmvVHRFXLcd0VGQ0h3MhbdZtsZ6utaKq_jEWAz8PLi1GcIlGFg=w800
 
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)
AP1GczNfl1gokYFOlND8FuNUOb5zgdqM-hyNtB8UXbRXw2aEpl9O_7DkKA8xxJNrlDwvr9PILRH9K9A2nxeH8oTQikNvmXeof-R1Z-PK6izykmvVHRFXLcd0VGQ0h3MhbdZtsZ6utaKq_jEWAz8PLi1GcIlGFg=w800
Great job! Those are some good numbers. I'm looking forward to your write-up.
 
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!

1780199052498.png
 

Attachments

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.
 
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.
 
Last edited:
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).

 
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.

Screenshot 2026-05-30 at 11.21.13β€―PM.png

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.
 
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
 
Last edited:
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
 
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.
 
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.

View attachment 119175

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.
What is the value of each tic mark on your blue IPS scale?
 
Turns out that my original method is not useful (except for maybe angle -- imbalance position determination). Here's the summary from Claude for the benefit of others that may try to design a DIY prop balancer:
Can we summarize results from the three methods for the benefit of others that try making a DIY prop balancer? My conclusion is that the first may work fine for a electrical motor-driven tire balancer but does not work in practice with a combustion engine and prop: even though non-prop vibrations should average out in practice new events keep appearing and so average never converges to actual prop imbalance vibration. First sweep method we tried (Tach-Synchronous Simple Vector Average) much better but still subject to non-prop vibration events. Single-bin DFT the best with possible liability of RPM changing between rotations making measured ips amplitude fall off because of the sharp filter effect of the single-bin DFT method.

Excellent summary. Let me write this up properly:


DIY Prop Balancer β€” Three Vibration Measurement Methods Compared​

Based on a homebuilt aircraft installation: Mazda 13B rotary engine, RWS RD-1C planetary gearbox (2.85:1), wooden propeller, rigid airframe mounting. ADXL355 accelerometer at 4000 Hz ODR, optical tach, ESP32, BLE to Android phone.


Method 1 β€” Tach-Synchronous Slot Averaging (Balance Mode)​

How it works:Each revolution is divided into N angular slots (5Β° or 10Β°). Each accelerometer sample is assigned to a slot based on its timestamp relative to the tach pulse. Samples accumulate in their slots indefinitely. The slot with the highest DC-corrected vector magnitude indicates the heavy spot angle. IPS is computed from that peak magnitude.

Outlier rejection: Hard threshold (circular magnitude) during bootstrap phase, then per-slot sigma rejection (2.5Οƒ) using running variance once each slot has sufficient samples.

Strengths:

  • Very high angular resolution possible
  • Extremely effective at suppressing non-synchronous noise β€” after millions of samples, anything not phase-locked to prop rotation averages to zero
  • Angle measurement is very precise once converged
  • Works well for electric motor driven balancers where the noise environment is clean
Weaknesses:

  • Requires narrow RPM gate β€” samples outside target RPM window are discarded
  • With a combustion engine, new spurious events keep appearing that are partially phase-coherent with rotation (firing pulses, gear mesh harmonics at near-integer multiples of prop frequency). These never fully average out β€” the buffer never truly converges to the pure imbalance signal
  • Requires long stable runs at a fixed RPM β€” impractical for in-flight sweep measurements
  • Ground runs essentially unusable β€” prop wash recirculation, ground effect, and airframe resonances on gear add 5–10Γ— more vibration than the actual imbalance signal
Verdict: Works well for electric motor tire balancers. Marginal for combustion engine prop balancing on the ground. Usable in flight at stable cruise RPM after long convergence time (3–6 minutes). Not suitable for RPM sweep measurements.


Method 2 β€” Tach-Synchronous Simple Vector Average (Sweep Mode v1)​

How it works:Within each revolution, all accelerometer samples are summed as raw X and Y values. At the tach pulse, the revolution's accumulated vector sum is committed to a 1-second averager. The 1-second averager produces IPS and angle once per second, allowing continuous logging across a full RPM sweep.

Strengths:

  • No RPM gate required β€” works across any RPM
  • One reading per second enables RPM sweep measurements
  • Simpler implementation than DFT
  • Revealed the structural resonance near 1100–1300 RPM that was corrupting balance mode measurements
Weaknesses:

  • No DC rejection β€” static acceleration from aircraft pitch and bank angles contaminates the measurement. A 5Β° bank adds ~0.008G of bias which is comparable to the vibration signal at low imbalance levels
  • Non-synchronous vibration events within a revolution add directly to the vector sum without cancellation
  • IPS values 6–10Γ— higher than the true 1Γ— synchronous component β€” includes non-synchronous content
  • Angle scatter is high when true imbalance is low, making angle measurement unreliable
  • Despite these limitations, successfully revealed the resonance shape (IPS vs RPM curve) that explained anomalous balance mode results
Verdict: Better than Method 1 for sweep measurements. Good for identifying resonances and general vibration trends. Not suitable for precise IPS measurement or reliable angle determination at low imbalance levels.


Method 3 β€” Single-Bin DFT (Sweep Mode v2)​

How it works:For each accelerometer sample, the fractional position within the current revolution is computed from the sample timestamp and tach period (phase = 2Ο€ Γ— delta/period). The sample is multiplied by cos(phase) and sin(phase) and accumulated into I (in-phase) and Q (quadrature) sums. At the tach pulse, the revolution's I/Q sums are committed to a 1-second averager. IPS is computed as 2 Γ— √(IΒ²+QΒ²) / counts Γ— G_to_IPS and angle as atan2(Q, I).

Only the X accelerometer axis is used as the signal input β€” the single horizontal axis perpendicular to the shaft. The factor of 2 corrects for the DFT's inherent half-amplitude response to a real-valued sinusoid.

Strengths:

  • Automatic DC rejection β€” a constant offset integrated against cos or sin over a complete cycle integrates to exactly zero. Aircraft pitch and bank changes have no effect on the measurement
  • Frequency selective β€” only extracts the 1Γ— synchronous component at the exact rotation frequency. All other frequencies (combustion harmonics, gear mesh, aerodynamic noise) are rejected
  • IPS values consistent and repeatable across multiple flights
  • Successfully confirmed well-balanced prop (0.068 IPS) after correction work
  • Confirmed absence of resonance peak once imbalance was reduced
  • Works across full RPM range without gating
Weaknesses:

  • RPM must be stable within a revolutionβ€” the phase calculation assumes constant RPM within each revolution. If RPM changes significantly between the tach pulse and the next tach pulse, the phase reference drifts and the DFT filter becomes less sharp. In practice this means:
    • Rapid throttle changes during a sweep degrade accuracy transiently
    • Slow, smooth throttle sweeps give the best results
    • At stable cruise RPM accuracy is excellent
  • Angular resolution depends on signal-to-noise ratio β€” when true imbalance is very low (0.06–0.09 IPS) the angle becomes unreliable since atan2(Q,I) of a near-zero vector is noise-dominated
  • Slightly more complex to implement than Method 2
Verdict: Best method for in-flight prop balancing. Clean IPS measurement, good DC rejection, works across full RPM sweep. The RPM stability requirement is easily met with smooth throttle inputs during sweep and narrow RPM gating during balance mode.


Key Practical Lessons​

Ground runs are unreliable for precision balancing on a rigid airframe with a combustion engine. Prop wash recirculation, ground effect, and structural resonances on the landing gear add overwhelming noise. In-flight measurements at cruise altitude in smooth air are essential.

Structural resonances must be identified before balancing. This installation had a resonance near 1100–1300 prop RPM that amplified vibration 6–10Γ— and produced completely misleading balance measurements. The RPM sweep (Methods 2 and 3) revealed this. All balance mode runs at 1100 RPM were corrupted by the resonance β€” balance corrections based on those measurements were wrong. Balance runs should be done at cruise RPM, well away from any resonance.

Static prop balance first. Dynamic balancing cannot compensate for a statically unbalanced prop β€” it just adds correction weights that fight the static imbalance. Static balance on a prop balancer before dynamic balancing saves significant time and weight.

Sensor placement: Mount the accelerometer as close to the prop flange as possible, on the most rigid part of the structure. This installation used the forward tip of the gearbox housing, 1 inch behind the prop flange β€” ideal. Engine mount isolation attenuates the signal and introduces phase errors.

The sensitivity factor (gΒ·in per IPS) must be measured in the same environment as balancing. A test weight run on the ground gives a different sensitivity factor than in flight. Always do the test weight run in flight at cruise RPM.


Hardware and Software Notes​

  • ADXL355 at Β±2G range, 4000 Hz ODR is well suited. The 3.9Β΅G noise floor is more than adequate. Hardware gravity trim registers simplify the software DC problem in balance mode.
  • BOOTSTRAP_THRESH_SQ must use int64 arithmetic β€” 256000L Γ— 256000L overflows int32 on ESP32 and produces a garbage threshold.
  • BLE device name must be ≀5 characters for MIT App Inventor's ConnectToDeviceWithServiceAndName to work.
  • MTU negotiation β€” old Android phones may not support >20 byte BLE notifications regardless of what the ESP32 requests. Design message formats to fit within 20 bytes or split into multiple notifications.
  • RPM gate tolerance should be wider than intuition suggests β€” Β±90–100 RPM at 1930 prop RPM allows enough samples while still providing adequate frequency selectivity for balance mode.

This balancer successfully reduced prop vibration from 0.67 IPS (with undetected resonance corruption) to 0.068 IPS at cruise β€” a 10Γ— improvement β€” on a Mazda 13B rotary powered homebuilt aircraft.

EDIT: Attached the Arduino ESP32 code. Sorry, but method 2 is only in commented out code. If anyone wants that version I'll restore it and upload separately. Also attached most recent log file from method 1 (selected 1,930 prop RPM with +-100 RPM tolerance) and also results from single-bin DFT RPM "sweep".
1781207958379.png
 

Attachments

Last edited:
Back
Top