Cube Orange turned itself off in flight?

We have had a strange occurrence with the Cube Orange (as many others have, unfortunately), which resulted in a catastrophic failure. So far we are pretty clueless when it comes to issue and none of the known problems seem to be related.
Some of the stats:

  • Firmware: v1.11.3
  • Hardware: Cube Orange + ADSB breakout
  • Power supply: Mauch 4-14S Backup BEC for Pixhawk 2
  • 39 flights
  • 10+ hour flight time

Before the flight, there were communication issue with peripheral hardware (I2C, CAN). This is something we can reproduce by powering up the system with low current restriction, but that was not the case. (this should have been a red flag but it wasn’t apparently)

The logger restarted itself twice, without a particular reason, according to the debug messages and log messages.

In the 3rd log, it shows the vehicle doing the following:

  • Armed motors for 90 seconds (don’t ask me why, the pilots don’t remember this but both the AP log as telemetry log show this)
  • Position control hover for 76 seconds
  • Mission start → climb to transition altitude 15 seconds
  • Transition to FWF start 1 second
    After that point the logging stops on both the AP log, and there are no more updates on the telemetry messages (and the machine plummets out of the sky).
    Batteries at 84% SOC, around 23.6V with the power draw, so the vehicle should have had plenty of juice to power itself, yet it seems like it turned itself off entirely. No kill commands were send, no odd RC inputs, no other messages recorded.
    One of our assumptions was the overloading of the breakout board’s power supply, since we have a lot of peripherals, but even shorting the power did not cause in the failure of the AP PSU.
    Anyone have had similar issues or experiences?

@Jeroen_van_Dongen do you happen to have flight logs available of the cases reported above? they would be very useful

Luckily it’s only one case, of which we do have the log, although we don’t want to share that direclty, since we also include a lot of proprietary stuff in there. (yes, I know, it’s not very useful to ask for help without showing anything :wink: )
I can share some CSV extracted from the logs, but it might be easier to see which are useful.
Some other points I can add:

  • there has not been a hard fault log, so that could be excluded.
  • No error messages in the debug messages or performance counter anomalies
  • All electronics are functioning after the crash (AP, power equipment, peripherals etc)

Again, sorry for being so vague, but there is quite a bit of confidential information in there. If there is a way to remove certain things from the ulog I would be happy to share them, or I could share the specifically required fields by extracting them.