DataSleeve, the Worst Best Wearable PC Ever

A while back, I saw this picture of Limor Fried (Ladyada) at MIT wearing a really awesome wearable computer. It was taken a long time ago, but I kept looking into the wearable PC subculture.

And I loved it.

So I threw together a concept called DataSleeve, a wearable with so many compromises it's cool.

HUDs and AR glasses are expensive, so the screen is a resistive TFT on your arm. I didn't want to buy a Pi 3, so the display is soldered to a Pi 0 W. Using gesture control for the keyboard would require a lot of work, so I plonked a 12-key keyboard on the main PCB. 12 keys isn't enough for the entire alphabet though, so there's a rotary encoder in charge of what each key does. The gesture control element I did keep is just for clicks (get it?), and bending my index finger triggers a left click, and bending my middle sends a right click. There's also gestures for space.

The final three features are the most interesting: The sensors, what the thing does when you connect it to another thing using BT, and the two Arduinos driving everything.

I'll start with the sensors. An MPU6050 tells me where my hand is and how it's moving, a DHT11 breakout senses temperature and humidity, and an APDS9960 detects the temperature and how I'm waving my hand under my arm. Most sensor data is displayed on a tiny OLED.

As for the driving Arduinos, there's an RP2040 Connect and a Micro. The RP2040 Connect does pretty much everything, from taking gesture inputs to updating the OLED to taking the keyboard presses. Some of the information is relayed to the Micro, which is plugged into the Pi and sends keyboard/mouse inputs. The Micro also does a few things itself, operating the MPU, the APDS, and an emergency buzzer for some reason.

Now for the Bluetooth thing. The wearable can actually be connected to another computer and act as a Wii-style airmouse, and also send inputs from the keyboard.


For now, DataSleeve is still in prototyping. I will update the thread periodically as I make R&D and build progress.

UPDATE | 8:11 | 1/12/22
I'm changing the RP2040 Connect for a Seeeduino XIAO RP2040 clone with more pins. I'm changing the original power controller I was using to something from Seeed called the LiPo rider.

UPDATE | 13:33 | 1/12/22
So turns out the Adafruit thing I was going to add requires code to be uploaded to two boards at once, but only one board can be reprogrammed. So I guess no sensor bracket.

EDIT - Actually I might keep it, but with no native reprogramming support.

UPDATE | 14:47 | 1/12/22
I found a tiny USB hub that I might be able to epoxy somewhere. If I can make it work, the Adafruit thing might be on track after all.

UPDATE | 8:45 | 1/13/22
I had an idea in the car this morning. The Adafruit sensor bracket doesn't need a reprogramming interface. Just a lot of flash memory. Each sensor in the sensor bracket system should have a different I2C address. If I sniff the address, I can do different things based on which sensor is connected. So the Arduino Micro, where the sensor bracket is connected, would sniff the address, pick the appropriate library, and then read the sensor. Next, there's two concepts I had in mind. The first saves memory but takes longer, and the second is the opposite. The two onboard microcontrollers are connected to different things, and the Micro, which takes the sensor readings, is not directly connected to the status display. The RP2040 is. The first concept requires a USB to be connected from the sleeve's main computer to the RP2040, and what it does is simple. Each sensor has a key combination. When that sensor is put in, the Micro sends the corresponding keycombo to the computer, which uploads a new sketch to the RP2040, compensating for the new sensor. The problem with this is that flashing the RP2040 takes a minute, and that the Pi 0 only has one USB output, which is being taken by the Micro for keystrokes. As I said previously, I could epoxy a tiny USB hub to one of the PCBs, but I'd rather not. So that's the first idea. The second idea uses the software serial communication (fight me) between the Micro and RP2040 to update the status display. Along with the data normally being sent across serial, the Micro also sends a small int. Almost like a note. It tells the RP2040 what sensor is connected. Depending on this, the RP2040 can change what data is being displayed. The problem with this is that it uses a lot of precious flash and RAM, because it has to change both the amount of data points that the OLED can display and the actual data. I'll have to see how much of the 2MB of flash and 256KB of RAM I've got left after programming.

UPDATE | 13:50 | 1/13/22
Another change to the RP2040 MCU, and this time it's permanent. I found the perfect board: the Adafruit ItsyBitsy RP2040. It's got 3rd party IDE support and has 8MB of flash. I also decided to change over from software serial to hardware serial. Sacrificing easy debugging for easy communication. Maybe I'll find another way to debug.

EDIT - I might add debug through a blinking LED. Obscure, but it might work.

UPDATE | 10:14 | 1/14/22
It wasn't permanent. Adafruit's KB2040 board fits a Pro Micro footprint and still has a reasonable amount of IO.

EDIT - Also, pink/purple PCBs are awesome.