Hey team
Does any of you have experience with Artnet with Wifi.
I have used Gladiator and created 8 universes to control 32x32 but unfortunatly it seems like Gladiator is mixing up the universes or i don’t receive all of them.
It’s only fluid with up to 3 universes
any idea ?
I have recently been Trying artnet dmx as well with fastled and an esp32 - experienced similar issues and gave up for now to do other projects… sorry
@Chris_Tarantl don’t be sorry at lease I am not crazy. I also use an esp32 m. I’ll keep you posted if I find the answer.
I got my artnet working 99% with a ESP32. Just the first pixel is always staying lit. The rest work smoothly.
Going to work on it more this weekend.
@Darren_Hedlund over the WiFi? I would be interested in your code then 
I had the same problem with e1.31. After 3 universes it was a problem. Try this, after you validate your artnet packet use the universe id and place that data in the correct location of the fastLED array but don’t send yet. , use a loop count variable to keep tack loops while detecting and storing. When loop count reaches the same count as desired universes then send the fastLED array to the leds . Almost all the code examples out there used different detect methods to capture all universes before it sends. I found that by doing this it would loose universe data quickly or if the array was sent to leds each loop it would also cause delays. Every time there’s delays you lose packets in your Ethernet buffer. missed packets = choppiness and missed frames
@Chris_Rees that is what I did and indeed I can see that most of the time universes 5 6 7 8 get lost. I will try to not call the Onread method each time and have this method use the second core to process the frame.
@Yves_BAZIN What Ethernet buffer size does esp32 give? My teensy platform I use 16k
@Yves_BAZIN the other balance of the equation I think can be the issue is the WiFi/Ethernet buffer if it’s too small you will loose packets. With a bigger buffer you can have time to buffer incoming packets and loop it before it gets over written
@Chris_Rees I will have a look at the buffer I think it’s around 530. But I need to look on how the program is written to manage udp packets
@Yves_BAZIN ok that’s what the udp uses and that can stay. I am talking about the actual WiFi buffer. in the wiznet code I use there is an additional buffer defined by sockets. I know this may not apply to esp32 but it may be something similar.
@Yves_BAZIN here is what I think may need to be looked at I know it’s talking TX buffer but see what it may help with on Rx buffer. Find out what the default RX buffer may be then see if it can be increased https://esp32.com/viewtopic.php?t=3279.
Here you go, its written for the ESP32(using SK9822/apa102 pixels) to be used with Resolume(but gladiator will work fine as long as you pixel map it properly) http://www.elec-tron.org/?page_id=1488
@Leon_Yuhanov thank you I will have a look at it
Waiting for news about that!
There was the same problem with the w5100. Had to increase buffer.
youtu.be - Esp32 WiFi 64x32 glediator
No increase of buffer for the WiFi but couple of programming tweaks and use of the second core. 64x32 pixels 16 universes #glediator #eps32 16 output.
Issue with gladiator the 16th universe is universe 0 ![]()
@Chris_Tarantl @X-WL1
@Yves_BAZIN in fact it is already very much! I do not think it’s really possible to squeeze out more than 16 universes from one module. Such solutions cost gigantic money on the market!
What is the size of the TX buffer? 8k?
@X-WL1 i did not change that. I am collecting 16 times 384octets that I store in a ‘buffer’ when I have all the frames I get out of the read loop and ask for the frame to be added to my board and the actual board display but this is done by the second core while I can continue on getting the frames from the udp on core 1
@Yves_BAZIN why exactly 16 universes of 128 pixels? It is more efficient to use 13 fully loaded universes. This will reduce the number of incoming packets!
@X-WL1 I know
it was more a matter of:
- testing the limit in term of number of universes
- it was easier to map with glediator which is a pain to create pixel mapping. 128 pixels =two lines ( and only selecting them is a mess)