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: https://www.magentacloud.de/share/a.sfxqu9vh
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
Cheers
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 
hi
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)
Adolfo
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
Adolfo
PS : I really like the yaapu script !
I have the same problem with R9M and R9 slim + rx. Random “No RC receiver” on yaapu widget (Jumper T16) but rc link is strong (no failsafe).
Matek F405 wing.
I do not think It’s a power or rx problem, because my other F405 wing + X4r have the same issues.
I’ve just released plane 4.0.5beta1. This release includes a one important bug fix and some minor enhancements. The changes are:
- fixed bug handling change of RC input source while MAVLink signing is active. This could cause a stack overflow and a crash
- added display of RC output types to aid in debugging DShot outputs
- modified clocking on H7 boards to produce more accurate clocks for DShot
- switched to new USB VIDs for dual-CDC boards
- fixed a bug in handling LOITER_TURNS for quadplanes when Q_GUIDED_MODE is enabled
- added a TECS reset at the end of a VTOL takeoff to handle aircraft with TECS climb rates below VTOL climb rates
Logs from testing would be much appreciated!
Happy flying!
2 Likes
Wonderful news Andrew.
Can you say what the bug was in the loiter turn when in guided mode?
how can i add values to SERIAL1_PROTOCOL in full parameter list in mission planner ?
Quoting Tridge here: “if NAV_LOITER_TURNS is used with Q_GUIDED_MODE=1 then we would orbit
forever. This ensures we do exit the loiter”.
1 Like