Marc's Public Blog - Arduino Hacking

What it looks like from the back:

Just like last year, Illuminaughty was about as far across the playa as a camp can be, so it was nice when we arrived :)

Ran into a bunch of people will cool gear:

Very cool hat:

Impressed that the newer panels can bend pretty well

a lot of work went into these patterns

Anthony had a lot of cool gear he built, I was very impressed:

Obligatory group picture:

Thank you to Chuck for organizing this year again, it was lots of fun.

And if you want even more details and history >>> See this full article on the why and evolution of my LED outfit <<<

For all these years, my outfit has relied on a fanny pack filled with batteries, and with an unslightly tether from the fanny pack to the panels, bringing 2 feeds with 5V (as backup and to spread out the amps over 2 wires). That system worked for many years and would survive the failure of one of the 2 5V connections, or even the 16V connection meant to feed the rPi from its own power source stepped down to 5V on the panels (so that it doesn't see a voltage dip on the remote 5V rail when the display sare fairly bright). All in all, it worked, but the fanny pack tether and wires were cumbersome, and some security folks didn't like all the wires.

After switching to a new neopixel controller that is directly USB powered, it made more sense to power the panels locally and put the batteries on the panels:

For comparison, the old panel on the left only has the rPi and a small 16B to 5V converter and than relies on that tether cable to the white box on the left which has the DC-DC step down and the ESP32:

finished design with padding, power routing from 3 lipos or 2 USB attery packs

While this was not new for v6, made sure the camera still worked, it turns out to not be super reliable on batteries, but when it works, it's a crowd favorite:

The new version works like the old one, but with batteries directly attached to the panels, which in turn makes them much heavier, but oh well. Video with Lipos and DC-DC converter:

However, the more interesting upside is that I could also replace the 16V lips that get stepped down to 5V, with 5V USB Battery packs. the reason I never did that at the time is that the entire system takes way more than the maybe 2.5A you can get from USB packs on a good day. A somewhat cumbersome workaround to this problem is to use 2 USB battery packs with 2 independent outputs each, meaning 4 independent 5V busses able to put out up to 2.5A depending on the battery pack. So, I split my power system in 4:

In total it means the whole thing uses about 3A at 5V, or 15W, which means 180Wh for 12h. In theory 2x 99Wh battery packs would work for 10H, but in real life, the first battery pack gets a lot more load since it runs the rPi, so it only really lasts about 7H before I have to replace it. Not ideal, but still nice that I can run from USB instead of lipos if needed:

Video of the USB version:

After some unfortunate feedback soon after I built the new version, I added a makeshift back cover with duct tape, mostly to hide the "scary" electronics, while still giving me accesss to them since this is still a prototype that needed occasional work and tweaks:

Since the original design with lipos, the good news is that lipo chargers have finally become much smaller. They are now small enough that I can simply leave one in my travel backpack forever:

Now I don't need this "custom made" battery box ;) which worked for its time, but didn't allow bigger batteries being an issue during 12H festivals (2 batteries wasn't enough), and was an issue during airport inspections when they wanted to "see inside the box":

I however found out over time that some airports really didn't like to see the panels in X-Ray with batteries attached. All airports were fine with the panels on their own, and the batteries on their own, but if I left the batteries in the outfit, which honestly is a lot more convenient to me, some airports really freaked out in totally irrational ways and now complained about "too many wires" "looks like a bomb" and all that good stuff. The 2 airports that delayed me enough that I barely made my flight (bangkok and Ontario, CA), literally said they would have been fine if I had packed the batteries together and still carried everything I was carrying, just not plugged in (of course everything was off, and plugged in is actually safer since you don't have loose power connectors that could somehow short).
So I'm not interested in missing a plane due to this and honestly nonsensical and irrational reactions (after all, no one said fear was rational or logical), so I eventually made a "battery pack" that I can more easily slide in and out before and after each flight:

Oh yes, it's still home made looking, could somehow get/make a box for it, but if I do they'll want to open it to see inside, going back to the original box I had earlier, so I'm not sure there is a good way to win this. Also if I make it look too much like one battery instead of 3, they'll complain it's 290Wh (over the limit) instead of 3x 98Wh (under the limit).

And to show how things evolved, this was the v3 outfit with neopixels and only 24x32 instead of 128x192, but much brighter. I did use v3 a couple of times again at day festivals, as it can be made bright enough to work in full daylight, but after doing this a few times (and that required extra batteries), I decided not to bother anymore, and skip the LED panel during day hours (I still have LEDs on arms and legs that can be made bright enough if need be):

Separately, I often have to explain to people, that my outfit is actually a scaled down version of the RGBPanels you see on stage. Once you have the display, it can scale up:

Version 5 was a bit upgrade with my P2 run rPi run RGB Panels for a resolution of 128x192 per side. The oldest part of the outfit at this point were actually the Neopixel strips I've had for about 5 years, and despite being more reliable WS2813B with backup data line, the PCB traces would break and the chips solder points would eventually break too. The amount of time I've spent fixing and replacing LED strips is more than I'm willing to talk about, but there was just no good alternative, until now.
In the past, flexible LED strands with wires between each pixel did not have enough density, maybe one pixel every 5cm, which was not acceptable for my use. And after many years of waiting, a company finally made P15 flexible strands, one LED every 1.5cm, which looks much better and is even a bit more dense than my previous strips that were P16.6.
Here there are: https://www.aliexpress.us/item/3256804447608449.html . Update, don't buy these, they are shit and broke within hours. See at the bottom

While I was at it, I added a small programmable 16x32 panel to my fanny pack, because why not (the existing fanny packs didn't have sufficient storage, so I ended up decking out mine), and here is the end result:

I have no idea how reliable the strips will be, and unfortunatley they are WS2811 without the backup data path that WS2813 had, but time will tell. I'm bringing it to EDC and we'll see what happens :)
Update: these broke within hours, they were crap.

Version 6.5.1: Ray Wu Strips

It ended up being more solid, but the flexing and occasional pulling on the bare strips that were attached with safety pins (I didn't want to glue or sew because it would then be unwashable), eventually caused the strips to fail, although it was more slowly. It worked for 4 festivals in Europe and required some resoldering, but it was not terrible. Still, it wasn't a long term solution either.

Version 6.5.2: Full LED Tubing Protection

This is now going to burning man, I hope it will hold, especially with lots of biking :)

once I got the servo validated, I connected it to an ESP8266 as a wifi controller

Here is the basic end result:

The one downside of the ESP8266 is at least the one I have with the firmware I'm using, does not have super reliable Wifi connectivity, so my server keeps track of it being there or not, and can remotely power cycle it as needed. Not ideal, but it works...

There are predators (hawks at least), so I had to add a full net around the area:

cute chickens

This is the door in action after I added a switch to control it locally and wrote code on my home controller to talk it is via wifi:

The last thing I wanted to add was a water level monitor, especially because I had issues with the dispenser leaking, and ending up without water, is bad obviously. My first plan was a predictable total failure;

looks wonderful, but it's not meant to stay in the water and the board, failed

2nd try with pins

oh look, lots of metal ended up in the water, of course!

So yeah, all those classes in middle school about electrolysis are not just to bore you, it is a real thing, and sending current to sense the water through conductors causes ions to move and metal too:

So, I tried again with new conductors and changed my code not to check for water constantly but only 20 seconds every hour. That's thankfully enough that it mostly stopped the issue I had:

And obligatory cute chickens and chicks videos:

And by the time I was almost done, I got 4 more, so that was enough for 192x128 with 12 panels. That happened to be the exact resolution of my LED outfit, although that one was 128x192. For wiring reasons and optimizing refresh speed with 3 parallel channels, I wired the array the wrong way display wise, but the best way hardware-wise:

Thankfully rpi-rgb-panel has a mode to flip, mirror and rotate the output, so it was easy to get back a 128x192 display, and run th exact same code that my outfit. This nicely allowed me to see the same thing between P2 and P5 pixels:

I now have 3 frames, fun :)

