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?
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 are closed for this discussion.
Could you give this modified binary a try? It's meant for an APM2-quad and Tridge has added some detection of whether the barometer is returning errors and if it is it should reduce the speed of the bus to 500kHz.
Curious to know, what was the exact problem of having increased the SPI bus speed to 8 MHz and when does this happen? I saw the z-acc reaching 0 when battery plugged, as per your first graph.
Here is the log for your new binary. I did a erase and reset before I started and during the log a ACCEL calibration.
and a second try... with the board just sitting still on the desk
So for most people increasing the SPI bus speed doesn't cause any problems and it saves some CPU time but for a few boards, we see errors in the values being returned from the mpu6k (accel/gyros) and the barometer. From the user point of view the HUD on the dataflash screen in the mission planner just spins and spins.
That's interesting. I had a board that did that occasionally 1 year ago. I think it had been dunked in a lake at some point...
Wait till Bruce gets to it :) I think mine is the little version of his jumpiness... LOL
PS: I did yesterday the first autotune flight with my quad and 2nd board, worked like a charm! Was just too late and too quick dark to do much test flying. Feels allot better than my manual tuning, that's for sure.
I appreciate this Randy. I'll be testing this morning remotely without the battery(I'm at my day Job as an IT sys admin) - A battery plugged in test will be done about 8.5 hours...... Stay tuned!
The new changes from Tridge include an inertial nav health flag so we may be able to catch some of that before arming...if it happens enough times before arming.
Maybe try this one instead. It's pretty much identical but it will print out some debug to the console and also to the dataflash log (but not to the tlogs). It should display lines like this in the console:
So that's saying that SPI0 (the one where the mpu6k is running) is running at high speed (1=high, 0 = low) and has seen 0 errors so far. If it works properly on yours you might see what's below which shows that it's dropped the speed automatically to low-speed and is not seeing any errors.
Will do. I've also been looking really hard at my broad voltage and I'm not happy with it. It's low - hangs around 4.7, but it's also noisy. Thanks again!