Plane 4.0 release

I am trying to have camera triggering happen on the ground before flying, and now I’m having no luck. It was working a few days ago, and I don’t recall having issues with previous firmwares but now something is different. I believe the logs indicate that the trigger message is not getting through as I can’t find any TRIG events. RC6_Option = 9, and that has worked in the past. Trigger camera now from mission planner is also not working. Log at the following link.!AunBK4rE1ZDCged5m_r3Z2tkNfI0GQ?e=JlXe8S

just a reminder that I’d love to see logs from the 4.0.4beta release. I can’t do the release till I have sufficient logs to be confident everything is OK

Do you need logs from any particular flight controller?

any flight controller is fine

1 Like

Would love to do some test flights but there ist very strong wind in Europe since Sunday, impossible to fly anything :smiley:

Everything ok, log file:


1 Like

fantastic, thanks Rolf!

If the log of the same aircraft is still of interest in a short flight in windy conditions:
2020-02-15 10-48-33.bin Folder:

1 Like

I’ve just released plane 4.0.4 stable. This release includes a significant number of changes from 4.0.3. Key changes are:

  • re-sync the 4.0 release with Copter-4.0, bringing them in line so
    as to maximise cross-vehicle testing
  • fixed a timing issue in IOMCU that could lead to loss of RC input
    frames and increased latency of output to ESCs on the IOMCU
  • fixed a bug in restoring gains in QAUTOTUNE that could cause the aircraft to be unstable on leaving QAUTOTUNE mode
  • fixed stack size of ftp thread

The Copter-4.0 re-sync brings in quite a few structural changes. The main user visible changes are:

  • UAVCAN DNA server no longer needs a microSD card to operate
  • added logging of UAVCAN servos and ESC feedback messages
  • reduced QTUN logging rate to 25Hz
  • reduced memory usage in EKF with multiple lanes
  • Minor OSD improvements
  • added a lot more scripting bindings
  • fixed UAVCAN GPS status when not connected
  • added EK3_MAG_EF_LIM limit for earth frame mag errors
  • added MAVLink FTP support
  • added support for WS2812 LEDs

Many thanks to those who tested the beta release, much appreciated.

Happy flying!

1 Like

Many thanks Tridge

I flew around 15 flights with Arduplane 4.03 (taranis X9D, R-XSR, pixracer, C&T passthrough telemetry).

I had severals “No RC receiver” (see my post) without any impact on the flights but quite stressfull

Do you think it could be link to the IOMCU ,

I will use this week 4.0.4 asap


We had the same experience while we only had the R-XSR in really, so not even connected to the AP. Ergo Firmware could easily be eliminated.

After tracking down the issue to R-XSR. We replaced them with good old X8R and the problem went away. This was in multiple builds, not just one. So quite confident that the RX is the culprit.

Also we were using X10 (Horus) RC, not X9D as you were.

So it FrSky (R-XSR) internal issue. Maybe can be fixed with firmware, maybe not). The issue only happens if the s-port is enable with any telemetry pass-though. I guess that is why it has laid dormant for so long. Not many people used that s-port. They have been dropping the ball a lot since early last year. Hope they don’t end up like Nokia soon.

EDIT: Sorry, was not clear, we had the issue even before 4.0.4beta was out, so I don’t think it is related to the Firmware IOMCU.
Test your system with X8R or X4R-SB and see if you get the same issue.

well here are some logs of today’s testing 4.0.4

the only issue i came across is getting analogue rssi to work on on sbus pin ( 103 )
the rx is outputting voltage as it should i was getting frsky rssi on my tx
and in auto-tune i could get it turn after a pass Turing it took about 300 meters to turn back lol with full aileron turn the only way i get to come back was put in manual mode so with all all that done will test auto takeoff mode next a session

Thanks a lot

I just received an x8r
Can you please advise about wiring with pixracer ?

Alex, can you help me reproduce this issue, I have an r-xsr on the bench and I might give it a try, just curious…thanks.

Hi Alex,

The issue was not related to your script.
If you are interested in the architecture…
UAV (dragonlink RX) rc control and telemetry to ground (dragonlink TX) wifi to computer and sbus + raw telemetry (via teensy) to r-xsr.

Worked ok most of the time default. But as soon as we went to fly, we got random failsafe. Even when the unit was 100m away. Then we replaced with another one. The a whole other unit, same thing. Up untile we remove the r-xsr and change back to x8r, the issue did not go away. Failsafe for 1 second, then back.

…this triggered my attention.
I know it’s not related to my script but it might be related to passtrough, but after reading it over I see that you’re not using ardupilot passtrough but rather a teensy in MavToPT relay mode?

Yes Dear, relay mode, with Teensy running Eric’s magics :wink:


I found the wiring between X8R & pixracer.

I had 2 flights today (X8R - arduplane 4.0.4 - passthrough telemetry)

The issue (" no Rc receiver " came only 3 times (compared to 12 times in similar conditions)

Debug with flash data log seems difficult (sampling time of log too slow for such event but not sure as I am learning about log analyis)


haha ok than most likely a receiver issue as you pointed out!

I flew today (good flight with a lot of thermals)

I had around 15 times “no RC receiver” message

Config was : X8D - pixracer R15 - yaapu script

I will try with a separate BEC for RC receiver


PS : I really like the yaapu script !