Combining LEDs on different data lines into a single blade

ProffieOS
,
1

I recently picked up a Korbanth VeeOne and since it is my first crystal chamber saber I’ve been playing around with styles for it. Wall of text to follow. :grin:

One thing I see with the way that the factory configuration is done is that the two crystal chamber LEDS are using different data pins, and so are set up as different blades running different styles.

One thing I wanted to do was run the same style on both LEDs as a single blade. I like the idea of being able to have effects fade across the two LEDs, etc. On the other hand I don’t really want to rewire this thing.

I did some experiments adding a what I called a combo blade, which is basically a virtual blade that forwards the various commands sent to the actual blades and has a length equal to the number of LEDs in the two real blades that it sends commands to. The code that I have is extremely hacky, but seems to mostly work - at least if I only use two LEDs.

For example, for my blades array, previously I had the two individual blades listed like this:

#define NUM_BLADES 3
BladeConfig blades[] = {
    { 0, WS281XBladePtr<128, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
    WS281XBladePtr<1, blade4Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
    WS281XBladePtr<1, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
};

Using the ComboBlade idea I could instead do this

#define NUM_BLADES 2
BladeConfig blades[] = {
    { 0, WS281XBladePtr<128, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
    ComboBlade(WS281XBladePtr<1, blade4Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
               WS281XBladePtr<1, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>()),

I wasn’t sure if this was an issue other had come across previously and if so how they had solved it. Is it worth spending some time cleaning this up for other to look at? I’m pretty new to this lightsaber thing but always like to play with code and electronics.

2

The simplest way to make the 2 LEDs act the same is to just use the same blade style on both.

3

Thanks! that was actually my starting point but the issue I ran into with that is that both LEDs are treated as as LED 0 by the style and end up essentially doing the same thing.

The reason I wanted both to be handled as a single blade is so that I can use styles that have lighting effects moving between the two LEDs. For example, I was testing with a rolling rainbow effect from fett263’s library. If I apply the same style to both blades it works, but the colors are in sync with one another rather than doing the “rolling” effect as desired.

4

You can apply a Remap<> to the second style but it will probably take a little tweaking to get it perfect.

So if the style on the first blade is

StylePtr<
Layers<SomeStyle>
>()

You’ll wrap either the base style or all layers in a Remap<> function. The Remap below will shift the second style 50% (Int<16384>) and then wrap the other half over the beginning almost like folding the style on itself, this may take some testing to get right though by adjusting the 16384 up or down.

StylePtr<
Remap<ModF<Sum<RampF,Int<16384>>,Int<32768>>,
Layers<SomeStyle>
>
>()

You’ll have to manually add this to the styles, be sure you close the Remap<> at the end.

1 Like
5

I suppose the correct way to fix these things would be to add an optional “phase” parameter to th e rainbow and stripe styles.

ComboBlade seems like an interesting tool to have available. (It’s kind of the inverse of subbblade()) Might be worth cleaning it up and submitting a PR maybe? Not sure exactly what people would use it for though…

There is one more possibility though, which is to use subblade:

Now each “blade” is two pixels long, but the first blade only shows the first one and the second one only shows the second one…

4 Likes
6

That solution is genius! :clap: :fire: Will definitely be keeping that one in my own toolbox!

7

Thanks for the thoughts all!

I quite like the subblade based approach, that ends up being pretty clean!

I will spend some time cleaning up the ComboBlade stuff up so I can make a PR. We can see if it ends up being a good fit. If nothing else it is good to write some code for fun instead of work.

Cheers!

1 Like
8

Close, no? This would be cool.

9

Ah. So lets say a really deep emitter makes the first 10 pixels of a 144 length main blade “unusable” for example.
This would essentially let then be ignored?

{0, SubBlade (10, 143, WS281XBladePtr<144, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >() )
10

Yes, although it might not work with proffieOS 7.x, which gets a bit confused if none of the subblades use pixel 0. ProffieOS 8.x should fix that.