First up was the arm display. I picked up an 8x16 flexible LED display that uses Bluetooth Low Energy for communication. It pairs with the CoolLEDX app for control, which is easy. But that’s not programmable. Pulling out a phone to change the display manually would destroy the fun. Having the display react automatically as events happen would be so much better. So I needed another way to drive it.

Some searching revealed UpDryTwist/coolledx-driver which worked, but also is written in Python and I’d much rather be doing all this coding in Clojure. So I tried and found out that the device really doesn’t follow BLE standards. It expects raw data to be pushed to an unidentified GATT service. I made some progress on re-implementing the driver, but reverese engineering the data format even with the Python code as a guide was slow progress.

Even worse, the BLE communication is slow. The display actually shows a brief "loading" animation for each image pushed to it. If there was nothing better this would just have to suffice. I’m glad there is a better option.

Maybe I’ll put up a post later about what I learned while trying to make BLE work with Clojure.

A friend challenged me to try skipping the Bluetooth part entirely and use a microcontroller to drive the LED panel. I had worked with Arduinos, ESP8266s, and ESP32s in the past — ask me about Atelier Chakraspace sometime — and kind of dreaded trying again. That’s because many of these panels are WS2812 based, which means the data logic lines for the LEDs want 5v but most of the microcontrollers put out 3.3v. Yeah yeah yeah, that can be handled with logic level converters, but once other components like that have to be added in the project becomes much more complex. I tried to get circuit boards fabricated for the Atelier Chakraspace project, and those failed spectacularly. Four years later and that project is still not a reality, and all due to the extra complexity.

With a bit of resignation, I tried again:

The ATMega was chosen because it has 5v data lines …​ or so I think. The specs I read were not completely clear. Anyway, it was cheap enough to give it a try and worked well in the end.

PlatformIO was my choice for programming the microcontroller. It is a little bit confusing to get going, though once set up is less constraining than using the Aruino IDE. The examples for starting a new project based on the ATMega32U4 were enough to make it work. For driving the WS2812 LEDs there are ample examples of how to use FastLED.

Less than half an hour of work and there was a single LED lit on the matrix!

A little more coding and the display was lighting up one LED at a time in a simple animation. A sort of "tracer". Which demonstrated up a fresh problem: the matrix is essentially a WS2812 LED strand that has been "woven" back and forth, thus every other row of the display is reversed. That will have to be handled in code before it can display images.

With that, I was pretty confident the panel would work. So next up was to give some attention to the "brain" of the jacket.

Driving displays, reading SDR, and coordinating actions is easier if the jacket has a central brain. The Pi 4 was chosen for a balance between capability and power consumption. Since this will have to run on battery, it needs to be somewhat efficient. Yet the rest of the capabilities like SDR require more power. Who knows if this will work? I’ve used the DevTerm for hours on two vape batteries. Surely I can make this work at least that long, even if it requires a few more batteries? There is plenty of place to hide them in that jacket!

When the microcontroller is plugged in via USB it shows up as the /dev/ttyAMC0 device. Sending data should be as easy as writing to that file. "Should be." To find out, I updated the C++ code to allow setting the brightness of the chaser LED.

And then tested with a simple echo statement from bash.

Success! That was enough to give me hope the display would work.

One of the main use cases for this LED matrix is to display "idle animations" as well as other information as it is gleaned from the environment. No matter how all those plans play out, the bare minimum I need is to push image "frames" to the matrix.

But first, can Clojure sanely talk to the serial port? Trying to change the brightness should be a good test.

Here is the code, along with lines executed in-REPL in the comment block:

It turns out there are some issues with writing bytes to an output stream with Java (and therefore Clojure). The C++ code is using unsigned integers - with an 8-bit int ranging from 0 to 255. Java, however, only has signed ints. Which means the numbers are stored using Two’s Complement so that negative numbers can be represented. Now the range of ints is -128 to 127.

Clojure handles this with unchecked-byte which gives us the proper behavior:

Now it’s time to push an image to the matrix. FastLED stores them as an array of CRGB structs, which are basically three 8-bit unsigned integers in a row. The nice thing about that is the bytes can be streamed over the serial port and read directly into the array! Here is an added "command" extending the switch statement from before that loads the LED array. Note that the number of LEDs is multiplied by three to accommodate the R, G, and B bytes.

Now the Clojure code just has to push the right set of bytes over the output stream and we’ll have control over the image on the matrix!

In my Going places I shouldn’t with JNA post, I cover useful Java classes for dealing with images. That was a great foundation for what had to be done next.

The plan of attack is to load an image with javax.imageio.ImageIO/read, convert it into TYPE_INT_RGB by creating an empty "working image" of that type and then using .drawImage to copy the loaded image into the working image. After that, the pixel array for the image can be found by pushing it through .getRaster, .getDataBuffer, and then .getData.

Sadly, that turns out to be a disaster.

That of course makes sense - the internal representation of the BufferedImage is a Java integer which is larger than the 8-bit ints that FastLED uses. And FastLED uses three uint8_t bytes in a row. That means each int has to be unpacked into three bytes. You can find many guides on the internet for this, but the idea is pretty simple: use a bitmask to mask off the portion of the integer to keep, then shift it right to "cut off" the parts you don’t need. If that doesn’t make sense, don’t worry. Here’s the code:

Now that just needs to be mapped over the pixel ints and flattened before sending down the wire:

Better! But this was supposed to be a rainbow as a test of colors. I forgot to fix the "weave" pattern built in to the matrix. I also didn’t remember to turn off the tracer animation, so it ate away part of the image.

This was an easy, if not clever, fix. Just use map-indexed which is like map but also passes the index number of the entry to the function being called. Then it runs reverse on the even rows and finally flattens them back into a list.

With the final push-image function being:

Finally, a proper image.