I think that particular option is NOT within my pay grade.
I like that there’s a ton of settings but understanding them all isn’t for the person with average intelligence.
That’s probably one of the simplest preset’s you could make (a basic GUI function).
Setup your LEDs to be all at 000 colour (full black) .
Save that setting as a preset and call it “Full Off”, note the preset #.
In Config->LED Preferences->Default change the “Apply at startup” preset to the Full Off number.
Save your changes and reboot.
The LEDs might flicker briefly at power up, but should all go to full black (off).
If that helps, you can work forward to a slightly more complicated preset that has more than one state.
It starts at Off and moves to something else you want at startup.
OK, I see what you are saying. I was overthinking it and thought you meant to change the code in the preset to start at OFF and then run the preset.
That wouldn’t solve my issue. My issue is I want to turn on with the preset so, like flipping a switch, I could turn on the LEDs in the preset.
But with these lights it just wants to show some white ones on GPIO2. Sometimes it loads the preset but not often.
I did notice a small spike in my power up with my power supply. I’m outputting 4.95v (average) after a small spike of 5.2v at power up. That shouldn’t be enough to be an issue, I would think.
Don’t be too sure on the power spike.
Power issues on the ESP are just about guaranteed to cause odd behaviour (at best).
Try and hold the reset button down until after you’re sure you have good power.
See if that makes any difference on startup.
What you’re describing with using Presets at startup is exactly how they’re meant to be used.
If that’s not happening, something else is interrupting.
I’d suggest you start with simple solid presets for testing, until you’re sure things are starting the way you’ve asked them to.
I’ll try the holding the reset.
I have tried the single color solid preset on startup. That’s really how this particular one is supposed to work under normal circumstances, and this is where I found that the problem isn’t just because I use a profile.
I have it working, as intended, with GPIO3. And if I were a “normal” person, I could be fine with it. I’m not normal that way. I need to “solve” this problem.
OK, a couple brain cells just connected.
The reason I’m having problem lies in this little part of the infor page linked above, where it says “pins that are used on boot”.
Specifically the part where it says GPIO 2 is high on boot but boot failure can happen if pulled low (same happens on GPIO3)
- GPIO16: pin is high at BOOT
- GPIO0: boot failure if pulled LOW
- GPIO2: pin is high on BOOT, boot failure if pulled LOW
- GPIO15: boot failure if pulled HIGH
- GPIO3: pin is high at BOOT
- GPIO1: pin is high at BOOT, boot failure if pulled LOW
- GPIO10: pin is high at BOOT
- GPIO9: pin is high at BOOT
So, with the LEDS hooked up, it’s being pulled low because the power supply is connected too closely (figuratively) to the controller and the LED strip.
Hmmm. Now how to fix this issue…
I think you’re possibly on the right track.
All of your description matches standard practice issues - except for the cause you’ve suggested:
So, with the LEDS hooked up, it’s being pulled low because the power supply is connected too closely (figuratively) to the controller and the LED strip
I agree that something may be pulling the GPIO Lo (or too near Lo sometimes), but power supply distance is not likely the cause. More realistically, the LEDs you’re using may load up GPIO2 a little more than is spec’d .
Conversely, the GPIO may not be pulled-up “hard” enough.
One way to get an idea is to use a multimeter to measure the resistance (on a bare board with no other connections) from GPIO2 to the 3.3V pin. That should tell you what size of pull-up resistor is being used to keep that pin Hi on boot. You could also measure GPIO2 to the 5V pin as well, although there shouldn’t be a pull-up there.
The value of that pull-up will tell you about how much load can be on that pin before you risk a false power up state.
I have a problem with finding the right word to explain what I’m thinking, sometimes.
When I said that the power supply was too close I was attempting to say there was a narrow range between the controller and LEDS.
Keeping in mind I’m trying to develop something that doesn’t appear to be out there, mainstream, a lot will be trial and error.
On that note, if I’m to understand correctly, I could go as high as 10v on the 5v in pin and the board “should” be OK.
So, what if I changed the input to 9v? Would that be too close to the danger zone? Otherwise, I could do more work and get the input closer to 6v.
Just thoughts.
The 5V to 3.3V regulators on different boards have a variety of tolerances. I see little value in going beyond 5V as:
- The chances of your board (or one similar) going “poof” are dramatically increased once you’re over 5V
- You’ll likely need 5V for some other device(s) as well.
I’d lean more towards getting the board to “wait” for clean 5V power before starting up.
You have a good point.
The question is, how does one make it so the board waits for clean 5v?
I was starting with the suggestion to “hold the reset button down”.
Theoretically, while you press RST, the processor is halted.
You can turn on a power supply(s), attach LEDs, etc and the processor won’t know about it.
Once you release the button, the processor starts up as if it had just been powered on.
So if “Reset starts” (which you can easily try multiple times after power up) don’t show the same initial light problems then the issue is very possibly related to power up issues.
As to how you can extend the time it takes the processor to start with power attached (vs. just reset), a common technique is to use a small RC circuit on the RST pin. Adding a larger electrolytic capacitor from the pin to ground will force that capacitor to charge before the pin can be pulled up to Vss (3.3V). That charging time delays the processor start.
On my list is to see if the power fluctuations are from the power supply plugged into the wall or if it’s a side effect of the buck converter I’m using.
I’ll have to check to see if the condition persists when using a more stable wall source.
If the wall power is the problem then it may not be a problem using vehicle on-off power.
I’m also toying around with the possibility of using a 555 timer circuit to delay the startup but, in reality, I would really like to have the lights power up instantly when the board is supplied power. Delays in startup routine kind of takes away from the finished idea.
I understand about the “instant light up” feel of a project.
And definitely explore how things react with alternate supply ideas.
Normally the delays involved are 10’s of ms (perhaps 50-80ms).
At processor speeds, 3/10 second (300ms) is literally an eternity.
Further testing.
I have installed a power plug to the board. This makes the power from the power supply instant. I turn on the power supply and then plug it in. No beneficial effect.
I tried a different board. No difference.
I tried a different set of LEDs. No difference.
I tried holding the reset while I plugged it in. No difference.
I tried pushing the reset button after plugging it in, no difference.
I tried with and without the backup wire on the WS2815. No difference.
i’m using a buck converter to go from main power (12v) to drop to 5v for the NodeMCU.
The 12v goes straight through to the LED strip. Common ground.
The last test I did was to disconnect the LEDs from the NodeMCU and then power up with the switch on the power supply. Then plugged the LEDs back in and they work fine, every time.
So, something in the LED strip is either drawing too much current, which shouldn’t be possible as I’m using a 30A power supply, or the LED strip is givng some sort of feedback.
Here’s the other variable. If I set the power supply to 7.5V, still getting 4,9v from the buck converter, it will start up more than 50% of the time.
All the above tests are on GPIO2
After all those tests, I’d suggest a last possibility: put a levelshifter on the data line (especially as the strips start up properly if they’re not connected when the MCU powers up.
The levelshifter will guarantee 2 things:
- The data to the LEDs is at the 5V level it needs.
- There’s no way the LED Data In line can load the GPIO output.
Wait a minute - you’re using WS2815’s?
How have you wired the BI (Backup Input) on the 1st pixel?
It’s supposed to be wired to ground at the start.
All the other BI’s will be wired to BO of the previous pixel, but the 1st one should be at ground Not connected to DI.
As tested, BI is wired to the ground or left open. Neither way changed the results. Nor did skipping the first LED or even 10 LEDs.
I am not knowledgeable about level shifters.
I’m wondering if, somehow, the LED strip is giving feedback to the data line and if adding a diode to the data line would prevent that.
I think one of the next tests will be to see if I get these results without the data line attached.
When the LEDs do their malfunction, the bleu on the NodeMCU doesn’t even light and the WLED program isn’t loaded (doesn’t show the WLED network)
Lack of a levelshifter can cause a variety of issue as the LEDs aren’t getting a data signal that’s up to their spec (5v) since the ESPs only work at 3.3V.
You can try the diode to see if it prevents any loading, but it may not work at all or cause other issues as it adds another drop in data voltage.
The ESP not starting properly is a major issue, if the MCU isn’t running you can’t guarantee anything…
I was just going off the data sheet that if GPIO2 is pulled low the ESP won’t boot.
It appears that’s the problem. It’s not booting.
Yes that’s one possibility, it’s just not a common issue for attached LEDs.
Definitely worth trying to isolate that GPIO on power up.
If the diode helps then great, it’s just that the levelshifter issue affects a far greater portion of LED installations and would also likely solve the CPIO issue.at the same time.
If I knew anything about level shifters…
Unfortunately, I don’t.
I get mental blocks. I have had one with transistors for 40 years.