Maximum refresh rate on 16x16x16 ?

[Mark Kriegsman]

Hi L3D'ers!

I know that on the 8x8x8 (512 pixel) cube, all of the WS2812B LEDs are sent data from a single pin.  Given that maximum data rate on the WS2812Bs, the fastest that they LEDs can up refreshed is a bit faster than 60 updates-per-second or so, which looks really good and smooth.

I'm wondering about the 16x16x16 cube.  If all of the pixesl are WS2812B's, and they're all fed from a single pin, the maximum update rate for the whole cube would be less than 10 updates per second.

So my question is this: are all of the WS2812B's on the 16x16x16 cube all driven from a single I/O pin?  If so, what's the fastest update rate that you're actually seeing in practice?  Or are the WS2812B's divided into separate parallel strings, driven in parallel from multiple I/O pins to achieve a faster overall refresh rate?

FastLED supports parallel output to WS2812 chips on the ARM/K20 (as used in the Teensy 3.x), but not at this point on the ARM/STM32 (as used in the SparkCore).  But in any case, it only even matters if the 16x16x16 cube is wired to drive the LEDs in parallel strings. So: what's the wiring on the 16x16x16?  Multiple parallel strings, or all 4096 pixels in one serial string?

[Alex Hornstein]

Hi Mark,

Good question.  With our current design, we have the LEDs split into four groups of 1024 LEDs each, for exactly the reason you mentioned.  This would give us ~30fps voumes/sec output with the WS2812B LEDs.  We’re doing our first tests in the coming weeks with Spark’s first prototype photon processors, and we’ll learn more about how well the new spark processor can handle the calculations for a 16x volume and stream the data to the LEDs.  If the only issue is the data rate going to the LEDs, we could split the LEDs into 8 groups, so we’d get the same refresh rate as the 8x cubes.  If the processor itself chokes on the calculations, we’ll look into using a more intense brain.

If you want to check out the eagle files directly for the 8x or 16x cubes, they’re up in the hardware repo on github.  The 16x files are in this folder.

—alex

--
You received this message because you are subscribed to the Google Groups "cubetalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cubetalk+u...@googlegroups.com.
To post to this group, send email to cube...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cubetalk/fadb9057-c594-451d-a67d-3de555d34d18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Kriegsman]

Thanks for the reply, Alex!

30 updates per second for 16x16x16 will be a beautiful sight to behold!   Going parallel sounds like a great design choice.  I suspect if you can get 4-way or 8-way parallel output from the MCU board, you'll be able to do a good amount of animation with the processing power of the SparkCore or Photon-- no computational fluid dynamics or 4-D simplex noise (well... not without a little tweaking ;) but relatively shallow, integer-based animations should be fine.  

Thinking about RAM, now too... a single full-cube RGB buffer will be 12K, so more than half of the 20K SRAM on the STM32F103CB will be used just for that.  Not a lot of headroom, but totally OK for lots of animations that don't require a lot of secondary backing memory.  For stepping up the RAM, the $20 Teensy 3.1 (MK20DX256 ARM Cortex-M4) has 64K RAM, but no inbuilt Wifi -- so that's good for some applications but not everything, and it'd miss out on the whole CubeTube angle.  There are Teensy3-based boards with built-in WiFi (e.g., the Mini Foofy https://www.tindie.com/products/sharedcircuits/mini-foofy-small-wifi-development-board-powered-by-teensy/ ) but at they come at a premium. 

Tradeoffs, man!  They're everywhere!

Anyway, thanks for the insights, and let me know if Daniel Garcia or I can help out (we're the "FastLED" guys).

-Mark