SparkFun will be closed on Tuesday, December 24th, and Wednesday, December 25th, in observance of the Christmas holiday. Any orders qualifying for same day shipping placed after 2:00 p.m. (MST) on Monday, December 23rd, will be processed on Thursday, December 26th, when we return to regular business hours. Wishing you a safe and happy holiday from all of us at SparkFun!
Please note - we will not be available for Local Pick up orders from December 24th-December 27th. If you place an order for Local Pick-Up we will have those ready on Monday, December 30th.
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.
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.
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.