Plane 4.1 stable

Autotune Atomrc dolphin. After first tune it was a little twitchy. But after second it fly better.
Video from first flight

video from second flight


Hi @tridge ,
Any comment on this Autotune?? Any advice on the PID is highly appreciated… Thank you…

Hi everybody

I am trying to configure Plane 4.1 for manual parachute release (via RC channel).
In previous versions this was set by CHUTE_CHAN parameter.
Digging a bit into the code I guess this functionality was moved to RCn_OPTIONS, but I cannot find documentation on which value to use for enabling manual parachute release.

Help much appreciated.

Janez Langus

Ardupilot version: 4.1.2
FC: Matek F405 wing, plane nano talon
I experienced some strange oscillation both on roll and pitch axis during my second flight.
1st flight: My first flight was normal…i made an autotune on level 5, and my gyro filter was on 28%. After i land…change battery and take off again.
2nd flight: First oscillation occured immediatly after the take of at FBWA mode…than i experinced this wired behaviour 2 minutes later started on pitch than roll also oscillated. I also noticed i got" EKF acticve" message on DJI custom OSD, right after the oscilations. When i checked my pids at home i realised that autotune (at first flight today) made only changes on Pitch rates but Roll rates was the same as i saved it a week before🤷‍♂️
I have never experinced this with 4.1.0 with another plane ranger g2 with same F405 wing Fc.
Here is my log bin file:

@tridge I flew two of my models on 4.1.2 on Thursday and had a rallpoint set at 70m relative, take off was perfect and the models loitered at 70m. I flew them both for some time and then engaged RTH and they came back and and started orbiting the rally point at 20m (not so ideal)

I also engaged an auto mission on one and it tried to fly it at 20m rather than 70m terrain as programmed. The throttle also dropped dramatically even though the trim throttle is 45%.

Have you seen this behaviour? It was weird to see both models work at 70m for launch but then drop to 20m

I can’t load rally points with terrain as a reference it gives me an invalid frame warning.

My understanding is relative is ref to arming height, absolute is height above sea level? And terrain is height above terrain.

Dear Devs
Is there any reason why we should seriously pay attention to use 4.1.x (or above) version of new arduplane with limited boards like F405 wing (use it with one gps no more external sensors)??? I read reports (in ardu discuss topics) and also experienced on my own plane about issues which can be related to EKF3
affinity and lane switching.

Lot of users suggested is more safe to use EKF2 intstead of EKF3 on these limited F4 FC s for plane. I dont know if the reason that ekf2 need less computing power than ekf3 but It seems to me when the FC activate EKF3 (i ve got this message on OSD) the FC can fails (probably try to go back to DCM🤷‍♂️) and cannot handle the plane attitude, starting high oscillation or cause a crash during take off…or can this be 4.1.2 bug or issue as till now i didnt experinced it with 4.1.0 running on also with f405 wing Fc🤔

Reviewed my previous logs from 3 different flights with 4.1.2 and i not received EK3 active/ DCM active message, beside this flight where the oscialltion occured (as shown in the attached log photo)

I really dont want to use custom fw or older versions (older fw s not support dji msp osd which primary for me) if its not necesary and will be confirmed that new version 4.1x are safe to use on older F4 limited board like f405 wing! OR we need to use F7 FC s to prevent these weird midflight behavior.
I think a lot of us No need so much extra feature for a hobbyplane which required ekf3…and if it can cause issue…i really appreciate if we can use a 4.1x or above fw with default or switchable ekf2 option.
Thanks for advise

My log with this issue here for further analyse:

1 Like

no problem with EKF3 on matek f405 wing FC


It is 22, see this page:

Thanks for feedback
Which version do you use now?.4.1.0 or 4.1.2?

i use plane from 4.1.beta6 till 4.1.2, no issues with ekf3. But i have compass

I’ve just ordered an Archer RS to test this myself, but could you please try setting the “Enable RC Protocol re-detection” bit in RC_OPTIONS. You will probably find that RC_OPTIONS is currently set to 32, so you would change it to 1056 to include the re-detection option.
The reason I suggest this is that the Archer RS specifications list it as both SBUS and FPort. I suspect it is really FPort2 (which is a different protocol to FPort). Possibly what is happening is it false detects as SBUS and can’t change to FPort2 due to protocol re-detection being disabled.
Otherwise we’ll need to wait a few days for my Archer RS to arrive so I can test.

I confirm no issues with EKF3 on matek f405 wing wse

I had a strange thing happen flying Tri Tilt Nimbus 4.1.2, It was gusty so I set an RC flight mode to Loiter (it gives my head a rest), Took off flying transitioned into FBWA - challenging, so switched to loiter which was fine, except it was closer to the chooks then I wanted so switched back to FBWA and moved about 200-300m further away and switched back into Loiter, It then proceeded to return to the original loiter circle. I’ve done this a few times previously using mission planner to change to loiter mode and controller to move it to a different location and back to loiter but this is the first time I can recall it returning to its original loiter circle.

Hi @tridge ,
In the mean time I have updated the Archer RS and the Taranis X9D receiver both to the latest FW versions. Still can observe the F.Port issue playing in the same conditions as before. Also I pluged the Archer RS in a Pixhawk 2.4.8, the issue is also there. But I notice the Pixhawk was jumping back and foward between decoding the S.BUS and decoding the F.Port. So I mask the RC_PROTOCOLS just to F.PORT and it stop decoding the SBUS. The communication was establish just in the F.PORT but after some seconds AP was in FAILSAFE, meaning the issue is also happening here.

Anyway I will follow up your request and change the RC_OPTIONS bit to 1056 and let you know later this evening CET time for the results.

Going inside the Taranis X9D Open TX, we can select in the Archer RS options the following: S.PORT/ F.PORT/ F.PORT2(FBUS)

wow, that is weird!
can you please upload the log?

Hi @tridge,

I have good and bad news!
Bad news:
After trying several times unfortunatly we continue to see the same failure mode in each trial. To note when setting RC_OPTIONS to 1056 (could not find the description you refer “enable protocol re-detection”) it represents the “enable multiple receiver support”.
I tried selecting the FPORT2 in the Taranis but it also fails after a couple of minutes.
Also tried in the Heli FW4.1.1 RC1 and this F.PORT issue is also there.

Good news:
I remove the SBUS wire and voilá the issue is gone! I think we are funneling to the root cause. :smiley:
Seams that this issue is related to both SBUS and FPORT being connected.

my Archer RS hasn’t arrived yet, can you explain what you mean by this? Does it mean there are two signal pins out of the archer RS, and you connected both? What pins did they connect to on the flight controller?

Correct, I have both SBUS signal line and SPORT/FPORT line connected to Rx6 and Tx6. When removing phisically the SBUS line and leaving the FPORT alone, the Failsafe doesnt happen, the issue is gone.

1 Like!Auv-5QlGCPQogah34Qswv4GV5t9YrA?e=ThcQWC

Logs 119 I think…can you also confirm if 119 initial transition was with the wind - scary… as I said it got a bit gusty.


Hi Pedro, this is why I asked you this some time ago:

Good to know it is solved now.