Cumulation of crashes due to seemingly weird input (Pixhawk 4)

If you have the option, I would try with an inverted signal and 14 ms update rate.

What does ‘65536’ mean?

It’s the maximum number represented by a 16 bit integer. Sometimes uint16_max is used to represent an error, but you’d need to check the code.

Hasn’t anyone else had this issue with Arducopter 3.6.4 running Pixhawk4 firmware?

@YovinRY,

FYI a new beta has gone out and the Pixhawk4 firmware can be found here (download the .apj file). This is 3.6.5-rc2.

This version includes a small fix to the RC input decoding but I don’t know if it will help the situation you’re seeing.

1 Like

@rmackay9
I converted the SBUS signal to PPM using an encoder and plugged it to the PPM RC port, but will try this beta firmware with SBUS when i get the chance. Thanks for the info.

Hello,
I think I’ll stick with the pixhawk 4 when rebuilding my copter.
In case the issue happens again, does anyone know if I could prevent the copter from crashing by turning off the transmitter?

I had the same problem today and my plane crashed badly!
I use a Pixhawk 4 with ArduPlane 3.9.4 installed. Transmitter is a Taranis X9D+ SE with D16 mode. Receiver is an RX8R.
My flight mode channel is CH8.
I posted this today on a different thread: Plane changes flightmode without any interaction
I will give the Pixhawk 4 firmware a shot. But first I need to buy a new plane :frowning:

@tridge: I attach the log of the flight. Does this seem to be the same failure?
https://www.dropbox.com/sh/qc5dhaqca46kogl/AAD_NEUhue1279R2vTdzKulRa?dl=0

@tridge: is this the latest plane firmware with SBUS fix?
http://firmware.ardupilot.org/Plane/beta/Pixhawk4/

Looking at the release notes of ArduPlane 3.9.4., it says it contains an S-Bus fix. I think it is the “semi-fix” which should be able to detect symptoms by checking the parity bits of the S-Bus data stream. I call it “semi-fix” because it did not address the root-cause (most probably the connection between S-Bus input and serial6 TX - in my opinion a hardware design flaw of Pixhawk 4) and there were still reports about that misbehaviour after the first “fix”. ArduCopter 3.6.5. seems to address also the cause (at least it says this in the release notes) but I can not find an information in the ArduPlane 3.9.5. release-notes about this kind of fix.

Thanks for the info Hacky! I will wait for an answer of the developers. I cannot fly anyway as I first need to order a new fuselage and its on backorder at the moment :wink:

Hello there! I was looking into buying a pixhawk 4, Wonder weather the issue is fully resolved and a stable AP version with fix released.

hi. I also had similar problems with ac but I was using version 3.6.9. I think problem is in Pixhawk 4 hardware. Problem seems to occur after updating AC and import of old parameter set. If I manually create parameters by hand, problem went away. That had happened two times but it occurs, yes randomly.

Problem looks like this in video I did end of last year. This particular event went away by updating missionplanner ?!

So whole phenomenom is really random. I will try to find log files to event for that video today.

Here is topic of crash story with logfiles which destroyed drone pretty bad.

Since the problem appears to still exist: Any information about this?

In case the issue happens again, does anyone know if I could prevent the copter from crashing by turning off the transmitter?

When the issue got reported the first time, I opened up the case on my Pixhawk 4, heated up the soldering iron and lifted up the PA10 pin on the STM32F0 “failsafe” chip - which is the Spektrum DSM input pin. If one doesn’t trust his soldering skills, a scalpel will do an equal job.

Never encountered a RC problem after the mod.

I still think, it is the connection between SBus input and USART6 TX (via 220 Ohm) and not the DSM input which causes the trouble.

wouldn’t it be safer to fix cold joints in oven ? Hmm, just an idea :slight_smile: for example https://community.spiceworks.com/topic/582322-baking-it-in-the-oven?page=6

I actually stopped using the Holybro Pixhawk4, however, turning the radio off will not help to save the drone. The problem is in the FC.
HTH,
Gal

1 Like

I asked help for this Holybro technic support, but they just said to use dedicated arducopter for pixhawk 4. I am tuning px4 currently and no errors after few tests. actual flying attempt will be in future.

Did you ever get to find out if turning off your receiver would help / trigger RtL? I experienced the issue in flight but can’t reproduce on the ground… Just wandering if it’s fixable when it happens again.