Wifi, FPP Remotes and Falcon Player 10

[silver_ice]

Following up this thread - https://auschristmaslighting.com/threads/brisbane-se-qld-mini-2026-25-july.17433/page-5

So I gave a talk at the Sydney and Brisbane Minis about how to effectively use wifi to enable density and, in the fun cases, run a show across multiple locations. The ;tl;dr is use FPP remote mode and multi-sync and just sync timestamps/timecodes, instead of trying to stream full pixel data across possibly unreliable wifi. The difference is a couple of bytes a second vs 10+ megabytes a second (depending on your show size). It also makes you a bit more resilient on a couple of fronts - splitting your show across multiple controllers, you can lose one and still limp along. Further, you could lose your network for a period of time - things would still run and stay mostly in-sync (until the current track ended). The caveat of course is you need to a) have multiple controllers that can run FPP, or at least speak FPP Remote and b) you have to distribute your media to all your controllers (since playback is controller local).

Anyway, I've been getting into Falcon Player 10 - all the basic stuff is there and still seems to work fine but there are a couple of changes around wifi that may affect you and that is a) the move to the new OS version (Debian Trixie) and not building in 3rd party wifi drivers anymore. This should actually result in broader wifi hardware compatibility as well as making it much easier to have a good idea if your little wifi dongle will work.

AS it turns out, I have 4 x HE123's on the bench at the moment, all with a mix of wifi adapters in Falcon Player 10 and as expected, all working fine - I have a mixture of RTL8188 chipsets (https://www.aliexpress.com/item/100....order_list.order_list_main.23.2b821802r9b74U)

[ 41.985304] usb 1-1: RTL8188FU rev B (SMIC) romver 0, 1T1R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
[ 42.087281] usb 1-1: RTL8188FU MAC: 00:2e:2d:30:76:05
[ 42.141382] usb 1-1: rtl8xxxu: Loading firmware rtlwifi/rtl8188fufw.bin

