News:

Server migration complete, Welcome to version 2.1.1

+-+-

+-User

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

+-Site Stats

Members
Total Members: 16443
Latest: Brad Bishop
New This Month: 13
New This Week: 1
New Today: 1
Stats
Total Posts: 132532
Total Topics: 16430
Most Online Today: 87
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 0
Guests: 56
Total: 56

8 strings from a single Raspberry PI.

Started by gsrunion, July 25, 2023, 06:00:02 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gsrunion

So I have been out of the game over a year because we had a little one in the fall last year and I wasn't going to spend the time to do lights. It appears that a lot has changed with regards to the capabilities of single Raspberry PI. Last I checked a PI could push 2 strings of ~1000 WS281x Pixels (via rpi_ws281x) and when I looked yesterday it looks like boards that can support up to 8 strings pixels.

1) Was there a discovery of a mechanism that allowed more efficient use of the RPI hardware to push more pixels or do these many string PI hat utilize extra circuitry to up the capability?

2) I have handfuls of RPI Zero Ws that I have used for years. What kind of pixel numbers can they push with say, a Kulp K8-PI? I presume it wouldn't be the full 8x800 that a more powerful PI could push.

Poporacer

Quote from: gsrunion on July 25, 2023, 06:00:02 AMWas there a discovery of a mechanism that allowed more efficient use of the RPI hardware to push more pixels or do these many string PI hat utilize extra circuitry to up the capability
Yes, they were able to leverage a video buffer for the outputs instead of using the PWM timer.

Quote from: gsrunion on July 25, 2023, 06:00:02 AMWhat kind of pixel numbers can they push with say, a Kulp K8-PI? I presume it wouldn't be the full 8x800 that a more powerful PI could push.
I think you can still get 8 x 800

If to err is human, I am more human than most people.

dkulp


Actually, it's now up to 24 strings on the Pi.   The K8-Pi also has 12 differential outputs so 20 strings total.   All at a full 800 pixels per string.

I'm not sure if the ancient armv6 processor on the older PiZeroW can do the full 20x800 along with the fseq decompression and such.   It might be able to, I'm just not really sure as I haven't tested it.
Daniel Kulp - https://kulplights.com

algerdes

Not trying to hijack the thread, but a question came to mind reading Dan's response.

Was the K8-Pi (with it's 20 strings total) designed for any specific model of the Raspberry?  Like, perhaps, the Model 4?  Or is its use on a 3B+ (or 3B2, or ...) acceptable to maintain that number of outputs?
Sequencers: Vixen3 and xLights
Players: FPP and xSchedule Controllers:  Renards - SS24/SS16; E1.31 - San Devices E682 - Falcon F16, F4, F48 - J1Sys - DIYLEDExpress E1.31 Bridges.  Much more!

dkulp

It's been tested with Pi3B+ and Pi4's.     The main issue has been Pi availability, but that seems to be easing.

In general, I test mostly with the Pi4's as I have several of them.   The only major issue with the Pi4 is that the hat can trap some of the heat so adding heat syncs is a "good idea".   The Pi3B+ doesn't generate as much heat.
Daniel Kulp - https://kulplights.com

algerdes

Sequencers: Vixen3 and xLights
Players: FPP and xSchedule Controllers:  Renards - SS24/SS16; E1.31 - San Devices E682 - Falcon F16, F4, F48 - J1Sys - DIYLEDExpress E1.31 Bridges.  Much more!

gsrunion

Quote from: dkulp on July 25, 2023, 08:01:13 AMActually, it's now up to 24 strings on the Pi.  The K8-Pi also has 12 differential outputs so 20 strings total.  All at a full 800 pixels per string.

I'm not sure if the ancient armv6 processor on the older PiZeroW can do the full 20x800 along with the fseq decompression and such.  It might be able to, I'm just not really sure as I haven't tested it.
Is there more technical documentation on K8-Pi somewhere, or perhaps a forum specific to it?

gsrunion

Secondly do the BBB Smart Receiver v2 work with the KP8? I know it say BBB right there in the name but at a glance it looks like a one input version of the SRx2.

JonB256

Yes, the BBB Smart Receiver V2 will work. Will also work with the Falcon boards (F16v2 and newer, F48v2 and newer)
Long time Falcon, FPP and xLights user

gsrunion

So in theory I should be able to daisy chain in this manner [K8-PI] -> [ BBB SR ] -> [ BBB SR ] -> [ BBB SR ] 
                                                                                          8                4                   4                   4         = 20 Strings

correct?

Would I be able to configure things to where I only used 4 ports on the K8 and trade that for another smart receiver in the daisy chain? This is where some technical docs would be helpful.

tbone321

 Yes, you can do that and you could also add a 4th SR and use them to save ports on the K8 but there are some things to keep in mind.  Each of the ports on the K8 are full ports and will support the full number of pixels listed which I believe is 800 at 40FPS.  The 3 smart receiver connectors also offer 4 ports each that also support 800 pixels if you are only using 1 card per connector for a full controller support of 20 ports (not including the expansion card).  If you daisy chain smart controller cards on those connections and you can (up to 6 per chain), then things change a little bit.  

When you daisy chain smart receivers, they are still all using the same 4 ports on that connector and are sharing the number of pixels between them.  For example, if you were to put a single SR on the first connector on the K8, your SR would have ports 9, 10, 11, and 12 and each would have support for up to 800 pixels.  If you were to add a second card to the chain, then the first card would become 9A, 10A, 11A, and 12A  and the second card would be 9B, 10B, 11B, and 12B.  The 800 pixels per port would then be shared between the A and B outputs for each port.  If you were to add 4 cards like you suggested, you would have an A, B C, and D connection for each of the 4 ports and all 4 of them would be sharing that same 800 pixels per port.  They do NOT however, need to be defined to the same number of pixels per output.  You could define 9A for 600 pixels, 9B for 100 pixels, 9C for 50 pixels and 9D for 25 pixels and it would work just fine since the total number is less than 800.  If you were to define 9A, 9B, 9C, and 9D all  to 250 pixels, the definition would fail because you have exceeded the 800 pixels per port.

gsrunion

Thank you for the in depth reply. So there are some nuances to consider but there is loads of flexibility to be had there. That was what I was wanting to confirm.

gsrunion

You mention expansion board. I see the KP8 has the header but I am not seeing a Kulp expansion board.

dkulp

It's the Falcon v3 expansion available from pixelcontroller.com.   That said, on the K8-Pi, if you use the expansion, it currently shares pixel data with the onboard ports so it would reduce the pixel counts on the other strings.   
Daniel Kulp - https://kulplights.com


Support FPP

+- Recent Topics

No RPIW281x on FPP 7.5? by Steve
Today at 02:19:36 PM

Second WS* strand not working? by HumanDactyl
Today at 11:02:08 AM

FPP 8 ui issues by Poporacer
May 19, 2024, 08:59:34 PM

Does FPP only suport panels listed in the single panel size drop down list? by Rubbermonster
May 18, 2024, 07:54:19 AM

Linsn receiver card setup by darylc
May 17, 2024, 05:55:46 AM

Control ESPixelStick with FPP (it's work with xligth) by Sawdust
May 15, 2024, 08:39:34 AM

Falcon F16V4 not receiving FPP data by tbone321
May 14, 2024, 09:43:33 PM

Power Draw for Board by darylc
May 11, 2024, 08:47:52 PM

Ethernet ports stopped communicating with pc by StickyWicket
May 10, 2024, 06:00:58 PM

Big Buttons update! by ScaryJerry
May 10, 2024, 11:49:11 AM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod