Amount of log time lost before autopilot shutdown?

Not quite sure if this is even copter specific, and it’s definitely not specific to a specific sub version of arducopter at least (seen on 4.1.x and 4.3.x at least).

I’ve noticed from a few recent crashes we had the logs just abruptly ended in flight, and did not capture much or any of the actual anomaly or subsequent fall to the ground.

All of the other crashes I’ve investigated were not bad enough to actually cause the flight controller to reboot or turn off on impact, so it was very easy to even see the moment it hit the ground up until the pilot disconnected the battery manually in the log.

I know that the common explanation here is that there must have been a power loss to the autopilot mid flight, however in both cases everything was still powered on when the drone was found, and the battery voltage and VCC measurements did not show much evidence for a brownout. (And I’ve tried to recreate a possible power hiccup on the recoverd, but in no way repaired drones without success)

Although I don’t expect it’s unreasonable that there could have been a power transient or other issue that rebooted the flight controller on impact with the ground. At least one of the said crashes was a fall from 50m.

Anyways this isn’t about those particular situations, it just got me thinking about how much time is needed for an event / measurement to make it to the data flash log and still be readable.

I did a very unscientific test on the bench (without props of course…) where I had a drone thinking it was flying and I pulled the battery, then reviewed the subsequent log. It looked like several seconds of the “flight” leading up to me disconnecting the battery was missing.

My question before I start doing more testing is, is this expected behavior, and if so what is the expected “delay” more information to make it in the log? If it is indeed several seconds is there anything that can be done to reduce that latency and preserve more critical information from a crash?

Without going into the logging and so on, your power transient comment made me think a bit.
I wonder if an out-of-bounds voltage is causing the internal voltage switching and protection circuitry to shut off. This would be instant and not allow the FC to continue monitoring.
I know in voltage regulators these days everyone uses SMD ceramic caps since they are “Low ESR” and small, but a good old fashion electrolytic on the 5vdc from the regulator to the flight controller power inputs would probably help. And maybe give an extra fraction of a second for something to be logged. 47uF 16v, or even up to 100uf if the regulator can handle supplying the inrush.

And a TVS diode across the input to the regulator? Although serious spikes on the input should only be a problem when first connecting the battery, not so much inflight - except for the ESCs giving back some power during decel of the props.

1 Like


I have been thinking along those lines. I’ve even gone through and looked at the cube PSM schematic and read the data sheet for the power path selector IC they use. If the voltage on power one is within bounds it should always use that even if it’s lower than some of the other voltages connected but I don’t have any way of verifying what the bounds are configured as on any particular board without doing a lot of desoldering and finicky measurement of 0402 or smaller resistors (used to set the “power good” boundaries on the IC).

For the next carrier boards I build I’m very likely going to implement the PSM functionality in my own circuit and that will be a convenient time to try to add some extra capacitance in as you mentioned. I will also be able to break out the different signals and monitor the voltage going directly into the cube with a separate microcontroller whose sold job it is to manage and log the state of the power systems on the drone.

I also want to implement two small buck converters who’s only job is powering the cube, and the cube alone and they are not going to have anything to do with any peripherals.

Even though there’s no way to verify it with the logs right now I can’t rule out that the payload (which is something that is not made by me, and generally a person who is fairly new to building electronics) may have caused some sort of power transient temporarily knocking the flight controller out.