This is a discussion re the bad Accel, Gyro and Baro values that we're seeing with ArduCopter-3.1.  The increase in the SPI bus speed from 500khz to 8Mhz has exposed a hardware problem on some boards.  That hardware problem is that the 3.3V regulator has been blown so all sensors are running at 5V instead of the intended 3.3V.

 

How have these regulators been burnt out?

  • Attaching a radio receiver or MinimOSD to the APM while the APM is only powered through the USB (see video below)

  • Some clone boards seem to come from the factory with blown regulators.  3DR boards might also come with blown regulators although they do a specific check of the regulator as part of the regular QA process.
  • It is not (as far as we know) actually caused by the AC3.1 software itself, it just exposes the problem.  You could prove this to yourself by checking the 3.3V regulator (see video above) before and after the upgrade.

 

How can we fix the regulator?

Option #1:  If it's a new board (so that it's less likely you burned it out yourself) you could report the problem to the retailer that sold you the board and ask for an replacement.  If it's 3DR it's called an "RMA".

Option #2: if you're handy with a soldering iron you can replace the regulator yourself.  On the APM2.5.2 (and higher) boards it's not that difficult.  On the APM2.5 it's far more difficult.

For APM2.5.2 : TPS79133DBVR

For APM 2.5: MIC5219-3.3YML TR

How can I stop it from happening again?

Do not connect any devices such as a radio receiver, MinimOSD, GPS, etc while the APM is powered especially while powered only through the USB cable.

Attaching a 100uF capacitor across any of the APM's radio input's 5V and GND pins will stop the regulator from being blown by plugging in a receiver.  video here!

There are very few reports of regulators being blown twice and no reports of it ever failing in flight.

 

Below are some graphs of the types of values that we are seeing on these boards.

Views: 104637

Replies are closed for this discussion.

Replies to This Discussion

hey guys, thought i would just mention that rather than get the thing repaired or throw it out, just run the APM using a 3v UBEC and it will work just fine

Philip, did any of the regulator actually go to 5V or let the 5V through? Or did all die and output 0V??

I am just thinking 0V leaves you with a dead APM but 5V was still working at slower bus speeds which was the original issue that started this thread. Or is it just random how the reg gives up?

both happened, i bought two apms and they both failed, one to 0v the other to 5v

most failed to 5v, then one to 0v. failure could be either way. so I think it may be random, not a big enough sample size to call it either way.

thx Philip, Jared,

I was just thinking not that it would be a different problem we discovered. Because mine died this week going to 0V - the second one I only smoked and I gave up because my USB port kept shutting down when I also had the scope on it trying to record it.

Paul, you are one of the few around who are not using the tsp79147. I haven't read anywhere in your posts where you repeat the exact procedure that triggers the problem. Philip put the original reg through a lot of abusive tests including just about every short circuit you can think of and it passed all of them with flying colors. Specifically powering up a receiver(probably other loads too) while powered via USB is the Achilles heel. If you can do that a few times without a micro-nuclear meltdown then your mod passes the test.

Also, with respect to the comparison of regulator technical details, the only thing that matters there is real performance. Sure one may be more stable than the other, but who cares if you can't tell the difference when flying? So you can also test that by flying and having some fun! Test out general stability, loiter, and alt hold performance. If performance is good enough for you then odds are it will be good enough for me and the rest of us too.

No fancy scientific instruments needed.

How can we do that?

Hi,

Could someone please help me. I have a quad with a pixhawk on it with 3.2-rc2 (beta) loaded. I have been getting unexpected rtl's on it. well I am guessing it is RTL's, it happened 2 times on this log. the first time when I lost control I hit it to land (one of my mode's) but it never said RTL in the log. the second time (at about 77%) it says it changed to RTL then I hit land.

I am not sure how to tell what caused this, I looked at the rc inputs which look ok to me and the batt voltage is good. any help would be appreciated.

John

Attachments:

John,

     This is very unlikely to be related to the 3.3V regulator issue.  Can you raise in the APM Forum?  Jonathan Challinger should be able to help you find the cause.

-Randy

Well, yeah... I kindof thought I made that clear; the reason I was asking for help is well... I don't really plan to push this thing very hard, and I don't know the product well enough to properly evaluate whether it's REALLY good enough. I don't have the budget right now to do big quads, and my Micro & Nano quads aren't really a good candidate for the APM controller. I really don't have a platform with which to abuse-test it.

I've tested under the same conditions, as best I can duplicate, as Philip showed in his Video. On USB power only, with and without multiple loads, and with and without ceramic caps. I've demonstrated that I can cause enough of a disruption in the 5V rail to make the APM reset just by applying a 20uF ceramic capacitor at the rail. This I thought was valid evidence that what I suggested might be true; it needs a low-ESR ceramic cap (like those commonly used in modern, digital RX) to cause the voltage at the 5V rail to tank fast enough to cause this condition.

My concern was that I could use this on one of my planes, which I intend to do, and have it function perfectly and declare it 100%. But if someone uses the mod on their big quad and it makes the gyros wig out under hard Gs because the power's too noisy or regulation isn't stable enough under light or heavy load, this would be something that could easily be seen and warned about, thereby prevented, with a better scope than I have at hand.

Also, simply having better experience with the product would allow a user to pick up on things I wouldn't know are wrong... going by the example of this failure to begin with, I can guess that a lot of folks were flying this board with this failure and not realizing it for Ifni knows how long, just because they didn't know those occasional glitches weren't normal.

Look... I've made my case, and there doesn't appear to be a lot of interest in taking up my little experiment, so I think I'm just going to let this die. Clearly I'm a lot more excited about this than anyone else is; I've already made a fool of myself, no sense in making a damned fool by pushing it.

Thanks; I think it's time to just move forward with my build. ;)

mnem

:embarrassed:

Hi Paul
Great reply, and fair enough, no one wants to put a uas in the sky to end up with silly things bringing it down.

I found the same, I could reset the APM by adding a cap while powered on. But that was not what the test was about. Two things....
The USB cables I use are not long enough to fly with :)
And the 3DR power module has a nice big cap on it.
This is why we are not seeing this happen in flight.

Many people have been flying with large caps added, as long as your power module can handle the inrush, that's all good
I did some more testing with low esr caps, and though the APM may reset, the reg is fine.... It looks to be an inductance issue. And the Cap is a great solution to that.
I appreciate your input, it has been useful :)

Phil

Detlef, Philip,

I bought this 100uf cap yesterday. I am not sure if this is a ceramic or not; it does NOT seem so. The guy showed me some other small caps claiming that those were ceramic but there was no print on them. I couldn't read anything; didn't want to risk it.

Would this 100uf 16v cap do the job for me if I plug it on A2 input?

Thanks

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service