Informative Display Panel

This is not a set of instructions, it's a set of "how did we get here?" mishaps.

Goal: Assemble a visual display that will display useful info to the Makerspace members present, ideally only on when someone is present.

Some people might have gone looking for prior art, but this is a Makerspace.

We don't have any easily usable "normal" monitor/TV screens, but we do have this pile of LED / HUB75 panels lying around (thanks Skippy!) and we know how to write software, so we can make our own mess/attempt.

Step one seems straight forward, measure available space and assemble set of panels that will fit / be big enough to view. Easier said than done as we'd chosen "over the main doors" (aka above head height), we both measured independently, came up with multiple sets of numbers, then by the time we got around to assembly, forgot where we'd written them down.

The panels are 64x32 pixels, multiple seems sane so we'll need some way of joining them together, we have a 3D printed bracket design (thanks Thingiverse!), but.. the set of panels we already have in use is disintegrating, turns out carrying them around from car to house to comic-con etc results in falling apart. So step two, redesign the brackets. The plan was to extend the brackets (which previously only joined the panels at the back) to the edges of the panels, with holes for mounting acrylic strips to cover the joins at the front as well. Finishing that is in progress...

Software, we're going to need at least two bits - something that runs on a small device that attaches to the panels, and something that serves content to be displayed. I suppose it could be all in one, but the small devices for running panels that we already have, are not brainy computers.

We write the server end first, as that involves not getting up and assembling hardware and finding USB cables. The rough plan is that ideally anyone could write scripts or binaries tool we can run, that produce an image of the correct size, or some text, which would be displayed. So I borrowed from our own prior tech (flipdot display) and made a small server that loads pluggable modules. The modules can do anything, as long as they return some text, or an image. Turns out that wasn't entirely how James envisioned it, but if he asks me to do it.. that's what he gets.

Now we get to the hardware, and have forgotten where we wrote the sizes, so we somewhat arbitrarily assemble a 3x3 grid (64x32x3x3, = 192x96 pixels), and chuck our 2nd HUB75 gadget on it. This is an Interstate 75W (Pimoroni) which is Ras-pi-pico based. The software that is recommended is Pimoroni's own micropython derivative with, for some reason that will likely become obvious later, a very specific set of allowed screen/panel sizes, this does not include 192x96. 256x32 is as big as it goes.

Why!? We ask ourselves, not thinking all that hard about it (maybe you see where this is going), and set about figuring out how to change the software so that it does. Minor adventures in cross-compiling aside (and a minor side-quest involving too many versions of Python), it turns out its not too hard to build locally (and if you want you can commit your changes to github, and that will do the hard work for you!)

Mutating the code to allow 192x96 (or 64*9x32 as we've connected them in a snake pattern), was doable and soon we had a build we could throw on the Interstate 75W and try.. Guess what.. Not enough memory! The pico on this device has ~256k memory, and once micropython is loaded it has ~190k left, the default colour depth/setting is RGB888, aka multiple bytes per pixel, it couldn't even create one copy of the empty display! (and it tries to load at least two copies..) Reducing the colour depth to 1bit per pixel allowed it to create one copy, but the 2nd one failed (again out of memory). We tried a barebones simple implementation (display a fade across all pixels) using the underlying hub75 module instead of the picographics one, and after running it there were ~190 bytes(!) of memory left. (Maybe this is why only certain display sizes are allowed..?)

Luckily, we also have in-use, an Adafruit Matrix Portal, which is based on an ESP32 S3, which includes 2MB of RAM instead of 256KB. Of course, Adafruit's recommended software is their own micropython mutation, Circuitpython, so now we need to retry in yet another software (ok we could probably have installed the Pimoroni one onto the Matrix portal, but, didn't, not sure if they offer an ESP32 build of it).

The Matrix Portal library allows for arbitrary sizes of panel layouts, as well as assembly in snake configuration, or various others. Circuitpython contains displayio as a way to layout content onto the display, which is like moden gui applications (sorta). Porting the simple code I'd found for the Pimoroni based software (fetch an imge from a url, dump the data into an in-memory bytearray, open it with pngdec.FromRAM, output to screen), proved to be a frustrating two-hour rabbit hole, as the docs have terrible SEO for "display downloaded image on display" (and all the variants I tried).

Two hours and a fair amount of "wtf is a BufferedReader, what is BytesIO, how to any of them talk to displayio.Bitmap later I more or less by accident found the correct code example, in the adafruit_loadimage library docs.

Current state: mini server exists, has a few bits of content it can output, display exists, can display images from the server (for some reason they align in the bottom corner of the display), power.. needs improving - the display draws 2A (at 5V) while doing nothing at all, and more when in use. Motion sensor: ordered (code tbd!), 2nd Matrix Portal: ordered, tempted to get an Interstate 75 RP2350 to try as well, that has 500KB memory...

Continuing some weeks later ...

We finished it! A mountable, usable version (is tech ever finished?) The modified brackets can be found on Printables, the code that runs the server and the display is on Github