Marc's Public Blog - Clubbing and Trance

History of the LED outfit:

So, why a version 8? Well, the flexible panels in v7 were nice and light, but the flexible part made them break repeatedly. The chip solder points in the back would eventually fail, causing different kinds of failures on the panels, and I had to replace them in the field (even carry spares with me). This was not a long term solution, never mind that my spares were running out and it was probably impossible to buy matching panels today.

When I said things broke, I often had to repair the outfit while at festivals. Initially repairing panels was a lot of work, and required a soldering iron. Version 7 was designed to allow easier panel replacement with just a screwdriver, but I still needed to prepare the spare panels at home (soldering them before they were needed), and I broke almost 10 in 1.5 years. This was not sustainable:

Another issue was that I would lose pixels as they would eventually fall off on the other side, and the plastic cutting board I used as a diffuser and protection layeer, helped, but was not sufficient. My favorite vendor, Hongren Su from Azerone, had a new GOB coating to protect the pixels and and even make them water proof, but he didn't have anymore legacy style panels, just new PWM panels which were not supported by the rpi-rgbpanels library that I use. Those new panels are better in theory since they self refresh at 2khz or so, but they all need a separate incompatible driver, which is a huge pain in the ass. By sheer luck, Kingdoc9 on github had the same problem and somehow managed to use a coding AI to make a driver for a few chips. Total hero!

At the same time, adafruit made an active-3 low profile board which is not ideal since it covers the CPU, hinders cooling and points the connectors up, but it's better than the electrodragon low profile passive 3 board:

And still at the same time (talk about me being lucky), Hongren Su from Azerone, nicely offered to make a custom metal frame for me, with 5 degree bend, which solved both the problem of panels breaking due to repeated flexing, but also significantly simplified mounting of new panels as I only had to slap them on and the magnets did the rest (and boy those magnets are strong):

new versus old, piece of wood used to stir paint, and 3mm screws with limited reach

trying both boards

Now another vexing failure point I had, was the ribbon cables from front panels to rear ones. I used a trick to only drive the front panels with a Raspberry Pi and had ribbon cables to pick up the signal coming out of the front panels, and feeding it to the rear panels. This was a great idea, it ran the rear panels for free, I didn't have to have a 2nd rPi in the rear and saved on power.
But, as there is always a but, wearing the panels, put stress on the ribbon cables and they would eventually break. I did put straps that would get the stress and in theory prevent those failures, but they still happened, worse by then it was the HUB75 plug on the panels that would fail. That was very annoying as it caused my rear panels to have display bugs after the plugs were losing pins and there was nothing I could do short of replacing the entire panel:

note the straps to protect the HUB75 cables

this was supposed remove stress from the HUB75 plugs, but didn't do well enough

there are the HUB75 plugs that would fail

with the new setup, 2 computers (really 4 with the ESP32s), no more ribbon cables front to back

One other build optimization is I did what I should have done a long time ago, which was to use the fat power cables to send power around. Those cables even have ends that plug directly into my 20V-5V DC-DC converter. Why did I not do that earlier and insisted on using JST 2 pin cables everywhere (which I had to solder on each new panel). As an added bonus, those big power cables are thick enough that a single one going across to the back (the only connection between the 2), is enough. In the process I also removed 2 straps between the mid and top panels, as they were unsightly and now unnecessary:

So the new build runs both screens independently:

while both sides are setup to display the same thing, they render independently. This is not a problem of course

Now, I had to write a fair amount of ESP32 code (I used gemini for help), so that the 2 chips would coordinate, the front one would be master (selected by switch) and the rear would listen for a broadcast, become slave, and send its IP to the master. The master would then send a UDP command to the slave to update the pattern every time the master changed. End result:

This is how it works with remote control:

Same communcation panel to panel;

People sometimes ask me if I can "just add" a graphics on the fly. In real life I have to use gimp to shrink the graphic to 128x192 or close to it and convert to gif, it takes a little while:

The new driver is not as fast as the old driver in pushing data to the panels (yet), so I had issues with tearing in some animations as the panel refresh was happening half way through a slower frame push to the panels. I had to fix this by implementing double buffering, and you see the before vs after (left panel vs right panel):

Now, the only problem I have left is increasing the panel refresh from the Pi3as, so that they hopefully allow the panels to refresh faster and not show these half refresh screens. Never a dull moment :)

0.004s

0.002s

0.001s

0.001s