Open-Source PIXEL LED Artnet sACN Controller project > Ethernet, 16 universes, 4 outputs, 5~24v!

Ernie -
As I recall, changing the PC<->AP connection from WiFi to wired Ethernet also resulted in a significant improvement in the number of 'connections' that could be driven per AP.
 
Actually it partly is due to WiFi. With the way WiFi is specified and typically configured, there is very limited bandwidth for broadcast data (typical E1.31 usage). That pushed people to start using Unicast UDP which is treated as lower class data than TCP and placed on slower queues. By upgrading to a configurable AP image and adjusting the settings, people got the APs to work. Not a good solution. Using fsync reduced the load to 40 small messages / second no matter how many devices were connected.
 
That's not what I'm asking, my question was poorly phrased. Are there a lot of pixels per controller (in multiples of 100's), or just a few (perhaps 100 each or fewer?

IDK, is this not enough channels? Like I said, before, I couldn't connect more than 10-13 IP's and there was lag. After, I could connect at least 60 and no lag.


Channel
# of Pixels
IP Address
1​
240​
192.168.1.6​
2​
192​
192.168.1.7​
3​
1260​
192.168.1.8​
4​
9​
192.168.1.9​
5​
24​
192.168.1.10​
6​
24​
192.168.1.11​
7​
24​
192.168.1.12​
8​
24​
192.168.1.13​
9​
24​
192.168.1.14​
10​
24​
192.168.1.15​
11​
24​
192.168.1.16​
12​
24​
192.168.1.17​
13​
24​
192.168.1.18​
14​
1080​
192.168.1.19​
15​
915​
192.168.1.20​
16​
171​
192.168.1.21​
17​
171​
192.168.1.22​
18​
171​
192.168.1.23​
19​
171​
192.168.1.24​
20​
171​
192.168.1.25​
21​
171​
192.168.1.26​
22​
171​
192.168.1.27​
23​
171​
192.168.1.28​
24​
171​
192.168.1.29​
25​
171​
192.168.1.30​
26​
108​
192.168.1.31​
27​
108​
192.168.1.32​
28​
108​
192.168.1.33​
29​
108​
192.168.1.34​
30​
108​
192.168.1.35​
31​
108​
192.168.1.36​
32​
108​
192.168.1.37​
33​
108​
192.168.1.38​
34​
108​
192.168.1.39​
35​
4050​
192.168.1.200​
Total
10644
 
As I recall, changing the PC<->AP connection from WiFi to wired Ethernet also resulted in a significant improvement in the number of 'connections' that could be driven per AP.
At that point, WiFi was unusable, even it I just had a couple of IP's connected.
 
Even wired can get into trouble as the number of channels goes up. My smallest pixelstick has 576 pixels on it and it goes up from there. My smallest F16 has 3000 pixels.
 
Ernie,
Thank you. That was quite enlightening, especially since that mixture of pixel counts would have led to a mixture of small and big packets.
 
There's also the saying, "Don't fix it if it ain't broke."

Try this Google search: "Issues people have with FPP every year."
 
I run FPP 5.2. Have been running it without issue for ~7 seasons. No plan to upgrade anytime soon. I did see those complaints and I agree, the version I was using had what I needed and there is no reason to upgrade. With that said, there will eventually be a version of the PI that will force me to update.
 
I have at least one of each Raspberry Pi Zero / Zero W, 3, 4, and 5 that will run FPP. Someday, maybe I'll need to upgrade too. So far though, going cheap is working out fine.

People have been telling me that just about everything I do, doesn't work and maybe some day, it won't.
 
I'm glad controllers are still generally supporting E1.31. The XL world seems to have almost exclusively moved on to DDP. A couple years ago I asked in the LOR forums if they would consider supporting that protocol, and was essentially told "no we are not considering it"
 
When I first started using pixels in 2012, I tried E1.31 Multicast. I think at that time that's all that Sandevices supported.

My pixel things (controller and computer) were all hardwired, but just turning on E1.31 data brought my whole home WiFi network down.

Thankfully Sandevices came out with a Unicast solution shortly after and I've been using that ever since.

I really don't want to have to go crazy with fancy network configs for the display.
 
Back
Top