DIY dynamic prop balancer?

[ve0kog]

The author found quite a bit of delay between the readings and the actual data.

Is this related to algorithmic delays when applying filters to the sample data? The higher shape factors have inherently increasing delays as additional samples must be collected in the buffer before they can be processed. This also depends on the choice of the window function. But in all cases the processing delay should be predictable. Or you are thinking of some other type of delay?

 

[jacoby]

Is this related to algorithmic delays when applying filters to the sample data? The higher shape factors have inherently increasing delays as additional samples must be collected in the buffer before they can be processed. This also depends on the choice of the window function. But in all cases the processing delay should be predictable. Or you are thinking of some other type of delay?

It's in the correctAngleForRpm function. i haven't pored over the code to tell what the source of it is from.

 

[CF86301]

It's from the codebase posted earlier. (https://github.com/peterashwoodsmith/vcheck). The author found quite a bit of delay between the readings and the actual data. He's got 70° at 3600 RPM and 5° at 1700 which means it's not a simple time delay for some reason. You'll have to measure a known imbalance to find the delay most likely.

In order to reduce sample time uncertainty, it may be necessary to use the external trigger/sync functionality provided by the ADXL355 and ADXL362. The ADXL362 has 12-bit resolution and provides an acceleration resolution of 1 mg/LSB on the +/- 2g range. Its maximum output data rate when internally triggered is only 400 Hz, which would still provide 4x oversampling at the Nyquist minimum sampling rate of 90 Hz for a 2700 rpm propeller if all you're looking to do is figure out where to put a weight to balance the prop. With an external trigger, it can sample at up to 625 Hz. For applications requiring higher frequency resolution or better amplitude accuracy — such as identifying harmonic content or structural resonances — the ADXL355 offers a much lower noise floor and up to a 4000 samples per second.

And speaking of delays, the optical sensor shown in one of the Dyna Vibe manuals is a Banner Engineering SM312LVMHS, which has a response time of 0.3 milliseconds (300 microseconds), amounting to almost 5 degrees of prop rotation at 2700 RPM.

 

[rv12is]

It's from the codebase posted earlier. (https://github.com/peterashwoodsmith/vcheck). The author found quite a bit of delay between the readings and the actual data. He's got 70° at 3600 RPM and 5° at 1700 which means it's not a simple time delay for some reason. You'll have to measure a known imbalance to find the delay most likely.

I think there might be something else other than accelerometer sample delay going on there. 5 to 70 degrees is a quite a drastic adjustment. While he states correctAngleForRpm() is "because the accelerometer lags by different amounts at different RPMs." He also states, "This array is determined by calibration where we run the system with a known 0 angle imballance and then measure the error at different RPMs." So it appears these values may have been determined experimentally and compensate for all errors in his system. Not just the accelerometer.

I tried to find the specs on the accelerometer he's using, but I couldn't find where he specified a part number. I do know it has an analog output and he's using the Arduino's ADC. This should give him precise control of sample timing. Also instead of a photosensor, he's using a coil of wire wrapped around a spark plug lead going to a 555 timer circuit. I have not looked into this enough to be able to say if that's potentially contributing any to his delay.

Edit: I also wonder if his mounting bracket could be a factor. Everything I've read has said mounting is critical. Looking at his bracket, I could see how it's response to vibration could change with frequency.

 

[rv12is]

And speaking of delays, the optical sensor shown in one of the Dyna Vibe manuals is a Banner Engineering SM312LVMHS, which has a response time of 0.3 milliseconds (300 microseconds), amounting to almost 5 degrees of prop rotation at 2700 RPM.

When testing my optical sensor I got very similar delays. There's a turn-on delay around 275 us. A turn-off delay around 300 us. Also a minimum pulse width of just under 200 us. (See below scope capture. Blue trace is LED control. Low is LED on. Yellow is the active low output from sensor.)



My firmware is not currently compensating for this. However, that is something I will add.

 

[jacoby]

I think there might be something else other than accelerometer sample delay going on there. 5 to 70 degrees is a quite a drastic adjustment. While he states correctAngleForRpm() is "because the accelerometer lags by different amounts at different RPMs." He also states, "This array is determined by calibration where we run the system with a known 0 angle imballance and then measure the error at different RPMs." So it appears these values may have been determined experimentally and compensate for all errors in his system. Not just the accelerometer.

I tried to find the specs on the accelerometer he's using, but I couldn't find where he specified a part number. I do know it has an analog output and he's using the Arduino's ADC. This should give him precise control of sample timing. Also instead of a photosensor, he's using a coil of wire wrapped around a spark plug lead going to a 555 timer circuit. I have not looked into this enough to be able to say if that's potentially contributing any to his delay.

Yeah it's weird. Which is why I brought it up. A 14x increase in lag at 2x the RPM doesn't make much sense if everything is sampling at the same rates and only the RPM changes.

Hopefully your code and the ADXL sensors don't exhibit such behavior!

 

[CF86301]

Yeah it's weird. Which is why I brought it up. A 14x increase in lag at 2x the RPM doesn't make much sense if everything is sampling at the same rates and only the RPM changes.

Hopefully your code and the ADXL sensors don't exhibit such behavior!

Here's the loop where he fills his input data array:
while(millis() < end_t) {
if ((rpm > 0) && (last_interrupt_time > 0)&&(dt > NUM_BIN)) { // if the isr() is giving us RPM and valid last spark
int accel = analogRead(accellerationPin); // Lets get the acell value and then find its slot
int rot = ((micros()-last_interrupt_time)*NUM_BIN)/dt; // simply conversion to rotation in 0..NUM_BIN units
if ((accel > 0)&&(accel < 1023)) {
if ((rot >= 0) && (rot < NUM_BIN)) { // sanity checks
acc[rot] += accel; // average in the accel voltage into this rotation slot
hit[rot] += 1; // into running average at this rotation angle (0..259).
}
} else
overG += 1; // Accelerometer out of range, over/under G.
}
}
Note that he measures rot with a call to micros() after he measures the analog acceleration value. Also note that the A/D converter (ADC) in the Arduino Mega 2560, which looks like what he's using, is a successive approximation type, which according to the data sheet has a specified conversion time of 13-260 microseconds. The data sheet also says that the ADC clock frequency can be anywhere between 50 kHz and 1 MHz, which is also a 1:20 ratio (like 13-260), and that a normal conversion takes 13 clock cycles.

