Wiring Check and pixel direction

Proffieboards Padawan Area
1

I’m laying out wiring and trying to limit the number of positive wires being spliced together near battery + and kill switch. Plus, this is ahead of a crystal chamber and my wire routes are already filled to capacity. My plan for these 2 pixels is to solder onto a spare + and - on the blade PCB, leaving on the data wire to go to the board (V3.9). FYI, I’m fine with the 2 accent pixels being the same as the blade.

DRAFT DIAGRAM - PRE CRYSTAL CHAMBER
DRAFT DIAGRAM - PRE CRYSTAL CHAMBER1512×1512 277 KB

First, is this a proper method? Second, which direction should the arrows be facing on the pixels? Thanks in advance for looking. This is only my 3rd install, and I’m making things more complicated with each build.

2

Using the PCB is a great way to have a distribution hub for positive power, I do it all the time.
Battery(+) - > PCB.
then PCB → board, accents, etc…

However, the Negative to the PCB is connected to one (or more) of the Proffieboard LED pads (and then the board’s BATT(-) goes back the the battery negative).
So, If you need to do the distribution with the PCB’s negative, just be sure to add #define SHARED_POWER_PINS to your config so that the board knows more than one “blade” is using that LED pad.

Now as far as data, it flows one direction, from the Proffieboard out to the pixels.
If you go to the accents first (on your way up to the main blade), you have 2 options:
serial, or parallel.

Option 1: Parallel
Now you said you don’t mind them being the same as the main blade, which would be a parallel connection. However, you have them drawn in series, meaning the dataIN and dataOUT pads on the accents are connected in series, passing the signal on to the next thing.
For them to use a parallel connection, you would need to split off of the same (dataIN) pad on the accents, and hop to the next one. You would leave the dataOUT unconnected.
Make sense?

Option 2: Series
A serial connection would be using dataIN and OUT, passing through the accent (as you have drawn).
In that case you would want to use SubBlades.
Simply put, SubBlade allows a single data line to send info to multiple blades n a single wire.
See here for more info:

3

This is great, and very clear. Thank you, Brian. I don’t mind too much doing it either way, but in keeping with limiting multiple wires soldered onto the same pad, I think I would rather do it in series, then handling the rest in the config.

1 Like
4

I think I’m in over my head in terms of programming SubBlades. I feel like I’ve read the SubBlade explainer 50 times and its just not clicking. I reduced my bladeconfig down to 1 blade on Fett263.com because I kept getting compiling errors (not saying it was the different blade styles, but I was trying to get a simplified, working setup going and go from there).

When powered on, through the battery btw, I only get like 4 pixels to light up on the pixel pcb. Both the side firing accent pixels do work. I’m not getting the Shtok 20 pixel pixel ring crystal chamber to light at all, but I’m pretty sure that’s because it is wired on a separate circuit to the rest of the LEDs

Here is a PasteBin link of the config I used just in case you wanted to take a look:

First of all, could there be something other than config coding causing only a handful of pcb pixels to light up? Secondly, Is there some sort of format I can go by to input the proper info in the blade and subblade configs. Like a, “take this code and replace certain bits of information that apply to your board wiring, then leave the rest as is” sort of thing. haha. If I had a config for another saber that closely matched the way mine is set up, I think I would understand the coding better.

I’ll have to put it down for tonight, but I will go back tomorrow and research some more. btw, I couldn’t get to the negative pad on the pcb, so re-routed my accent pixel Negative to the board.

IMG_6283
IMG_62831512×1512 226 KB

IMG_6284
IMG_62841512×2016 101 KB

IMG_6285
IMG_62851512×2016 226 KB

5

First of all, make sure that maxLedsPerStrip is at least as much as your longest string of LEDs, which in this case is 144. That may be why not all lights light up.

When you say “the subblade explainer”, do you mean this page:

ProffieOS Documentation: SubBlade

or something else?

The code you have in your config file for subblades is entirely made up, so I’m not sure what it’s supposed to be.

In your drawing you have two accent LEDs. Then the LEDs on the PCB, but in your config you also talk about a pixel ring, is that also part of the same chain of LEDs? How many LEDs does your actual blade have?

