Flamecaster: Art-Net to Pixelblaze Router

Patterns and Code
1

Hi!
I’ve just released the alpha version of Flamecaster - The least visually interesting thing you’ll ever see at a light show, but nonetheless, potentially helpful in some cases!

Here’s a quick overview:

What is it?

Flamecaster receives LED data from Art-Net sources and distributes it to one or more Pixelblazes.
It is CPU efficient, and is designed to be reliable and resilient in the face of network and device changes. It can run unattended in the background, and can be controlled remotely via its web interface.

What is it for?

It’s ideal for installations of a few thousand pixels that you need to control with Art-Net lighting
software, in situations where it isn’t practical to run wired Ethernet to controllers. Camping shade structures, small mutant vehicles, display booths, and other portable installations are good examples.

Do I need it?

No, unless you know you want to use Art-Net controller software with your Pixelblazes. A flock of self-coordinating Pixelblazes can handle similar pixel counts, and may be simpler to configure for many projects of this sort.

Rationale:

This is about improving wireless reliability by more efficient network usage.

When transmitting pixel data, Art-Net sends many small UDP datagrams at a very high rate. As the number of pixels increases, the sheer number of packets can quickly saturate a network, which is why large Art-Net installations are typically run over wired Ethernet, using complex routing and switching infrastructure.

Wi-Fi is particularly susceptible to this problem, because of the way it works. The more traffic on a network, the more likely it is that a packet will collide with another packet and have to be retransmitted.

Flamecaster is designed to minimize the number of packets sent over the wireless network. It receives the small Art-Net packets, combines them as necessary and sends them to Pixelblazes as complete frames via websockets - generally larger packets sent at a lower rate.

If you run Flamecaster on a wired Ethernet segment, or better still, on the same computer as your lighting software, you can keep Art-Net packet traffic totally off your Wi-Fi network! This can be a major gain in reliability vs. sending Art-Net directly to WLED or other Wi-Fi-based controllers.

For more information:

For details, installation instructions, source code and other documentation, see the Flamecaster repo on GitHub:

5 Likes
2

THANK YOU !!!
Exactly what i was looking for !

Gave a few tests. In short it does not work (yet) for me :slight_smile:

INSTALLATION
Since I’m a noob with Python and I struggled to find basics (never ran python before), i will write it here in case someone is in the same position as me.

  1. Download the zip from Github using the green “code” button
  2. Extract the zip in an easy to access folder
  3. Open a command line (Windows+R, Type “cmd”) and install python (just write python in there and it should open the Windows store)
  4. Install the needed packages from the readme using the pip command (copy this code in the command line) pip install numpy websocket-client remi. Note that if you get a warning about a need to add to some “PATH”, use this link How to Add Python to PATH – Real Python to understand how to add to PATH the folder it gave you a warning on
  5. I needed to install as well setuptools using: pip install setuptools when notified it was missing
  6. Then at this point I just needed to navigate to the installation folder of Flamecaster (use CD then folder names of your hierarchy and TAB to auto complete / use ls or dir to list the folders), then execute with python -m Flamecaster

SETUP
I run 201 RGBW SK6822 pixels on my Pixelblaze at 192.168.1.60.
I’m trying to run it from Resolume Arena and my setup works fine with WLED (disabled from my network at the moment to avoid issues).

FLAMECASTER
First, for some reason, putting the fixture as RGBW in Resolume does not work. I get wrong colors. But putting as RGB actually creates the correct colors, and lights up the white pixels as needed.

Since I have more than 170 pixels, I created 2 lamps of 170 pixels in resolume:

  • Universe 1 / ch 1
  • Universe 2 / ch 513

Then configured as below. I have several problems:

  • I cannot have artnet devices in the same wifi network indeed. If I activate other Lumiverses sending to Wled devices, it’s very choppy and glitchy (devices don’t show exactly what they should). So let’s disable it for the moment, but to note it’s not only a problem of speed, it seems it’s polluting other artnet devices.
  • The second universe does not show up (only the first 170 pixels light up)
  • I only see a fixed image which represents a snapshot of Resolume state when I reload manually Flamecaster. Does not animate at all.

