Second flight and a brownout with crash

Yesterday evening I was doing some testing with my Tarot 650 Sport quad.
And I made a series of mistakes, first didn’t enable logging of all data, second my rudder switch was set to AutoTune on the Pixhawk and in the same time connected to my receiver for switching between the two cameras I have onboard.

At some period of time I switched for a short period to Alt hold, then stabilize, and then probably switched to the second camera.
The sequence triggered AutoTune, which I was not aware of as I was controlling the quad as it was near a tree.
The moment I released the sticks AutoTune kicked in, and it seems to me that there was a brownout as it just shut down everything and fell of the sky. Fortunately I was flying relatively low so the fall just broke the skids which are already replaced. I am not an expert in analyzing the log, but it seems to me there was a sudden change in throttle input which I don’t remember I did (had no reason for it) which resulted in a extreme drop of battery voltage under 9 volts.
I checked the batteries after and all four cells were at around 4.01-4.02 volts.

I admit I made mistakes that lead to the crash, but would like to know, if possible, why was there a brownout?
Should I blame the batteries (Multistar 8000mah 10C)? Or there was something else?
I am attaching the log of the flight.

Without logs it will be difficult to tell. And even then you say: “And I made a series of mistakes, first didn’t enable logging of all data”. You don’t necessarily have to log ALL data, but pertinent data is helpful. I’ve found that logging all data in the Pixhawk can overload the CPU. I strike a decent balance by setting the log_bitmask to 10230. That’s usually enough to be able to diagnose but not so much that it bogs the CPU. Essentially you log everything in this mask but the deprecated items and performance data (which I find a little frustrating with the long loops and all).

Brownouts can have multiple causes, obviously.

Sorry, I uploaded the log the first time without checking the result, so I did it a few more times, just to find out that it landed in VOID :angry:

So here is the link:

Trying to figure it out by myself I found out that something weird happened with the voltage just before the fall.
It was going up and down way more than usual.
I don’t know what caused that but it seems to me that the 10C Multistar batteries I have are just not up to the task.

Thanks BigTulsa for the advice of setting the log_bitmask to 10230.
Will do that.

Yeah I had one of those 10kmah batteries and they never really gave me problems but I didn’t task them really hard either. I have heard of issues with those. 10C is not a lot of battery punch so likely under load voltages will sag a lot more than say a 25 or 30C battery will.

I’ve used them a lot. They should really be rated at 2C. Even a few seconds at 5C can cause them to puff. They have huge internal resistance, and the voltage drops very badly under load.

Interesting. I’m pretty sure I used them pretty hard at least at 5c for more than a few seconds and never saw them puff.

I was using them for about a year almost without problems.
The only one problem I had was with one of them which arrived with one bad cell and was replaced.
But I did notice that in order to Auto Tune my bird, I must do it one axis at a time with the batteries fully loaded.
So I agree with Rob and will get rid of them as I already bought two 8000mAh 30C batteries.

Thanks for testing despite the crash!

I had a quick look at the logs and I basically agree with what’s been said above but some additional data and clarification below.

The cause of the fall is not exactly a brownout because, as far as I can tell, the board keeps logging until the moment of impact. It looks like it stops at the moment of impact though because we see a final massive spike on the IMU.AccX, Y, Z.

It definitely looks like some kind of power failure to the motors though (i.e. battery failure) because the total throttle output goes to maximum but the vehicle falls. Sadly we don’t have the RCOU messages so we can’t see what’s being sent to each motor but we can assume that they were all near maximum too.

By the way, I’m not sure if logging can slow down the CPU on a Pixhawk. I might but personally I haven’t made that connection. You can check the load on the CPU by looking at the PM (aka Performance Management) message. So you can see the “NLon” column which means “Number of long loops” which means the number of loops (out of 4000) that took more than 3ms (2.5ms is the ideal) and “MaxT” is the Maximum Time that any single loop took. Nomrlaly this is between 3ms and 4ms but occasionally we see a MaxTime of 10ms~12ms. We’re not sure what’s causing this but heck, it could be the dataflash or some other I/O process that’s locking things up.

1 Like

Thanks for looking at the log and for the explanations.
I am now pretty sure it was a battery problem.

It may not affect in-flight performance (heavy logging that is), but I know for a fact it does affect some telemetry items as I have a craft and theory Taranis module and when I did accidentally have almost all logging set, the HUD and other items froze up or were slow to respond. I switched back to my default mask (10230) and it corrected the problem. But even the wiki states that lots of logging is cpu cycle intensive. And when in that state, a log that otherwise for me would have been about 2mb in a bin file wound up being over 70mb.

I’m just saying be selective when logging. You don’t need everything, but rcin/rcout are definitely required. Compass and IMU are a suggestion as well as they can surface problems that you might otherwise not be aware of.