Taking Wiring Liberties...?

The Proffieboard is such an amazing system, and the more I learn about it, the more I’m discovering lots of little-known features that have the potential to make certain installs much simpler or better-featured. For example the ability to wire switches so that they short to battery positive rather than ground with nothing more than a tweak of the code can save valuable wire space in tight builds. Indeed I did an install recently in which I would have liked two-button operation, but the number of rings on the removable chassis section meant I didn’t have enough lines for Main, Aux and Ground, so I had to ditch the Aux and go to one-button operation. But had I known about this little feature, I could have ditched the ground and wired the switches to the Batt+ at the back of the blade connector, thus keeping two switch lines.

So in my constant quest to reduce the amount of wiring I need to cram into my builds, and always wanting my toolbox to give me as many build options as possible, I’m curious whether taking other liberties like the one in the diagram below is OK…

Basically I’m wondering just how much I can cross-connect LED power pads and data lines. So let’s take a hypothetical scenario loosely based on a build I did recently. The basic scenario is:

  • Three accent LEDs with dataline wired in series through all of them and coded as sub-blades. But of those three accent LEDs, numbers 1 and 2 are powered off one LED power pad (let’s say LED 4) and the 3.3 volt positive pad, but the last LED is powered from splits of the main blade LED pads 2 and 3 with positive hard off the battery.

  • A fourth accent LED is also fitted, but this must have its own data line as its colour order is RGB, not GRB. But for wire management reasons, it’s easiest to power that fourth LED off the same positive and negative as the first two accent LEDs in the other array, i.e. LED 4 and 3.3 volts.

Obviously I would need to use the SHARED_POWER_PINS define, but are there any other objections to this scheme seemingly convoluted, but more wire-efficient, scheme?

My own thoughts are that the LED power pads and data line cross-connections would be fine, but I think the mismatch of positives (3.3 volt versus battery positive) on the same LED array might be an issue, resulting in the various components trying to balance their voltages via the data line, which in turn could cause lighting style interruptions on those LEDs, or worse.

In this instance I could of course wire the LED behind the blade connector using data 1 and coding as a sub-blade before going on to the main blade, but that would prevent another little-known feature I want to use which is blade plug charging as it would mess up the Blade ID process.

So I’d value the thoughts of the clever folk here to help me figure out where the line is between unconventional installs and unworkable ones. How bad is this hypothetical scheme? Or is it all, in fact, completely fine?

Thoughts welcome. Thanks in advance.
:slight_smile:

Why are you using the 3.3v pad in the first place? Just hook up the pixels to batt+ and then you won’t have a problem.

There is a workaround for this: The ByteOrderStyle<>. This lets you byte-swap the colors that come out of a style so that it will look even though the pixels are using the “wrong” byte order. This workaround doesn’t work if you have a mix of 4-channel (RGBW) and 3-channel (RGB/BGR) pixels, but for RGB ↔ BGR, it works just fine.

1 Like

Yeh, it did occur to me to use Batt+for all of the accents, but I was making a hypothetical worst case just to test the premise. But it sounds like everything else in my preposterous scheme would work! :smiley: :ok_hand: Which is great to know! :+1:

This is what ah’m talkin’ about! :smiley: :pray: :clap: :sparkler: I had no idea you could do this for an individual accent on a sub-blade array. I’d always thought you couldn’t mix byte orders on the same data line. Another great little nugget which has already just saved me one ring on a removable chassis connector for an install I have coming up, which in turn means I can look again at a removable crystal chamber option that I previously had to rule out for lack of connection lines. :smiley:

So just quickly, what would a simple blade style look like with the ByteOrderStyle added? I’m guessing something like:

ByteOrderStyle<RGB>,StylePtr<InOutHelper<SimpleClash<Lockup<Blast<Blue,White>,AudioFlicker<Blue,White>>,White>, 300, 800>>(),

Close, it works just like any other style:

1 Like

Many thanks Prof - another useful tool added to the toolbox! :+1:
Appreciated as always. :pray: