Support for SPI with BNO085 instead of I2C?

[ReSummit]

I wanted to ask but is there a possibility to communicate with the BNO085 using SPI down the line? There is a ESP32 board that I have that has a BNO085 but is not connected through I2C.

If it hasn't been worked on yet, I've made some adjustments to the code in a fork that enables SPI communications but not sure if I should make a pull request or not.

[Turbine1991]

Did you try any latency or precision tests?

[ReSummit]

Did you try any latency or precision tests?

I'm looking at this datasheet: https://cdn.sparkfun.com/assets/2/b/9/0/6/DS-14686-BNO080.pdf

On latency, it seems that from the BNO08X data sheet that SPI has lower latency depending on the frequency you use. Sections 5.2 and 5.3 show that I2C has timings in the scale of us whereas SPI has timings in the scale of ns (with the exception of two sections of timings involving Ns[?] and us). In general, SPI will provide higher bandwidth and lower latency due to the separate transmit and receive lanes.

On precision, it will basically be dependent on the sensor so nothing changes unless you increase the frequency for those. I'm slightly surprised that the frequencies for this are mostly 10 but maybe this is for battery life? You can technically get fast data in the SlimeVR Server and is probably doing that anyway.

The biggest problem if you do crank the latency as fast as possible is whether the router can handle all the data transmitted. Crank out as many measurements ignoring the battery life detriments but then now the latency bottleneck is on the networking side of things. Allowing the option though for high end setups could open the doors for higher accuracy though.

Tldr:
SPI lowers latency but does not affect precision unless you use that increased bandwidth for precision. It's best to allow for people to use SPI rather than I2C; then the bottleneck for latency becomes networking.

[Turbine1991]

That's an incredible amount of detail!

I'm going to give your branch a go.

What kind of battery did you end up using? I have 18650, but I'm not sure if they're ideal.

[ReSummit]

That's an incredible amount of detail!

I'm going to give your branch a go.

The fork I have is a public repo:
https://github.com/ReSummit/SlimeVR-Tracker-ESP

Feel free to test it! The main modifications and what to change are generalized in the README, though if you really want to tinker around with higher rates of BNO085 data for I2C or SPI, I would look in src/sensors/bno080sensor.cpp and refer to section 6.9 in the datasheet for specifically the BNO085. If you have another IMU that supports SPI, I could try doing the same thing for that IMU but the defines.h will stay strictly for the BNO085 with a ESP32-WROOM32 regardless; however, the parameters to enable SPI for the other IMU would remain the same.

The function motionSPISetup is the core of this modification and contains the same frequency assignments from I2C but switches the initiation of the IMU from I2C to SPI with the different parameters. It isn't a trivial switch technically as the input parameters for initializing SPI are different so the choice would have to be made before compilation, though unless you're comparing between I2C and SPI in the same session I don't think that this will be too much of a problem.

What kind of battery did you end up using? I have 18650, but I'm not sure if they're ideal.

(Battery choice is off-topic but I just followed the battery choice of 1800mAh on the documentation website as the board I used had a JST PH connector for power regulation. An 18650 isn't a bad choice though; it all depends on how long you want it to last)