This means he is computing rot some time after sampling the acceleration signal. I don't know what ADC clock frequency the Arduino software sets. Someone with more time than I have may be able to dive into the nuances of this more than I can right now. But now that I look at the code, I'm a little surprised that he got it working as well as he seems to have. The first fix I would make is to switch the order of the int accel... and int rot... statements so the computed rotation would be closer in time to when the acceleration signal is sampled. And I'm making the bold assumption that the Arduino analogRead() function makes use of the sample and hold circuit at the front of the ADC.

All that having been said, I don't understand the 14x increase in lag for a 2x change in RPM either. He blames it on the lag of "cheap analog accelerometers," but I don't see details on exactly what accelerometer he used.

P.S.: To the best of my ability to figure it out, it appears that the ADC clock is typically set to 125 kHz by the Arduino software, so the ADC clock period is 8.25 microseconds and the conversion time is 104 microseconds (13 A/D clock cycles). So he's computing rot at least 104 microseconds after measuring the acceleration.

 

[jacoby]

Note that he measures rot with a call to micros() after he measures the analog acceleration value. Also note that the A/D converter in the Arduino Mega or Mega 2560, which looks like what he's using, is a successive approximation type, which according to the data sheet has a specified conversion time of 13-260 microseconds. That means he could be computing rot anywhere from 13-260 microseconds (plus some instruction delays) after sampling the acceleration signal. Someone with more time than I have may be able to dive into the nuances of this more than I can right now. But now that I look at the code, I'm a little surprised that he got it working as well as he seems to have. The first fix I would make is to switch the order of theint accel... and int rot... statements. And I'm making the bold assumption that the Arduino analogRead() function makes use of the sample and hold circuit at the front of the A/D converter.

Ahh interesting catch. This is deeper than my knowledge of the arduino.

Searching around it looks like you can put an ISR on TIMER1 and use that instead of micros(). I found this thread for the 328 series (post #3) that has sample code. The 640 series looks like it also has the TIMER1 interrupts.

 

[ve0kog]

I think there might be something else other than accelerometer sample delay going on there. 5 to 70 degrees is a quite a drastic adjustment.

If using Hann window like on Walt's charts there will be a processing delay at least half of the window frame size compared to the real time trigger from the tachometer, plus the compute delay to calculate the spectrum. This is completely dependent on the sampling rate and the FFT function performance, since it needs to operate on the N number of samples which takes a non-zero time to collect. It would explain the shift at higher RPMs as the prop rotates farther from the trigger in the same fixed delay time. I wrote some SDR code years ago for a ham radio project (openHPSDR) and ran into this (wasn't easy to figure out without AI assistance ). Someone proficient in DSP can probably calculate the exact delay to compensate for, or as the @jacoby pointed out just measure it in the code during calibration.

 

[CF86301]

If using Hann window like on Walt's charts there will be a processing delay at least half of the window frame size compared to the real time trigger from the tachometer, plus the compute delay to calculate the spectrum. This is completely dependent on the sampling rate and the FFT function performance, since it needs to operate on the N number of samples which takes a non-zero time to collect. It would explain the shift at higher RPMs as the prop rotates farther from the trigger in the same fixed delay time. I wrote some SDR code years ago for a ham radio project (openHPSDR) and ran into this (wasn't easy to figure out without AI assistance ). Someone proficient in DSP can probably calculate the exact delay to compensate for, or as the @jacoby pointed out just measure it in the code during calibration.

I think the key is to refer the time-domain samples to some known reference point on the flywheel or spinner, taking into account the A/D conversion delay, optical or magnetic detector delay, and the DSP processing delays. I would ask at least two AIs to help me figure out how to do that. And then I'd confirm with measurements. If you can do that successfully, you should be able to extract useful acceleration phase data from the DFT or FFT output.

The other thing I think you need to correct for when using Hann windowing is the "coherent gain" of the windowing function, where a sine wave of amplitude A will appear in the corresponding frequency bin with an amplitude of A/2 in the DFT/FFT output.

 

[FinnFlyer]

I think the key is to refer the time-domain samples to some known reference point on the flywheel or spinner, taking into account the A/D conversion delay, optical or magnetic detector delay, and the DSP processing delays. I would ask at least two AIs to help me figure out how to do that. And then I'd confirm with measurements. If you can do that successfully, you should be able to extract useful acceleration phase data from the DFT or FFT output.

The other thing I think you need to correct for when using Hann windowing is the "coherent gain" of the windowing function, where a sine wave of amplitude A will appear in the corresponding frequency bin with an amplitude of A/2 in the DFT/FFT output.

When doing single-bin FFT/DFT to determine prop vibration amplitude there is no windowing and amplitude is correctly calculated from accelerometer Gs, right?
That was my reasoning from going from filtered and amplified analog to digital accelerometer.

 

[CF86301]

When doing single-bin FFT/DFT to determine prop vibration amplitude there is no windowing and amplitude is correctly calculated from accelerometer Gs, right?
That was my reasoning from going from filtered and amplified analog to digital accelerometer.

I'm not sure what you mean. If you mean “If the propeller vibration is at a single known frequency (e.g., prop RPM), and I compute a DFT bin exactly at that frequency, can I skip windowing and still get the correct amplitude from the accelerometer?” the answer is yes, that should work. If amplitude is all you care about, unless you're oversampling so much and in phase with a prop angle reference that you don't care about the phase output of the DFT. Frankly, this scenario requires more thought than I'm willing to invest right now.

But I'm also not sure how well that would work for the RV-12 with the Rotax engine and gearbox situation that kicked off this discussion, IIRC. Direct drive, might work, with sufficient oversampling. Again, scenario, time to invest...

 

[rv12is]

I haven't had the chance to make it down to the hangar and collect actual prop data yet. But I was able to 3d print an adapter so I can clamp this on my cordless drill.

I've got three different size clips I can clamp on to create heavy spots.

Here's the results from one of the runs.


I also had Claude generate a Python script to perform a FFT on the logged raw sensor data.

