I2C Unknwon Report Type

[TwoTenPvP]

When listening to many different events on I2C. I get the attached stacktrace after some time.

I am running a Raspberry Pi 4B.

The less reports I enable the larger the sequence number (I.E it takes longer for the problem to occur). I assume this has to do with bandwidth restrictions on I2C? But I am by no means an expert. Looking for a way to solve it. Thanks!

        ********** Packet *************
DBG::        HEADER:
DBG::        Data Len: 15
DBG::        Channel: INPUT_SENSOR_REPORTS (3)
DBG::           ** UNKNOWN Report Type **: 0x7b
DBG::        Sequence number: 166

DBG::        Data:
DBG::       [0x04] 0x7B 0x15 0x00 0x00 
DBG::       [0x08] 0x00 0x02 0x28 0x00 
DBG::       [0x0C] 0x00 0x02 0x00 0x00 
DBG::       [0x10] 0x00 0x02 0x00 
        *******************************

Traceback (most recent call last):
  File "Main.py", line 40, in <module>
    ChipManager.update()
  File "/home/pi/erm/Chip/ChipManager.py", line 89, in update
    ChipManager.s_linear_acceleration = ChipManager.bno.linear_acceleration
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 577, in linear_acceleration
    self._process_available_packets()
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 783, in _process_available_packets
    self._handle_packet(new_packet)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 841, in _handle_packet
    raise error
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 836, in _handle_packet
    _separate_batch(packet, self._packet_slices)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 351, in _separate_batch
    required_bytes = _report_length(report_id)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 340, in _report_length
    return _AVAIL_SENSOR_REPORTS[report_id][2]

[ladyada]

yeah it could be due to the clock stretching on i2c you may want to reduce the number of reports, and slow down i2c

[TwoTenPvP]

yeah it could be due to the clock stretching on i2c you may want to reduce the number of reports, and slow down i2c

Is there no other ways? I really do need these reports.

[ladyada]

well why not try to speed up i2c? could also try UART

[caternuson]

Try just slowing down first: https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/i2c-clock-stretching

[TwoTenPvP]

I have tried slowing down my clock to 10KHz as per that article.

Seems it just takes a few seconds for any interaction between my BNO and Raspberry pi now.

I really fail to understand this, perhaps one of you could explain it to me. How is the BNO intended to be used? Over I2C or UART? I need all the features I have enabled, I need it at a fast rate. ~50Hz.

How is the chip intended to be used? Surley this is not a wierd usecase? It's one I could easily accomplish with my old IMU.

[TwoTenPvP]

Actually, just found this article: https://cdn-learn.adafruit.com/downloads/pdf/bno055-absolute-orientation-sensor-with-raspberry-pi-and-beaglebone-black.pdf and it states that for Raspberry Pi. UART should be used.

Thanks for your help anyways guys! Very much appreciated!

[caternuson]

If you can get the data rate you want with UART, then should be fine.

If you need to continue to try I2C, then you'll be dealing with the clock stretching issue. This is a feature of the I2C protocol, but the Raspberry Pi does not handle it well and is a known issue. (Pi 4 may be different?) Not all I2C devices do clock stretching. However, the BNO08x apparently does. Similar to the BNO055.

The clock slow down is one approach for getting around the issue. Another approach to investigate would be the use of software I2C via the i2c-gpio device tree overlay.

[TwoTenPvP]

I tried UART. And it does not have the data rate I need. So I am going with software I2C (thanks for the pointer @caternuson). I guess this might be the wrong forum to ask, but I am not quite sure about the API regarding the board pins.

I setup my i2c-gpio like this: dtoverlay=i2c-gpio,bus=3,i2c_gpio_sda=27,i2c_gpio_scl=22. The busio API however seems to take some arbitrary pin numbers in it's constructor. Putting in 27 and 22 won't work.

Any pointers?

[caternuson]

You'll want to use this library instead: https://github.com/adafruit/Adafruit_Python_Extended_Bus and just give it the bus number.

[TwoTenPvP]

Thank you very much @caternuson. Works wonderfly!

For people in the future who need high data rate on the Raspberry Pi. Here is my guide:

1. Enable software I2C by adding the following entry to your /boot/config.txt file: dtoverlay=i2c-gpio,bus=3,i2c_gpio_sda=27,i2c_gpio_scl=22. By default it will use GPIO 23 and 24. But I was already using them so I specified the ports as a parameter. It's however optional.
2. Reboot to apply the effects.
3. Double check with ls /dev | grep i2c. You should see a i2c-3 (bus 3)
4. Using the PythonExtendedBus. The following code can be used:

   
   import adafruit_bno08x
   from adafruit_bno08x.i2c import BNO08X_I2C
   from adafruit_extended_bus import ExtendedI2C as I2C

bno = BNO08X_I2C(I2C(3))

Big thanks to the people in this thread!

[bodkal]

Thank you very much @caternuson. Works wonderfly!

For people in the future who need high data rate on the Raspberry Pi. Here is my guide:

1. Enable software I2C by adding the following entry to your /boot/config.txt file: dtoverlay=i2c-gpio,bus=3,i2c_gpio_sda=27,i2c_gpio_scl=22. By default it will use GPIO 23 and 24. But I was already using them so I specified the ports as a parameter. It's however optional.
2. Reboot to apply the effects.
3. Double check with ls /dev | grep i2c. You should see a i2c-3 (bus 3)
4. Using the PythonExtendedBus. The following code can be used:

import adafruit_bno08x
from adafruit_bno08x.i2c import BNO08X_I2C
from adafruit_extended_bus import ExtendedI2C as I2C

bno = BNO08X_I2C(I2C(3))

Big thanks to the people in this thread!

it is old thread. but @TwoTenPvP you are the best i struggle with this problem over a weak. tanks alot for the example.