Enginursday: Glowing Guitar, Part Deux
I recently figured out how to make a custom-shaped screen using an ESP32 and DMX512 over ArtNet. Let's check it out.
If you've been following my blog posts, you might know what's coming up with this project. I first posted about using ArtNet to drive pixels here. I then got to work creating an LED-covered guitar in this blog post (I'd suggest checking these out if you haven't yet, to see the progression of this idea). The next logical step was to combine these two ideas and make a DMX-controlled, glowing guitar! Also, if you'd like to get more familiar, check out my tutorial on DMX below.
Introduction to DMX
November 14, 2018
DMX512 is an industry standard in lighting and stage design, whether it be controlling lights, motors, or lasers, DMX512 has many uses. In this tutorial we’ll cover DMX512 (Digital Multiplex with 512 pieces of information).
That's a lot more lights than the first DMX demo; any differences?
Why yes, there are! Thanks for asking. A single DMX universe can fit 170 individually addressable LEDs in it (512 channels, three channels required, one for each color, 512 / 3 = 170.66). In that original demo, I was only using 120 lights, which can fit in a single DMX universe. This project uses just over 1500 LEDs, which requires nine universes of DMX data to drive.
The issue here is that DMX is a fire and forget protocol, meaning that it never checks to see if a message is actually received (this is why you shouldn't control pyrotechnics or stage architecture with DMX). Due to this, DMX packets are occasionally dropped. This means that occasionally, if a packet wasn't received, the previous packet's data would be displayed in the dropped packet's universe, causing one part of the screen to lag. To fix this, I simply have to get rid of old data whenever I write to the screen. In my DMX frame handling function below, we can see that whenever I recieve the last universe, I write to the screen as well as flush my UDP buffer. This ensures that I never write old data to the screen as I flush all of my data away every time I write. I should've been doing this in my original demo, but hey, if it ain't broke don't fix it, or something, right?
void onDmxFrame(uint16_t universe, uint16_t length, uint8_t sequence, uint8_t* data)
{
int offset = (universe - startUniverse) * 170;
int led;
// read universe and put into the right part of the display buffer
for (int i = 0; i < 510; i += 3)
{
led = (i / 3) + offset;
if (led < NUM_LEDS_LOWER)
{
ledsLower[led] = CRGB(data[i], data[i + 1], data[i + 2]);
}
else if (led < NUM_LEDS_NECK + NUM_LEDS_LOWER)
{
ledsNeck[led - NUM_LEDS_LOWER] = CRGB(data[i], data[i + 1], data[i + 2]);
}
else if (led < NUM_LEDS_NECK + NUM_LEDS_LOWER + NUM_LEDS_PLATE)
{
ledsPlate[led - (NUM_LEDS_NECK + NUM_LEDS_LOWER )] = CRGB(data[i], data[i + 1], data[i + 2]);
}
}
if(universe == 8){
FastLED.show();
UdpSend.flush();
}
}
You'll also notice that this subroutine reads the universe, and based on that, decides which part of the LED array to add data to.
The other difficult part was actually mapping all of those LEDs to a physical location. This step is painstaking, as you have to create a custom fixture for each small segment of the guitar, then place it in a specific location. This mapping process is different based on the DMX controller software you are using, but you can follow the process for Resolume in my Resolume to ArtNet tutorial. This map is shown in the video below.
I'll give you a dollar if you can guess what's up next for this guitar in the comments below.
Interested in learning more about LEDs?
See our LED page for everything you need to know to start using these components in your project.
DMX over wifi/bluetooth?
Wifi!
Is the next step stringing it up and dealing with all the switching noise in the audio signal?
You'd be surprised, its not an issue as all of my signals for the lights originate on an ESP32 on the back of the guitar.