probably the battery rail came loose 
The only strange thing was that during free fall the external LED was still green (seen on my recorded video), so I’m not sure. Maybe someone can take a look.
2019-12-17 16-28-21.bin (936 KB)
Following log please ?
It might have been the I2C storm again…
Hi @webmotions
It seems that there is problem with battery
your battery voltage suddenly droped and copter was underpowered
1 Like
Your battery voltage and current consumption went down right before everything else went south.
Looks like a LiPo sensor meltdown.
1 Like
The LED was still green because the FC still had Vcc power right into the ground.
1 Like
It’s not that easy. If it had power, it should’ve logged all the 170m of uncontrolled descent…
I have encountered a similar behaviour twice, on 3.6.9, with two different machines. Both hexarotors. One was a Cube Black that lost a motor, and was ultimately nursed down on 5, in stabilize, with little damage. It was reported reacting OK to manual control, but the log abruptly ended right after the motor-loss event, with one maxxed out and the opposite at idle. And the physical motor issue was identified and corrected in the workshop.
The second was an older Pixhawk build, with a chute fitted. The logs also end up straight after recording a seemingly motor-loss event. It didn’t deploy the chute and made a hole into the ground. All ESCs are functional, , motors were pretty banged up, but spinning, etc…
No logs is only wild guessing.
I don’t see 170m of uncontrolled descent. ~6m and it lost power and rapidly descended ~2m and the log quit. But you have a good point that if Vcc was good, which is was when it stopped logging, it should have continued to log.
I agree it looks like a battery problem although it also displays symptoms of a motor failure. In particular it looks like motor 4 (back right) stopped first.
So the graph below shows the RC outputs and we can see motor 4 goes high and the opposite motor (2) goes low.
And here is a graph of the desired and actual attitude and we can see it rolls right (green line goes positive) and pitches back (orange line becomes negative)
I think it’s safe to assume this is a hardware/frame issue because we do see some falling. If this was an I2C storm then we wouldn’t get that I think… because the I2C storm would cause the lock and crash whereas here we see the start of the crash at least. Anyway, as @Andre-K says if you can find the next log we can confirm for sure.
Sorry about the height thinghie… was graphing AHR2.Alt instead of Baro. 
The loss of power happens before AP starts reacting, trying to push the motors harder.
After some in-depth research and with your help, it can be said that the first event was the voltage drop (about 0.2 seconds before motor 4 fails). We were able to reproduce such voltage drops with a loose XT60 connector and therefore assume that the locking of our battery rail has come loose. Thank you very much for your help!
@rmackay9 @Andre-K what do you mean by the following log? The battery was disconnected by the impact. The damage was fortunately small so that we could test yesterday still another indoor flight in stabilize mode without any problems. Today we flew 10 minutes in PosHold, also without any problems. Do you mean the log files of these flights?
Yes the the next time ArduCopter boots up, the log would show if there was a lockup or watchdog event before the last shutdown. But I think this is pretty open and shut anyway as a battery or battery connection issue.
That’s the log file after the crash. Flown in stabilize mode indoors. How can i find the watchdog event?