Quad Blade Question

I’m not sure if this is the right category… please move as needed.

I have a question about building a quad blade–how bad would it be (data lag) to run the data wire back to the hilt side to have all four strips running in the same direction and using subblade rather than using a zigzag formation with subbladereverse? I’m starting on some denser pixel strips and was thinking I could better limit voltage drop by having the start of each strip wired directly to the PCB–but that would mean either running them in parallel (which i feel defeats the purpose) or running a data wire from the tip back to the base–which increases the distance the signal has to travel between the strips.
These are the strips i’m looking at: SMD3014 332 led/m 12w/m ( Full Color COB LED Strip Same As WS2812B SK6812 High Density Individually Addressable Smart RGB Dream Color COB Led Light DC5V (aliexpress.us))

Somewhat related question–I saw that the number of blades is capped at 20 due to a hard coded section that handles the blade arrays–are there any performance issues with having a high blade count–in the range of 10-15, including a 4 or 5 strip blade plus independently controlled pixel switches, accents, and crystal chambers (additional blades would have 1 to 10 pixels each)?


Electricity is fast, lag is not an issue.
There is a chance that a longer wire could degrade the signal and cause flickering though, but I’ve used much longer cables than this, so I don’t think it would be an issue.

The strip doesn’t really care which way the power is going though, so you can wire the end of some some strips to the PCB, and that should basically do the same thing. (That’s what I do in my zig-zag blades, every other strip gets power injected “backwards”)

ProffieOS works on one blade at a time. Once it’s calculated the colors for each LED in that blade, it hands it off to the data output code to transmit it to the blade. This works in parallel with the calculations, but only one data stream runs at a time. The data stream runs at 800kBit/s. Since each LED needs 24 bits, that is 33333 LED updates per second, maximum. I have a saber with 530 LEDs in the blade, 5 in the pogo pin PCB, 7 LEDs in the control box, and 30 in the pommel, for a total of 572. The maximum theoretical frame rate for my saber is 33333/572 = 58 updates per second. However, I get less than that because of some overhead. Also, I have to compile with optimization, or the frame rate drops even more.

If you have significantly more LEDs and blades than my saber, I would expect that the frame rate drops enough that it starts to look bad. If I compile with the “smallest” setting on my saber, the ignition and retraction doesn’t look smooth anymore, and I would imagine that the same thing would happen if you start using too many LEDs.

Note that limitations might vary depending on hardware. The Teensy4 is for instance capable of feeding out data to multiple blades at the same time, which means that the limiting factor is the longest string, not the sum total of all strings.

I’ve also been exploring ways to support dotstar pixels. Dotstar pixels support data rates which are 20 times higher than ws2811 pixels, but unfortunately they require two wires.


I was looking at about 1000 LEDs on a 30" blade. If I’m understanding all the nuance to your answer, splitting this into multiple subblades doesn’t help–but what wasn’t entirely clear was whether using 2 data pins instead of 1 would make a difference (although it would require a custom blade connector)–but wiring in parallel with 2 independent strips and 2 mirrored strips would improve the framerate overall (which is why KR created the V2 pixel stick).

thank you,

Having more data pins does not help on Proffieboards. Only Teensy4-based setups see any benefit from doing that.

PS: One thing that can help with really long strings is overclocking. Most neopixels are able to handle data at higher rates than advertised. The maximum stable speed is probably somewhere around 1Mhz. (Which is what I use for my 530-pixel blade.)

1 Like