RPMs were at 1244. This explains the peak at 20.7 hertz. At first I didn't understand the huge peak at ~320 Hz (19,200 RPM). But now I think that's either from the motor itself or from the (currently disabled) hammer drill functionality. Looking at the drill specs, the max RPM is 1600, and the max beats per minute in hammer mode is 25,000. That's a ratio of 15.625 beats per revolution. At the 1244 revolutions we were running, that's 19437 beats per minute, or ~324 beats per second. I then ran another test with nothing in the chuck. As expected everything low went away, but that peak around 320 Hz remained. Then as one final test I wanted to make sure these results were actual vibrations and not interference being induced from operating so close to a brushed dc motor. So I removed the sensor mount and held it in approximately the same position but physically isolated from the drill. The noise floor dropped tremendously and the ~320 Hz spike went completely away.

Initially I wasn't expecting the difference between X and Y. But that makes sense given the placement of the battery weight. I suspect we may see something similar, although to a much smaller degree, on actual prop data.

 

[jacoby]

At first I didn't understand the huge peak at ~320 Hz (19,200 RPM). But now I think that's either from the motor itself or from the (currently disabled) hammer drill functionality.

I would think it's the motor. There is a planetary drive gear set between the motor and the chuck. You're showing around 15.4:1 which seems plausible. If your drill has a high/low speed setting I would also expect to see the same ~19200 spike in both settings.

All the engines have gearboxes of some sort. Mags, redrive, governor, accessory drive, oil pump, etc are all gear driven and can have their own harmonic appear.

 

[FinnFlyer]

What I find worrisome is the ~340 degree phase, if you indeed had the clip 180 degrees opposite the tape.
I know it can be compensated for by test weights and trial and error, but would be nice if showed the actual phase relative to tape.

 

[rv12is]

What I find worrisome is the ~340 degree phase, if you indeed had the clip 180 degrees opposite the tape.
I know it can be compensated for by test weights and trial and error, but would be nice if showed the actual phase relative to tape.

Nice catch! Fortunately, the photos of my test setup aren't associated with the particular test results I posted. I performed numerous tests and just picked one at random to post.

For the most part, test results are within ten degrees of where I'm placing the weights. Although so far I haven't been actually measuring where I place the weight. I've just been trying to eyeball it at 45 degree increments. Definitely notice the zero degree point is the start (not the middle) of the reflective tape. Also there is some shift as I change RPMs. Going from 1250 to 500 RPMs results in a 10-15 degree shift. Although, by far my biggest errors came when I accidentally switched the drill direction without realizing it!

 

[petehowell]

Got a chance to test my esp32/adxl355 gizmo today. It's a work in progress - got some data, but no good solutions. I'm still tweaking the code based on the flight today.

Here is my mount - we might reengineer it, but it works for now.

The rpm is coming from a PMag tach output. My code does analysis on the tach signal, and it is jittery - I'm working on that. I think that is causing the data to jump around.

Here is a short video of the webapp on my phone while gathering data. I've made quite a few changes tonight and hope to fly again mid-week. I'm in over my head here, so I welcome comments and suggestions. If you think I have no idea what I am doing - well, I agree- but I'm having fun!

 

[FinnFlyer]

Interesting. When you've solved the tach noise you could try to improve the solidity of the mount. Doesn't look bad as-is, but by adding another angle piece on the other side of the bolt it could be made stiffer.

Fancy app. AI-generated?

Edit: But at least you got some real-time data, unlike our OP

 

[petehowell]

Interesting. When you've solved the tach noise you could try to improve the solidity of the mount. Doesn't look bad as-is, but by adding another angle piece on the other side of the bolt it could be made stiffer.

Fancy app. AI-generated?

Edit: But at least you got some real-time data, unlike our OP

Hey Finn-

We are working on a 2 leg mount for exactly the reasons you mention. I have a really smart buddy who is helping. We have access to a cnc router, so hoping to maybe cut and bend something.

Lots of AI help - so it needs a lot of validation. Right now all I have is real time garbage in and garbage out...............but working on it.

The good news is the ESP32 and ADXL355 seem to have lots of headroom to supply data and do the math. I seem to be the (very) weak link here.

 

[uk_RV9A]

What an awesome thread. A lot of the technical stuff is a bit over my head, but great to follow along and try and get my head round it. One wonders with all the technical expertise here, and so much cheap and powerful hardware available now, just what open source avionics projects could be developed for a real experimental alternative to the big players!

 

[rv12is]

Got a chance to test my esp32/adxl355 gizmo today. It's a work in progress - got some data, but no good solutions. I'm still tweaking the code based on the flight today.

Here is my mount - we might reengineer it, but it works for now.

The rpm is coming from a PMag tach output. My code does analysis on the tach signal, and it is jittery - I'm working on that. I think that is causing the data to jump around.

Here is a short video of the webapp on my phone while gathering data. I've made quite a few changes tonight and hope to fly again mid-week. I'm in over my head here, so I welcome comments and suggestions. If you think I have no idea what I am doing - well, I agree- but I'm having fun!

This is great! I love seeing someone else playing with this.

 

[rv12is]

Edit: But at least you got some real-time data, unlike our OP

Yep. I was really hoping to make it to the hangar last week, but it just didn't happen. I hate living so far away. Even a short flight requires a 3 hour commitment. Unfortunately, this week is looking really busy. So I'm pretty sure this week is out too. Hopefully next week.

Based off the assumption, that eventually I'll be able to get some good data, I did go ahead and add some more features to the firmware/app. One such change is the addition of balancing sessions. The app will allow the user to take a baseline reading. Then add some weight and make a 2nd run. Then by knowing what weight was added where, and the resulting difference this weight made, the app will suggest a weight to add for the next run. Based off the number of bolt holts provided at the start, the app will also split the weight between holes if needed. Screen shots below. (Please note weight information is being input and saved. Just not shown on the results summary or pdf yet.)


To improve the balance results I'm now gathering data over more revolutions, and also averaging multiple readings together. This is good for balancing, but the slow update rate is not ideal for other purposes. So, I've also added a broadband vibration measurement that updates 4 times per second.

