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.

3691073788?profile=originalFor 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.


You need to be a member of diydrones to add comments!

Join diydrones

Replies are closed for this discussion.


    • Developer


          Updated!  look ok?

      • looks good :)

        • Detlef, Philip, Randy,

          Is the 3300uf cap iskess linked above same or better solution than using 100uf ceramic cap?

          Do you guys have an answer for this?

          Never mind guys. My question is answered below. When I was posting my question, the below posts were on the next page and I didn't realize...

          Going with the 100uf cap. for sure if that is what we need...



          • Alex,

            independent of APM or not if you you need such size capacitor to protect you against brownouts then I would rather opt for a bigger/better BEC in your RC system. If you believe that a big size capacitor helps to safe your model with issues in the wiring like a bad contact - then such things show up when it gets that bad that the capacitor will be not be big enough no more to buffer those connection failures. Because before you won't notice that you even have a wiring issue.

            Besides that it is during power-on at first a full short circuit for your power system in my opinion size is not helping unless you have a real odd load with occasional high currents on your RC system that you want to smooth out. Whatever load spike you pull out of your buffer capacitor your BEC has to put back in it the next moment.

  • Developer

    Hi All

            After much delay.... we have some news :)

    First the problem.... we all know that. 5v on the 3.3v rail. but how? 

    there were a list of suspected causes of the failure of the 3.3v reg.

    1 plugging in a UBEC backwards on the RX rail. no issue, as the center pin is 5v, couldn do damage this way.

    2 connecting the 5v bec to the power pins the wrong way around, ie 5v to ground, 0v to vcc. could be done... and in testing this, vcc3.3 dropped to -0.3v

    3 Servo noise on the rail.  quite a plausable one, this was my prime suspect.


    And as can be seen in the scope trace, the 3.3v jumps whenever the 5v rail goes above 6v. however, there was no sign of permanent damage. (this also assumed the onboard zener was damaged, simulated by removal of the zener.

    4 direct short of the 5V to ground.


    this had the obvious effect of shutting things down, and showed the 3.3v rail could hold above the 5v rail during shutdown for around 11 ms at 6-700mv above the 5v rail.

    But again, no matter haw many times it was repeated, the failure did not come.

    6 short of 3.3v reg to ground.

    Again, no issues, it handled it well.

    7 5v connected directly to the 3.3v rail via a faulty component.

    Again, the reg had no problem with 5v on both sides.

    and the Most rediculous suggestion of all.....

    connecting a receiver while powered just by the USB could do it......

    surely not I say....

    watch the videos in order... the first showing the most unlikely to be the actual cause

    the problem repeated

    the second eliminates the u32 PPM encoder from the equation (as well as the level shifters)

    reducing the suspects

    and the third :) a solution a simple 100uF ceramic capacitor across the 5v rail

    the solution

    but the problem is still a problem.... WHY? what is it about the receivers that cause this. as you will see in video 1, it is not a large capacitance causing an inrush.

    theories are welcome.......

    Another note.... NO FIRMWARE WAS ON THE BOARD.......... this is a hardware issue, it is not caused by 3.01 firmware, but 3.01 shows the error if it is there.

    so, to mod your board to reduce the risk of this happening? connect a cap to a old servo cable, between the blac and the red. use a ceramic cap, 100uF and plug this into Analogue 2 (if not used) make sure to remove the signal wire.


    and finally, thankyou to 3DR who sent me 3 brand new, factory blank APM2.6's for this test.

    • Can you try shorting 5v to ground through an inductor?

      One more thing for any 3DR guys listening, this may be a good time for a PSA announcement warning against plugging in peripherals while powered up.

    • Interesting.  I actually have been putting capacitors on most of my boards already.  I often leave the Input rail unpopulated, since I us PPM Sum, which leaves some convenient Vcc solder pads empty.  I just solder a cap directly to those rails.  I had done it just to protect against the possibility of power supply problems due to contact bounce due to vibration.  Just seemed like a good idea.  

      I'll have to check, but the one that I have that is failed, I don't think I added the cap.

      Did you by chance check to see if the diode between 3.3V and 5V would protect against this failure?

      Would be interesting to find out if plugging anything else in while it's running would cause the same fault (GPS, Mag, etc).

      • Hi Rob,

        I can confirm you that it breaks the regulator with the minimOSD on the telemetry port in the same way and Philip replicated that test with the radio on the telemetry port - for him one out of 10 times it failed the regulator. I did it twice in one evening with the OSD. If you are quick enough disconnecting power you can save the regulator. 

        What I am wondering is if using USB power is more common to create that failure than as if you use 3DR power modules or BEC. At least for me I've hot plugged stuff plenty of times while on battery power and never had an issue. But I think most stuff dies on the bench with USB power.

        • Which power source does the APM use if USB and 3RD power module connected at the same time?

          • It uses whichever has the higher voltage and if voltage drops due to load the stronger one takes over.

This reply was deleted.


DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord:
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: Another incident:
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: What a great way to connect why @diyrobocars community is so valuable and important! Have to start somewhere @IndyAChallenge…
Oct 23