Uncompleted project but hit a milestone. Also a question

Show and Tell
#1

So in my infinite wisdom to follow MaltWhiskeys 16x16x16 cube project, I finally dove in and if you want to look at what 4200 LEDs that have been bent and cut look like, here ya go. Those bowls probably weight about 3 lbs a piece. I’ve been keeping track of the time and it’s taken 60 hours just to prep them. It took MW 80 hours to do it but I got friends to help and also spent just 10 hours sharpie marking the front side because squinting at which side is which after they’ve been cut is awful after about 10 minutes. Also fun fact! Just the cost of the LEDs eclipsed the entire cost of the 8x8x8 cube including tools and soldering irons I purchased!

Also for those who have seen the video of his project, I’m going to use the PixelBlaze, or more likely multiple PBs to push it. Mainly because his Teensy uses C/C+ and I don’t know anyone who knows those (and I’m already struggling with JS) but I know multiple people that know Javascript plus the amount of support on here so here’s a question! It’s gonna be 4096 LEDs on 32 different channels. Were definitely looking at multiple output expanders and technically I know 1 PB can handle that number of LEDs but how would that transfer to framerate? How many in theory might I need to handle that many LEDs if anyone has a guess?

I’ve done a bit of research on the forums and I know there’s going to have to be code adjustments to the patters if more than one PB is involved. How significant are we talking theoretically. Thanks yall!

image
image1504×2016 209 KB

2 Likes
#2

LEDs by the pound, very nice!

You can experiment with a PB to know empirically, just set it up as if it had all the pixels and expanders you want.

Theoretically, you have on average 48k pixels a second of pattern rendering capability, so physical LEDs aside, you would get on average 48k / 4096 ~= 11.7 FPS.
The data rate on the output expander bus is limited to about 66k pixels a second. So even with the simplest of patterns, you’d never get over about 16 FPS.

For some kind of animations, that might be OK, but anything quickly moving you’d probably want more, and that means multiple PBs. Assuming you divvy it up evenly, you can scale those numbers accordingly. Throw two PBs at it and double those numbers, four for a 4x gain. Since you have 32 possible output channels, you could scale that all the way up to 32 PBs, though that would be quite overkill.

Another way to think of it, your 8x8x8 is 512 pixels, and 4096 is 8x as many, so throwing 8 Pixelblazes at it would give you the same FPS as your 8x8x8.

2 Likes
#3

Looking sweet :beers: it’s a lot of work just bending and cutting those leds.

Using many pixelblazes wouldn’t that complicate things a lot? How do you sync all those channels? You know the single teensy runs the cube at 188fps right? And that barely uses any processing power. And JavaScript and C++ isn’t that different. Maybe learn some C?

Anyway i’ll keep an eye one this, good luck :+1:t2:

1 Like
#4

Honestly I’m still considering which way I’m gonna go on it. I had a thread on it a month ago or so but by far the most daunting thing about this isn’t building it but the programming aspect of it. I’ve been doing some crash courses and making some progress but I am still pretty hopeless with programming so at least for the time being I’m kinda at the mercy of others when it comes to patterns and configurations. Then again, I’ve only got looks around my disaaster workzone 5 planes completed so I got plenty of time to figure it out.

#5

Thank you sir! I’m going to investigate a little further down the line and hook these 2 I got and see how that comes out. Definitely more trial and error this time around.

#6

On this note, a software feature request… While the FPS numbers are great, would love an ability to see where the time was spent in the various parts (to help know where to debug/tune…). I’m presuming the 3 parts are BeforeRender, Render, and the internal push out the bus. I’d presume the first two have to be done serially, and possibly the third can be run in parallel with the next cycle of the first two. So a debug screen with BR: 27%, R3D: 73%, and push: 43% (meaning it’s using 43% of the time available to push said pixels, i.e. not the choke point)

Hardware side, I did a bit of research and if I understand right, an esp32 can drive multiple gpio pins simultaneously. Depending on where the choke point is processing wise, maybe it could make sense to have a PB+ with say 4 outputs for some of the more complicated projects out there. Not that the Fire solution doesn’t work, but it does restrict some features of the patterns and makes sensor based things a bunch harder to coordinate. Or maybe a PB4 feature down the line, market forces and timing allowing.