A solution where I can get all 8 LED strips (428 total) to work as expected (expected color and no flickering or random color flashing), even when dimming all with 1 NodeMCU
See https://photos.app.goo.gl/qNuqHExrgzrzsCkS7 for pictures that explain the setup and a video showing the undesired behavior flickering and random colors when dimming (described in Issue #1) as well as a picture of the one strip of 33 LEDs which won’t change color from white when the sacrificial SK6812 LED was introduced (described in Issue #2)
Setup Summary:
I have 2 electrical lines, each branch off 4 times to serve a total of 8 SK6812 LED strips (so 8 electrical entries for 8 strips) where no strip has more than 65 LEDs (all 8 strips add up to a total of 428 LEDS), all supported by a 60A 300W power supply controlled by a NodeMCU with WLED. I’ve confirmed 5 volts at all 8 wires that serve the 8 LED strips
Issue #1 (1 65 LED Strip - Flickering Only When Dimming)
At full brightness, the undesired behavior doesn’t exist - any color can be used any effect I’ve tried seems to behave as expected
With both lines connected only the LEDs from line 1 ever exhibit the undesired behavior (line 2 always works as expected despite any dimming)
If line 2 is removed line 1 works as expected even when dimming
The more the brightness is reduced the more significant the undesired behavior becomes - starts with slight flickering as and ends with groups of blinking random colors when dimmed the most
Color seems to have some impact on how much dimming results in undesired behavior - white can be dimmed the most before undesired behavior, another color (like red) exhibits undesired behavior with less dimming
Unless dimmed to pretty much the very lowest possible amount, essentially only 1 65 LED strip is effected of the 8 strips of 428 total LEDs - if at the very lowest brightness one of the other strips can also exhibit undesired behavior
When partially dimmed and no undesired behavior occurs, when transitioning colors, 1 or 2 of the strips seem to flicker a little bit (but just when transitioning colors)
When powering off via WLED, unless the lights are white and at full brightness, all LEDs won’t turn off (sometimes even when at white and full brightness sometimes a couple LEDs remain on typically with a non white color)
Powering the NodeMCU via the mini-usb didn’t seem to have much impact the undesired behavior but allowed WLED to be more reliably available (i.e. sometimes I couldn’t connect to WLED (or WLED to the NodeMCU))
Issue #2 (One 33 LED Strip - won’t change color after added sacrificial SK6812 LED)
From My LEDSs act funny and flicker randomly, under “Reason 2” I followed the link for Cheating At 5V WS2812 Control To Use 3.3V Data where I added a sacrificial SK6812 LED. This caused the 65 LED strip to behave properly (even when dimming) but caused a strip half the size (33 LEDs) to misbehave but not when dimming occurred (like before), instead, they just won’t change color as expected, essentially they stay white and flicker a little (except the last 3 or 4 which are random colors). Oddly, I tried adding a 1N4148 diode between the NodeMCU and the sacrificial SK6812 LED but that resulted in all but 1 of the 8 LED strips to not to lite up at all, so I just eliminated it. Note, like with Issue #1, if line 2 is removed line 1 works as expected even when dimming
Component Details:
Power supply: 5V 60A 300W Power Supply Transformer Adapter Converter (ALITOVE)
First of all remove resistor and move your sacrificial pixel close to your board. Second make sure all your GND (negative) wires is connected together. Negative and positive wires must be same gauge. Data wire can be smaller gauge.
Start from first strip and add one by one after you sure everything is working as desired. Doing complex setup is difficult especially if it’s your first time project.
Yes, this has proven to be a bit of a challenge for my first time venture for sure . I just know I’m soooo close, I’m going to be so happy when this finally works!
Addressing your comments:
I don’t have a resistor and my sacrificial pixel is actually really close to my board, see the pic here - definitely let me know if you see something awry from my pictures of my wiring and whatnot
All ground wires are connected together
I’m using 18 gauge (power & data); 14 gauge (ground) - should it really be a problem for positive (power) to be 18 and negative (ground) to be 14?
With the sacrificial LED, of 8 LED strips (totaling 428 LEDs), only one strip of 33 LEDs is problematic (see Issue #2 for details). I’ve also determined that the one strip of 33 LEDs works perfectly fine if I either remove the sacrificial LED (which causes a larger strip of 65 LEDs to be problematic as I described in Issue #1) OR, I disconnect the 4 strips supported by line 2. With that, I think I can safely conclude that the connection to that one 33 LED strip in line 1 should be ok.
NOTE: I have 2 lines, each supporting 4 strips (this can be seen in the pictures here, and all 8 strips have their own 5v electrical entry point - I did test/verify each of the 8 5v entry points
The pictures are a little unclear - are you powering your LEDs directly from the power supply, or from the Vin pin? Make sure you’re powering directly from the power supply, as the Vin pin can only supply ~1A.
So long as you are, in fact, powering the LEDs direct from the power supply, turn off the automatic brightness limiter while we troubleshoot this
Since you’ve already installed a sacrificial pixel, enable “skip first LED.” This should allow the pixel to act as a signal repeater
It looks like you may be using multiple outputs from your power supply - make sure the grounds are common! (power it off, use a multimeter, measure resistance between the grounds. This value should be near 0 ohms. If it’s not, connect them with a wire).
Try updating to v0.13.0-b4 to see if this problem persists on the newest release
Are these 8 strips controlled as 1 long strip from the default pin? or as 8 separate segments on different pins? Is there any convenient way to “shuffle” the strips to see if the problem moves with the strip?
I see you have confirmed 5V at the LEDs, but have you confirmed it’s still present while the problem is occurring? I would initiate the problem, and then measure the voltage at the final LED of the problematic strip to help rule out voltage drop issues.
@mjg1088 - I’m PUMPED you have some additional thoughts!
Ok, so I wanted to get back to you quick with some responses but I won’t be able to try some of this out until tomorrow
The power supply is going into the the 2 main lines that support each of the 4 LED strips (3 positive & 3 negative wrapped together)
The power supply is also powering the board via a micro USB that plugs into the board
Out of the board - Positive goes to both the sacrificial LED and is also twisted into the other 3 positives (so 4 positives together); Negative and data goes into to the sacrificial LED then (unlike the positive) it also goes out of the sacrificial LED and negative is twisted into the other 3 negatives (so 4 negatives together) and data goes into the 2 other data lines (so 3 data lines twisted together) that serve the 2 sets of 4 strips
“Are these 8 strips controlled as 1 long strip from the default pin?” - not sure what you mean by default pin? But I can say that the 2 main lines (supported by both the power source and the board as described) serve the 8 separate strips (4 strips for each main line, each strip branches off to 4 sources, one for each strip)
I have not checked for voltage with all the lights running yet. I thought of doing that but haven’t yet because it’s a pain to disconnect the strip. When I do, I’ll just test that source with all the other 7 strips on to verify if it’s still 5V
I set “skip first LED" and I’ve turn off the automatic brightness limiter as you’ve mentioned for troubleshooting
I’ll update to v0.13.0-b4 as you’ve suggested tomorrow
It might be worthwhile to try and power the board directly via Dupont connectors on the +5/Gnd pins.
Some USB wires end up limiting the max current you can draw which could be limiting the Node MCU board. Simple to try.
A little difficult to trace all the wires, but I think I can see what you’re trying to do.
Provided the Red wire shown in the last photo connects to the labelled 5V pin on the NodeMCU (it should).
I would remove the usb cable completely, then add a new Red (NRd) and new Black (NBk).
NRd goes directly from the PS to red junction of the sacrificial LED and NodeMCU.
NBk goes directly from the PS to black junction of the sacrificial LED and NodeMCU.
That wire doesn’t need to be heavy, it will be carrying less than 1A (probably a few hundreds of mA).
Everything else stays the same.
That will guarantee you have solid power to the board and at the same time ensure you have common ground.
If possible it would be good to measure power voltages on the board when “things are displaying badly”
Thanks @divsys, so instead of the red (+) and white (-) coming out of the board → sacrificial LED, you’re saying following, correct?
Have the red and white come out of the power supply → sacrificial LED
Remove the micro usb from the power supply and the board
Then have the red and white come out of the board directly into the main lines (#1 & #2)
The sacrificial LED is right next to the board but probably about 10-15 ft from the first LED. I can’t measure at the moment because I’m not home but I believe that’s about right.
@mjg1088 - I did update to v0.13.0-b4 but no change. It’s raining out so I can’t test that one strip with the other lights on but will as soon as I can.
Are these 8 strips controlled as 1 long strip from the default pin?” - not sure what you mean by default pin?
Are you using pin d4 for the data? Do you branch the data out for 8 different connections, as you have power? Or do you run the data from the output of one strip to the input of the next?
Hi @mjg1088, yes, I’m using D4 for data and I’m branching the data out for 8 different connections, just like I did for power: 4 for line #1 and 4 for line #2. This picture shows the left side of the deck where line #1 supports 4 of the strips. Connecting the strips directly to the sources individually is significantly easier than finding a way to connect the strips to each other under the rails (which in itself was a bit challenging).
For perspective, I’ve included a picture to show what I used to connect the strips to the wires under the railings and how I routed groves underneath to be able to inset the casings that hold the LED strips. Once everything works I plan to seal the connections with silicone calking. The connectors are specific to fit the waterproof LEDs (which are also in the casing that are routed under the railings)
On the left is the first strip of 33 LEDs that’s currently problematic with the sacrificial LED. To the right of it is the 2nd strip of 65 LEDs which were the most problematic when dimming without the sacrificial LED (as described in my OP - other strips to the right were also problematic when dimming but less so than that 2nd strip).
The power supply, board, main lines #1 & 2, and the sacrificial LED are in the house. Main lines both travel 10 feet exiting the house under the deck. Line #1 travels about 4 more feet under the deck and about 3 feet up the white post to support the first 33 LED strip that’s problematic (as shown in this picture)
Branching data without buffer is a bad idea. It might work for a few strips but not as many as you have. WLED is multipin now so you can use few more pins to connect your strips.
@srg74, thanks for your response, but can you elaborate a little more?
“Branching data without buffer is a bad idea” - How do I add a buffer in my setup where I’m branching data (the same way I’m branching power), assuming doing so may solve my described problem?
“WLED is multipin now so you can use few more pins to connect your strips” - Could you elaborate on what this means and offer details as to how I can leverage this information with my setup to solve my described problem?
Okay, the basic idea is that, because each LED needs to be controlled individually, they each need to be assigned an “address” by wled. When you run the output of each strip to the input of the next, everything acts as one very long strip, meaning each LED has it’s own unique address assigned by wled.
When you instead branch this data line out to multiple strips in parallel, your LEDs are no longer individually addressed. There are 4 (or 8, I can’t quite figure out your wiring). LEDs that think they are #1 in the string. As srg pointed out, this is not best practice, and will slowly become less reliable with the more strips added. Personally, I feel confident that this is the origin of your issues. There are 3 potential fixes.
Rewire your data so that the output of strip 1 becomes the input of strip 2. I understand that the wiring requirements for this can be a little challenging, but it is best practice, and it will require the least “trial and error” from both a hardware and software perspective.
Rewire your data so that it is driven from multiple pins. WLED allows you to specify all sorts of settings for custom installations without needing to compile your own copy. I believe this would be achieved using the LED & Hardware settings page. Basically, instead of running all your strips from pin D4, you would split them across multiple D pins. The link srg has provided states that the best pins to use on esp8266 are D4(Gpio2, you’re already using this one) and TX(gpio1, this is the one you will want to add). Because you would likely still be branching your data out, it’s not really possible for us to speak knowledgeably about how many pins you’d need for stable operation. It might only require 1 extra pin, and it might require 7 extra pins. Instead of 8 strips on 1 pin, you could start with 4 strips each, 2 pins total, you’ll just need to add a second output for the new pin. This fix would be a “trial and error” fix, slowly increasing your pin count until your performance is stable, but the rewiring would be simple each time.
Add a buffer. The buffer will essentially perform the same task as your sacrificial LED, and it will be wired essentially the same way, but it will likely do a better job at it. The job of the buffer is to strengthen the data signal coming out of your esp, both in the voltage supplied (esp uses 3.3V, the strips expect 5V) and in current capability. The hope is that strengthening the signal will overcome the limitatations of driving multiple strips in parallel. Unfortunately I don’t have any first hand experience using these, so I can’t say for certain what your requirements or results would be. If you did explore this option, I would recommend starting by replacing your sacrificial LED with the buffer.
I hope this is helpful for some background info! Read the link srg sent, it’s very good information, sometimes it’s just helpful to have some extra background!
One more vote for adding a buffer or the equivalent in this case - level shifter.
One other aspect that could have some relevance in your scenario(s) is the wire distance from the output buffer to the start of the strip(s).
The output of the level shifter (LSO) brings things back up to the 5V levels the strips require to work properly and that’s good. When you connect a “long” wire to the output of the level shifter (>5m IMHO) you degrade that signal, not by voltage drop, but by added capacitance and injected noise.
On any single run from the LSO the added loss may not affect things at all, but when you combine 8 of them, the effects could easily compound. So you need multiple LSO’s and/or data pins to reduce the added noise.
One other suggestion to make this discussion a little easier on all of us: it would be worthwhile to draw up a simple diagram of your setup to document what you intended and where the changes will apply. In my experience it’s much easier to “see” the concepts on a schematic than to try and interpret what a photograph is trying to show.
@mjg1088 - My understanding is that your option #1 is the best case scenario, the problem is it adds a significant amount of work - re-wiring and routing out space under the boards. It seems like I’m too close to a solution to resort to that yet
@srg74 & @mjg1088 - Great link & description for Multi-strip Support. I think what I’m hearing/reading is that either or both D4 and/or TX can be used for data?
I tried using TX instead of using D4 and it just lit up only the sacrificial LED, I then tried using D4 for line #1 (supporting 4 strips) as normal, then using TX for line #2 (supporting the other 4 strips) - all lights in line #1 worked but for line #2 (where TX was used for data) only the first LED of each of the 4 lines lit up and in the wrong color
Is there anything I need to configure in WLED to be able to use TX?
If both D4 & TX can work for data, I’d keep line #1 (supporting 4 strips) as is, then connect the data for line #2 to TX - in this case would I add another sacrificial LED?
Searching to learn more about using a buffer, I discovered the following diagram using a 74AHCT125, would I want to replace my sacrificial LED with this? Should I use 2 of them, one for line #1 and one for line #2?
@divsys - Asking for a schematic is a totally fair/understandable request. I’ve already re-wired as you suggested earlier (removing the micro usb) and it all works the same (so that’s good as it simplifies). Depending on replies to this post maybe I’ll have the problem solved, if not, my next post will have a schematic
I figured out how to configure WLED to use TX (GPIO1) for line #2 as follows, worked like a charm! All lights on all LED strips work as expected, even with dimming (with one very minor exception that I explain below).
The only side effect I can see with using TX (GPIO1) for line #2 is with some effects like “bouncing balls” or “chase”, where the 4 strips on line #1 are out of sync with the 4 strips in line #2 which is a bit behind line #1. At this point I can live with that!
Thank you all so much for your help (@mjg1088, @divsys, @srg74) - you’ve all been so kind in sharing your time, I really appreciate it!
