UGen to handle I2C sensor on Bela

Hey everyone,
my question revolves around having to create a SuperCollider class to read data from the accelerometer Adafruit LIS3DH (GitHub - adafruit/Adafruit_LIS3DH: Arduino Library for Adafruit LIS3DH breakout board). This sensor is an I2C device and so far I’ve been using my laptop connected to an Arduino, to read the sensor values and stream it into SC via serial port.
This has been fairly simple as LIS3DH requires minimal to none intervention in the Arduino code, being extremely documented there. The problem begins trying to move to a desktop-less system: my choice is Bela (, which would allow me to run SuperCollider straight on board and work with the sensor data in the same environment, without having to rely on a laptop/desktop to run SC.
In the Bela forum I’ve found some similar attempts (for example GitHub - jreus/Trill_SC: Trill UGens for SuperCollider on the Bela, I2C basis for SuperCollider UGens - Bela), but I lack the formal technical knowledge to understand how to even contemplate setting up such system.
If you’re wondering “why don’t you just use OSC to communicate between the Bela and SC” well, I don’t really know. Probably it would be a triple-backflip pickle to make that happen all on Bela, at least that’s my understanding of it.

To whoever has had experience setting up a SuperCollider UGen to read I2C sensor data, how would you advice me to proceed? What would be a good workflow to get this started?
Appreciate any help on the matter :smiley:

I have a plugin for the BNO055 IMU made for the Bela, over here: GitHub - jpburstrom/scbno055: SuperCollider plugin for reading BNO055 IMU on Bela. It’s using a couple of auxiliary tasks (a Bela-specific pthread wrapper) to read from the IMU and handle a calibration routine. Hopefully it can be of some use as an example. It works for me, but not being a c++ programmer, I more or less tried things out until it stopped crashing.

I based the IMU reading code on a previous Bela-based project, so I didn’t need to convert any Arduino code. That might be the tricky part. But you could perhaps use the basic structure of the sensor-reading class (in the files Bela_BNO055.cpp/h), and bring in the LIS3DH-specific stuff from the Arduino library.

1 Like

Thanks for sharing this!

Big mood…

Do you recall / can you share which one? tbh I’m a bit more confused about what to do then before :smiley: learning curve I guess

The project is this one: GitHub - theleadingzero/belaonurhead: Bela On Ur Head - head-tracking for binaural audio with Bela. I basically used the code in the lib/ directory and wrapped it as a SC plugin.

1 Like

Another option would be to make a script or small executable which runs on the bela and sends the accelerometer data over OSC, either to the language or directly to the server (for example by setting control bus values). Maybe this GitHub - feyzikesim/lis3dh: LIS3DH Accelerometer I2C Driver for Python3 could be used for that?

1 Like

ohhhhh so this was yours! I stumbled upon this while researching projects using this kind of approach. Nice, I have to dig this way deeper than I’ve done so far.

Yea this was the only other guess I had, maybe it’s a little easier to start from this one? I’ll post updates if I manage to proceed a bit ahead with this. Thank you so much for these awesome inputs!!

Not mine, I just found it while searching. Hope you’ll find a way forward!

1 Like

Hello @jpburstrom - thank you very much for sharing your knowledge about using the BNO055 on a Bela running SuperCollider. Unfortunately I can not fully follow the instructions of yours to get it running just from the Readme. @Robin_Morabito summed up quite well, how I feel about it.

tbh I’m a bit more confused about what to do then before :smiley:

Would you be willing to provide some further information? Also about the wiring, if all the steps have to be done via SSH on the Bela or on your computer, an example program to see the raw data… I would really like to follow, if you gave me some guidance, and would also be willing to contribute to its documentation afterwards.


Yes, the README was wrong on a number of accounts. I’ve updated it as well as making the project compilable with the older version of CMake (3.7.2) running on the Bela.

Also I’ve added compiled binaries with an install script if you don’t want to spend time on compiling the project yourself.

As for the wiring, It was a while ago I dabbled with the hardware, but I believe I connected the sensor to GND and 3.3v, and then used pins 9.24 and 9.26 connected to SCL and SDA respectively.

1 Like

Thank you! Will give it a shot and report back!

So, everything works great here, thanks for your further work on this! During setup I ran into a couple of issues, which I documented and provided as a pull request, so feel free to merge them. Its mostly about some additions for the setup procedure and a wrong class used in the help file. If everything is fine for you, I could also drop a copy&pastable code example in the Readme.

One more question though: I quite don’t get how to get the acceleration running. I expected here values that are changing over time, depending on the acceleration of the sensor, but they remain static. Can you shed some light on this maybe?

Here is the mentioned pull request - any thoughts on this are very much appreciated!

Thanks! I’ll need to get back to my Bela to test and see if there’s anything wrong with the accelerometer data. Recently I’ve only used the orientation (euler) data (BNO.orientationKr). Do you get input from any of the UGen methods?

Also make sure you don’t have trigged the calibration. Then it will output zeroes until you have finished the second calibration step. It’s outlined in the documentation but I should probably better document how that’s done – it’s a bit idiosyncratic, like the load/save methods.

Yes, I get input from all the UGens, and can read the orientation data reliably. Also triggering the re-calibration works well.

Its really just that I expected the acceleration data to return values above 0.0 only when the sensor is moving and when it is at rest, to return 0.0 for all directions. Right now the accelKr method seems to return absolute values, similar to the orientation.