6

Always a good idea!

Sure. A broken pixel could prevent subsequent ones in series from getting data.

7

Yes, that’s the one I was looking at. And yeah, sorry about the subblade code. The ones I initially wrote just gave me errors, then I used AI to help write one until I could get it to at least compile in Arduino. I know AI is not reliable enough, but I was hoping it would help explain the logistics.

Either way, there is a pixel ring that the crystal pokes through that is connected to pad FREE1 and DATA2. The pixel pcb is LED2 and 3, with the 2 accent pixels on LED5, both with DATA in parallel to DATA1

My actual blade is 132

8

I thought about that… maybe I hit a pixel with the iron, but don’t remember as such. I’ve handled the components pretty carefully throughout. Though, seeing that 4 out of 16 were lit, it’s almost as if it is separated into 4 segments of 4, with 3 outer pixels and the nearest inner pixel being grouped together. So I’m hoping that a coding error is causing it

9

What is this, did I miss something?

#ifdef CONFIG_SUBBLADES
const int maxLedsPerSubBlade = 38; // Total LED count for the blade
SubBladeConfig subBlades[] = {
    { 0, 0, 16 }, // Blade PCB (LEDs 0-15)
    { 0, 16, 2 }, // Accent Pixels (LEDs 16-17)
    { 0, 18, 20 } // Pixel Ring (LEDs 18-37)
};
int numSubBlades = sizeof(subBlades) / sizeof(SubBladeConfig);
#endif

First, your NUM_BLADES and number of styles per preset is set to 1, but you have 4 (each SubBlade is a blade)
Next, CONFIG_SUBBLADES is not a thing,
Neither are maxLedsPerSubBlade, SubBladeConfig subBlades, or numSubBlades.

Now, I can see if you don’t have any other config files as reference that this could be a bit challenging to set up, but you can’t just make things up (or in this case think that AI can give you some working code when it doesn’t know ProffieOS ).

I’d be interested to understand what about the documentation is not clear enough to get you a working set up? Is there something confusing or unclear?

10

Pretty sure that’s the made up code Fredrick pointed out… it’s just gibberish. Well, I’m just not grasping coding in general. I’ll read the documentation and it only makes sense to a point. It could be my ADHD, but I’m not able to take the information given and apply it to what I’m doing… not sure if that makes sense.

11

My brain is tired. I’ll re-approach it tomorrow afternoon. It just takes me longer to absorb information. I’ll go back over the documentation tomorrow and try to write the script myself again (no more AI). Worst case is I get a compiling error and try again. I just have to make sure I’m not attempting the same thing over and over expecting a different result. :sweat_smile:

1 Like
12

You have 1 data line to the PCB (data 1 from the Proffieboard).
Hilt side blade PCBs are typically wired to either be parallel with the main blade, or dedicated as their own blade (no data out option from the last 16th pixel)

If in parallel with the main blade, you would not count the 16 as separate SubBlade, since they are lumped together with the main. That means that whatever shows on the first 16 pixels of your main blade will be mirrored on the PCB.
The other wiring possibility is if they take their own data, are their own 16 pixel blade, and the data ends there.
I’ve not seen one wired where the PCB takes the data through it’s 16 pixels first, then continues from there on to the main blade in series.

Does that make sense so far?

When you said starting simple, you were on the right track. The first thing I would suggest is making sure all of your pixels actually light. This would mean just make one blade, with one standard blade definition with the total number of pixels on your chain and set it to a single color, or better yet use Rainbow to test that they all light and that each one can do R,G, and B.
So if your main blade is indeed in parallel with the PCB, then you have 1 accent, 1 accent, 16 PCB pixels. That’s 18 total, so to test you’d do:

BladeConfig blades[] = {
 { 0, 
  WS281XBladePtr<18, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3,bladePowerPin5> >(), 
  CONFIGARRAY(presets) },
};

That’s without the main blade in (so you can see the PCB).

It’s also a little weird because you split the power to a different LED pad, so we need to include them all since the data line is the same (I think, I never did that before).
Why not just wire the accents to the same LED 2&3 pads the Proffieboard a with the main blade and PCB?

