Firstly, do the following values, coming from the magnetometry readings and accelerometer readings have some special meaning, I've seen them occur during the crashes I'll later describe, they clearly aren't related to actual readings (>240 uT vertical is absurd as is a 19m/s^2 sideways acceleration in my application) so are they the BNO 055 reporting an error status: Mag x=0, y=320, z=240.19, Acc x=19.62, y=5.68, z=0 and Mag x=-16, y=335.94,z=240.19, Acc x=19.62, y=5.68, z=0 These values are being shown after processing the raw I2C readings in the following way, where the buufer starts at 0x08 and 0x0E for Acc and Mag respectively. x = ((int16_t)buffer[0]) | (((int16_t)buffer[1]) << 8); y = ((int16_t)buffer[2]) | (((int16_t)buffer[3]) << 8); z = ((int16_t)buffer[4]) | (((int16_t)buffer[5]) << 8); and then the magnetometry readings divided by 16 and the accelerometry ones by 100 Also, what does the BNO 055 do to the I2C bus and other devices on it during a reset? I'm getting some very severe problems. I also find that when other devices on the I2C bus give a NACK of any kind to an I2C reading the BNO 055 seems to hang? And any time that other devices on the bus, when the BNO 055 is not being communicated with have to have their I2C systems reset via 9 toggles of the SCL clock line this too seems to affect the BNO 055. When in AccMag mode how long does the BNO take to recover from a reset? I know that given this use of it I probably should have used a simpler magnetometer accelerometer chip than a BNO 055, but I too far in to a design to go back due to things such as pinout arrangements. Thanks
... View more