I'm planning to build a mobile light installation, consisting of 25 strands, each being 3 meters long and containing 15 leds (SK6812). If possible, I want to use McLighting and the NeoPixelBus library with its effects.
Each strand has an JST 4 pin connector (5V, GND, D_in, D_return) on each end, and there is one additional cable which acts as a hub with 25 JST connectors, furthermore there are "terminator" connectors, which connect D_in and D_return, so the signal goes back to the beginning of the strand
There are several ways to connect the strands and the hub: in a 25x15 matrix, star-shaped or in a few very long strands.
This setup will cause two problems:
For few long strands, the connection from the last LED back along all the strands and to the next LED will be very long.
As the JST connectors are rated at 3 Amperes, the current might be too high for long strands under certain conditions and effects.
For the first problem, I found the following solution: The last LED in the strand is actually wired in the return trace of the strand, and is connected to the D_return wire. So if you have a long strand, consisting of sveral shorter strands, the longest distance between two LEDs is something like 3 meters, not 10 meters or more like with normal wiring.
Normal wiring:
Alternative wiring:
The pictures only show a single strand, additional strands would be connected on the left side to the hub.
Of course this would cause certain effects to look glitchy, as some pixels would jump between their normal position and the return pixels.
To solve this, the program should take the pixel data of the return pixels and add them at the end of the bitstream in reverse order.
To achieve this, I would suggest adding the following changes to the code:
You can define the number of main segments, the number of pixels in a sub-segment and the number of sub-segments in each main segments. The main segments are treated like the segments in the old FX library, you can run different FX on different main segments. The number of sub-segments and the pixels in each sub-segment tell the code which pixel data has to be shifted to the end of the data stream.
For the second problem, I would suggest the following:
As the current drawn by each color of each LED is more or less directly proportionate to its brightness value, you could define the following variables:
where each value is the maximum current drawn by each color or the current drawn by the IC itself.
Now you define MaxCurrent_total and MaxCurrent_strand.
Before sending out the data, the program adds all pixel brightness values for each color, divides them by 255 and multiplies them with the current for each color. Thus, you have the total current for this color. Add all total currents, and compare it with the maximum allowed current. If the current is higher than allowed, reduce brightness.
I'm planning to build a mobile light installation, consisting of 25 strands, each being 3 meters long and containing 15 leds (SK6812). If possible, I want to use McLighting and the NeoPixelBus library with its effects. Each strand has an JST 4 pin connector (5V, GND, D_in, D_return) on each end, and there is one additional cable which acts as a hub with 25 JST connectors, furthermore there are "terminator" connectors, which connect D_in and D_return, so the signal goes back to the beginning of the strand There are several ways to connect the strands and the hub: in a 25x15 matrix, star-shaped or in a few very long strands.
This setup will cause two problems:
For the first problem, I found the following solution: The last LED in the strand is actually wired in the return trace of the strand, and is connected to the D_return wire. So if you have a long strand, consisting of sveral shorter strands, the longest distance between two LEDs is something like 3 meters, not 10 meters or more like with normal wiring.
Normal wiring:
Alternative wiring:
The pictures only show a single strand, additional strands would be connected on the left side to the hub.
Of course this would cause certain effects to look glitchy, as some pixels would jump between their normal position and the return pixels.
To solve this, the program should take the pixel data of the return pixels and add them at the end of the bitstream in reverse order. To achieve this, I would suggest adding the following changes to the code: You can define the number of main segments, the number of pixels in a sub-segment and the number of sub-segments in each main segments. The main segments are treated like the segments in the old FX library, you can run different FX on different main segments. The number of sub-segments and the pixels in each sub-segment tell the code which pixel data has to be shifted to the end of the data stream.
For the second problem, I would suggest the following: As the current drawn by each color of each LED is more or less directly proportionate to its brightness value, you could define the following variables:
R_current G_current B_current W_current IC_current
where each value is the maximum current drawn by each color or the current drawn by the IC itself.
Now you define MaxCurrent_total and MaxCurrent_strand. Before sending out the data, the program adds all pixel brightness values for each color, divides them by 255 and multiplies them with the current for each color. Thus, you have the total current for this color. Add all total currents, and compare it with the maximum allowed current. If the current is higher than allowed, reduce brightness.