Well, the 5th (and maybe last?) edition of my LCD outfit was a lot of work compared to the previous ones, it took 1.5 years of work during covid to make it happen. Version 4 was described here.

end result after 1.5 years of work

Move to Raspberry Pi

So, easy, I just have to port all my code from arduino/ESP32 to rPi/linux, right? Damn, that's actually a lot of work, and I didn't want to do this, so I was able to do something better, I found ArduinoOnPC, and was able to fork and modify it to add Framebuffer::GFX support and added 3 display outputs:

This combined work allows running my arduino code on linux, mostly unmodified, which means it runs on rPi. Then, the FastLED_RPIRGBPanel_GFX glue driver I wrote to make rpi-rgb-panel compatible with FrameBuffer::GFX, allows running all my 2D code, unmodified and have it sent to RGBPanels through the rpi-rgb-panel driver, I'm glad I didn't have to write :)

So, this is what the prototype looked like now 2 years ago:

I ended up writing this page explaining how others can do the same (run their arduino code on linux). On the way there, I took a small detour, built some RGBPanel frames with "excess panels" (those cost $50 a piece, I have over $1000's worth, ouch), and wrote this page about it: RGB Panels, from 192x80, to 384x192, to 384x256 and maybe not much beyond

ok, that was a nice distraction :)

In the process, I fixed a lot of bugs in all the 2D code I had when I went to a 384x256 panel which obviously overflowed all code that relied on x and y being smaller than 256, and also blew up FastLED code that assumed that there could only ever be 64K pixels :)

