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.
Replies
on left picture I have 3.3V in vertical row,but not in horizontal i2c row
And my GPS 3DFix blue led is always solid on,it does not matter if gps is connected or not..i tought gps does not work but actually it does,problem was internal batt of gps was empty..after exchange all is good except that led..
If you have 3.3v at one place but not at other measurement points that should be 3.3v then there is a good chance that you have a cracked or bad solder joint somewhere.
Hey Joe, where you goin' With that gun in your hand?
peace
https://www.youtube.com/watch?v=4VxMDwYfxvQ
I am not businessman but common logic tells me that for 3DR reputation would be better to hire some professional help to find what is the problem,it is not nuclear power plant electric circuit and should be possible....
maybe 3DR can offer some award for the one who find problem ;-)
Emin,
I'm sure they've had some professionals look at it to some extent at least. The reward is a good idea and I'd actually had the same thought myself. I'd been thinking a new Pixhawk and a replacement APM2.5 or 2.6 would be good.
There's some risk that it'll cause more harm than good as people who don't know what they're doing might start blowing up perfectly good boards in the search of the cause. Anyway, I've passed on the suggestion 'cuz it's certainly worth considering.
I figured out how to blow the reg on my board. A little background, I initially had a bad regulator that I replaced. The replacement only functioned intermittently. I cut the Vcca and Vccb lines of my dataflash translator chip to troubleshoot my issues so I know that particular chip has nothing to do with blown regs.
To toast it, I first have to power the board via usb with all peripherals unplugged. JP1 removed (probably not relevent). Then if I plug in my receiver on the input rail, even for a split second and then remove it, the board appears to over the course of 2-3 seconds go into a latch-up or runaway state of some kind. The alive led will dim and if I keep it powered up long enough, smoke will come out of the reg near the 3v3 out pin. So far I have been able to remove power fast enough to prevent permanent damage as far as I can tell but I can confirm with 100% certainty that this procedure has resulted in white smoke. The brown-out caused by suddenly powering the reciever must be causing it. My board is a HK clone.
I blew the 3.3v regulator my RC-Timer board exactly like this last week!
1) Conneted the board to my Lenovo E130 PC, nothing else conneted, JP1 installed.
2) Booted up ok, communication with Mission Planner (USB) ok
3) Conneted one servo lead to my receiver (Wfly 7ch)
4) Noted that the LEDs on the receiver AND on the board suddenly dimed
5) Disconnected USB and everything else, no smoke, no smell
6) After this event, 0.0v on the 3.3v pins and "No dataflash inserted" in the CLI. No contact with any of the sensors running on 3.3v (from the CLI, in test mode)
I also noticed in my experience that repeating the process once the reg is blown merely initiates a reset. If the 3v3 is shorting to ground, what path is it taking? I think there is a pnpn junction in the flash level translator chip. I wonder if that has anything to do with it. If that junction goes to a latch up state and the reg fails before the translator chip fails then it is possible that the translator chip comes out of the scenario undamaged. The failing reg would remove the current source and stop the latch up. Replacing the regulator would fix the problem and the board would operate as normal until another latch up is encountered. Just a hypothesis at this point... I wonder if the behavior changes depending on the firmware loaded? Why would these issues crop up starting with 3.x?
The problem didn't start with 3.x, it was only revealed with 3.x.
My blown board was blown on 3.0. But at the time, I only had the dataflash error, and we didn't know what the cause was. It wasn't until 3.1 came, and this discussion started, that I pulled it out of my junk box and discovered the root cause of the dataflash error was the regulator.
The big question that I am trying to figure out is what is the root cause of the failed regulator? I don't think the regulator is responsible for its own failure.
-
24
-
25
-
26
-
27
-
28
of 56 Next