If I remember things right (please devs correct me if not), RPM-based filtering is still Fourier-based in its nature, so it may fail to cope with the big data rates from IMUs.
I ran a Pixracer with fast sampling on both IMU’s with FFT referenced Notch for quite awhile before changing ESC’s. Load was a bit high but I never experienced any problems. Now it’s using ESC RPM from Bdshot, no problems with that.
It can depend on what else you have enabled. I had scripting enabled at the same time (so had huge issues with fitting all that into the memory). The scripts were not hot, but probably in the time frames they were running the filtering machinery failed to finish in time, all the prop noise was getting further into the controls, and everything was going SNAFU pretty much - as the PIDs were good enough with filtering and too much without it.
No scripting enabled just crsf and terrain following, and rpm filtering pretty generic really. I will post a param file once I land later. Looks like its time to update my little test platforms to a H7. I just have a bunch of pixracers laying around guess they will make good ap_periph’s hahah
Not quite the same. It’s the backend rate at 8Khz that is too much. A backend rate of 1Khz is fine
Ah, yes, this is what I missed, thanks. I’ve tuned mine to 8/8.
Thanks very much for the detailed report including logs. I’ve added it to the 4.4 issues list so it won’t be forgotten.
Well I think I may have found the culprit of this misbehaviour and it was a cracked sd card
Here is a link of the flight on the latest beta should be labeled PDX in the beginning. It flew great had no issues just a quick hover in the backyard. @rmackay9 would that sd card have caused the watchdog reset? Here is a param file just in case anyone cared.
4.4.0 MASTER Param.param (17.1 KB)
Hi @406FPV,
Thanks for the follow-up. A bad SD card should never cause a watchdog… it might be but it shouldn’t so we will have a look at the WDG message and see if we can find the cause.
@406FPV can you check if you have a crash_dump.bin file on your microSD card? it may also be embedded in a bin log from a later flight (if a crash dump is present in flash we embed it in all logs)
@tridge
Unfortunately my logging failed due to a sd card crack and then I reverted back to stable and then back to latest beta so I do not have a crash_dump I am very sorry.
any word on the previous wdg reset I received? are f427 EOL after the recent update to beta 4.4.0 seems I have had two mro pixracers throw 2 wdg’s first was not allocating cores to ekf3 the second I have not heard anything about what it was. when they previously had never had one. has there been any word on if 4.4.0 is pushing cpu’s harder?
As reported on the other thread, it seems that Gremsy is aware of the problem and has a fixed Pixy WE firmware coming that resolves the issues. Txs again for the report.
How did you solved the Bad Gyro Health error? I’m having the same too
Most errors can be mitigated by good hardware construction followed by methodical configuration and tuning: How to methodically tune (almost) any multicopter using ArduCopter 4.4.x
All processes are covered there, if you have any questions, or something is not clear, ask in there.
Noted. Thank you for the info.