I tried running your log through mavfft_isb.py and got an error - its because you have opts set to 3, which is an error - you can’t do sample rate logging with post-filter. Sample-rate logging is by definition pre-filter. So I’m not sure what your FFT data is showing but you should changes opts to 2
The way these things work is we have to eliminate all the obvious things before diving deeper - otherwise there are too many variables. So you may or may not be right, but either way we need to eliminate that from the equation.
If you can do your next log with attitude fast logging that would also help
I had it set get post-filter data to double check my filters worked and I later ticked the sensor rate logging because I thought it got me higher sampling rate as it seemed Iike the time plots had a very long sampling period and maybe I wasn’t getting all of the frequency information. I seemed to have missed the note to not enable both.
So I’ll set opt to 2 and enable attitude fast logging for my next flights.
One of the reasons I raised my Spin_Min and lowered MOT_THST_EXP was to get rid of some ‘grinding’ sound from the motors that occurs at low throttle (with just quad level and dropping down from hover, or dropping down and sitting on the ground).
The first question is this due to tuning, so I should tune every time I change spin or THST. Thus, I plan to run a controlled series of experiments where I do a sweep of MOT_THST and for each value of MOT_THST, I run run auto-tune -> test hover -> check for low throttle grinding -> apply static notch where applicable -> check for low throttle oscillation and the loss of control issue (or anything else you may suggest I check)
Before I start this, could you take a look at one log to check if the logging setup looks good so I know my logs will be useful for analysis later?
This log is after I raised my MOT_THST_EXP to 0.4, ran an auto-tune, and applied a notch filter at 214Hz to kill a huge spike of noise (seems associated with the 'grinding I get with higher MOT_THST_EXP and doesn’t go away with autotune).
https://drive.google.com/file/d/1W7xaKafVz2M-VZZp1PY6LOXqFVZvMaCL/view?usp=sharing
Ok, so one big problem here is that your RPM feedback rate is too low. The default at 10Hz is going to struggle to kill noise. Since you are on a Matek405, I recommend you try the -bdshot target (shouldn’t need to change any parameters) and then you will get much higher RPM feedback to the notch which should kill the noise much more effectively. I would do this before playing around with static notches.
If you don’t want to use the bdshot target (or can’t, the target is for a STD, no idea how well that maps to a wing, also the target changes which UART has full DMA so would affect your use of CRSF) then raise the telemetry rate to say 100Hz - so SERVO_BLH_TRATE = 100.
The other thing you can do is raise SCHED_LOOP_RATE to 800 - this always makes a big difference on smaller craft.
Note that you are asking quite a lot of this board, there would be more options with an F7 or H7.
The logging looks good. You can see R/P/Y oscillation on RATE.R/P/Y so some more tuning required.
1 Like
I’ll try the setting changes since changing the target will make me move my UART1 (assuming it works). Thanks for your advise.
Long-term I’ll look into upgrading the FC to an F7. Does the kakute F7 AIO look good? Having a uSD card is like a requirement 
and that seems like the only option.
1 Like
H7, all The Matek H743 boards, even the mini, have an Sd card. Ditch the F4.
I have a Kakute F7 AIO and an F7 Mini. Nice boards but not an H7. Impressed so far with the Matek H743-Mini.
1 Like
Ah sorry I didn’t make my constraints clear. For my build I wanted an FC with a built in PDB with pads at each corner for my individual ESCs, which means an matek F722-SE. That didn’t look like it’s supported. Otherwise I’d have gone with a Matek.
I’m curious, is adding support mainly a matter of figuring out the right IO mapping (like making a header file) for the target or more complex? I’ve got some basic coding experience so trying to judge if it’s something I can do.
You will have a large compromise needing an AIO. F722 doesn’t have enough flash to run Arducopter. Why don’t you go with an FC/ESC stack instead?
F722 does not have enough flash - need 1Mb minimum.
KakuteF7 AIO is ok as a board but currently a bit hobbled because the F7 sector size means there is slightly less available flash and the SD card requires a bunch of flash. So no CRSF for instance. This will go away when the custom build server is publicly available.
1 Like
I’ve had an 4-in-1 ESC burn and another fail mid-flight so I’ve been shy about using them for a quad that will be flying far.
Thanks, really helpful to know about lack of crsf support for the kakute atm. Is custom build server something that lets user select features they want in the build so there’s more flexible use of the flash space?
So alternatively I could get an h743-Slim and a matek pdb (Matek FCHUB-6S) to drive my ESCs. Does that look good?
Yea, nice combination.
So I tried scheduler loop rate set to 800Hz and the BLH_TRATE to 100Hz and the quad managed to finish roll autotune, but when pitch autotune seemed to complete, the quad entered a false failsafe for a good 35 seconds, which kicked it into smart RTL. So probably too much for this F4, though 35 seconds to clear the failsafe seems way too long.
I didn’t get very far in the rest of the testing since when I didn’t know at the time it was smart-RTL so I panic-disarmed, which caused the quad to fall out of the sky once the failsafe cleared and I broke a few props.
Smart RTL works flawlessly though; I thought it was quite amazing the quad kept rolling “out of my control” but always stopped short of hitting something. =P
1 Like
I did have a successful autotune at 400Hz loop rate, BLH_TRATE to 100 however, with MOT_THST = 0.40. I wanted to fix the low-throttle grinding sound (D-term oscillation because the motors do get hot when I continuously reproduce this?) before I tried to test the 0-throttle issue I reported earlier.
All I have to report on is to show a video of what this sounds like for some opinions. Note when I ease the throttle (ie. whenever I make the descend or if I wiggle the throttle as it’s ascending ), there’s a low frequency grinding-like sound. And I’ve been able to reproduce that same sound with the quad landed on soft grass before.
I’m confused by this since in Betaflight, over-tuned D oscillation tends to be a higher pitch whirring sound… and it usually happens across the range of throttle. And if it stuck out so much, increasing the throttle would always make it worse, not better.
If you are getting hot motors then you almost certainly need to drop INS_GYRO_FILT and ATC_RAT_*_FLTD
My guess would be that this is simply feedback oscillation made worse by propwash.
I don’t know what ESCs you have but have you tried playing with SERVO_DSHOT_RATE?
I only get hot motors if I continuously operate in the oscillatory mode by twiddling the throttle. If I’m hovering there’s no hot motor.
I’ve also been able to get that mode to drop to well below hover (but not completely disappear) with the same filter in previous configurations where I had THST_EXPO = 0 and SPIN_MIN = 0.12, and different tunes. I can freestyle aggressively for 5 minutes and motors are luke warm.
Going back to the more ‘normal’ settings for THST_EXPO and auto-tuning has actually makes this worse, but I’m playing around with it since I think also PID tune related.
I suspect autotuning may be blind to it because it’s not happening at hover throttle.
This is why the correct value for THST_EXPO is so important, it’s the only way the tune at hover throttle can apply correctly at high and low throttle values
I had one question on whether the THST_EXP and MOTOR_SPIN_MIN interact with each other.
Is the exponential curve calculated from SPIN_MIN to 100%, or is it calculated from 0% to 100%, and SPIN_MIN just provides a floor?
The graph from here would suggest it’s calculated from SPIN_MIN.
