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

Replies are closed for this discussion.

Replies to This Discussion

I'm anxious to learn the results of your board's transplant surgery!

I haven't had the chance to fly out that far.  But since you mentioned it, I'll do some on ground range testing this week as a precaution.

I count on my RTL feature - never tested the range of my TX/RX. It actually works pretty good. I did the testing already the other week by turning off the transmitter completely :)

Was a bit of a setup hassle to activate RTL and later safely take over control again because during startup the FrSky receiver outputs all channels except throttle somewhere at middle possition - independent of what you taught as RX failsafe. The problem is the APM changes flight modes as soon as it sees a change on the mode selection channel. In my case that startup value was my ARCO mode value and that with "0" throttle - would have been a nice plunge.

I had to rearrange my modes so the RTL mode equals the startup value of the RX. So when I come back in TX range or turn on the TX the APM stays in RTL mode and does not go crazy.

Great point on the mode change. Is there a way to delay the mode change in APM to about the length of time it takes a three position switch to go from one extreme to the other in one quick motion? 

I don't think it switches modes that quick. There is a certain delay in there. But when you loose connection and when it is reestablished the FrSky RX puts all channels to middle and throttle to zero for aprx 3-4 sec before it goes back to the real values that it gets from the TX.

You can easily simulate that in MP with the TX calibration screen and check where your values go if you do turn off the TX and back on. There you can look at all channels from RX failsafe to startup to full communication.

In my case throttle failsafe and RTL all would have worked fine till I turn the TX back on. Then I would have been for 3-4 sec in ACRO with zero throttle.

It also depends out of what mode you loose connection - I guess its a timing thing. If my mode channel changes (RX failsafe position) it sometimes overrides the throttle failsafe that activated the RTL (in MP red RTL means throttle failsafe - a white flight mode means it was activated by the flight mode channel). So I put everything at ~1500 as RTL mode, RX failsafe for flight mode channel, and startup value is already anyway at ~1500.

Good to know.  I mainly fly within a 100 yard area for now.  I'm leary on setting any failsafes until I can trust the APM/My settings to do as expected.  I've had a couple close calls where I placed it in a mode and the result was not expected. I've even had it chase me when I tried a short mission - but that was because I mounted the compass backwards!  As you can see - noob here!

A learning experience! If you look at my first Penguin flight on youtube I had the board orientation parameter wrong and my HUD was always tilting the wrong way and I couldn't figure out why. Somehow I managed to reverse and invert all other things correctly that it would fly that way. LOL

The replacement for the Penguin is now the quad :) But we are getting there... and Bixler is already sitting under the table!

Ok, I am back in business! Seems like the APM did not mind the birth defect of 5V on the 3.3V rail. I loaded Randy's test firmware with the error counter and SPI0 stays at high-speed "1" and counts "0" errors:

Double checking my power during USB power-up looks good this time - the 3.3V stay at 3.3V:

I know there are concerns of 5V on the 3.3V rail damaging components but so far it flew for 2 months with Arducopter 3.0.1 without any problems and now with the 3.3V fixed it will go as ArduPlane into a Bixler :)

That's a good news Detlef. The 5V is a bit scary, is it your ESC that is doing this ? Do you have a mechanical switch after the ESC ?

For good CPU starts, the power voltage should rise in a monotonic curve shape. I think that it's not really critical for the AVR but this kind of power start can cause lockups at boot up on sensitive devices.

Olivier

No, its my USB port that is doing that and it changed since I replaced the 3.3V regulator on the board. I powered it up a few times because I couldn't believe that this drop after the initial rise to 5V is normal but it is there every time I plug it in. Below is the same USB port powering the same board with a defect 3.3V regulator. Only the time base on those scope shots is different old 20us (below) & new was 40us.

But I think that drop is related to the new working 3.3V regulator firing up now. Before 5V and 3.3V rise together - now with the working 3.3V the 3.3V curve comes up delayed and that's when the 5V gives in a bit.

I didn't check my ESC what that would look like.

I wouldn't do that since most UBEC are switched which brings probably a lot of unwanted noise onto the board. Besides that a UBEC is overkill by amperage values. If you don't trust the little fellow on the board then get a bigger linear regulator that you patch in.

Detlef,

     Well, that's very impressive that you replaced the regulator.  I almost wonder if it's worth posting a couple of pictures of where to find the regulator, a link as to where to buy a replacement and how to replace it.  Of course you've already done it now so I should have thought of this earlier.  I suspect that we will find a many more people with this issue when AC3.1 goes live.

RSS

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service