This post and the rest of the “Catching Up” series are the (long overdue) updates on the development process. They will not be thorough, but I will try to remember the essential details as much as I can.

Initially, I started working on the project on a Raspberry Pi Zero WH because I have already had it and programmed it using Python before. It is small enough to be used in a wearable application, it has built-in wireless, and it was already conveniently connected to a breadboard through an Adafruit T-Cobbler.

I wiped its memory card to make it headless, and I updated/upgraded all of its packages. I installed the necessary Python libraries for the components I use, as well. Since Raspberry Pi Zero W has no ADC on it, I used an MCP3008 (8-channel, 10-bit ADC) for flex sensor inputs. I also used a BNO085 IMU to gather orientation and acceleration data. I chose an Adafruit Breakout Board for BNO085, which has the IMU conveniently soldered, and all the necessary pull-up resistors are present, so I don’t have to go through a demanding soldering task myself. It also allows for both I2C and SPI communications. Even though I’m only using the I2C connection, I enjoy having another option.

I wrote the Python code to poll quaternion and linear acceleration data from the BNO085, and the data rate was way lower than what I expected. Another issue was that I was getting the same readings three times. I decided to implement an interrupt service routine (ISR) since BNO085 can notify the host whenever there’s a new reading through its “INT” pin. It’s a good practice to keep ISRs short, so, in the interrupt handler, I change the flag for either quaternion or linear acceleration data rather than reading the data. The main loop checks these flags and reads the data only when a new reading is available. This practice increased the data rate quite a lot; however, it was still slower than it was supposed to be. Adding the piece of code to read analog inputs of MCP3008 reduced the rate even further. Finally, I added the code to send the data over OSC to my computer into Max. The data rate on the receiving end was a whopping 11 Hz at maximum.

After some experimentation, I decided to write the same code in C to see if Python was the reason for this frustrating issue. Not to my surprise, the data rate went up quite a lot again; however, my code was running at one-fifth of the frequency the BNO085 prepared new readings.

The conclusion after hours of frustration was that the Raspberry Pi Zero wasn’t built for this task. A fully-fledged operating system runs on it and uses a lot of necessary system resources for things that I don’t even need. I gave up and ordered an Arduino MKR1000 WIFI.