And Atheros AR9271 chips (https://www.aliexpress.com/item/100....order_list.order_list_main.17.2b821802r9b74U) - these are nice since they have the detachable antenna which wil be nice to connect to a bulkhead connector and put outside the enclosure for my far away controller

[ 10.418142] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980
[ 10.456725] systemd[1]: Finished systemd-modules-load.service - Load Kernel Modules.
[ 10.493430] systemd[1]: Finished systemd-network-generator.service - Generate Network Units from Kernel Command Line.
[ 10.539122] systemd[1]: Started systemd-journald.service - Journal Service.
[ 10.654884] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits
[ 11.382289] ath9k_htc 1-1:1.0: ath9k_htc: FW Version: 1.3
[ 11.406917] ath9k_htc 1-1:1.0: FW RMW support: Off

I've also got a couple of Baldrick8's here - going to hook them up to some of these HE123s to show you FPP Remote can also bridge and make the Baldrick "wireless" if that is of interest.

Anyway, no real point to this post other than to continue the Briz mini thread and throw myself open to questions now that I have a full bench setup with a bunch of different configurations I can try, so if anyone has questions, fire away

 

[Godfree2000]

Its the black magic that people dont understand with wifi links etc. I understand why a lot of people say hardwire it because you can see it, but effectively wifi is the same thing.
I went almost full wifi last year, my wifi bridges were the biggest issue, hopefully I have that sorted this year.....

 

[coops]

We need to convince Baldrick to stick a wifi chip on their boards or a USB port so no need to bridge I do like how the Kulp have that option.

 

[Skymaster]

Getting Wi-Fi design right is not easy.

Always — and I mean always — put your AP at the corner of the yard, never in the middle.

You want all clients to be closer to each other than they are to the AP. For example, the first layout, not the second:

    /----- CLIENT 1
AP +----- CLIENT 2 --- CLIENT 4
    \----- CLIENT 3


CLIENT 1        CLIENT 2
|               |
+------AP-------+
|               |
CLIENT 3        CLIENT 4

This is because all clients need to "hear" each other, as well as the AP. This allows Wi-Fi's CSMA/CA to prevent clients from clobbering each other's transmissions (and they absolutely will https://en.wikipedia.org/wiki/Hidden_node_problem).

In the first example, Client 4 will stop hearing the AP before it stops hearing the other clients. That's what you want.

Multicast over Wi-Fi is also horrendously inefficient. Set FPPD Multisync to Unicast.

Depending on the AP, multicast will either be transmitted once at the lowest/base rate (often 11 Mbps), or replicated and transmitted individually to every connected client — whether they need the packet or not.

And finally: if you can hard-wire it, hard-wire it. Wi-Fi should be the last resort, not the default.

 

[silver_ice]

Multicast over Wi-Fi is also horrendously inefficient. Set FPPD Multisync to Unicast.

Yes and its nice that this is now the default in FPP 10.

We need to convince Baldrick to stick a wifi chip on their boards or a USB port so no need to bridge I do like how the Kulp have that option.

See, my hope is that they _dont_ do this - this goes back to broadcasting pixel data over wifi, which is much more reliant on the dark arts of radio engineering. The bridge mode allows your wifi controller to just sync timing - playback is effectively local to the single hop to the Baldrick connected to the BBB or Pi ethernet port. Pretty easy to do this on any controller that runs FPP

And finally: if you can hard-wire it, hard-wire it. Wi-Fi should be the last resort, not the default.

Eh, I enjoy not having the extra data run everywhere - for me this doesn't hold true, so long as you are just doing FPP multi-sync (caveat all the things that encode this as a pre-req). Of course, for raw pixel data (DDP/E.131/whatever), yes big pref for hardwired. I just bring this up since I have more success with mutlisync over wifi vs hardcoded with those crappy bulkhead RJ45 connectors And to dispel the idea that all wifi is bad when it comes to show setup.

Anyway, to each their own.

 

[coops]

Why would you have to automatically broadcast pixel data if the chip's onboard?

If the controller is running FPP Remote, you still only need to send the MultiSync timing/sync information. That eliminates the need for a bridge entirely while keeping pixel playback local to the controller.

I run Pi's and Kulps this way. If I'm adding a bridge just to get Wi-Fi to a controller, I'd almost rather just run Ethernet — it's another device to power, configure, test and troubleshoot.

Baldrick with built-in Wi-Fi (or a USB port) would be a pretty sick little FPP Remote package, especially with its ARM processor.

I'm also with @silver_ice on the Ethernet point. A lot of these controllers are only 100 Mbps anyway, while a decent 5 GHz Wi-Fi link can potentially smash that IF you have the RF coverage. But either way, you're only sending sync information, so the traffic is tiny and 2.4 GHz is plenty.

 

[silver_ice]

Baldricks don't run FPP so they can't (in their native firmware) operate in that mode -they dont have storage, cant store sequences etc (even with a mass stor usb option they'd need to actually be able to understand/parse fseq. They are pixel data receivers and pushers. Unless I'm misunderstanding what you're getting at?

 

[coops]

Baldricks don't run FPP so they can't (in their native firmware) operate in that mode -they dont have storage, cant store sequences etc (even with a mass stor usb option they'd need to actually be able to understand/parse fseq. They are pixel data receivers and pushers. Unless I'm misunderstanding what you're getting at?

Ah fair, well it'd need a few extra chips hahaha

 

[Skymaster]

Using Multisync ties you in to the FPP ecosystem, if you're using any non-FPP based controllers, you'd likely pushing industry standard (E1.31/DDP) protocol data to it.
I believe the Falcon and Genius based boards _can_ run as remotes, but then you have to add storage to them. The Falcons are also only hard-wired, the Wifi in them is for configuration only.

The difference is a couple of bytes a second vs 10+ megabytes a second

You're very unlikely pushing 10+ megabytes / 100 megabits of traffic.
Even the biggest controllers out there that can do 48 ports, only do around 32,000 pixels, so at 40fps, that's 3.9 million channels per second.
Add DDP / E1.31 overheads and you're looking at 35 Megabits per second per controller.