RCin and RCout freezes (becomes flat line) during flight leading to crash

Hey folks!
I’m new to this community, and excited to be here.

I’ve been flying an Alien H4 Quadcopter with Pixhawk Cube Orange
ArduCopter Firmware Version V4.1.5.

I’ve flown it few times earlier too with no issues as such.
The only change since then was that I had completed until AltHold Testing from this page here in Ardupilot docs.
There were no problems and AltHold worked well.

The issue occured in AltHold mode on the next flight.
It wobbled and dropped after raising the altitude to 30m.

Initially suspected a Motor/ESC fault, because one motor did act a little twitchy after the crash, and in the logs, it was the same corner which dipped first. However, once dismantled and bench tested it, motor was concluded to be good.
Another reason to eliminate motor issue is that the autopilot did not increase RCout to that motor during the dip.

This lead to the findings for another reason for the crash: Both RCin and RCout (CH1,2,3,4) all became a flat line and froze to their current values right before the stability was lost.
This leads me to believe that the crash occured due the autopilot freezing the inputs given to ESC to a constant value.

Log file: file on drive
RCout froze at 18:17:48.563 and the extreme roll and pitch occured right after.


I would love some help and expertise on:

  1. Am I correct in locating the error as the frozen Rcout which caused the crash?
  2. If yes, Why did it happen? There was NO event triggered during this time frame either. How to make sure this doesn’t happen again?

Again, I’m new here, so might be missing some basic stuff too, any and all help would be appreciated.
Thank you.

1 Like

If you are using a LIDAR I would strongly recommend upgrading to latest copter 4.2.3. as there been some issues in earlier versions.

Noted, we will do that. However that can’t be related to this crash right? Because we were way out of Lidar Range and Altitude was estimated based on Barometer by Pixhawk itself.

I saw your logs and there are lots of spam messages from CAN device ID 125… What is this device? Maybe this could be related to the crash but I am not sure…

That’s a Here3 GPS Module connected to CAN port of Pixhawk.

I’ve used here3 for a long time and never saw these message spams… maybe you ran in some kind of trouble with it (really don’t know if it can be related to the crash or not, try to check a prior good flight to evaluate if the messages were always there).

1 Like

Update your here3 firmware ASAP.

1 Like

Another lead I have is the IOMCU NPkt & TS stopped right before the uncontrolled descent.
That means the IOMCU stopped running which could explain the RC in&out freezing. Would love to get some info on why IOMCU stopped or any other data on how to prevent this?

Note: Not sure if it matters but Vcc Voltage to board also dipped from 5.16V to 5.09V right before the uncontrolled descent. It never dropped during normal flight. Hence found this suspicious.

Will do, thank you for the advice. Still can’t tell why the IOMCU co-processer shut off.

There is some irony in that. The IOMCU is supposed to be a back-up processor for when the main IMU fails… In reality it’s just an annoying piece of hardware that won’t run Dshot :slightly_smiling_face:

Thats interesting. I read on the docs that it’s a co-processor which manages the MAIN pins. Hence I thought that it was the reason for the crash. Should we consider otherwise?

Yes right. The Aux outs are directly from the Main processor or FMU outputs.

So is there a way we can point out what caused the issue? And how to proceed further?

  1. Just try flying again and see if it happens again

  2. Try to fix the IOMCU somehow (no idea if it’s possible

  3. Replace the entire flight control unit.

I hope to get more details on the following options

I suppose I would update to latest Stable version of firmware and fly a pack at low hover and see what happens. Did you try posting on the Cubepilot Forum?