Support HUB75 connectors with wrong order for RGB channels?

[kirberich]

Hi!

I just finally got a 64x64 matrix (this one: https://www.aliexpress.com/item/xxx-pictures-indoor-led-video-screen-module-power-supply-controller-led-rgb-matrix-p2-128mmx-128mm/32854261443.html?spm=a2g0s.9042311.0.0.36ad4c4dqlWTlq) and it works just fine with the v4 board!

I noticed one problem though, for some reason my colour channels are shifted (red is blue, green is red, blue is green). I'm assuming this is because of hardware differences between different panels, I'd be happy to look into adding some configuration for that but am unsure where to start looking. Do you have any pointers or ideas where this might be most easily fixed?

Cheers Rob

[embedded-creations]

I'm not planning to make the color channels user configurable as the HUB75 pinout specifies the correct pins for R,G,B. Sounds like the manufacturer made a mistake. There's a couple ways you could compensate for this by modifying the library source files. I think the easiest is to find the code in SmartMatrix_Impl.h where the R,G,B temp buffers are filled, and fill them with the swapped color.

https://github.com/pixelmatix/SmartMatrix/blob/master/src/SmartMatrix_Impl.h#L703

There's a a few of these sections of code, just search for temp0red =

[ColinHarrington]

@kirberich Some LED strips have that issue too. It's the order that the LED expects data to be in. Looks like your 64x64 grid is expecting the data in RGB order, but this library is sending them out in a different order (GBR I think)

Pixel configuration | 1R1G1B

Most of the other libraries handle the color order by configuration during setup FastLED does this https://github.com/FastLED/FastLED/wiki/Rgb-calibration OctoWS2811: https://github.com/PaulStoffregen/OctoWS2811/blob/master/OctoWS2811.h#L41-L46 + a switch statement: https://github.com/PaulStoffregen/OctoWS2811/blob/master/OctoWS2811.cpp#L390-L405

It gets complicated to pack the data right with the corresponding order, not to mention any performance concerns looping through each LED. What if you used preprocessors to in the assignment section you linked to? Something like:

#ifdef RGB_BYTE_ORDER
    temp0red = tempRow0[tempPosition].blue;
    temp0green = tempRow0[tempPosition].red;
    temp0blue = tempRow0[tempPosition].green;
    temp1red = tempRow1[tempPosition].blue;
    temp1green = tempRow1[tempPosition].red;
    temp1blue = tempRow1[tempPosition].green;
#else
    temp0red = tempRow0[tempPosition].red;
    temp0green = tempRow0[tempPosition].green;
    temp0blue = tempRow0[tempPosition].blue;
    temp1red = tempRow1[tempPosition].red;
    temp1green = tempRow1[tempPosition].green;
    temp1blue = tempRow1[tempPosition].blue;
#endif

then the user could define the appropriate Color/Byte order (#define RGB_BYTE_ORDER = 1) in their code and have it compiled accordingly? Would that work?

[embedded-creations]

@ColinHarrington Thanks for the input, but I think this is different than addressable pixel color order, which is common. This is a case of a manufacturer not following the HUB75 pinout, which specifies which pins to use for RGB, and is (hopefully very) uncommon. This issue could be fixed in code, but could also be fixed with a wiring change. I'm not planning to take on this configuration, as among other reasons, it would result in more work maintaining the library for a very limited use case.

[tbitson]

Louis, Just my 2 cents: I've bought several cases of the 64x64 matrix panels from different manufacturers. So far, all have been the BGR varity vs the standard RGB. Maybe this is something unique with the 1:32 scan, hence the HUB75-E designation. The labels on the input connector use 'DR1' rather than 'R1', 'DG1' for 'G1' etc as on my 32x32 panel. I just noticed that above the output connector there's a small silkscreen label that says R=G G=B B=R. I think this is fairly common.

Maybe at least a note on what to change and how in the docs so it's consistent between users (aids in troubleshooting if we all do it the same).

• Tim

[embedded-creations]

@tbitson that's an unfortunate trend. I'm guessing these manufacturers made a mistake, and decided it's easier to fix it in silkscreen and software than in copper. I'll at least open this issue back up as it might be more widespread than I thought.

[tbitson]

Thanks Louis.

BTW, a tip of the hat to you (pun intended) for your impressive work on SmartMatrix. Its easy to tell you've put a lot of hard work into SmartMatrix. Its one hell of a project, from the electrical design on the interface boards to the extensive list of options in your code. I know I speak for many when I say Thank You!

• Tim

[embedded-creations]

I'm thinking about this issue as more people (including me) have received panels with non-standard HUB75 pinout for the color channels. I have two ideas on how to fix this:

1. Add flags to kMatrixOptions to allow for reordering RGB channels, as @easone has done here: https://github.com/pixelmatix/SmartMatrix/commit/66da0bde92cfc8e90a8d19d8742c35c895b86b01

2. Allow for customizing the MatrixHardware file in the Sketch, so instead of including the default <SmartLEDShieldV4.h> at the top of your Sketch, you'd include "SmartLEDShieldV4_custom.h", and then just swap the numbers for the R,G,B pins to match your panel.

I personally like the second option more, as I was planning to make customizing the MatrixHardware file easier in the next major release anyway, and it's going to be a lot less work and testing.

Thoughts?

[embedded-creations]

I've already made some changes to allow for easier customization of the Teensy 3 MatrixHardware files to rearrange RGB pins (and made it more clear what can be tweaked by the user, and what should be left alone):

https://github.com/pixelmatix/SmartMatrix/commit/deab88934cd463ce57442489d3d5248a369a8164