Example Usage in README Fails with RuntimeError: Not implemented

[sandsfish]

Running the example usage on the current (4/12/2021) README, on a Raspberry Pi Zero W results in a RuntimeError: Not implemented error.

If I pull the import from another example and import:

from adafruit_bno08x.i2c import BNO08X_I2C

and then use:

bno = BNO08X_I2C(i2c)

I simply get:

AttributeError: 'BNO08X_I2C' object has no attribute 'rotation_vector'

What's going on with these examples?

[tannewt]

I think the README is out of date because it wasn't updated with a refactoring. Want to make a pull request to update it? That'd be helpful!

[sandsfish]

@tannewt I'd love to but I don't know what the correct code is. Per above, when I try to adapt this code to another code example, it doesn't work. I'm having problems getting my RPiZeroW to read from the sensor without exceptions being thrown, so this is part of my troubleshooting process to fix it.

I was hoping to go to the simplest example I could find as a sanity check, but alas, it did not work.

If anyone has any suggestions, I'm happy to put together a pull request with my successful solution.

[caternuson]

The BNO085 / Pi combo is tricky to get working since the BNO085 clock stretches. Try raising the Pi's I2C clock speed up to 400k:
https://learn.adafruit.com/adafruit-9-dof-orientation-imu-fusion-breakout-bno085/python-circuitpython#python-computer-wiring-3072324-8

rotation_vector may have been refactored into quaternion
https://circuitpython.readthedocs.io/projects/bno08x/en/latest/api.html#adafruit_bno08x.BNO08X.quaternion

[sandsfish]

@caternuson it's funny, some of the Adafruit I2C documentation says the opposite, that this sensor and others—due to lack of I2C hardware clock-stretching support—requires a dramatic slowdown in the baud rate.

See:
https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/i2c-clock-stretching

"In order to use certain I2C sensors, such as the BNO055, BNO085 and the CCS811, you'll need to enable I2C clock stretching 'support' by greatly slowing down the I2C clock on the Raspberry Pi using the device tree overlay."

I've tried it at 10,000 but just getting weirder failures. I haven't gone any lower than this, but I'm going to double-check that 400,000 doesn't work (gets these intermittent failures) as I recently found out via this handy I2C speed verification script:

https://gist.github.com/ribasco/c22ab6b791e681800df47dd0a46c7c3a

...that the PiZero W I2C bus defaults to initializing to 100,000.

I've also seen a hack with tying SDA and SCL to 3V with different sized resistors to (checks notes) slow the rate of the clock decay? but I'm hoping to get away without adding more components and keeping the hardware simple. That solution is described here:

#7

Then there is this software config, which creates an alternate software I2C, but it makes me nervous for some reason, probably because I have no insight into what's behind that solution and diverges quite a bit from what is supposed to be the default configuration.

https://github.com/fivdi/i2c-bus/blob/master/doc/raspberry-pi-software-i2c.md

I'm going to keep banging my head against this. Any additional suggestions would be most welcome.

[sandsfish]

Ok @caternuson, having figured out that the default was not 400,000, I tried explicitly setting this in the /boot/config.txt and now it's been running and pulling values from the sensor for about 8 minutes straight without an error, so I guess that solves that part of the problem. (It has an 0.5s delay in between each call, so I'm hesitant to call it a complete success, as I need as fast as possible, or at least above the refresh Hz where a human could distinguish the change (the IMU output will be mapped to parameters that change a sound, so it can't be chunky/discrete, needs to be smooth. I will test increasingly more frequent read speeds.

On that point, does anyone know if there is much of a delay between the python libraries and the underlying (C?) call? I was concerned with going to Python instead of C, but someone convinced me that the Python should be a thin layer over the underlying calls and shouldn't introduce much delay.

[tannewt]

@caternuson Mind updating the README? Thanks!

[caternuson]

@tannewt Sure.

@sandsfish Yah, the BNO085 seems to be unique in its oddness. It actually may be more than clock stretching, which is why speeding up works vs. slowing down. And future guidance about it may change if we learn more. But for now, that's the hack/fix.

[caternuson]

Hopefully fixed with #22?

[tannewt]

Looks good to me!