I have just pushed some updates, should be quite a bit faster.
1 Like
I think the loading problem and “Aw Snap” is the amount of RAM I have at the moment, only 8GB - I can see memory usage climb while loading the log, and then it stops.
Not much chance of getting this to work on the old Sinclair ZX81 with only 1K RAM 
2 Likes
I have been reading up a little. It seems that no matter the amount of actual RAM you have chrome limits each tab to 4GB, so even if the machine has plenty left you can still run out. Your results may vary with other browsers.
I will see what I can do to save some, but I guess there will always be logs that are just too big.
1 Like
It’s probably the amount of physical ram I have. Firefox is actually working OK except for a few missing graphs.
EDIT - feature request 
Another Calculate button near the “Filter Configuration” would be nice
1 Like
@MindProbe
Suggesting some Filter settings - these are very experimental due to the size of your props and considering what are normal guidelines are.
INS_ACCEL_FILTER,10
INS_GYRO_FILTER,7 // extremely low!
INS_HNTCH_ENABLE,1 // set this then refresh params to see the rest
INS_HNTCH_MODE,1
INS_HNTCH_REF,0.12
INS_HNTCH_FREQ,9 // also very low!
INS_HNTCH_BW,4
INS_HNTCH_FM_RAT,0.7
INS_HNTCH_HMNCS,3
These work well enough in theory, but may be too low and cause instability. I’ve tried to balance out filtering noise versus the phase and whatever else I can see onscreen or think of.
I would be more confident if we heard a recommendation from @Leonardthall in case he says my suggested settings would be disastrous. 62inch props are outside of just about everyones comfort zone.
1 Like
Now with handy new button.Should also be faster and use less memory.
We could add a “auto re-calc” checkbox, if the log is not too big then it will update in less than a second, it was this way to start with but got very painful to change several filter parameters, were much faster now so its not quite so bad.
2 Likes
Thanks Pete - great work!
1 Like
Oh, I like this… lots
1 Like
I’ve tried these settings with not much improvement
I’ve also made a separate thread with the recent logs
1 Like
Had another copter that went from this pre-filter
to this post-filter
You can’t get much better than that!
And this was a reasonably large multirotor of a type that has proved difficult to tune in the past.
We were able to carefully select the harmonics thanks to the Filter Review Tool, and we also had the advantage of using ESC RPM data so that made it easy. We set a per-motor dynamic notch.
We were also able to increase the INS_GYRO_FILTER above the calculated value based on prop size - this is possible using the old methods (MP FFT graphs), but the filter review lets us view the expected results and tie that in with any other HNOTCH changes to give a total result.
4 Likes
Pushed a few more updates and bug fixes in the last couple of days. There is now a “open in filter tool” button right at the bottom.
This opens the current set of filters in the filter tool so you can see the none averaged bode plot.
In the filter tool itself there is also now a “Show individual filters” check box. This shows the individual filter components so you can see which filter is contributing the most at each frequency.
3 Likes
Excellent - thanks Pete. I like the additional tools!
I’ve been using the Filter Review Tool extensively, now I’ve got more to play with
…and the PID section - I assume that is about how the PIDs will be affected by the filters.
I’ve noticed there is some logs that have the batch logging settings but wont open in the filter review tool, but they will open in the MissionPlanner FFT graphing tool. So far I cant pic the difference between logs that work and logs that dont 
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
1 Like
If you can send me any logs that don’t work I’ll take a look.
The PID bit is more just because its interesting, not a huge amount of practical use at this stage. You can see which gains are doing the most at each frequency. It confirms those rules of thumb of manual tuning. High frequency oscillation is too much D, middle is P and very low is too much I. You can use it to trade off between say the D filter and the D gain. Lower filter means you can have more gain ect.
1 Like
Hey @iampete, I saw on this forum, that you were able to integrate AirSim and SITL using WSL2. I am currently integrating these two programs together and following the instructions posted by @rajat2004 on the forum post but I keep getting the error “[Errno 111] Connection refused sleeping” whenever I follow the steps. I was hoping you could help me figure what is wrong.
I also apologize for this not being another topic thread.
1 Like
Hello Peter! I continued to work on eliminating the effects of vibration using Dynamic Harmonic Notch Filters with an internal combustion engine with RPM sensor. It was hard to figure out how to install an RPM sensor on a nitro ICE - OSMAX FS62V , but I managed to install two magnets on the propeller support sleeve. I now have the opportunity to doing this section of the RPM Sensor Based Dynamic Notch Setup for my Durandal
I did the tests and posted their results at this link I need to apply Dynamic Harmonic Notch Filters to two IMUs - ArduPlane / Plane 4.3 - ArduPilot Discourse
Thank you for your development of the tool Ardupilot Filter Review Tool.
I got the result of my test and applied it on your instrument, here is its view in the picture.
I would like to get a better result from applying filters. I tried changing the parameters in the TOOL : INS_HNTCH_FREQ and INS_HNTCH_BW , but it does not give a noticeable result.
I would like to get recommendations from you on how to improve the result of filters.
I have files from my tests, if they are required for your answer, how can I transfer them over the Internet?
Thank you for your attention to my problems!
1 Like
Don’t post results, post the .bin log file. The 1st thing I would do is change the amplitude scaling to linear.
1 Like
I did 4 tests, there are files from each IMU.
1 Like
I looked at the first and largest log.
The notch filter as configured was completely missing the noise.
So I checked a few things without going over your results, just so my review is independent and maybe we will come up with totally different results.
It’s like the RPM value is almost double 50% more than what it should be, based on the frequencies we are seeing logged.
Average RPM from some of the steady sections of log is ~5500 RPM = 60 Hz
Where as RPM should be reading as 2800RPM = 46Hz based on the noise we see.
I would change:
RPM1_SCALING,0.254
INS_HNTCH_FREQ,30
INS_HNTCH_BW,15
You might be able to better calculate that RPM scaling factor based on the physical sensor properties and placement, like 0.25 might be more accurate and make more sense.
The Freq and BW will scale up with RPM once the RPM reading is correct, so setting them lower than the lowest frequency peak is the correct thing to do.
See what you think and what you can come up with, and let’s see another log.
1 Like
Hello, Shawn! Thank you for your quick response! The parameter RPM1_SCALING was set correctly, for two rotating magnets this value is 0.5. To check the rpm, I used a tachometer, the engine worked in the rev range from 2500 to 9300 rpm with a 12x8 propeller. This is a heavy propeller for this engine, so on the ground the speed is no more than 9300 rpm. When the plane is flying, the propeller runs up to 11000 rpm.
