I have an Adafruit BNO055 breakout board and the temperature fluctuates pretty wildly between the actual temperature and something completely wrong - in the range of -99 to -103 degrees C, with the typical wrong value of -102 degrees C. So, while printing values at 1 Hz, it will display the error value (-102 C) then occasionally display the correct temperature of 26 degrees C.
Is there an issue with the temperature sensor on this chip? Any way to reset it?
Solved! Go to Solution.
How about the other sensor data? for example, gravity, orientation data, are those data output correctly?
In BNO055 registe r 0x40, you can select temperature source, you can change the value in this register then try again if the temperature data is correct or not?
I see this regularly with reading with Raspberry Pi and GoPiGo3 sofware based I2C with clock-stretching. There are many soft I2C exceptions that you need to catch, causing the temperature or other values read.
For example my read temp routine:
def safe_read_temperature(self): """Read chip temperature :returns: Tuple of temperature in degC :rtype: float """ ifMutexAcquire(self.use_mutex) try: temp = self.read_temperature() except Exception as e: temp = 0.0 self.exceptionCount += 1 finally: ifMutexRelease(self.use_mutex) return temp
There are probably lots of exceptions happening that you are not catching. Here are the number of exceptions I am logging in 12 hours on my robot:
2020-05-10 21:56|[logIMU.py.main]** resetIMU docked - visually 0 degrees ** 2020-05-10 23:51|[imulog.py.logMotionStop]heading: 1.5 rotation: 1.7 motion: 2.8 sec errors: 567 2020-05-11 06:00|[imulog.py.logMotionStop]heading: 179.4 rotation: 177.9 motion: 2.4 sec errors: 593 2020-05-11 06:00|[imulog.py.logMotionStop]heading: 179.5 rotation: 0.1 motion: 0.1 sec errors: 593 2020-05-11 06:00|[imulog.py.logMotionStop]heading: 358.4 rotation: 178.8 motion: 2.4 sec errors: 593 2020-05-11 06:01|[imulog.py.logMotionStop]heading: 358.0 rotation: -0.7 motion: 2.7 sec errors: 593 2020-05-11 06:01|[imulog.py.logMotionStop]heading: 358.0 rotation: 0.0 motion: 0.3 sec errors: 593 2020-05-11 06:01|[imulog.py.logMotionStop]heading: 358.0 rotation: 0.0 motion: 0.1 sec errors: 593 2020-05-11 06:01|[imulog.py.logMotionStop]heading: 358.1 rotation: 0.1 motion: 0.4 sec errors: 593 2020-05-11 08:51|[imulog.py.logMotionStop]heading: 0.0 rotation: 1.9 motion: 2.8 sec errors: 605
A total of 48 soft I2C exceptions occurred in 23 hours.
Many thanks GPGC. A little more Googling and tinkering before I posted could have saved some trouble. The lack of clock stretching support, even in RPi 4 is surprising. Knocking the baud rate down to 50kHz gives a little bit better performance - catching and tossing the bad values is working fine for the occasional hiccup. Finding quite a bit of difference from the quaternion solution to the Euler angle solution so not sure what that's all about but that's a different thread for a different time.
Thanks, Vincent. I have a five sample delay with a moving median filter that just dumps the bad value and grabs uses the median. It's working fine but I had to knock down the baud rate because of the lack of I2C clock stretching as pointed out below. It's not clear why the Pi has trouble with this in hardware - it's fairly standard (defined in the protocol even) but not well supported. I have the work around now. When the temp is off, it throws all the other measurements off because they are temp compensated. Off by a few degrees wouldn't move the needle much, but going from room temp to -100 degrees C makes the sensor think it's operating out of it's range.