I'm running into this same issue in my test setup.

First, there should be no need for CAP across the data pin to ground. Get rid of it. This will effect the form of the data pulses. Especially the first one.

@eisteinx2 Please list the model of NeoPixel you are using.

Depending on the model of the NeoPixel and how its packaged, it may already have the resistor on board; and it may already have a cap across the power to ground. But I have never found another resister at the MCU on the first NeoPixel ever hurt anything even when the individuals had it on them also.

A large 4700uf cap at the power supply across V+ to Gnd is good to minimize power draw spikes from large lines of NeoPixels or a short run of them when near the limits of the power supply.

Not sure exactly, they're the WS8212B I think. They have a small SMD cap next to each pixel if that helps. And they're the 60/meter strands. I believe these were ordered from eBay, not Adafruit. I can tell you more when I get home.

I don't have anything on the data pin, but I do have a cap across V+ and Gnd.

Actually, now that I think about it, I did a bunch of prototyping yesterday and while I initially saw that green pixel, I don't think I saw it anymore once I got everything working on GPIO13.

Please ignore my comments this issue for now. I'll confirm later whether I still see this issue. Sorry for the noise.

The use of the 74HCT245Ns maybe effecting the data transmissions. The datasheet states timing accuracy of around 40ns (simplified), this is 1/3 f the error allowed on bit. Due to how the esp8266 bit bangs out the pulses, the error is already near max sometimes and this "maybe" pushing it over the limit; but that doesn't explain why only first pixel. I still think that is the cap on the IO line.
Further, with a esp12, I am seeing a very slow rise time on the pulse. 200ns minimum. With the resistor inline this goes to over 400ns, and the 74HCT245Ns max rise on input is 500ns; while seemly within it, its close.

Are you using a Eep01 still?

Have you tried running the pixels at only 3.6v without the level adjustment for data pin?

