ok, the static port hole is way too close to the leading edge of the wing. The pitot needs to be much further out.
It is a common misunderstanding where users think that it is only the hole in the end of the pitot that matters. There are more often issues with the position of the static port hole (the small holes in the side of the pitot). Those needs to be in clear air, which means quite a long way ahead of the wing.
It’s always recommend that use pitot tube order 2 ( static , dynamic) or only dynamic pitot tube can reliably read the airspeed value.
Because the above case if we configured tube order to 1 ( only dynamic tube straight one)can read the airspeed value consistently?
Currently it’s not documented - the only way to tell is to look at hwdef. I did have a PR that prints a message telling you which UART has DMA, but that got rejected. Probably we will just have to document the DMA enabled UARTS for each board.
You say “it works”, but I have had several people report RC failsafes that go away when they use DMA, so as far as I am concerned the problem is real. It’s more of a problem on slower CPUs - on H7 there is HW support that makes even non-DMA likely fast enough.
@andyp1per Does DMA as a requirement only apply to CRSF? Or also for other RC protocols? Then this should be documented really urgently and if errors accumulate as you write also warned not to use a UART without DMA for fast RC connections.
Currently only CRSF - there is already a warning you get.
@andyp1per Could it be that “problems” without DMA only occur because high-speed connections with CRSF are used? CRSF also runs with 115.200 baud and I can’t really imagine why high-speed is necessary for ArduPilot configurations … This is more a thing for race copters, which are rather not operated with ArduPilot.
And if a MAVLink from Crossfire is connected to FC, it does not need DMA?
No it doesn’t. CRSF is spec’ed to run at 416Kbaud only. CRSFv3 optionally increases this to 1Mbaud and 2Mbaud
RC by mavlink is a different protocol - can be very low rate, but you lose a lot of the CRSF benefits
OK, understand, thanks. I am using MAVlink only for communication via Crossfire TX WiFi to the MP mobile app, which is very slow. But probably this is not due to DMA or not DMA UART, but due to little reserved space in the whole Crossfire communication.
Hi tridge,my rc plane crash again.I guess it’s still EKF issue.I changed the EKF3 back to EKF2，but the issue still exist.It have been crashed tree times.
it happens when in AUTO mode,the plane was flying normally at the beginning，then it nosed down suddenly and hit the ground.
I can’t get the plane back until next day. It was powered on until the battery was dead .so it produced very big size replay log.the size of the replay log is about 1GB,please download from attached web size,and let me know if you can’t get the replay log
@tridge
RE Play log
thanks for the log.
This crash was caused by a GCS command to switch to MANUAL mode when it is fairly clear the pilot was not trying to fly the plane manually. The trim was a bit off and that led the plane to foll right and nose down. If you had SERVO_AUTO_TRIM=1 then it would have been correctly trimmed and would have stayed closer to level in MANUAL mode. Clearly the mistake was the switch to MANUAL mode though.
This shows it was a GCS command:
2021-09-22 23:22:46.341 MODE {TimeUS : 261193066, Mode : 0, ModeNum : 0, Rsn : 2}
2021-09-22 23:22:53.041 MODE {TimeUS : 267892500, Mode : 11, ModeNum : 11, Rsn : 1}
2021-09-22 23:22:53.041 MODE {TimeUS : 267892590, Mode : 11, ModeNum : 11, Rsn : 1}
The EKF performed fine and all seemed OK until the switch to MANUAL mode.
AP takes 1 sec to disarm when it detects a sink rate less than 20 cm/s. With LAND_DISARMDELAY = 1 it should disarm between 1-2 sec but it takes 5 sec. This is crítical in one Tailsitter Dual Motor (AUTO mode).
Is there any option to disarm as soon as you touch down?
Thanks tridge,it seems right,I remember I put on the cell phone and the plane keep nose down,but one things strange is that the QGC should pop out an slider bar to comfirm the command,but it didn’t pop out any slider bar.
did QGC record a tlog?
“internal error 0x400”
The flight is much better than with the old variant,
only the message “internal error 0x400” appears.
Log record on the link:
NO.the cell phone QGC can’t record the log .
thanks for reporting this! That indicates a NaN was caught in the function set_throttle_avg_max() which gets called from AC_AttitudeControl_Multi::set_throttle_out().
The error was harmless and the actual throttle levels used were fine, but I will try and track this down.
1 Like