This last one I’m still working on. After performing the offline FFT on my test setup, I thought it might be fun to try and do that live. I think I should have the processing power available. But my BLE connection does have limited bandwidth. What I’m testing now is performing an FFT, finding the ten highest peaks, and sending that data out to the app.

 

[petehowell]

Some data for us nerds -

Got the tach Jitter under better control. Data pointing to needing a stiffer mount - That is in work.

Confidence numbers are better - but still have some clunkers. Data file attached.

Plan:

- get some 0.25" Al plate
- CNC rout a new stiff mount
- fly more for data

Data file from today:
Raw data from Today


Quick and dirty analysis says lots of scatter - I'm thinking it's the mount - appreciate suggestions. The data up near 3000 rpm is a bug that has been fixed - ignore it.

Some screenshots from today

Stiffer mount in work

Flight test engineer sleeping on the job - she's mad about all the wires.......

Yet still demands to be fed

 

[petehowell]

Yep. I was really hoping to make it to the hangar last week, but it just didn't happen. I hate living so far away. Even a short flight requires a 3 hour commitment. Unfortunately, this week is looking really busy. So I'm pretty sure this week is out too. Hopefully next week.

Based off the assumption, that eventually I'll be able to get some good data, I did go ahead and add some more features to the firmware/app. One such change is the addition of balancing sessions. The app will allow the user to take a baseline reading. Then add some weight and make a 2nd run. Then by knowing what weight was added where, and the resulting difference this weight made, the app will suggest a weight to add for the next run. Based off the number of bolt holts provided at the start, the app will also split the weight between holes if needed. Screen shots below. (Please note weight information is being input and saved. Just not shown on the results summary or pdf yet.)
View attachment 114428View attachment 114429View attachment 114430

To improve the balance results I'm now gathering data over more revolutions, and also averaging multiple readings together. This is good for balancing, but the slow update rate is not ideal for other purposes. So, I've also added a broadband vibration measurement that updates 4 times per second.

This last one I’m still working on. After performing the offline FFT on my test setup, I thought it might be fun to try and do that live. I think I should have the processing power available. But my BLE connection does have limited bandwidth. What I’m testing now is performing an FFT, finding the ten highest peaks, and sending that data out to the app.

Good stuff here!

 

[Pilot8]

Yep. I was really hoping to make it to the hangar last week, but it just didn't happen. I hate living so far away. Even a short flight requires a 3 hour commitment. Unfortunately, this week is looking really busy. So I'm pretty sure this week is out too. Hopefully next week.

Based off the assumption, that eventually I'll be able to get some good data, I did go ahead and add some more features to the firmware/app. One such change is the addition of balancing sessions. The app will allow the user to take a baseline reading. Then add some weight and make a 2nd run. Then by knowing what weight was added where, and the resulting difference this weight made, the app will suggest a weight to add for the next run. Based off the number of bolt holts provided at the start, the app will also split the weight between holes if needed. Screen shots below. (Please note weight information is being input and saved. Just not shown on the results summary or pdf ye

Yep. I was really hoping to make it to the hangar last week, but it just didn't happen. I hate living so far away. Even a short flight requires a 3 hour commitment. Unfortunately, this week is looking really busy. So I'm pretty sure this week is out too. Hopefully next week.

Based off the assumption, that eventually I'll be able to get some good data, I did go ahead and add some more features to the firmware/app. One such change is the addition of balancing sessions. The app will allow the user to take a baseline reading. Then add some weight and make a 2nd run. Then by knowing what weight was added where, and the resulting difference this weight made, the app will suggest a weight to add for the next run. Based off the number of bolt holts provided at the start, the app will also split the weight between holes if needed. Screen shots below. (Please note weight information is being input and saved. Just not shown on the results summary or pdf yet.)
View attachment 114428View attachment 114429View attachment 114430

To improve the balance results I'm now gathering data over more revolutions, and also averaging multiple readings together. This is good for balancing, but the slow update rate is not ideal for other purposes. So, I've also added a broadband vibration measurement that updates 4 times per second.

This last one I’m still working on. After performing the offline FFT on my test setup, I thought it might be fun to try and do that live. I think I should have the processing power available. But my BLE connection does have limited bandwidth. What I’m testing now is performing an FFT, finding the ten highest peaks, and sending that data out to the app.

What is the time duration of a single continuous sample?

 

[rv12is]

What is the time duration of a single continuous sample?

For such a simple question, there's a complicated answer. And it's made even more complicated by the fact that I'm taking four different types of measurements and almost all of this is configurable from the command line interface. The below answers are based on the current default parameters. Please let me know if you have any suggestions. I'm still trying to figure all this out and will be making mistakes along the way.

There are four different types of measurements I'm currently making.

Measurement	Frequency content	Update rate	Use case
Broadband RMS	All (0–400 Hz)	250ms	Monitoring, GEA24
Monitoring DFT	Prop fundamental only	~1.4s	Live balance display
Balancing DFT	Prop fundamental only	~17s	High-accuracy balance
Spectrum FFT	All (5–400 Hz), binned	~5s	Frequency diagnosis

As far as sample rate, I'm taking 800 samples a second. For the data used in a balancing session, I'm collecting data samples over 256 rotations. During this 256 rotation window, if the RPMs do not stay consistent the results will be marked invalid. Once a window is complete, the results will be made available to the user and another window immediately started. Once this next window is complete and data validated, the average RPMs will be compared to the previous window. If the RPMs between the two windows are within 1% of each other, the results are averaged together. This process will continue with the firmware averaging together the last three valid 256 rotation windows. So if the prop RPMs are 2300, the first window will be collecting data for approximately 6.7 seconds. The three window average would be just over 20 seconds.

I'm also performing a faster DFT. This monitoring DFT is only collecting samples for a 64 rotation window. There is no data validation and no multi window averaging.

Then there's the broadband vibration measurement. This is just the averaging together of samples over a 250 ms period. This result is in g's, not IPS.

Finally there's the FFT. For this I'm collecting 4096 samples (regardless of RPM). At 800 samples/second, this takes 5.12 seconds.

 

[Pilot8]

For such a simple question, there's a complicated answer. And it's made even more complicated by the fact that I'm taking four different types of measurements and almost all of this is configurable from the command line interface. The below answers are based on the current default parameters. Please let me know if you have any suggestions. I'm still trying to figure all this out and will be making mistakes along the way.

