I have begun the conversation with the distributor, with same kind of conversation delays as we have here. Distributor will try to reproduce the issue. I will still update our findings here.
Can’t do that now. Will do that during next few months. Thanks for the caution.
As I have said on my last post, we didn’t have SD card attached during taking those images.
We use them always when flying and this should be quite obvious as we had the LOGS there for you to download.
Even tough the software is not most up to date and SD card was not used while taking prints screen of startup info, it has nothing to do with the issue.
Feels like this issue is a joke for you. Thanks for your efforts anyway.
NONE OF THIS IS A JOKE TO US!
You are running code that has known serious bugs that directly affects the safety of your flight!
I have said we are looking into the issues we have raised, and I thank you for finally contacting your reseller, who is actively assisting in the matter.
Our team is looking into the code, and neither Nuttx or Chibios versions of ardupilot do anything but set the pin low.
It is possible that there is a change of timing of when that happens due to the new systems being more efficient, so we are looking at that.
If you could chill with the narrative around the issue, and stick to the exact known facts, we will get to the bottom of this.
I do thank you for bringing it up, it has highlighted that ardupilot is missing some key code on how to safely reset accessories for a transient OC in flight
Thanks for that bit.
Let’s get back to the engineering on this issue, and get some results.
Thanks for taking this under work
I think I have nothing more to add to this for now.
Distributor has my email and I will check this forum frequently if you need something like testing from me.
Hopefully this will further improve the autopilot and it’s resilience to external error sources.
I’d like to add that we may be experiencing the same issue, although we use Cube Black. I described our experience here, but the tl;dr is that our peripheral supply seems to be getting stuck in a current limiting state, even though our draw is well under the limit (<400 mA) and no overcurrent state is logged.
Any tests we can/should do to determine if it’s the same issue?
In any case, we will likewise be contacting our supplier with our test data.
I have read your description and that sounds similar. During the current limiting the yellow flashing turned to orange.
You could verify this issue by having resistor or other constant load of about 800mA on peripheral output. Remove all other peripherals and connect 6 ohm power resistor or other suitable load across the peripheral power supply (Note: Power 4W). Measure voltage and or current on the resistor with multimeter. Voltage should be about 5V at begin and current about 0.8A, after a while voltage will drop to about 1,5V across the resistor and current to ~250mA.
If you don’t mind, I would like to change the title of this to **peripheral power / bootloader/ brownout **
Or something similar, need to get some more software types onto this
In my case, no. It can happen regardless of when the load is applied.
I haven’t been able to correlate the time-to-failure with any factors, such as hot start vs. cold start. The issue often appears between 5 and 15 minutes after boot/load applied, but it seems quite random; I’ve had it happen immediately after applying the load, or never (left it overnight).
Is it possible this is not a new issue? Here is a thread in the archive over at ardupilot.org, referencing low/no voltage on peripherals using a similar bq2431x component, but i assume back on legacy pixhawk and the user reports a crash, so maybe it was physically damaged:
… And there’s another current thread over there in the /hardware/pixhawk section with no power:
For what it’s worth, we have never experienced this issue before (100+ units). It only started happening recently, and on multiple units, so it seems to be a new issue to us.
My experiments:
Attached a load that pulls ~0.8A on the I2C 2 port. Ran trials that consist of powering the Cube Black, waiting ~5 minutes for the current to be limited (or not), then un-power the Cube.
Copter 3.5.7 NuttX: Problem appeared 37/50 trials.
Copter 3.6.2 ChibiOS (and later): 0/30 trials.
Copter 3.6.8 with above PR: 0/10 trials.
It seems that, at least for this specimen, the problem had already been solved by Copter 3.6.x, I guess it gets hidden by different timing on ChibiOS boot, so I can’t really test the PR with this particular Cube. We have blue cubes on hand, I’ll see if I can reproduce it with them.
To me, the mystery is why this suddenly started happening. We’ve flown 3.5.7 since its release and only had this issue appear lately, which suggests a hardware change. It won’t be an issue once we finish migrating to 3.6 (assuming the PR fixes it), but the sudden and inexplicable onset was a bit jarring. Glad @Morso was able to dive into it deeper than I could.