# Lightshowpi (and others) integration: sACN/e1.31 proxy

**URL:** <https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766>\
**Category:** Patterns and Code\
**Created:** [November 28, 2020, 2:20am UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766 "2020-11-28T02:20:07Z")\
**Posts on this page:** 15\
**Page:** 2

<div class="post-metadata">

**Author:** ![zranger1](https://forum.electromage.com/user_avatar/forum.electromage.com/zranger1/32/301_2.png) [@zranger1](https://forum.electromage.com/u/zranger1)\
**Post date:** [December 17, 2022, 12:19am UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/21 "2022-12-17T00:19:25Z")

</div>

Without taking a thing away from my great fondness for Pixelblazes, let me be really clear about this:

Until @wizard decides to adds an Artnet receiver option, while it’s technically possible to do this, it’s really, really not a great use for a Pixelblaze. It’s a very inefficient use of both controller and net bandwidth, and it would be hard to scale into a robust production system.

If I had to build a DMX/multicast e1.31 based display **right now** , and I wanted to use distributed wireless controllers, I’d go with [WLED](https://github.com/Aircoookie/WLED), which includes an Artnet client. That way, all you’d have to do is figure out which controller goes with which universes, and send the multicast datagrams. With a reasonable midrange gaming router, you could drive at least several thousand LEDs over wifi this way (depending on signal conditions).

---

<div class="post-metadata">

**Author:** ![bbqchickennn](https://forum.electromage.com/user_avatar/forum.electromage.com/bbqchickennn/32/1952_2.png) [@bbqchickennn](https://forum.electromage.com/u/bbqchickennn)\
**Post date:** [December 26, 2022, 5:18pm UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/22 "2022-12-26T17:18:23Z")

</div>

Thanks for the honesty @zranger1 ! I’m looking into WLED right now. In terms of the networking, do you suggest that a wireless connection will be robust enough for a Burn installation? Or should I do it wired to avoid issues with wifi?

---

<div class="post-metadata">

**Author:** ![zranger1](https://forum.electromage.com/user_avatar/forum.electromage.com/zranger1/32/301_2.png) [@zranger1](https://forum.electromage.com/u/zranger1)\
**Post date:** [December 26, 2022, 5:53pm UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/23 "2022-12-26T17:53:36Z")

</div>

Oh wow, good question! Wifi reliability in the field is tremendously dependent on what’s going on around you. If you can get a good signal to all your controllers, there’s not much other traffic on your net, and there aren’t a lot of other wifi installations nearby competing for channels, you should be able to drive a few thousand pixels easily with multicast UDP.

If you can, build a small section of your project and test it somewhere you know has a lot of radio traffic and other interference, from random metal structures to leaky microwave ovens - pretty much any building in most cities will do.

Out in the field, very heavy rain might interfere, but that’s gonna drive everybody inside anyway. In my experience, even severe dust storms don’t seem to affect wifi much (except for the wind ripping things apart, but that’s a whole separate issue!)

---

<div class="post-metadata">

**Author:** ![wizard](https://forum.electromage.com/user_avatar/forum.electromage.com/wizard/32/4_2.png) [@wizard](https://forum.electromage.com/u/wizard)\
**Post date:** [December 27, 2022, 9:40pm UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/24 "2022-12-27T21:40:27Z")

</div>

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](https://wirelesslywired.com/2019/05/02/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](https://www.diychristmas.org/wiki/index.php?title=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.

> [@bbqchickennn](#):
>
> should I do it wired to avoid issues with wifi

Yes!

Check out **Angio** controllers on [https://chroma.tech/](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](https://www.facebook.com/groups/LEDSAREAWESOME/posts/2001952606666855/) on the LEDs are Awesome FB group.

---

<div class="post-metadata">

**Author:** ![zranger1](https://forum.electromage.com/user_avatar/forum.electromage.com/zranger1/32/301_2.png) [@zranger1](https://forum.electromage.com/u/zranger1)\
**Post date:** [December 28, 2022, 1:55am UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/25 "2022-12-28T01:55:21Z")

</div>

100% agree – wired is absolutely the best way to go.

But the wireless thing is _interesting_, and a lot of the information out there looks like it originated from a single source. A perfect opportunity to do some testing and see what happens!

So, my initial half-baked attempt to just slam some Artnet pixels across my normal messy home network with all its phones, tablets, TVs, etc. turned out fairly well. Without changing anything, I was able to multicast 172,000 pixels/sec from desktop to router to AP and over the wifi with about 7% packet loss.

Depending on how the LED controller handles dropped packets, this probably produces a workable frame rate for 3000-ish pixels. And I’m pretty sure I can reduce the packet loss by increasing the AP’s minimum fixed transmission rate.

Will play with this more and post results&video here when done!

---

<div class="post-metadata">

**Author:** ![zranger1](https://forum.electromage.com/user_avatar/forum.electromage.com/zranger1/32/301_2.png) [@zranger1](https://forum.electromage.com/u/zranger1)\
**Post date:** [December 28, 2022, 6:25pm UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/26 "2022-12-28T18:25:32Z")

</div>

Ok… that devolved into chaos in a big hurry. @wizard you were right - straight-up multicast is all but unworkable over wifi.

With a lot of fiddling with AP settings, I was able to multicast 310,500 bytes/sec (3000 pixels@30 fps) successfully from my desktop to couple of fairly powerful laptops, “success” being relative. There was still some packet loss, and it was “lumpy” – unevenly distributed, so it would show up as visual glitches.

The IoT devices I set up to just listen to the traffic and report their packet handling rate pretty much crashed and burned. Had trouble even getting them to stay connected.

So it looks from here like wired multicast is best, wireless UDP unicast is possible but possibly unreliable, and maybe this e1.31-to-Pixelblaze websocket proxy thing isn’t as bad an idea as I’d thought.

---

<div class="post-metadata">

**Author:** ![bbqchickennn](https://forum.electromage.com/user_avatar/forum.electromage.com/bbqchickennn/32/1952_2.png) [@bbqchickennn](https://forum.electromage.com/u/bbqchickennn)\
**Post date:** [December 28, 2022, 7:54pm UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/27 "2022-12-28T19:54:47Z")

</div>

> and maybe this e1.31-to-Pixelblaze websocket proxy thing isn’t as bad an idea as I’d thought.

still no go according to your test on my multicast fleet idea IIUC

@wizard also what I don’t understand about those controllers you mentioned is how I go from the Ethernet sACN outputs to a strip.

---

<div class="post-metadata">

**Author:** ![jeff](https://forum.electromage.com/user_avatar/forum.electromage.com/jeff/32/3473_2.png) [@jeff](https://forum.electromage.com/u/jeff)\
**Post date:** [December 30, 2022, 8:48pm UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/28 "2022-12-30T20:48:32Z")

</div>

> [@bbqchickennn](#):
>
> what I don’t understand about those controllers you mentioned is how I go from the Ethernet sACN outputs to a strip.

Does this clear things up? Ethernet plugs in, you configure your sACN or ArtNet destination to be the IP address for the controller, configure the universes if necessary, and then each channel can have up to 1020 pixels on it. They sell a 4-channel and 8-channel version.

 ![Angio 8 — chroma.tech 2022-12-30 12-41-47](https://forum.electromage.com/uploads/default/original/2X/9/9fd831b166a20a5fccdf28cacf2e30ae451ae6ac.jpeg)

---

<div class="post-metadata">

**Author:** ![zeb](https://forum.electromage.com/user_avatar/forum.electromage.com/zeb/32/257_2.png) [@zeb](https://forum.electromage.com/u/zeb)\
**Post date:** [January 3, 2023, 6:25pm UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/29 "2023-01-03T18:25:17Z")

</div>

You may want to check out the ESPixelStick firmware:

> **[GitHub - forkineye/ESPixelStick: Firmware for the ESPixelStick](https://github.com/forkineye/ESPixelStick)**
>
> Firmware for the ESPixelStick. Contribute to forkineye/ESPixelStick development by creating an account on GitHub.

I’ve used it, quite a while back, as a wireless E1.31 to DMX “bridge” without issue but I wasn’t throwing around that much data and was using a wireless access point dedicated to the lighting traffic.

It appears to support a wired connection (never tried) but I’m not 100% certain what pixels it supports (definitely WS2811/2 but there may be others).

If you’re interested, I’ll get it installed on one of my ESP32 boards that has a wired connection with PoE as a test. No reason why I can’t power a few pixels from the switch!

---

<div class="post-metadata">

**Author:** ![zranger1](https://forum.electromage.com/user_avatar/forum.electromage.com/zranger1/32/301_2.png) [@zranger1](https://forum.electromage.com/u/zranger1)\
**Post date:** [January 7, 2023, 2:42am UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/30 "2023-01-07T02:42:54Z")

</div>

and I’m back to working on an upgrade for this, since it actually seems like a sane and reliable way to distribute pixel data over wifi. It’ll be a couple of weeks yet 'till an alpha arrives, but here’s what I’m working on:

- support for multiple source protocols. At least sACN and Artnet to start with.
- reliable, automatic connection management (thanks to @pixie’s work on the pixelblaze-client library!)
- Can distribute multiple universes to multiple Pixelblazes in any combination. Send a different set of universes to each Pixelblaze, or the same universes to all.
- simple, readable configuration via JSON file. No programming required under normal circumstances.
- pixel count limited only by network bandwidth and the power of the host machine.

If there are other specific features that anybody would like, this is a great time to ask!

---

<div class="post-metadata">

**Author:** ![bbqchickennn](https://forum.electromage.com/user_avatar/forum.electromage.com/bbqchickennn/32/1952_2.png) [@bbqchickennn](https://forum.electromage.com/u/bbqchickennn)\
**Post date:** [January 8, 2023, 11:01pm UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/31 "2023-01-08T23:01:27Z")

</div>

@zranger1 I’d love to work on the fleet management parts that I had been imagining

---

<div class="post-metadata">

**Author:** ![hololit](https://forum.electromage.com/letter_avatar_proxy/v4/letter/h/5daacb/32.png) [@hololit](https://forum.electromage.com/u/hololit)\
**Post date:** [December 13, 2023, 6:37pm UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/32 "2023-12-13T18:37:46Z")

</div>

Just a small comment on this conversation.

Consider wearables you’d want to be able to map to stage lights. This is a perfect application where wireless “pixel pushing” would be extremely useful, without losing the major advantages of the PB when you want to be autonomous.

At the moment, to sync with software through Artnet or SACN for example, I’m using Wled. But when i want to use it independently… WLED is really weak compared to Pixelblaze.

That’s where it could be useful, especially because i don’t really see other controllers like this on the market.

---

<div class="post-metadata">

**Author:** ![Pixelplanetarorcus](https://forum.electromage.com/user_avatar/forum.electromage.com/pixelplanetarorcus/32/2273_2.png) [@Pixelplanetarorcus](https://forum.electromage.com/u/Pixelplanetarorcus)\
**Post date:** [February 11, 2024, 7:42pm UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/33 "2024-02-11T19:42:05Z")

</div>

Hello, how are things going on setting up Artnet with your framework?

My organization have been struggling with getting Wled working and I keep mentioning Pixelblaze… They say that the main thing holding them back from buying a truckload of pixelblazes is the lack of Artnet support.

---

<div class="post-metadata">

**Author:** ![zranger1](https://forum.electromage.com/user_avatar/forum.electromage.com/zranger1/32/301_2.png) [@zranger1](https://forum.electromage.com/u/zranger1)\
**Post date:** [February 12, 2024, 1:58am UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/34 "2024-02-12T01:58:50Z")

</div>

Thanks for asking! It’s good to know that somebody might be able to use it. It’s been sitting partially completed – between the new startup and the Giant Art Car, I haven’t had a lot of free programming time lately.

I’ll bump it up my priority list, but it’s still likely to be a few weeks before there’s something reasonable to test.

---

<div class="post-metadata">

**Author:** ![zranger1](https://forum.electromage.com/user_avatar/forum.electromage.com/zranger1/32/301_2.png) [@zranger1](https://forum.electromage.com/u/zranger1)\
**Post date:** [March 5, 2024, 12:05am UTC](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766/35 "2024-03-05T00:05:29Z")

</div>

Ok! I’ve just posted the first alpha of Flamecaster. It will route up to 32,768 Art-Net universes to… a highly impractical number of Pixelblazes.

I’ll open a new forum thread with more details, and pictures and video shortly. Meantime, there’s more information in the [repo](https://github.com/zranger1/Flamecaster). If you’re interested, please give it a try!

> **[GitHub - zranger1/Flamecaster: Art-Net Router for Pixelblaze](https://github.com/zranger1/Flamecaster)**
>
> Art-Net Router for Pixelblaze. Contribute to zranger1/Flamecaster development by creating an account on GitHub.

[Previous page](https://forum.electromage.com/t/lightshowpi-and-others-integration-sacn-e1-31-proxy/766.md?page=1)
