BMP085 sensor value stop update

[haley0918]

Hi all,

I'd left my flight controller running for long time and connected to the GUI. After more than an hour, the BMP085 suddenly just stopped update. Mag, acc, gyro and GPS still work and there was no I2C error.

My flight controller consists of an Arduino Nano with Allinone by CSG_EU and another Arduino pro mini with MTK3329 GPS for I2C GPS.

The BMP085 just suddenly stop at one value and I have no idea if anything is wrong with the sensor, Multiwii or the GUI itself. Although I only notice this happens after an hour, I fear that it might happen within my 10 minutes flight time.

[haley0918]

Now I had acquired another 2 flight controllers from Hobbyking. They are:

1) MultiWii 328P Flight Controller w/FTDI & DSM2 Port http://www.hobbyking.com/hobbyking/store/__27033__MultiWii_328P_Flight_Controller_w_FTDI_DSM2_Port.html
2) Multiwii and Megapirate AIO Flight Controller w/FTDI http://www.hobbyking.com/hobbyking/store/__31138__Multiwii_and_Megapirate_AIO_Flight_Controller_w_FTDI_ATmega_2560_.html

The same thing happens, even on MS5611. To narrow down the location of the fault, I had the flight controllers connected to the GUI by bluetooth so that they don't reset when I close down and reinitialize the GUI. Turns out the fault is actually located in the MultiWii code. Not related to hardware and the GUI. Also the fault seems to occur only after more than 1 hour, sometimes extending up to 2 hours.

This is what I could report so far. Will spend some time later going through the code to find out the bug.

[gotchafr]

Hi,

I don't know if this topic is current or not, but here is my little experience.

I am currently testing my first board. It's a Crius AIOP V2.0. I am having the same problem, among others. The others are may be related, but I have't figured it out yet. In any case, this seems to be same problem: http://www.multiwii.com/forum/viewtopic.php?f=8&t=2007&start=20#p18398

Indeed, it stops after 71 minutes indicating a uint32 overflow. Are you sure this happened after 2 hours without a reset or something?

This is what you find in the Sensors.ino file in the Baro_uodate function (taken from 2.2, but 2.1 is the same:

Code: Select all

  if (currentTime < ms561101ba_ctx.deadline) return 0; 
  ms561101ba_ctx.deadline = currentTime+10000; 

When it alt freezes, did you notice any other "stange" thing such as incorrect or frozen values? Were the RX signals correctly decoded and outputs correctly calculated?

Have you tried to let the board run for more than 71 minutes and then connect via MSP (BT or GUI?) I have the impression this is related to MSP...

[haley0918]

Hi,

Yes, in some trails I'd had it over 2 hours before the freezing. I did a number of trails with their time recorded each time and some of them went over the 71 minutes limit as you said.
If the error was caused by the code section that overflow I could only say that my board might have the clock drifted by temperature changes.

The state of freezing is, as you described, everything else still works and just the alt value stops at what I believe the last value reported to the GUI before it freezes.
I believe this has no relation to the MSP, which handles the serial communication, as I had also passed some values along the alt processing through the debug array.
If I have not forgotten, the final alt value also stops updating through the debug array.

[Gandalf]

Hi,
You have probably resolved your problems by now, but the 71 minute limit is because of the way the real time clock works, it counts microseconds from the time the board is powered up and it hits the limit at 71 minutes, if you have incorrectly configured the board speed it is possible to run up to twice this time i.e. 142 minutes however this is likely to give problems in other areas such as a large number of i2C errors as the timeout values will be wrong. Clearly the designer of the software did not envisage that a multicopter would have the endurance to run for 71 minutes which given today's battery technology is a reasonable assumption.