My opinion may differ a bit here, figured I should add some context/knowledge.
I haven’t prioritized adding e1.31 support to Pixelblaze because I think sending pixels over WiFi generally leads to poor quality art, especially at burning man or any kind of event where there’s a lot of wifi activity and/or dirty power and EMI issues. I’ve seen way too many burning man installations have glitchy stutters, even the otherwise beautiful art made by Christopher Schardt. Still, this is popular enough of a request I’m considering it, but I would still caution anyone against doing it in a serious way.
One networking feature you should be aware of, multicast UDP works very differently on WiFi than it does on ethernet/switched networks. True multicast tends to slow the transmission speed down to the slowest/worst client receiving them, and will drop frames a lot more than on a wired network. Unicast UDP over WiFi is more reliable (with retry handled by WiFi), and can be done at faster rates, but has the potential to stall in the event of a spot of poor reception where frames pile up until they can be sent.
In any event, with retry built in to wifi, the difference between unicast UDP or TCP is less significant. With multicast UDP, the retry mechanism is removed, but you are transmitting over an inherently unreliable medium at lower speeds / reduced bandwidth and will have frame loss.
This article on Multicast over Wireless has a lot more detail, a few highlights:
Because multicast is a single transmission that must be received by all transmitted receivers, access points are forced to send that frame at the lowest-common-denominator settings, to give the receivers the best chance of hearing the transmission uncorrupted. While this is fine for small broadcast traffic like beacons, it’s unsustainable for high-bandwidth applications.
Multicast senders will not resend corrupt frames. Frame corruption and retransmissions are a standard part of any WiFi transaction. Every unicast frame, even if unacknowledged at upper OSI layers such as when using UDP, are acknowledged at Layer 2, and retransmitted by the sending station if necessary. This may not seem like a big deal at first, as unacknowledged traffic on a wired network works fine most of the time. But in an area of interference or poor RSSI level, it’s not unusual to see 10% of wireless frames retransmitted. 10% loss would be considered extremely high on a wired network, and most applications are unable to handle this level of loss.
This article on Streaming ACN over WiFi goes in to more detail and has some tips.
All devices that have a wifi power save mode should be forbidden from your show WiFi network during show times.
Regardless if you have multiple clients receiving a given sACN universe or just one, it’s always better to use multicast for sACN over WiFi simply because it bypasses the ACK process.
Because multicast is far less common than the other two mechanisms you will often observe buggy or less than optimal performance on lower end WiFi equipment. This includes most home grade routers and APs.
Yes!
Check out Angio controllers on https://chroma.tech/ - these are relatively new and low cost controllers with ethernet. @jeff recently used these in a large art car installation for Titanic’s End (over 85k LEDs) and has recommended them on the LEDs are Awesome FB group.
