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: 106057

Replies are closed for this discussion.

Replies to This Discussion


     If you were on AC3.0.1 before the HUD moving around could be caused by:

            1. the gyros and accels are getting bad readings which is normally caused by a bad 3.3V regulator.

            2. if armed the HUD tends to move around even if the copter is not moving because of the centrifugal force correction which uses the GPS signal.

     I'm pretty sure that it's not the software that is killing the regulators.  It's the higher bus speed that we use in AC3.1 (because this saves CPU time) that is exposing the existing problem.


a) We're not exactly sure of the cause of the 3.3V regulators being blown but we don't believe it's caused by the software.  We think it's an existing condition that just being exposed by the higher bus speeds in AC3.2.

Some boards may be broken right from the factory or I've heard you can blow it by connecting the JP1 jumper, then connect an ESC cable upside-down and apply power.

b) we haven't had any reports of people blowing the regulator again.  It's probably possible to do if you attach the ESC cable upside-down with the JP1 jumper in place though.  We also haven't had any reports of it failing in flight.

Have you checked your board to see if the 3.3V line is really 3.3V?

The software only shows the effect of a blown regulator but its not damaging a working regulator.

With the fixed regulator its working with 3.1. I used the original part number as posted here: a stronger version should be this one: MIC5219

As I posted earlier I use an external compass adding to the 3.3V load and the 100mA original part works fine for me. So out of my experience a stronger one is not needed but probably would not hurt.

While writing this I was wondering about power consumption - my complete APM setup draws 110mA and that includes 3DR power module, APM2.5.2, uBlox GPS, minimOSD, external compass, FrSky 6ch RX, and Airspeed sensor. (I was too lazy to pull it all apart) 

So out of that total 110mA how much do you think falls on the 3.3V side? Maybe 10-20mA at the most if I guess...


Hi Randy, have watched many of your videos, read many of your articles to get this far. Jabram's posts have been a staple as well. What a passion you have for all this! Been pretty much a reader until today. On 3.0.1 the HUD was stable, it was the VSI that would jump around just sitting. I took it outside, let it sit after getting GPS lock and watched it and the VSI would be fairly stable but occasionally would jump a bit.  Everything else was pretty much rock solid. I do know at one time the 3.3 volts was good, it's possible I've blown it out somehow before upgrading and like you said only showed up with the faster bus. New parts on the way, I'll fix it in a week or so. I just want to fly the thing and do all the cool stuff this board is capable of doing. Merry Christmas! 

I have a few 3DR APM but they are all 2.5. The other day i upgraded to 3.1 and got the bad health.

I also perviously used to use a sonar but noticed it periodically got spikes in its height measurements. I have also cut the bridge to the internal compass. Im just wondering if my unreliability for the sonar(its not removed and in a box) was due to the bad 5v and not 3.3v ? DOes the sonar expect 3.3 ? I noticed in my logs the spikes from the sonar seemed to be sort of periodical, they were not really random and seemed to be equally spaced.

I've updated the main intro area of this discussion to highlight the video and hopefully get people to the main answers they need quicker.

Detlef (and others), please tell me if you think of some more details in the intro that would help.  Thanks for your help!


     The sonar problem could be related but I'm not sure.  In terms of power the sonar uses 5V but the reading of the analog voltage from the sonar is done by the main Atemel2560 chip which runs at 5V so it should be ok.  It's more likely to be with the power supply being sent to the sonar.  You've read the wiki page on preparing the cable of course?

     Have you already upgraded all boards to AC3.1?  If not could you check the 3.3V lines (according to the video) before the upgrade?

Sorry for the troubles!  We tried a software solution to automatically downgrade the bus speed and that code is actually still in AC3.1 but we couldn't get it to work reliably.  We would have avoided the problem if we could but we really need that extra CPU time on the AVR 'cuz it's really really at the limits of it's abilities...perhaps a step or two beyond.

EDITED *again*

I recently bought an external compass and installed that with the problem apm described (it shows bad gyro messages with 3.1) above. Measuring the vcc and +gnd pins i get 4.7 while powering thru the usb as we speak. This APM is about 6 months old and is a 2.5

My hex which has an APM about a year old, and has never had 3.1.x and is currently on 3.0.1 measures 3.3 on the external compass.

My plane which has an APM which is approx the same age as the first above measures 3.3 but it has never had 3.0.1 and of course runs Arduplane 2.74.

The last 2 voltage measurements are strange i would have expected them to match, since im pretty sure i got them at the same time, they might even be batch brothers from the factory. Seems odd the 3.1 copter now measures 4.8 but the never had 3.1 measures 3.3v. Hard to tell from such a small sample but they are the same age from the same order i think.

Thanks for some answers Randy .. I have not checked the reg yet .. I intend to, as I have three copters in the workshop being built .. and was also waiting for a stable 3.1 to be released .. So before I up load 3.1 i will check each board before and after , one is a 3dr .. the other two are Rctimer.. I have about about 7 copters running about the contry side, I best check all of them one or two are version 2 boards, My main concern was, if it blew why ? and will it do it again..?  I guess as more info comes through we will all know the answers.. Thanks R

Great idea!

Looks complete to me unless you want to mention the MIC5219-3.3YM5 as alternative since it keeps coming up

added, thanks!


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service