Greetings guys, I have a code where I use Art-Net on an ESP8266, the example code is here ArtnetWifi/examples/ArtnetWifiNeoPixel at master · rstephan/ArtnetWifi · GitHub, it works normally with 1 universe, but when I try to control my led panel with 24 X 25 leds, a total of 600 Pixels, I need 4 universes, however when I try to use more than 1 universe, it generates a delay of 1 pixel in the next universe, because 512 channels divided by 3 that are the RGB, from 170.66, and this .66 interferes in the panel, since it is turned off. Could someone give me a light?
Just been dealing with the Artnet thing myself, first of all, you will not get a stable wifi connection with adafruit neopixel as it uses a bit-banged method, you need to use a UARTmethod or a DMA method as is provided with makuna neopixelbus.
Now as for your current issue.
Yes a DMX frame holds 512 slots and which comes down to 170 RGB channels + 2 (or 171 - 1)
now you store the data 3 bytes at a time using setPixelColor()
for (int i = 0; i < length / 3; i++)
{
int led = i + (universe - startUniverse) * (previousDataLength / 3);
if (led < numLeds)
leds.setPixelColor(led, data[i * 3], data[i * 3 + 1], data[i * 3 + 2]);
}
but what you should do is set it 1 byte at a time
for (int i = 0; i < length; i++)
{
uint16_t pix = ( (universe - startUniverse) * 512 + i) / 3;
if (pix < numLeds)
uint32_t color = leds.getPixelColor(pix);
uint32_t newColor = 0;
switch (pix % 3) {
case 0: // red
newColor = ((uint32_t) data[i] << 16) | (color & 0xFFFF);
break;
case 1: // green
newColor = ((uint32_t) data[i] << 8) | (color & 0xFF00FF)
break;
case 2: // blue
newColor = ((uint32_t) data[i] ) | (color & 0xFFFF00)
break;
}
leds.setPixelColor(pix, newColor);
}
I haven't tested the result with this 32-bit color method, but i think i got this right (haven't tried compiling yet either) . I did it with a 3-byte RGB method, and to be honest the way that makes the most sense to me is through directly accessing the pixel buffer, but for that you'd need to modify the library a tad.
Anyway it is mainly for you to get the gist of what you should do.
Do not discard the first thing i mentioned here, and maybe it is better to switch libraries before you implement.
Also you should consider trying to receive all universes before calling show(), to prevent the call to show() reducing the framerate (which it will) which at 600 pixels will be a significant reduction particularly with a bitbanged method, but also definitely with a UART method (DMA happens fully in the background, but i guess you will still see some slowing since a new call to show() can be done unless the old one has been completed and the processor will just idle until that has been done if i understand the I2S core correctly)
Oh yeh, about that, keep in mind that UDP packets may not always come in in the same order as they have been sent.
Heh!
Keep in mind that UDP packets may never come in. UDP packets are not guaranteed to arrive (it's important to emphasize this). I spent a fun morning at a client site trying to show them that this was their problem: their network was dropping most of the UDP packets, probably to reduce congestion.
yes, I'm using the neopixel library, I left it with 1 universe running for a few hours and it seems stable, the problem is my 24x 25 matrix, 170 pixels from the 7th row and 2 more pixels.
And the next universe starts shifting 2 pixels, and consequently universe two will end up with 7 row plus 4 pixels and so always generating a lag.
It won't be, but hey you can try.
I thought i explained how to solve this.
The bit-banged method will be slower than I2S, but you could give the program a timeout within which it can try to receive the extra universe. Basically you could make the processor wait for an x amount of time or until all universes have come in.
Some lag will always be there, but the idea would be to minimize it.
Yep that is the nature. Usually they do come in, but there is no guarantee.
I tested the code, changed the panel control software, used lumikit show, tested it with resolume arena and it worked, because resolume interprets only 510 channels and lumikit interprets the 512 channels and the error, I just need to change within the code instead of 512 to 510, any tips, because I looked and didn't find anything
if resolume only send 510 (or 170 RGB) then i don't think you need to change anything.
Lumkit ?
Anyway there are a few possible ways in which the Artnet universes are sent.
- The primary universe contains 170 RGB channels and the final 2 addresses are the RG channels of the next pixel, where the B channel ends up in the next universe. For this you should look at the code i posted.
- The primary universe contains 170 RGB channels and the final 2 addresses are just not transmitted and therefore the next universe starts of with a complet RGB channel again (Resolume as so you say)
- The primary universe contains 170 RGB channels and the final 2 addresses are transmitted but are to be discarded and the next universe starts of with a complet RGB channel again (lumkit ?)
for the latter 2 cases the original code will work, but to discard the last 2 channels if they do get transmitted you should change.
previousDataLength = length;
to
previousDataLength = length - (length % 3);
or
previousDataLength = (length / 3) * 3;
which will deduct the final channels from 'length' if they are transmitted.
If the UDP packets are not received correctly or in the wrong order, you will not get the correct output. (actually as long as universe 0 is received first, all should be OK i think)
actually if you do
if (previousDataLength < length) previousDataLength = length - (length % 3);
that should fix that as well.
Othe left pixel is thethe left pixel is the end of the first universe, channel 510 and the right pixel is the beginning of the second universe, universe 2 channel 1. channels 511 and 512 it is off and it gives this error that I will send a photo now
with universe two starting nwith universe two starting at this pixel, it generates a pixel delaywith universe two starting at this pixel, it generates a delay of the pixel that adds up to the other universes, I would have to join the universes I think, to work right.
I am not sure what it is that you are showing (what is wrong ?). Are the LEDs supposed to be the same color ? (if so which color)
which is which color ? white ?
which is red, is that correct ?
yeah well what is the program sending you ? You see the original ESP code (example btw) just discards the 2 channels , but does include them in the calculation of the pixel. If that is no supposed to happen, the fix is in reply#10
If the channels 511 & 512 include information that has to be used, then the fix is in reply#2
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.