hey guys, i know this is ongoing but i can't solve this issue either.
i tried with a ESP-01 and a ESP-201 (which i recommend since it's breadboard friendly) with a neopixel stick found here: http://www.aliexpress.com/item/NeoPixel-Stick-8-x-WS2812-5050-RGB-LED-Strip-Driver-for-Arduino-r3-Free-shipping-tracking/32332566319.html?spm=2114.32010308.5.11.wyhHuT

i tried with a resistor between the gpio and the neopixel DIN. i tried with usb or 2S lipo through a 3.3v voltage regulator and with a 1s lipo (3.7v) direct. (i did not have any caps in any case).
i consistantly get a green first pixel. it does turn off sometimes but is lit most of the time. it's always lit when i clear the whole bar of pixels (set all pixels to black).
everything works great otherwise.
any idea?
thanks much.

@matroll A 3.7 lipo when fully charged will often give 4.2v. 4.2v is outside acceptable range, the difference between IO and VCC must be below 0.5v, and with the esp8266 being only 3.3v, you need to bring the voltage powering the pixels down. Drain the battery a little or put a variable DC-DC and configure for 3.6v.

Something to try for testing, put a 20 second delay at the top of your setup so that the values you push into the NeoPixelBus is delayed.

From banter around the web I came to the conclusion that the 74HCT245Ns is the best thing to try to level the voltage.

I will try running them at 3.6 with no level adjustment. see what happens.. i tried a lower voltage before, and they loose a lot of brightness, so not sure it is the best option... will try though!

Right I can confirm that even at 3.3V the strip works but the first pixel still flicks... just the first one. The rest behave perfectly!

@sticilface Could you try it with the VCC being above 3.5v, the pixels aren't rated to work below 3.5v.

Please include esp module model you have and pixel model. I am waiting for a level interface to come in to test out connecting them "indirectly".

Also note, I created a gitter im chat channel for this project, feel free to join in and lets discuss how to resolve this "issue".

OK, 3.6V still the same. I'm Using both ESP-01s and ESP 12 (also got 7s but not rigged up for this..

I worked with @sticilface to clean up the first pixel, I pushed the fix, please get the latest and let me know if you still see the problem.

that worked for me - awesome! you're fast :))

@einsteinx2 Does this work for you also?
a fix was applied in 503c7e3

hi, looks like i spoke a bit too fast. it did solve the problem for the ESP-01 powered by 3.7 lipo direct.
but still flickering/staying on for the ESP-201 powered by USB or 7.4lipo through 3.3v vreg (no cap or resistor).
i will play around more with it this weekend and see if it can be fixed.

please join the chat at https://gitter.im/Makuna/NeoPixelBus, so we try some things faster

Did more testing today, can confirm I do not see this issue even before pulling any of your fixes.

Hi, I see the same problem with the green LED on the first pixel. My configuration follows.

• Arduino IDE 1.6.4 on Linux
• ESP8266 1.6.4-673-g8cd3697
• NeoPixelBus library

Using the latest code on master.

commit 10bbd7bdf943eeb54a7a890cf35193bc572a4392 (HEAD, origin/master, origin/HEA
Merge: 503c7e3 5f79afb
Author: Makuna <Makuna@hotmail.com>
Date:   Thu May 28 11:22:13 2015 -0700

    Merge branch 'master' of https://github.com/Makuna/NeoPixelBus

commit 503c7e3d7b3eeea11dd803efcab0616596738296
Author: Makuna <Makuna@hotmail.com>
Date:   Thu May 28 11:22:05 2015 -0700

    FirstPixelBitCleanup

    The first bit on some esp8266 will get elongated, this change has shown
    to cause this to be fixed.

• Adafruit HUZZAH ESP8266 breakout board
  BAT connected to battery 5V. The board has a 3.3V regulator. GPIO Dimming #4 used to drive the LEDs (actually the level shifter),
• 74AHCT125

74AHCT125 to do level shifting from 3.3V to 5V.

VCC connected to battery 5V. Input from ESP8266 GPIO #4, output to NeoPixel data in.

• Adafruit NeoPixel Jewel (7 LEDs)

PWR connected to battery 5V. Data In connected to the level shifter output.

• USB battery

The USB battery provides 5V 2A. This is the type of battery used to charge cell phones and tablets.

• Test app

The NeoPixelTest.ino and NeoPixelFun.ino programs work fine. The problem happens for me when WiFi is added to the mix. See the test program below.

#include <ESP8266WiFi.h>
#include <WiFiUdp.h>
#include <NeoPixelBus.h>

#define pixelCount 4
#define colorSaturation 128

NeoPixelBus strip = NeoPixelBus(pixelCount, 4);

RgbColor red = RgbColor(colorSaturation, 0, 0);
RgbColor green = RgbColor(0, colorSaturation, 0);
RgbColor blue = RgbColor(0, 0, colorSaturation);
RgbColor white = RgbColor(colorSaturation);
RgbColor black = RgbColor(0);

const char* ssid = "xxxxxxxxxx";       //  your network SSID (name)
const char* pass = "yyyyyyyyyy";       // your network password

uint8_t LEDColor[3] = {0, 0, 0};
uint8_t packetBuffer[512]; //buffer to hold incoming and outgoing packets

// A UDP instance to let us send and receive packets over UDP
WiFiUDP Udp;

// Multicast declarations for multicast MIDI Port 3
IPAddress ipMulti(225, 0, 0, 37);
const unsigned int MIDI_MCAST_PORT = 21928;  // Base port
const unsigned int portMulti = MIDI_MCAST_PORT + 2;

void setup()
{
    // this resets all the neopixels to an off state
    strip.Begin();
    strip.Show();

    // setting up Station AP
    WiFi.begin(ssid, pass);

    // Wait for connect to AP
    int tries = 0;
    while (WiFi.status() != WL_CONNECTED) {
        delay(500);
        tries++;
        if (tries > 30) {
            break;
        }
    }
    if (WiFi.status() * WL_CONNECTED) {
        Udp.beginMulticast(WiFi.localIP(),  ipMulti, portMulti);
    }
}


void loop()
{
    delay(1000);

    // set the colors, 
    // if they don't match in order, you may need to use NEO_GRB flag
    strip.SetPixelColor(0, red);
    strip.SetPixelColor(1, green);
    strip.SetPixelColor(2, blue);
    strip.SetPixelColor(3, white);
    strip.Show();

    delay(3000);

    // turn off the pixels
    strip.SetPixelColor(0, black);
    strip.SetPixelColor(1, black);
    strip.SetPixelColor(2, black);
    strip.SetPixelColor(3, black);
    strip.Show();
}

Thanks, @Makuna!

Commit 92edf4d fixes the green LED problem described in my previous message. After making small changes to a more complex program, the problem has not occurred as well. As far as I can tell, this issue can be closed!