PB
PB1231×263 22.9 KB

Artnet
Artnet1237×334 22.7 KB

preset
preset1247×766 36.2 KB

Resolume
Resolume592×522 20.8 KB

Did I miss something ?

1 Like
3

Thanks for trying this out! I tested with XLights, Chromatik/LXStudio and Processing, but not with Resolume (is there a demo version that will drive live output I can try?) , so I’m not 100% sure how it wants to be configured, but I can give you a couple of things to try:

  • RGBW vs RGB: This is expected behavior. The Pixelblaze takes care of color order conversions for you, so if you’re running an output expander, you can even mix LED types with different color orders, and have your controller just send RGB.

  • Not sure what 0.0.0.0 as a target address will do in this case. It is usually used for listening, and indicates all interfaces on the computer, so it might work if there’s only one network adapter. But try 127.0.0.1, or the actual IP address of the computer flamecaster’s running on.

  • Flamecaster uses 0-based channel indexing so try setting your start channels to 0 and 512. (And don’t forget to press “Save” afterwards!) I’ll check on this and make sure it isn’t causing any internal buffer weirdness. It might well be.

  • It isn’t actually doing anything that should interfere with other traffic on a strong wifi network. The only thing I can think of is, if you’re broadcasting or multicasting to your WLED devices, try having Resolume unicast to them instead. Multicast over wifi has a huge chance of packet loss anyway, and the extra websocket traffic from Flamecaster to Pixelblazes might be enough to push it over the edge.

1 Like
4

Oh, just noticed – to see the second universe, you’ll need to set the pixel count on the Pixelblaze’s screen to show the actual number of connected pixels - 340 in this case. (I need to have the UI either get this number directly from the Pixelblaze, or calculate it from the universe data. Will add it to my TBD list!)

5

OK I made some progress based on what you said:

  • Modified the Pixelblaze to 170 Pixels for the test (in settings, result is that it disables the end of my strip)
  • Send Resolume output to 1x 170 pixture
  • Indeed putting 0 as first channel in Artnet settings of Flamecaster works even though it stays at 1 in Resolume (you can’t put a DXM channel to 0)
  • Zero output (black) if I send to my PC IP or 127.0.0.1, but i do have the correct output if I send Resolume to 0.0.0.0 !

However even though Flamecaster says 30 FPS input and 29.7 FPS output, it’s a bit laggy (where WLED + Artnet is pretty fluid).

Now i put back:

  • 201 LED on PB: no change, output stays the same (correct but a bit laggy)
  • 201 pixels under the Pixelblaze in Flamecaster: no change, output stays the same
  • Add second fixture under universe 2n channel 512 or 512: no change, output stays the same
  • Add second row in Artnet menu of Flamecaster. Whatever the parameter (Universe 0 or 1), channel (512 or 513) and the index / number of LED: animation freezes and only updates manually when i click reload. I tried every combination, didn’t work, and at some point the PB crashed repetitively and lost all settings (number and type of LED)…

So so far, works with 1 universe only but a bit choppy: doesn’t feel like 30 fps.

6

So after testing, for now the answer is “don’t use Resolume”. Try TouchDesigner, or Chromatik. Or Unreal Engine 5.

Resolume has a very idiosyncratic, not very configurable way of supporting Art-Net which is focused on older hardware solutions with IP addresses in a fixed range. It does not happily support unicast which is more-or-less necessary to make Flamecaster relevant. (I think it’s actually switching to sACN, which I don’t currently support, when you specify a unicast IP address.)

Using 0.0.0.0 makes it broadcast what looks like Art-Net version 2. Great, but everybody else is on on version 4 now. I’ll get around to figuring out what they’re doing, and probably add sACN support, but it’s not going to be right away.

I’d thought that Art-Net was going to be a solid least-common denominator that everybody supported, but things are just never that simple, I guess.

7

