SP511e - can't run full 300-string LEDs as stock firmware; inability to "loop fill"

I lined the walls of my bedroom with addressable LEDs (small half-width 5v LEDs) and hooked up beefy wiring to power it all. Worked great. The stock firmware left a lot to be desired though (e.g. no presets to call Alexa with; no Home Assistant integration). That led me to WLED firmware.

On the stock firmware, effects seemed to be grouped in repeating patterns of 50 LEDs or so (patterns/effects would repeat every 50 LEDs), but somehow the firmware was able to loop the pattern throughout any length of string you want (I think they advertised 9000 LEDs or some absurd number?). Infinite string length by means of repeating the data in memory.

WLED, though, seems lacking this capability: it produces one gigantic non-repeating canvas of LEDs (wow!), but yet… I know this tiny hardware cannot support my whole long string.

I can’t seem to find any setting that lends itself to “save memory by repeating the pattern” or otherwise. Anything I try to do consumes memory – and I’m sitting here with 260 LEDs configured, consuming all 3000 bytes, with about 80 LEDs on my string effectively “zombies” (currently white from the previous firmware, but would hopefully stay dark/off if I power-cycle the strip). Unable to go past 260 as I run out of memory.

You can:

  • wire individual strips in parallel, this will give you less logical LEDs and will provide “repeating” patterns
  • open up SP511e and connect GPIO1 to LED output (this will reduce memory requirements for LEDs) instead of GPIO3 (which is what SP511e uses)

GPIO3 uses DMA and hence its RAM requirements are 5x larger than that of GPIO1. There is nothing you can do about that.
I will not speculate what original firmware does but apparently they do not use DMA if they allow 9000 LEDs on GPIO3. Perhaps the also don’t do a lot of other things WLED does.

I am sorry to disappoint you but GPIO3 is useful for about as many LEDs as you have figured out the hard way.

If you are brave and know how to code C/C++ you can modify the limits which WLED imposes, compile source yourself and hope for the best.

You may want to check this as well.

Hmm. I’m just wondering how on earth they manage to do that repeating effect with the LEDs. I’m loosely familiar with how the protocol works – each LED has a tiny memory that carries its input in, and when it’s full, it reproduces the past signal on its output, so the whole chain effectively works as a large block of memory.

Now, how they sync their activities (such that they don’t flicker as the data streams through each one), I’m not sure - similarly, I’m not sure if there’s a way they’re sending a sort of “loop” command to only send 50 LEDs worth of data with a “pass it along” bit, perhaps.

What WLED does is the same as I’d ever seen from Arduino-based systems that have a fixed length of LEDs, and a large canvas to fill them all. Any LED past the end of the configured array, somehow stays blank/untouched, as if the end of the string has a “reset” bit on it. I’m wondering if there’s something WLED is missing that this original firmware figured out, w.r.t. this “loop to fill string” behavior. Maybe the original firmware just doesn’t send this reset bit, and it just cascades the last frame forever?

Really not looking forward to hacking up the hardware any further, but if it’ll let me use WLED (which is amazingly beautiful) with this setup, then I’ll just have to.

(I actually already have my LEDs set up in 2 parallel strings around the room - it’s actually a pretty small room, but amounts to around 600 LEDs in total, split in two equal runs around half the room each. Makes for some really nice, symmetrical effects. :slight_smile: )

Why not just buy an Esp8266 or an Esp 32 and and eliminate the problem all together?

If you don’t want to solder or something you can either buy a prebuilt shield w/Esp or get one of the generic shields that is a breakout board with screw terminals.