OSD parameter manipulation is merged
@andyp1per, can you clarify? I think you are saying the LC filter solved some visual noise on the video feed, which is quite common and seems to be what this filter is intended for. But we were also discussing interference with GPS. Are you saying it helped with this too?
Just helped the video - I don’t have any GPS interference issues that I am aware of.
OH, thanks for the clarification. I’m trying to improve GPS reception.
For video interference, I just use a big cap… Some super low ESR oscon caps… Although the LC filter might be lighter… I should check that.
Yeah, big cap made a bit of difference for me but not nearly enough
Hi friends, I crashed my tiny 2 "quad because it was rocket into the sky.
It’s probably the vibrations, but the failsafe vibration doesn’t seem to work well. Unfortunately my flight controller has no logs so I can only guess.
I had to disarm the engines in flight.
I have put a few more details here:
Regarding this I tested latest master on OmnibusNanoV6 and I get not so good log, I can read it with APM Planner 2 (with some error), Mission Planner say there are no FMT messages and with mavfft_isb I get a lot of
bad header 0x00 0x00 at 255
Skipped 44 bad bytes in log at offset 19929, type=(163, 149, 155) (prev=177)
but in the end I get the plot.
Ouch, this is probably a conflict between the FFT and logging threads which I have also seen. I need to dig into this a bit more as it only just started happening.
The log posted above comes from OmnibusNanoV6 with master built without DSP (the default for this board) so I don’t think that problems comes from FFT.
Ok, that’s pretty bad - the work I did on logging was designed to avoid this situation. Are you able to replicate the problem? Are you able to identify a commit that made it worse?
Have a look at the DSF messages (if you can) they will tell you how logging is getting on.
I will try and I will let you know but unfortunately I cannot do it soon.
@anbello I have pushed a change to my small copter branch that might help. It seems to get rid of the logger thread died messages and may help with your logging also. It does however make the FFT priority the same as logging so I am worried that on an F4 you might not get enough updates. It seems to work ok on my F7.
I can test both with HAL_WITH_DSP=1 and HAL_WITH_DSP=0 to see how FFT influence on logging.
Does it makes sense?
You don’t need to change the compile options - just FFT_ENABLE=0/1 will be enough
This change is working really well for me - be interested to see how well it works for you.
Tested latest small-copter-4.1 on my 3 inch quad with OmnibusNanoV6 and I get complete logs that are red without errors by Mission Planner, APM Planner 2 and mavfft_isb, both with FFT_ENABLE=0 and with FFT_ENABLE=1. Good!
The only strange things I see is a bad baro behavior on take-off and landing, but I don’t think that this is due to your last logging PR. I attach a plot with baro going to -4m on take-off and landing. Perhaps the foam above the barometer has shifted and is taking air from the propellers.
Great news! Yeah bro must be unrelated.
Do you get decent notch tracking with the FFT enabled?
Yes really good tracking.
has anyone used the S.port telemetry Frsky protocol on the Omnibus nano V6.0?
I connected an RX jumper r1 + with S.port output to pad TX1 on the nano v6 (as indicated on the schematic on the wiki so it would seem to support s.port) but it doesn’t seem to work.
The RX itself works fine on a kakute F4 (unfortunately 30x30 not good for 3" quad).
Anyone put Ardupilot on a Cinewhoop? I want to fly it with a 4S LiIon and the trouble with Betaflight is it really is hard to fly it with the serene throttle management required to keep current under 20-25A. Alt Hold will really help as I can remember – I use Plane now and have not used Arducopter since APM 2.6! The use-case is to use a it with a Naked GoPro Hero 8 for slower cinematic passes. Anyone have any input here?