There are four different types of measurements I'm currently making.

Measurement	Frequency content	Update rate	Use case
Broadband RMS	All (0–400 Hz)	250ms	Monitoring, GEA24
Monitoring DFT	Prop fundamental only	~1.4s	Live balance display
Balancing DFT	Prop fundamental only	~17s	High-accuracy balance
Spectrum FFT	All (5–400 Hz), binned	~5s	Frequency diagnosis

As far as sample rate, I'm taking 800 samples a second. For the data used in a balancing session, I'm collecting data samples over 256 rotations. During this 256 rotation window, if the RPMs do not stay consistent the results will be marked invalid. Once a window is complete, the results will be made available to the user and another window immediately started. Once this next window is complete and data validated, the average RPMs will be compared to the previous window. If the RPMs between the two windows are within 1% of each other, the results are averaged together. This process will continue with the firmware averaging together the last three valid 256 rotation windows. So if the prop RPMs are 2300, the first window will be collecting data for approximately 6.7 seconds. The three window average would be just over 20 seconds.

I'm also performing a faster DFT. This monitoring DFT is only collecting samples for a 64 rotation window. There is no data validation and no multi window averaging.

Then there's the broadband vibration measurement. This is just the averaging together of samples over a 250 ms period. This result is in g's, not IPS.

Finally there's the FFT. For this I'm collecting 4096 samples (regardless of RPM). At 800 samples/second, this takes 5.12 seconds.

Very good info, thank you. I do have some ideas, but first a few followup questions to make the suggestions helpful:
1. By DFT you mean you are using np.abs and np.angle to get magnitude and phase from np.fft?
2. Can you plot the fft output log10(g) vs log10(freq) @800 sps with a single 1 second duration with the accelerometer is at rest, no averaging, and no rpm activity? Hanning window with no overlap is best. This would be super informative.

What you are working on is incredibly interesting and you are doing a very good job.

 

[Walt]

I always try to mount the vib pickup as close to the prop as possible, looks like you're a bit further back.

 

[petehowell]

New mount made with help from airport buddies - thicker, shorter, lighter. Hope to test tomorrow - the mount turned 90 degrees, so I had to flip the axes in the software, it was pretty easy. Will report success or failure.

New Mount

 

[ve0kog]

when i rented a test kit from Two Wing aviation (a good company!) they had a clever sensor mounting method which utilized exposed threads of an existing case bolt. It was a nut welded to the head of another hex bolt . this extension avoided removal of the case bolt for the vibration test. There were multiple variations of this extension in the kit for different case bolt sizes

 

[petehowell]

when i rented a test kit from Two Wing aviation (a good company!) they had a clever sensor mounting method which utilized exposed threads of an existing case bolt. It was a nut welded to the head of another hex bolt . this extension avoided removal of the case bolt for the vibration test. There were multiple variations of this extension in the kit for different case bolt sizes

I like that! This will probably stay mounted for a while. I do have a Deutch connector on it so we can move it to another plane later tho.

 

[rv12is]

1. By DFT you mean you are using np.abs and np.angle to get magnitude and phase from np.fft?

For this I'm just going to quote claude directly:
No — the firmware DFT is not using numpy or any FFT algorithm at all. It's a completely different approach.
The firmware computes a single-bin DFT manually using direct summation. For each accelerometer sample within a revolution:
c

angle = 2π × sample_index / samples_per_revolution

sum_sin += x_g × sin(angle)
sum_cos += x_g × cos(angle)

After N complete revolutions, amplitude and phase are recovered as:
c

magnitude = (2/total_samples) × sqrt(sum_sin² + sum_cos²)
phase     = atan2(sum_cos, sum_sin)

This is mathematically equivalent to evaluating the DFT at exactly one frequency — the prop fundamental — rather than computing the full spectrum at all frequencies. It's also known as a lock-in amplifier or synchronous averaging technique.
The key distinction from a standard FFT approach:

-	Firmware DFT	FFT + np.abs/np.angle
Frequencies computed	1 (prop fundamental only)	N/2 (full spectrum)
Reference signal	Tach edge (physical rotation)	Implicit sample timing
Averaging	Across complete revolutions	Across time samples
Rejects off-frequency content	Yes, very strongly	Partially (windowing)
Equivalent numpy call	None — manual summation	np.fft.rfft() then np.abs() / np.angle()

The closest numpy equivalent to what the firmware does would be:
python

# Evaluate DFT at exactly k=1 (one cycle per revolution window)
X = np.sum(x_g * np.exp(-1j * 2 * np.pi * np.arange(N) / N))
magnitude = (2/N) * np.abs(X)
phase     = np.angle(X)

But even that isn't quite right because the firmware doesn't have a fixed-length revolution window — it uses the actual tach-measured period to determine samples_per_revolution, which varies slightly with RPM. The firmware's approach is more accurate than a fixed-window DFT because it references directly to the physical rotation rather than assuming uniform sampling across a fixed time window.

2. Can you plot the fft output log10(g) vs log10(freq) @800 sps with a single 1 second duration with the accelerometer is at rest, no averaging, and no rpm activity? Hanning window with no overlap is best. This would be super informative.

 

[Walt]

when i rented a test kit from Two Wing aviation (a good company!) they had a clever sensor mounting method which utilized exposed threads of an existing case bolt. It was a nut welded to the head of another hex bolt . this extension avoided removal of the case bolt for the vibration test. There were multiple variations of this extension in the kit for different case bolt sizes

Sounds great but from my experience, relying on a couple of exposed threads to secure the sensor vs just taking the nut off and mounting the sensor seems like it would not be gaining anything and may risk the sensor coming loose or stripping the exposed threads. If removing a single case bolt scares you then that’s a different issue.

 

[Pilot8]

For this I'm just going to quote claude directly:
No — the firmware DFT is not using numpy or any FFT algorithm at all. It's a completely different approach.
The firmware computes a single-bin DFT manually using direct summation. For each accelerometer sample within a revolution:
c

angle = 2π × sample_index / samples_per_revolution

sum_sin += x_g × sin(angle)
sum_cos += x_g × cos(angle)

