Neopixels suddenly on full bright white light

I am having an issue all of a sudden using the Neopixels in a project.
I am working with 3.3v mini pros and I power 4 pixels from the board.
As of Yesterday, after I uploaded new code I have been working on, all LEDs in my project light up regardless of what I do.
I have two devices which communicate(duplex). The problem was present on one, yesterday and when I added the new code to the second one today, I got exactly the same result.
So I thought it must be the new code but to be sure I tried this code to check:

#include <Adafruit_NeoPixel.h>

#define LED_PIN    6

#define LED_COUNT 4

Adafruit_NeoPixel strip(LED_COUNT, LED_PIN);


void setup() {
  //Set NeoPixel
  strip.begin();
  strip.clear();
  strip.show(); // Initialize all pixels to 'off'
}

void loop() {
}

And the same thing happened.
All lights on, bright white.

I don`t think it can be hardware or power or grounding because as I say, the second device worked perfectly until I updated the code, this evening. Now, even this bare-bones code returns rubbish.
I killed the power and uploaded the following empty code and the lights didn't start:

void setup() {
}

void loop() {
}

There was an update to the NeoPixel code yesterday. The problem arrived before I updated and persisted after. I have 1.15.2 and tried multiple older version with exactly the same result.
Anyone having such an issue?

What do you expect to happen, what does the code say?

What happens if you add:

 strip.Color(0, 0, 0);

Theoretically .clear() should clear to black or an OFF state, but that is evidently not the case here? The connection to the data pin is definitely sound?

I don`t think it can be hardware or power or grounding...

...I am working with 3.3v mini pros

Bingo! NeoPixels expect 5V data. Sometimes 3.3V works, and sometimes not, and sometimes it's flaky.

As you may know, the data passes-through in series. The data signal gets buffered-boosted each stage. That means if the first LED gets the data wrong, it will feed the same wrong-data to the following LEDs and that's probably why they are all white.

3 Likes

You need a wall wart 5VDC supply for the Neopixels, you can not use a board to power the Leds.

I do know it requires 5V. But both worked fine. And then I uploaded new code to one and no more. The other still worked. Then I uploaded code to it a day later(though it was working fine with with the previous code), and it also stopped working correctly. It would seem a strange coincidence that they both don't work all of a sudden because of the voltage.
I do have a 5V power supply I could use, though. I will give it a try.

Again, I know 5V is "required". But of course it does work. As I mentioned, it was working for some considerable time with 3.3V.

Thanks for the suggestion. I tried this but it didn't help either. As for the data connection, there are two devices and both worked until the code was updated. I can't imagine there is a problem with both all of as sudden. Would be strange.

But did you provide the LED power from the Mini or a wall wart or PC/USB?

LEDs are powered from the mini. So 3.3 v power and 3.3v logic. And it worked for months until the last time I updated the code. Since then(yesterday for one and today for the other), it doesn't matter what the code is. All lights at on and white.

WAG here. Did you do anything to change the processing speed for the Neopixel output? Because to me, it sounds like the data is being transmitted as all 1's, which in the case of the Neopixel is just a longer (IIRC) data pulse than a '0'; a slower clock rate might achieve that.

Not sure on any of that, very strange.

The sudden voltage insufficient theory doesn't really ring true to me, UNLESS you've changed conditions you're not mentioning to us.

Ok, good luck.

Yup, very strange.

Might the data line be shorted to VCC? The clocked pulses would then all look like 1's?

Can you turn on and off an ordinary LED (i.e. blink sketch) on pin 6? On another pin? Just wondering about a GPIO failure here.

Looks like the Neopixel library was updated recently (to v 1.15.2). Might there be a bug? Maybe try reverting to a previous version of the library?

BTW, what new code did you add exactly?

but the data IS the clock. So, it can't achieve a low-active state, and be read as high.

He might be able to, not my project. but, What would it prove?

Her acknowledged receiving that, but says the problem predated it(same day as download, though, so I'm suspicious of memory faults).

He did that, didn't fix the problem. Again, this is a confidence thing.

Not gonna read you back his postings. The present test is all but foolproof, it's so simple, yet he's telling us it's faulty, so I have doubts all around.

My suspicion is, the library had a change, the change is flawed, and

  • the problem arrived with the library
  • the attempt to switch to a previous version of the library was flawed, so the same flawed update is still running.

Apologies, @njun , but it's the only explanation that fits the data as I see it.

Sorry, yes, was thinking like I2C data + clk. But indeed, only single wire + gnd.

Only that the GPIO is actually switching, but in light of the above, sounds like that may indeed be pointless.

1 Like

Measure the voltages at the processor and each end of the LED strips when it is all white and let us know what you found. Also post a picture of your 5V source so we can see its rating.

Just been playing with a NeoPixel Jewel which has 7 LEDs. I am using a Leonardo so the same 32u4 MCU, and connected to the USB port of my laptop. I could not replicate the problem. It works equally well from both the 3.3V and 5V supply on the Leonardo board, at low or high intensity and using either the current (v1.15.2) or the older (v1.51.0 & v1.51.1)) version of the library.

Have you tried reverting to an earlier version of the library ?

I uploaded exactly the same code(so replaced code with the same code) and now it is working all of a sudden. No hardware change, no software change. It's also an original board and components. I guess it must just have been reverting somehow didn't get deployed even though I tried with multiple old versions back to 1.11.