Now you see how frustrating this problem is itâs desperation for me to try everyone elses ideas
The term you are looking for is âprop washâ and differential pressure pulses over the Baro - None of which is the problem, Bigger slower props would present a bigger problem Sure, just like a passing thermal or air temp/pressure gradient we occasionally feel ourselves that make Quads drift up and down itâs a problem but thatâs not the cause here. In calm Air I have watched the Copter just sink all the way to the ground from 8 feet
Iâm happy to accept my baro is poor but a little disheartened the ALtitude controller just does not work well or respond to setting changes on these little Quads - This little Quad is a complete pain as each time I have to take the top frame off to get at the USB connection to make changes so you can imagine how much work it is
As I mentioned, we have some other stuff to test on Arducopter which might shed some light on the issue
I see this a lot on my 2.5" quad. Itâs really annoying and I havenât figured out what the problem is. Itâs not necessarily tuning - could be a driver problem. This is also the only quad I have with a DPS310
years back, I made a little 5" alt hold in Baseflight without a baro !!! just set all the weighting to ACC and it did a pretty good job
The ACC is the most accurate sensor we have and we are obviously not using it enough on the ALT controller here
To see if I was able to overcome this problem I put an external MS5611 baro in a plastic box with foam and I fixed it over the battery with a rubber band. The battery in my build is on top of the frame.
The MS5611 is noisier then DPS310 but mounted away from the prop wash there are no more the deep minimum on the baro measurement on takeoff and landing.
One thing that I donât understand is the rise of CTUN.DAlt and CTUN.Alt before takeoff with CTUN.BAlt remaining correctly near 0.
Good stuff , thanks
Yes for sure we donât baffle our baros well enough most of the time.
Arducopter is a very complex stack that seems to either work well for you out of the box or you have a big fight on your hands to get it better, Arduplane is the same and I have learnt how to make the Planes work the way to suite the stack. The same EKF and control loops do give you a smoothness in and out of GPS functions other stacks donât, so we just have to work at it
Looks like PSC_ACCZ_SMAX seems to reduce/stop my hover motor pulsing - now I need to understand itâs effects and how to set it correctly !!
Anyone have a clue what this means ? PSC_ACCZ_SMAX for position control. The limit should be set to no more than 25% of the actuatorâs maximum slew rate to allow for load effects
The EKF altitude is a blend of barometer and accelerometer so the EKF altitude estimate is often different from the barometer. In this log we see the EKF altitude estimate is climbing from zero after arming but before takeoff, this is probably because the EKF is still learning the accelerometer bias which can change over time and also depending upon the temperature of the IMU.
Another reason the EKF estimate is different from the barometer is the barometer has a relatively long lag (about 0.2 seconds) and is quite noisy so the EKFâs estimate is first based on the accelerometers and then the baro altitude more gently pulls the estimate in one direction or another.
Thanks @rmackay9 I understood your explanation. Do you think that this could explain also the fact that EKF alt estimate, desired alt and baro alt become close only after a while and only after this I have a stable AltHold? I attach a plot to visualize this.
Yes, it takes some time for EKFâs altitude estimate to stabilize so this is what youâre seeing. If it was just sitting on the ground a little longer before takeoff then I think they would be together right from the start of the log.
Itâs a guess but you could try re-doing the accelerometer calibration but I suspect it is mostly the IMU temperature that is the issue.
itâs desperation for me to try everyone elses ideas 