After N complete revolutions, amplitude and phase are recovered as:
c

magnitude = (2/total_samples) × sqrt(sum_sin² + sum_cos²)
phase     = atan2(sum_cos, sum_sin)

This is mathematically equivalent to evaluating the DFT at exactly one frequency — the prop fundamental — rather than computing the full spectrum at all frequencies. It's also known as a lock-in amplifier or synchronous averaging technique.
The key distinction from a standard FFT approach:

-	Firmware DFT	FFT + np.abs/np.angle
Frequencies computed	1 (prop fundamental only)	N/2 (full spectrum)
Reference signal	Tach edge (physical rotation)	Implicit sample timing
Averaging	Across complete revolutions	Across time samples
Rejects off-frequency content	Yes, very strongly	Partially (windowing)
Equivalent numpy call	None — manual summation	np.fft.rfft() then np.abs() / np.angle()

The closest numpy equivalent to what the firmware does would be:
python

# Evaluate DFT at exactly k=1 (one cycle per revolution window)
X = np.sum(x_g * np.exp(-1j * 2 * np.pi * np.arange(N) / N))
magnitude = (2/N) * np.abs(X)
phase     = np.angle(X)

But even that isn't quite right because the firmware doesn't have a fixed-length revolution window — it uses the actual tach-measured period to determine samples_per_revolution, which varies slightly with RPM. The firmware's approach is more accurate than a fixed-window DFT because it references directly to the physical rotation rather than assuming unifoling across a fixed time window.


View attachment 114646

Got it, you are effectively synchronizing time to crankshaft angle before performing the DFT with a running average. In a fixed sample DFT there are a bunch of issues, the reason I asked. The last cycle's value of RPM is used for the next cycle's RPM to set the sample length- the jitter in the cycle to cycle RPM will impact the SNR. Are you using the internal clock or an external clock? Are you using your own filter coefficient to set the first sinc filter notch at 800 hz?

 

[petehowell]

Got some more data today with the new mount. Still having issues with "phase smearing" causing low confidence results. There is no correlation with tach jitter, and the mount is rigid, so I am focusing on the getting a good data snapshot when the engine settles into a new rpm range. Made some code changes this afternoon - hope to fly tomorrow.

i was running an adaptive window that would grab 64 or 128 revs depending on the data quality. The results exiting early at 64 revs were higher quality - so we are trying a shorter window.

Taking a deeper dive on "phase smearing" (love that term) another culprit looks to be the dynafocal mount - the lycoming moves in an ellipse vs a circle - so I adjusted the math to accommodate this. As to if I did the adjustment correctly.......that will require more data - maybe tomorrow.

We might need to use the baseline then trial weight method to map how the engine behaves. That is plan B if the short window and new math dont give less smear......

 

[rv12is]

Got it, you are effectively synchronizing time to crankshaft angle before performing the DFT with a running average. In a fixed sample DFT there are a bunch of issues, the reason I asked. The last cycle's value of RPM is used for the next cycle's RPM to set the sample length- the jitter in the cycle to cycle RPM will impact the SNR. Are you using the internal clock or an external clock?

The data sample rate is controlled by the ADXL345, but all time is referenced to microseconds since startup on the microcontrollers clock. When an interrupt occurs (indicating a sample is ready), the microcontroller records the time and sets a flag to read the sensor data.

I don't know if this is a good idea, but for the rotation period I am using an exponential moving average filter. The filter coefficient can be adjusted in real time from the command line interface. This doesn't fix the jitter problem, but does mean I'm not looking solely at the last revolution to determine angle position of the current revolution. (Although, if desired, I can still tweak the filter coefficient so that it only uses the last rotation)

I've also considered buffering all the sensor readings during a revolution. Then once the rotation has completed, using the actual rotation period to go back and assign angles to the buffered readings. However, I wasn't going to go through with this until after I take some measurements to see how bad the jitter is. So I did develop a Python script that will retroactively go through a sensor log file and recalculate using this modified rotation approach and quantify the difference it actually makes.

Are you using your own filter coefficient to set the first sinc filter notch at 800 hz?

I'm still using the ADXL345. I now have a ADXL355, but haven't switched to it yet. Unfortunately, the ADXL345 gives almost no information on it's filtering. There's a footnote that indicates the −3 dB frequency is half the output data rate, but that's about it.

Another thing I'm unsure of with the ADXL345 is the delay between sampling and indicating data ready. The ADXL355 data sheet gives some detailed timing info, but I can't find similar info for the 345.

 

[CF86301]

I don't know if this is a good idea, but for the rotation period I am using an exponential moving average filter. The filter coefficient can be adjusted in real time from the command line interface. This doesn't fix the jitter problem, but does mean I'm not looking solely at the last revolution to determine angle position of the current revolution. (Although, if desired, I can still tweak the filter coefficient so that it only uses the last rotation)

I've also considered buffering all the sensor readings during a revolution. Then once the rotation has completed, using the actual rotation period to go back and assign angles to the buffered readings. However, I wasn't going to go through with this until after I take some measurements to see how bad the jitter is. So I did develop a Python script that will retroactively go through a sensor log file and recalculate using this modified rotation approach and quantify the difference it actually makes.

It seems to me that there are at least three sources of uncertainty on the RPM pulse timing. One is the uncertainty of measuring the exact instant of TDC (or whatever reference angle you choose), using an ignition system's RPM pulse, an optical sensor pulse, or a Hall effect sensor pulse. Let's call that "jitter," which is a form of measurement noise. Another source of cycle-to-cycle timing variation might be unequal pulses from different pistons, i.e., "cyclic irregularity". That would show up as a periodic signal interfering with the RPM pulse timing measurement. Cycle averaging should help mitigate it. Another thing is the uncertainty of the RPM itself, because the engine RPM may vary a bit around the setpoint. Let's call that "drift". It's a form of low-frequency process noise, I think.

Another approach would be to use an alpha-beta filter. Here's an explanation of how that works.

And still another approach would be to use a Kalman filter. Here's an explanation of how that could work.

Attached is a Matlab file that implements the two approaches described above and an exponential moving average filter and compares them. You can download a free trial version of Matlab to run it if need be. I had to change the file extension from .m to .txt to attach it here.