While this was a big milestone and proved that my crazy idea running arduino code on rPi using my same 2D library, was possible, there was a lot of work left to do for my outfit, including changing all the code to deal with a much higher resolution, and days (yes days) of work finding close to 200 animated GIFs in the higher resolution, and rescaling them for my non standard 128x192 resolution. Also, all the fonts had to be changed, and a bunch of other stuff, which took months and months of work (all in all over a year):

So, this is what it looks like, ESP32 SmartMatrix 64x96, compared to rPi rpi-rgb-panel 128x192, triple channel. Some gifs, I found the exact one in higher resolution:

this gif was so cool, it's only with the higher resolution that I found out it was Pulp Fiction

Other gifs, I found a much better one:

Here is a good video showing the resolution difference between the 2 chips:

Hardware

For wiring reasons, I had a nice trick with the front panels would shift out bits, and I would send them to the back panels with ribbon cables. If you know how RGBPanels work, it does mean that a BCM plane meant to be displayed for an interval t1 in the front, ends up being displayed for an interval t2, when shifted to the back. Because of random luck of the order of BCM planes, it happened to work well enough with SmartMatrix, so it saved wiring for me (no need to splice the output to go to front and rear panels). Unfortunately with rpi-rgb-panel, the BCM planes are displayed in the opposite order it seems, so the output shifted on the rear panels, is visibly not good:

Unfortunately, there is no good fix to this outside of splicing cables, which I didn't want to do, so instead I slightly hacked the rpi-rgb-panel library to shift output bits twice. This is a bit wasteful for refresh rate, but things were fast enough with 3 channels, that I could afford the software hack and losing half of my refresh speed.
Another issue with the ribbon cables is that the active 3 board is wired to have the cable stick up (i.e. towards my belly). I worked with the nice folks at electrodragon to get bare boards without the connectors soldered and looked at how to best make it work for minimal height footprint. Bottom in blue is the original which sticks up the wrong way, upper right is what I would love to have but isn't possible because the traces on the board would have to be rewired (pin order is wrong when the plug is put underneath), so I had to settle with upper right, some angled connectors and I had to move the key hole from one side to the other for the cable to go in the right way.

I really wish I could have done this, but the wire order would be wrong

Then, I also had to protect the panels with my kitchen cutting board sheets that I've been using. It's not perfect, but they act as diffusers and protect the pixels a bit, because the P2 pixels are so small that they fall off if you look at them wrong:

Battery Use

ESP32 - rPi Integration

The rPi can also back-control the ESP32, so when I test at home, I ssh into the rPi, and the rPi uses the serial connection to the ESP32 to tell it what to do, or I can use the web server on the ESP32 and tell it what to do directly.

This means the rPi can work on its own without the ESP32 being needed, except for: - IR input (it's not really necessary, and linux IR code is very different, so it would be a full rewrite) - Wifi commands (none of Wifi code works on linux and would have to be entirely rewritten) - FastLED output would not work well on rPi since it's timing dependent, and also there are no IO pins left on mine with 3 channel output

If I were to re-write a lot of code to make wifi work on linux, that would make the rPi independent and not need the ESP32 anymore (except for the neopixel strips), so I just didn't bother. Also I can brag about having a dual CPU system with synchronization between the chips, which was fun to write and debug.

This bit of video shows how the 2 communicate:

Using Linux integration for development

This shows an example of what it looks like:

Wifi and OmEspHelpers

This is the end result, the main screen allows selecting which demos run (neopixel strips + main screen), at which speed, how bright:

there are over 200 2D demos to cycle through, some are machine generated, some are animated gifs

The diagnosis screens give more info on the device, and allow editing the config file that selects which demos run by default depending on the screen size, and whether 'bestof' is selected, or not. The config file also allows choosing the order demos run, in:

Demo of wifi:

Glasses

I ended up getting neopixel glasses which had good battery life, but after I dropped them once, a pixel fell out, and that stopped the rest of the string from working. Thankfully I was able to take a spare neopixel from a strip and replace the missing one. I didn't have the right tools or skill, so I was not able to solder it, but I used glue and that worked too :)

LED Shoes

Where is the code?

End result

I got everything somewhat working in April 2021 for a first show (about 1.5 years from when I started), and then worked through multiple electrical and reliably problems (including serial ttyUSB stability issues, and power issues I had to fix by adding a second higher voltage feed to the rPi). Also fixed sync issues between the chips and other improvements in graphics and menus. I considered V5 mostly done and reliable just in time for ADE 2021, EDC 2021, and Dreamstate 2021

I had the outfit mostly working (with a few occasional hardware issues) in time for Creamfields and untold in Aug-Sept 2021:

This even got me on Romanian national TV :)

I had fun at ADE also, and add time to make custom displays for specific events:

