8 strings from a single Raspberry PI.

[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]

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

Yes, they were able to leverage a video buffer for the outputs instead of using the PWM timer.

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.

I think you can still get 8 x 800

[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.

[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?

[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.

[algerdes]

Thanks.  Good information to have.

[gsrunion]

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.

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)

[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.   

[gsrunion]

Roger