All of these approaches benefit greatly from proper tuning of filter coefficients. The exponential moving average filter works pretty well if the dominant uncertainty is jitter and there isn't much drift. The alpha-beta filter is fairly simple to implement and works pretty well. It handles both jitter and drift. The Kalman filter is probably the best if it's properly tuned, but is more complex to implement.

 

[CF86301]

I've also considered buffering all the sensor readings during a revolution. Then once the rotation has completed, using the actual rotation period to go back and assign angles to the buffered readings. However, I wasn't going to go through with this until after I take some measurements to see how bad the jitter is. So I did develop a Python script that will retroactively go through a sensor log file and recalculate using this modified rotation approach and quantify the difference it actually makes.

It would definitely be useful to try to characterize the jitter and drift. That would be very helpful for tuning the rotation timing filter coefficients.

The idea of buffering one revolution of measurements and then assigning angles based on the measured interval between rotation pulses is interesting. Are you binning acceleration measurements by angle?

 

[petehowell]

I have been fighting tach jitter off the PMag signal, so today I coded a scope tab on my balancer. It showed a dirty signal.

I'm now using an analog to digital pin on the esp32 to convert the signal to single pulse using a using a blanking window to ignore the ringing pulses at the 40ms mark. I'm also using a software Schmitt Trigger* to ignore the fuzzy noise at the bottom. It seems to work when pulling the prop thru by hand. Will maybe get a ground run in tomorrow to test while running.

I have learned A LOT working on this project. I'm sure there is more to learn..........

* A Schmitt trigger is a comparator-based circuit that converts noisy or slow-moving analog signals into clean, fast-switching digital square waves. It utilizes positive feedback to create hysteresis—two distinct threshold voltages (upper and lower)—which prevents multiple false triggering caused by noise as the signal passes the trigger point.

 

[FinnFlyer]

I have been fighting tach jitter off the PMag signal, so today I coded a scope tab on my balancer. It showed a dirty signal.


I'm now using an analog to digital pin on the esp32 to convert the signal to single pulse using a using a blanking window to ignore the ringing pulses at the 40ms mark. I'm also using a software Schmitt Trigger* to ignore the fuzzy noise at the bottom. It seems to work when pulling the prop thru by hand. Will maybe get a ground run in tomorrow to test while running.

I have learned A LOT working on this project. I'm sure there is more to learn.......... Hey

* A Schmitt trigger is a comparator-based circuit that converts noisy or slow-moving analog signals into clean, fast-switching digital square waves. It utilizes positive feedback to create hysteresis—two distinct threshold voltages (upper and lower)—which prevents multiple false triggering caused by noise as the signal passes the trigger point.

That severe ringing must be from your ignition system.
The "blanking window" appears to do the same as a one-shot (also called a Monostable Multivibrator). A one-shot can't be triggered again until its set time has expired.
74LS121 is such a chip.
Never occurred to me to implement that with software.
Finn

 

[CF86301]

That severe ringing must be from your ignition system.
The "blanking window" appears to do the same as a one-shot (also called a Monostable Multivibrator). A one-shot can't be triggered again until its set time has expired.
74LS121 is such a chip.
Never occurred to me to implement that with software.
Finn

Google "switch debounce software algorithm". It's a common problem. I usually use a software state machine so I don't have to sit in a loop waiting for the input to change or a timer to time out.

So there's another source of jitter: glitchy signals.

 

[petehowell]

Google "switch debounce software algorithm". It's a common problem. I usually use a software state machine so I don't have to sit in a loop waiting for the input to change or a timer to time out.

So there's another source of jitter: glitchy signals.

I think I got the signal tamed - the orange box is the blanking window - here on a hand pull thru -bad data ignored

Here on the running engine - looking good - tach scope is cool!
Tach Jitter now reading under 0.40 percent for all samples

i'll try to get a balancing run in later. So much to learn - data makes it real.

 

[petehowell]

Ok - finally got a run in tonight - there is good news and bad news......

The good news is that my results match really well with a commercial balancer (ACES Probalancer). That unit got me down to .04 IPS last year with a few runs and showed 19g split between holes 6 and 7 on my flywheel. The Homebrew Vibemaster Elite(tm) showed 20g at hole 6.5 - so I think it works. This was a ground run at my cruise RPM of about 2270. I did not get to make another run after adding weights.

The bad news is the 0.5x vibration - that senses engine vibration and is showing a pretty big engine imbalance that might be drifting into the prop balance. It might just be the carbed Lycoming and may be normal. Gemini thinks carbed Lycomings might have mixture imbalance.............

I think I will fly with it next to see what results I get there - more to come. The tach jitter was about 0.5%, so I am happy with the filters that have been set up on the tach signal. Still seeing some phase smearing, but the spread is much better (narrower) now.

 

[petehowell]

I got some data in flight today with the naked(no weights) flywheel. This data is consistent with the ground run, indicating to add about 20g at hole 6.6. It still thinks my engine is gonna fall apart with the 0.5X ips being really high - I dont feel any misfires, so it must be more subtle. I have noticed when doing an inflight mag check - the engine is smoother on the megajolt on the top plugs vs the PMag on the bottom plugs - might swap in my spare PMag to see of that makes a difference.

Bottom line - this gizmo seems to work and provides useful data - I'll continue to refine it.

Next up - add the suggested weight and grab more data. I'm trying to figure out if I can identify the weak cylinder(if there is one) from the vibe data(see below)

I'm open to ideas, suggestions, snarky comments. What have ya got?

Graphs for nerds like me.


This is me way out over my skis with a bubble gum analysis to find where the engine vibes are coming from. Polar plot of 0.5X IPS (at cruise rpm) with the quantity and sum of IPS by cylinder quadrant. Not sure is this is valid at all. Shows a bunch of scatter, but combustion of cylinders 1 and 2 seem to be more vibey (technical term) but CHT are well balanced. Maybe the engine brain trust here will have some thoughts - or just have a good chuckle at me like my wife and family do......

Some ideas with help from Gemini:

Key Findings from the Severity Distribution:​

