LATEST RELEASE:  FPP 7.5 - Download from here -



Welcome, Guest.
Please login or register.
Forgot your password?

+-Site Stats

Total Members: 16443
Latest: Brad Bishop
New This Month: 13
New This Week: 1
New Today: 0
Total Posts: 132537
Total Topics: 16431
Most Online Today: 105
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 1
Guests: 80
Total: 81

F16v5 : Number of different protocols support simultaneously

Started by ihbar, December 23, 2023, 04:03:55 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


I would like to use a F16V5 to drive some pixels, but I have multiple types.  (WS2801, WS2811, RGBW)

On the excel doc, for a F16v5, I see that number of different protocols supported simultaneously is '1 per group of 16 Pixels output'.

Do you know if the 4 Receiver outputs are parts of the same group of 16 ?
I guess that if there are only 2 groups for the F16V5, I can not have 3 types of pixel on the F16V5, even if I add 2 smart receiver. :(  Should I look for a V3 instead ? (But I like the eFuses and return info from receiver and the RGBW support)

I understand that different type pet output like V3 may be too complex, but Would it be possible to have separate type control for group of 8 ?  ::)




for starters - ALL 28xx are one protocol and RGBW is not a protocol so I would be surprised if it is not a 28xx compatible.
Jim Nealand
Kennesaw, GA all Falcon controllers, all 12v Master Remote Multisync with Pi and BBB P10 and P5


Quote from: jnealand on December 23, 2023, 07:39:13 PMfor starters - ALL 28xx are one protocol
Small clarification...ws2801 is a clocked protocol and ws281x is a non clocked protocol. So, if you were trying to run ws2801, it might be differently implemented in the hardware as well as having to send a clock signal to the pixels. I don't know which protocols Falcon controllers consider different but they are in different sections of the protocols supported. And the SK6812 RGBW is listed separately.

IIWM, I would standardize on ws2811 and like protocols so different groups are not a problem. And I'm pretty sure there are ws2811 compatible RGBW pixels so if you want to run RGBW, you should be able to within that group (or have I been misreading the whole RGBW thing?).

The F16V3 is capable controller and if your requirements are such that you need to have one pixel type per output, then you should give it a try. Otherwise, only buy the pixels that fit into your controller's capability.



Thanks @jnealand and @MikeKrebs for your reply.
It is right that RGBW is not a protocol, I have used "RGBW" because I don't have yet the RGBW pixels, but I don't find RGBW in WS2811.

The WS2801 and WS2811/WS2812 are chips with RGB per pixels and as mentionned by WS811 datasheet : "The WS2811 is 3 output channels".
There is a WS28xx for RGBW : WS2814, it is 4x8 bits per pixel, and not in the  supported protocol of the FPP. :(

I will use the controller for charity events, so I don't know what pixel they will have. (At least a mix of WS2801,WS2811 and WS2812)

So if anyone  has tried to put 2 smart receivers on the F16V5, I would like to know if they are in the same group or not. And if it is possible to have 2 different types of pixel for the receivers.


You can have a max of 2 protocol types on the F16v5.

Group 1 - on board 16 ports
Group 2 - the smart receiver ports.

As others have stated, often RGBW pixels will be 281x compatible, so you may not need a different pixel type.  In fact most pixels people have bought in recent years are WS281x compatible.  WS2801 can only be run from the on board 16 ports, WS2801's are getting pretty rare these days.


RGBW using WS2814 is more about effects and sequencing than controllers. The controllers spit out pixel data, they don't really care what the bytes represent. If you get fancy about it (as some controllers will), they need support for rgbw if they are going to reformat the R-B-G-W but I would put that on the effects/sequences instead of the controller to figure out.


While this is true to a point, many controllers determine the number of channels they will need to process and send out on a port by the number of pixels you define to be on the port.  If it is expecting 3 channel RGB pixels and your pixels are 4 channel RGBW pixels, it's gonna get it wrong and be short channels the string needs.

Support FPP

+- Recent Topics

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod