Crazy idea of the day #2: Blade controllers

Sabers
1

So I have a blade with 529 LEDs in it.
It’s kind of slow.
Making a blade with more LEDs in it becomes difficult, because the WS2811 protocol runs at 800kHz, and once your have more than 500 LEDs in a single string, the frame rate starts to become the bottleneck. Once you have 1000 leds, the maximum frame rate is 800000/24/1000 = 33 fps.

There are a couple of ways to work around this:

  1. Use multiple data strings. (ProffieOS currently only sends one at a time, but that could potentially be fixed/changed.) But you would also need pogo pins/blade PCBs with more than three rings…
  2. Use dotstar / SPI output, which can go much faster. Needs data and clock pins though.
  3. Use some other faster protocol to send the data…

Of course #3 won’t work without something that can receive that data, and that’s where the controller comes in.

What if there was a controller on the back of the blade PCB that could speak multiple protocols, handle blade ID and communicate data back to proffieOS?

There are multiple parts to this, so bear with me…

Part one would be a talk-back protocol for blades.
After sending data to a blade, ProffieOS waits for 300us to make sure that the data is displayed. During this time, a chip in the blade could start talking back to ProffieOS. It could send information about the blade, like how many LEDs there are, how they are arranged and what protocols the blade supports. For instance, it could say something like:

Hello, I am a blade with the following configurations:

  1. 1x132 LEDS
  2. 4x132 LEDS

I support the following protocols:

  1. WS2811+, 800kHz
  2. WS2811+, 2Mhz
  3. serial 8N1, 4Mhz

The reason this says WS2811+, is because in order to reply, ProffieOS needs to send a high signal for a period of time that is not normally allowed by the WS2811 protocol. This would tell the chip that a command from ProffieOS is incoming. That command could be something like:

Please switch to configuration 2, protocol 2.

And then we could start sending WS2811 data at 2Mhz.
The controller in the blade would buffer the incoming WS2811 data, and then send it out to the actual pixel strips. The controller would support multiple strings, it’s output would be 800kHz WS2811 x 4 (one per strip).

The benefit of all this would be that the blade would work with any hilt. By default it would just replicate the data to all four strips. But when told to use “configuration 2, protocol 2”, it would allow for higher data rates, and individual control of each strip.

All of this is a bit complicated, but most of this would be hidden from users, and it would “just work”.

I also have some potential ideas for having clash detectors in the blade, which would then use the same talk-back mechanism when a clash occurs.

1 Like
2

They have been coming out with more blades that use more pixels like the quatum & quad-star to meet people’s demands, but it would be nicer to have a protocol of some sorts to make it more feasible to make your own.

And I LOVE that idea about clash sesativaty. Would just feel more “fun” being able to consistently activating things like Clash, Lockup, & Drag by bumping the blade against something instead of the hilt against your hand.

3

Although I sense it would make certain install harder because of extra wiring, I really like dot-stars in flow gear and displays. It would be a big upgrade tech wise and I bet many collectors would want to adopt it. Just one wave of the blade with Vaders face in POV and boom, every premade blade is sold out :slight_smile:

But that extra pcb ring is problematic. The 4 ring pcb would ideally be backwards compatible.

Agree. I bet it would feel totally different. “Detects clashes on the blade” sounds like another huge reason to upgrade.

Cool stuff.

4

A blade controller could potentially fix this.
Basically taking in data in one protocol (uart, or fast ws2811+) and then feeding it out in dotstar format.

I don’t know about you people, but my sabers all detects a clash if I bump the blade into something, even though the IMU is in the hilt.

The point of having clash detection in the blade would be to detect where the clash happens…

5

Ah, yes that’s even more interesting. Sometimes I “hilt clash” to keep expensive gear from breaking. My thought was that localized sensitivity could let people hit things with their precious pcb style blades veeeeery gently and get good feedback.

6

And of course the biggest hurdle would be how to make it detect blade clashes without it being too sensitive. Perhaps a type of “Battle Mode” that would let you prime a blade for a series of clashes. Like maybe a series of quick button pushes, something like hold aux for 2 or more secs & as soon as you release press aux for how ever many clashes you want to prime.

7

Offtopic or not,but my reaction was normal when testing common “brighter” neopixel blade sold on some eshops(not sure which strip it is). Those WS2811 probably 50W power and not that bright and not fast enough,SK6812 has 1.2 KHz same regular 50W. LED Lightbulb has frequency of 50Hz but power can be multiplied by hundreds of wats. Really can’t tell difference without measurement with tired eyes outdoor with strong lights on. Is there need for additional lines in config for SK6812? Count on leds per strip probably default but same animation but faster pulses because of RBGW strip. (I hate 50Hz light sources btw.)