Solarstone looks better than his picture, haha

I have some early code that allows me to send text from my phone for special occasions, need to improve the interface:

Future

Give me the code

Introduction

Later, I found out about Arduino_GFX from Leung CHAN, which is a unified driver for a lot of TFTs of much better quality than the adafruit drivers. There is support for: GC9A01, GC9106, HX8347C, HX8347D, HX8352C, HX8357A, HX8357B, ILI9225, ILI9341, ILI9341, ILI9342, ILI9481, ILI9486, ILI9488, ILI9488, ILI9806, JBT6K71, NT35310, NT35510, NT39125, R61529, SEPS525, SSD1283A, SSD1331, SSD1351, SSD1351, ST7735, ST7735, ST7735, ST7789, ST7789, ST7789, ST7789, ST7789, ST7796
all with a single driver, a single interface, and better speed than Adafruit drivers. Good job Leung, thanks.

Now, why would you use my FastLED_ArduinoGFX::TFT layer, especially when Arduino::GFX has some support for Canvas (equivalent to FrameBuffer?)

See the Framebuffer::GFX that explains support

So, this is why FastLED_ArduinoGFX::TFT is here. If you want more APIs than just Adafruit::GFX, and you want your code to also work on all other supported backends (FastLED Matrix, SmartMatrix, RGBPanel on rPi, or even running directly on linux to write/debug your arduino code on linux with gdb or ASAN memory sanitizer)

This same LEDMatrix demo now works a lot faster thanks to Arduino_GFX copying data to the TFT faster:

This is 24bpp FastLED/LEDMatrix code running on a 16bpp TFT via Framebuffer::GFX

Basic code example

Running Framebuffer::GFX code on a TFT, FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos and neomatrix_config.h

#define ILI9341
#include "neomatrix_config.h"

If you think the file is way too big and hard to understand, you can look at the shorter TFT only version: https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/blob/master/neomatrix_config_tftonly.h

Running Framebuffer::GFX code portions of a TFT

This is the end result, you can see that the ILI9341 is spilt in two, the top half is mapped to a framebuffer, the 2nd part uses direct adafruit::GFX rendering through Arduino_GFX:

Multiple TFTs and multiple framebuffers

Arduino_DataBus *bus_[TFTCNT];
Arduino_TFT *tft_[TFTCNT];
CRGB *matrixleds_[TFTCNT];
FastLED_ArduinoGFX_TFT *matrix_[TFTCNT];
uint16_t mw_[TFTCNT];
uint16_t mh_[TFTCNT];
uint16_t tftw_[TFTCNT];
uint16_t tfth_[TFTCNT];
uint8_t gfx_scale_[TFTCNT];
const char *tftname_[TFTCNT];

As a hint:

End result

Video result:

Have Fun!

I hacked the capacitive touch penguins to add obvious missing stuff :)

The 2nd board, I couldn't help but put a hole in it and install SPI screens:

started with one screen

then got the 2 original I2C screens to display blinking eyes and worked on the SPI screen

SPI is a bus that allows multiple devices, so I added 2 screens

getting the Arduino_GFX lib to support both screens was a bit challenging, but got it working

I'll start by saying that the kit is very cool in design: the sensors are wired so that they just work, but they can be disconnected and used with wire cables later:

The kit is not as diverse as a previous kit I had, but that previous kit had so many sensors, many hard to use, and came with no instructions whatsoever. The seeed studio kit is much better in that respect and only costs $25:

Documentation:

The main downside though was that this was a colaboration with arduino, who thinks it still makes sense to push the entirely obsolete and overpriced arduino uno. The uno is so limited that it's not even funny. The kit could not even make proper use of OLED display due to lack of RAM. I really really wish it was designed to work with a proper 32bit board, like the one shown in this picture (you can also see the wires between the different boards):

At the time of this writing, the kit does not come with instructions on using a better board that is 3.3v based instead of the 5V arduino uno. See this bug: https://github.com/arduino-libraries/Arduino_SensorKit/issues/10
You could probably use one of these: https://www.seeedstudio.com/Seeeduino-Lotus-Cortex-M0-p-2896.html

To use it, Install "arduino sensor kit" from tools/manage libraries, which will include dependencies:

In my arduino install, I ended up with this:

The OLED display can be used with U8g2 insted of U8x8 (see https://github.com/arduino-libraries/Arduino_SensorKit/issues/8 ), but this stretches the very limited memory on an arduino uno:

One downside of the kit was that it didn't have an example that uses all the sensors, but I wrote one, so now it does ( https://github.com/arduino-libraries/Arduino_SensorKit/pull/6 ):

The resulting code is here: https://github.com/arduino-libraries/Arduino_SensorKit/blob/main/examples/Combined_Demo/Combined_Demo.ino

Enjoy the kit!