Copter-4.0.5 released!

what is your MP version ?
I think that is related.

it’s 4.0.5 didn’t’ get it from what I recall on 4.0.4 and it only seems to happen when powered via the USB.
My MP version is

I am observing that if pulse multiplexer output is inverted it is detected in Pixhawk (with IOMCU) but not in Mini Pixhawk and similar controllers (without IOMCU), as if edge detection were not detected both ways. Am I missing something?


I just have done the manual tuning today, in Stabilize mode, tuning Roll only. After a while, the drone faced toilet bowling issue, keep testing many times later on but still got the same problem. I have log file and parameters here, it would be nice if they got checked.


I’ve only had a quick look at the logs but a couple of things stand-out:

  • The vehicle seems to be in stabilize mode the whole time so I wonder how toiletbowling could be happening or maybe you mean something else? Toiletbowling normally means the vehicle circles on it’s own in Loiter mode (or sometimes other modes).
  • ARMING_CHECK = 0. This is nearly always a bad idea and disabling the checks could be hiding the source of the problem
  • EKF3 is enabled. Any particular reason? Normally it’s best to stick with the default EKF2 unless there is a good reason not to.
  • There are some very large deviations in the magnetic field at the end of the log. It may be motor interference or something else but certainly some kind of physical issue (i.e. not software) or maybe the vehicle crashed at the end? In which case you can ignore this comment, the mag field looks OK in the early part of the log.
  • Re tuning, have you seen the Tuning Process Instruction wiki page? I know it’s quite long but it is a good idea to follow this precisely.

Good Luck!

Hi @rmackay9,

Thanks for the response. That was my bad on that report. Basically, the symptom is similar to tb effects but in Stabilize mode. I also strongly believe that the tune was bad so today I have done another one. Everything seems better but the Yaw using dual GPS (I enable EK3 for that purpose before)
I have enable the EK3 for dual GPS heading function. It seems to me that the functions did not work.

GPS for base: 3D fix
GPS for rover: DGPS
GPS1_POS_Y : -0.15
GPS2_POS_Y : 0.15

The yaw angle kept drifting during the static condition.
Could you please have a look on my parameter:


Anyone having trouble upgrading to 4.0.5.
I have been successful on two other drones but one I had held off on doing and decided to do it today.
It went in but each time I connected with Mission Planner I got told that 4.0.5 was available …huh
So I check the system messages and found I had 4.0.3 installed.
So I tried again. Same result.
Again Same result.
You know what they say about insanity.
Anyway I then wiped the firmware and started from scratch. Still 4.0.3.
I realized there was a problem because the compass priority settings where gone.

Anyway I then went to 4.0.5 Beta and got 4.0.4 RC2…so I am back where I started.
I have no clue why.

Above (four batteries changed on the fly) is for a pulse multiplexer connected to a conventional receiver: no pulse shifting and no ROI loss. I have had other flights without any problem. So the problem seems to happen with this receiver, and it seems to happen also with other identical receiver. Anyhow, I think this receiver is not being manufactured any more, but S.BUS is the way to go.

BTW, it seems that if the multiplexer output has inverted pulses it is not always recognized by all FC’s, having IUOMCU or not.

Try upgrading with QGC.

I would like to report landing gear bug.
Case: LGR retract alt is set to 30m, deploy to 25m. RNGFND_MAX_CM is set to 35m (using lidar lite v3)
whenever i flight lower than 35-40m, LGR works fine deploys and retracts how it should, but when i go above 35-40m and lidar readings are 0/chaotic the LGR deploys. it wont switch to GPS/baro altsource.
This is a bad feature/bug, because it alway deploys LGR when flying above 40m.
And no i cant use a manual retraction/deploynment.

Can you try 4.0.6-rc1. I think I fixed that.

I would love to, but it still is beta i think, and this is very expensive drone, so i am not sure how very stable this beta is. Shouldnt i wait for stable release?

4.0.6-rc1 is a release candidate. It will probably be released as 4.0.6 without any changes next week.
But it is your drone, your responsability and your decision to make.

Take a look at the ReleaseNotes

I might wait. But maybe i wont be able to, because today i had another problem that might relate to the same bug.
I tried to ascend from 25m to 60m. All the time the throttle was at 1700 us. However when aproximately when lidar was out of range (cca 44m) the drone stopped ascending despite the fact that throttle was at 1700 us still. It just hovered at 44m.
The strange thing is that i have alt_source set to 0.
Could it be the same issue? If yes, than i might have to upload 4.0.6 sooner then stable release is released.
If this is something new to you, i can provide logs.

This is new. That bug should not happen with alt_source set to 0. Post a log.

ill do that tommorrow morning.
Here they are.

I am refering to this event starting at aproximately 15:15.

And i had a similat problem in the past. I described in this thread Copter problem - descends or climbs - - ArduCopter / Copter 4.0 - ArduPilot Discourse

I did try today with 4.0.6-rc1 as you requested, but still no luck. Landing gear still doesnt work.
Here is the log from the flight

When I check here Complete Parameter List — Copter documentation I see many EK3 params but can’t see EK3_IMU_MASK.
When looking in version 4.1.0 EK3_IMU_MASK exists. Complete Parameter List — Copter documentation

Does 4.0.5 support EK3 despite missing this param?

I replied in another discussion regarding your tuning issues.
If you want to use EKF3 then update firmware to 4.1 where it is tested and stable, otherwise read the doco on enabling EKF3 in earlier versions. Any particular reason you are worried about IMU_MASK ?