• Cylinder 2 (The "Chronic" Roughness): Cylinder 2 has the highest count of "Rough" events (13 hits in the 0.4–0.6 IPS range). This confirms that Cylinder 2 is the most consistent source of the 0.5x "buzz" you feel in cruise.
• Cylinder 1 (The "Sharpest" Hits): Interestingly, while Cylinder 2 is consistently rougher, Cylinder 1 produced the most "Severe" spikes (4 hits >0.6 IPS). This might indicate an occasional misfire or a more erratic combustion event on that front-right cylinder.
• Cylinder 4 (The Healthiest): Cylinder 4 has the most readings in the "Smooth" band (12 hits). Despite being the hottest cylinder (342∘F), it is providing the most stable power pulses.

What this confirms for your diagnosis:​

The fact that Cylinder 2 leads in the moderate-to-rough bands while Cylinder 1 leads in the severe spikes points to an overall Bank 1-2 (Front) issue.

1. Induction: Check for minor leaks at the intake gaskets for cylinders 1 and 2.
2. Ignition: With a wasted spark setup, the same coil often fires 1 & 2. If there is a slight weakness in that specific coil or its wiring, it would explain why both front cylinders are showing higher roughness than the rear.

 

[CF86301]

I got some data in flight today with the naked(no weights) flywheel. This data is consistent with the ground run, indicating to add about 20g at hole 6.6. It still thinks my engine is gonna fall apart with the 0.5X ips being really high - I dont feel any misfires, so it must be more subtle. I have noticed when doing an inflight mag check - the engine is smoother on the megajolt on the top plugs vs the PMag on the bottom plugs - might swap in my spare PMag to see of that makes a difference.

Bottom line - this gizmo seems to work and provides useful data - I'll continue to refine it.

Next up - add the suggested weight and grab more data. I'm trying to figure out if I can identify the weak cylinder(if there is one) from the vibe data(see below)

I'm open to ideas, suggestions, snarky comments. What have ya got?

Graphs for nerds like me.

View attachment 115047
This is me way out over my skis with a bubble gum analysis to find where the engine vibes are coming from. Polar plot of 0.5X IPS (at cruise rpm) with the quantity and sum of IPS by cylinder quadrant. Not sure is this is valid at all. Shows a bunch of scatter, but combustion of cylinders 1 and 2 seem to be more vibey (technical term) but CHT are well balanced. Maybe the engine brain trust here will have some thoughts - or just have a good chuckle at me like my wife and family do......

Some ideas with help from Gemini:

Key Findings from the Severity Distribution:​

• Cylinder 2 (The "Chronic" Roughness): Cylinder 2 has the highest count of "Rough" events (13 hits in the 0.4–0.6 IPS range). This confirms that Cylinder 2 is the most consistent source of the 0.5x "buzz" you feel in cruise.
• Cylinder 1 (The "Sharpest" Hits): Interestingly, while Cylinder 2 is consistently rougher, Cylinder 1 produced the most "Severe" spikes (4 hits >0.6 IPS). This might indicate an occasional misfire or a more erratic combustion event on that front-right cylinder.
• Cylinder 4 (The Healthiest): Cylinder 4 has the most readings in the "Smooth" band (12 hits). Despite being the hottest cylinder (342∘F), it is providing the most stable power pulses.

What this confirms for your diagnosis:​

The fact that Cylinder 2 leads in the moderate-to-rough bands while Cylinder 1 leads in the severe spikes points to an overall Bank 1-2 (Front) issue.

1. Induction: Check for minor leaks at the intake gaskets for cylinders 1 and 2.
2. Ignition: With a wasted spark setup, the same coil often fires 1 & 2. If there is a slight weakness in that specific coil or its wiring, it would explain why both front cylinders are showing higher roughness than the rear.

Are you also reading the P-Mag and looking at the Coil Bank 1 and 2 values?

In addition to what Gemini says, I'd take a look at the plugs and wires.

And what about the EGTs? Any correlation there?

All in all, remarkable progress in a relatively short period of time with the Homebrew Vibemaster Elite(tm).

 

[petehowell]

Are you also reading the P-Mag and looking at the Coil Bank 1 and 2 values?

In addition to what Gemini says, I'd take a look at the plugs and wires.

And what about the EGTs? Any correlation there?

All in all, remarkable progress in a relatively short period of time with the Homebrew Vibemaster Elite(tm).

Chip - thanks for buying into our marketing campaign!

Good call to check wires - the megajolt has new wires all around, but the Pmag has older ones hat were Ohmed out at annual. I have all the materials to make new ones and it's a fun process.

Here is the polar plot with a bit more analysis - the EGTs are pretty similar - but might be something there.

 

[walkman]

I've been thinking a bit about the way the app suggests corrective action. We have a finite selection of possible weights in terms of AN3 and AN4 nuts, bolts, and washers.

You could go AN3 or AN4, and there's probably a small selection of bolt shaft lengths that will work, call that 6 options. A standard lock nut, 2 options one for AN3 and one for AN4. Then there's maybe 3 different washer options for each bolt size - standard, L, and large area. So, 6 standard options for washers.

So the recommended suggestions could be "place an an3-4A with one an96010 and one an970-3 washers and an an365 lock nut"

 

[Walt]

The 1/2 order vibs are generally under .2IPS as an average (Lyc), 0.3 is not what I consider unusually high and not something I get concerned about.
All my readings are taken during ground runs.
Example: (disregard the 'warning' limit of .2 which is for prop balance only)


Another example this one a bit higher at .347 IPS.

 

[petehowell]

OK - I like that spectrum display - I iterated to get a version this evening. I'll try to fly and get data tomorrow.

Wrote some logic to capture accessory peaks at odd multipliers-let's see if it works..........

 

[rv12is]

I finally made it to the hangar and did a preliminary run. Ran into some problems with my tach signal. It appears the nuts and washers used to mount the prop are reflective enough to produce multiple false tach signals per revolution. I was able to mitigate this some by spacing the sensor out with washers below the angle, and decreasing the pulse width for LED modulation. This was enough to get me a clean tach signal at lower RPMs, but when I did a full throttle runup I would start having problems again.



Likely will need to space this out just a bit further to get a clean signal. Until then, I think I can filter out the erroneous readings and perform some analysis on the data I was able to collect.