Ok, I’ve just pushed a new version to github that should make it easier for Resolume to work. There are a few subtle gotchas though. You’ll need to:

  • set the target IP address to the actual IP address of the computer Flamecaster’s running on
  • change Flamecaster’s Artnet IP address to the same one (You can use the WebUI and press save, or just edit the config file and restart.)
  • In Flamecaster, make sure you start at Art-Net universe 0 (not 1)
  • Also in Flamecaster, start channel should always be 0. In every universe. That tells it where in the data packet to start looking for color data to send to the Pixelblaze. You’ll need to use destindex (0 and 512) to tell it where on the Pixelblaze to put the data.
  • go to Resolume’s Arena/Preferences/DMX panel and be sure that “Network Adapter” is set to your actual network adapter. Not to localhost. If Resolume and Flamecaster are both running on the same machine, they have to both be using the same network adapter. That’s the part I missed earlier.
    20240311_163608_1
1 Like
8

Thank you very much for the update ! it works fine now up to my 201 pixels.

But indeed veeeery sensitive to Wifi quality: my Pixelblaze is in the metal base of a floor lamp and struggles to receive wifi it seems.

I did a few tests:

  • Lamp 4.5m from router (-60 dB); choppy performance, i can see lost frames pretty much every second
  • If I put m lamp horizontally (no metal cover under, -47 dB): acceptable performance, but 30 FPS.

So 2 follow up questions:
1- Is it possible to push to 40-50 FPS for added fluidity ? I assume it will only worsen my Wifi issues ?
2- Any way to improve Pixelblaze reception without moving it, for example is it possible to connect it to an external antenna ?

Thank you !

9

Wi-Fi signal quality is the limiting factor for framerate. Given a strong connection, it is definitely worth trying at 40+ fps to see what it looks like. It does increase net traffic though.

On external antennas, it is possible, but I wouldn’t unless you’re a very skilled solderer, and also feeling extra steady and confident on the day you try. I’m reasonably good with small electronics and have a 50% success rate doing this, where failure means that the Pixelblaze is ruined. It is very easy to overheat and destroy the antenna traces.

See this forum thread for more details and some tutorials:

Metal enclosures are just terrible for radio. The best thing to do would be to move the Pixelblaze out of the metal lamp base. Some of the things I’ve done when working with metal lamps:

  • use wall-wart or enclosed brick-style power supplies rather than the metal frame, and have most of the lamp’s cable run carry D/C rather than A/C. That way, you can put the Pixelblaze in a small plastic enclosure on the cord and run 3 conductor cable (+5v, GND and Data) from the PB enclosure to the actual lamp.
  • use a Pixelblaze Pico, which is more easily concealed in the upper, plastic portion of the lamp. (See picture below.)
  • In one case, where the light was safe from being accidentally kicked by stray humans, I cut a small slot in the metal, insulated it with liquid vinyl and mounted the Pixelblaze so its antenna was sticking out through the slot.

20240224_160446
20240224_1604461920×3950 245 KB

2 Likes
10

Wi-Fi signal quality is the limiting factor for framerate.

LedFX + WLED (Sacn) works flawlessy though, not one frame lost and visibly higher framerate (I assume 40 FPS since it’s WLED). I will do some tests at 40 FPS with my PB to see if it works.

Thank you anyways for all the support, this new update is really cool ! I can see a lot of potential for wearables.

11

@hololit ,
There’s a good chance that anything else wifi will also choke if you enclosed it in metal.

Multicast UDP won’t get more packets through, but it will drop frames.

I have some Pixelblaze 4MB with external antenna connections (IPEX / uFL), and a few inexpensive external antennas. I hope to get these in the shop soon. That would let you drill a hole for an antenna to attach, or run it to an internal area of your lamp that isn’t encased in metal.

1 Like
12

There’s a good chance that anything else wifi will also choke if you enclosed it in metal.

Indeed, but if i compare WLED + LEDFX (SACN if i’m correct) or even in Artnet in similar conditions (both outside the casing of my lamp), i still have performances difference. I will do deeper tests occasionnaly to see if it comes from wifi, controller or maybe my computer (highly doubt this one).

I have some Pixelblaze 4MB with external antenna connections (IPEX / uFL)

You really have a solution to everything do you ? Amazing, i’d be super interested to try to put an antenna out.