Anyway, once you know they all work (which also means you’re wiring is good) ,
then you can split it into SubBlades and add in the main blade, which would be:
accent = 1 pixel
accent = 1 pixel
main blade = 132 (the PCB 16 pixels is already included in here because it’s wired in parallel)

  SubBlade (2, 133, WS281XBladePtr<134, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3, bladePowerPin5> >() ), // Main blade and PCB
  SubBlade (1, 1, NULL),  // accent #2
  SubBlade (0, 0, NULL),  // accent #1

Assuming you meant in series like your diagram.

2 Likes
13

It didn’t help you, it pointed you in the opposite direction, gave you a map that points to a steep cliff, taped a note on your back that says “kick me”. Then said “trust me, I’m an AI” and waved happily as you strolled off towards your doom…

There is no CONFIG_SUBBLADES, and you can write anything you want between #ifdef CONFIG_SUBBLADE and #endif and it will still compile.

2 Likes
14

Okay, so first test failed. There’s still the same 4 pixels lighting up on the blade pcb. Though, I’m pretty sure the side leds were brighter this time. Last night I was looking at them in a darkened room and they still felt dim compared to a well lit room today.

I’ve got a spare pixel pcb and could swap it out, but then I wouldn’t be able to test the first one. I have a multimeter if there’s a way to test.

Either way, if I wire all in one wire from the PCB, to the same LED 2&3 pads, I’m assuming I should run 22ga for the Negative wire from tip to tail? And then is it still okay to wire in series? The smaller the pad, the less confident I am in soldering two wires onto it together. And what about the Positive wire at this point?

15

Wow that’s a lot. You might be complicating things unnecessarily.
Why not just wire the PCB by itself for a minute directly to data1?
Then use a blade that’s way longer to make sure you cover it like 144.
See if it works.

22AWG negative line needs to go from the blade PCB to the board’s LED pads, and from the board’s BATT(-) to the battery.
The accents can just tack onto one of those pads (2or3) with 28AWG.

THis drawing is hella mess, but it gets the idea across maybe.

0894e35702e0f706418a8e9dac702e7a94d8fe50
0894e35702e0f706418a8e9dac702e7a94d8fe501512×1512 262 KB

16

To clarify, you are suggesting bypassing the 2 accent pixels and run data directly from blade PCB to DATA1 to test? Should I leave the rest of the wiring as-is in the meantime?

When it comes to your updated wiring diagram, the 2 wire channels I have are packed… not sure I can even get that 8th wire through and that’s with 30ga switch wires through there too (shown as 28 in lower right) I’m currently using silicone. If it comes down to having to add the wire, I have 22 and 28ga Teflon. Maybe that can get me the millimeter or so needed.

17

Yes and yes. I mean it should work fine with everything in series even if you use a standard blade definition without sub blade. I was just suggesting going simple to start by unsoldering your current data line from the PCB and just running a temporary home run from data to it. Test with a standard blade definition. That’s just to see that all of your PCB pixels are working.

I just drew in power to the board while I was there. I could certainly come straight from the battery or a kill switch or whatever you have.

18

I’m experiencing the same problem with the direct jump of the data line. I even went so far as to sever the 2 accent pixels from the circuit (excluding bladepowerpin5 from the bladeconfig) and test again… only getting the same 4/16 pixels to light.

Unless I missed something, it might benefit me to re-design the wiring diagram to a known, working layout (like your sketch) and try again

EDIT: I have resolved the issue. Can go into detail later… but phew!

19

Turns out it is a faulty blade PCB. I had the benefit of helping my friend install the same hilt. She brought hers and I did a quick and dirty wire to the board. She had gotten as far as me with the top-side wiring so I did not change anything that was already connected. The blade PCB fully lit!

FYI: My initial wiring diagram stayed the same apart from one thing. I kept the blade PCB on LED2 and moved the 2 pixel string Negative to pad LED3 and bridged the pads on top of the board.

I’m not saying my LED5 pad setup would not have worked, but I AM NOT about to change back to see. :rofl:

1 Like