Strange behaviour with Animation branch on NodeMCU arduino ide about neopixelbus HOT 12 CLOSED

Does your project have active wifi?

from neopixelbus.

Nope. Just basic testing using your example. A detail i renemeber now. I
only tested the non animation version on the first branch. e.g. All I know
is that the animation version does not work well with nodemcu.

On Wednesday, September 9, 2015, Michael Miller [email protected]
wrote:

Does your project have active wifi?

—
Reply to this email directly or view it on GitHub
#26 (comment).

from neopixelbus.

Its not the NodeMCU, this is what I use, I am investigating, but there are several issues it could be.

First, do you have v0.9 or v1.0? Do you have the esp12 or esp12e?

1. Make sure you either use a level adjuster for the IO pin if you power the pixels with 5v (neopixels require IO to be within +-0.5v to vcc),
2. If you don't have one, then you must supply power that that both can use, 3.8v (esp is 3.3v, NeoPixels min VCC is 3.8v). This will also make sure the pixels IO and VCC are within +-0.5v.

Due to the fact you are not using WiFi, then you aren't yet concerned about the SDK changes that broke this library and others. But I will have a branch with a supported solution very soon.

from neopixelbus.

I use vin 5v from usb. The data is 3.3v directly from the pin. I am not
sure this answers your question. I might have to go back to the old branch
to verify.

On Thu, Sep 10, 2015 at 10:34 PM, Michael Miller [email protected]
wrote:

Its not the NodeMCU, this is what I use, I am investigating, but there are
several issues it could be.

1. have you ever had it working well? If not, then make sure you either
   use a level adjuster for the IO pin if you power the pixels with 5v
   (neopixels require IO to be within +-0.5v to vcc), or you must supply power
   that that both can use, 3.8v (esp is 3.3v, NeoPixels min is 3.8v)
2. There is a change happening in how the data is written out due to esp
   SDK change that makes turning off interrupts not possible anymore. The
   esp/Arduino code make have changed noInterrupts to support the new SDK
   which would have broken my code. I am addressing this soon in the animator
   branch, and there will be a new branch that will be required if you plan to
   have WiFi.

—
Reply to this email directly or view it on GitHub
#26 (comment).

Mads Høbye
PhD in Interaction Design
hobye.dk
[email protected]
+45 26223408

from neopixelbus.

Ok, your problem is how you have connected the hardware. This is a common issue and several of the closed issues are the same problem.

You can't drive the NeoPixel at 5v and also use 3.3v data line. The data line MUST be within 0.5v of the vcc. Further, the NeoPixel minimum voltage is 3.8v.

Thus, either you need to either run both the esp and neopixels at a common usable voltage level (3.8v) or you will need level shifters to convert the 3.3v IO from the esp to 5v for the NeoPixel (these can be purchased for a few dollars from most places that also sell the esp)

P.s. new branch, "uartdriven" has the fixes to allow for active wifi without crashing but you are restricted to a specific pin.

from neopixelbus.

Okay I have made a level shifter with two not gates in series.

It is strange - because my own code works (a modified version of your code

• se below) but the examples provided with the animation library still yels
  strange results.

#include <NeoPixelBus.h>

#define pixelCount 200

NeoPixelBus strip = NeoPixelBus(pixelCount, 2);
uint16_t effectState = 0;

float h = 0;
float offset = 0;

void setup()
{
strip.Begin();
strip.Show();

}

void loop()
{ h = 0;
for(int i =0; i < pixelCount; i ++)
{
h = h + 1.0f;

strip.SetPixelColor(i, HSLtoRGB( round(h + offset)% 360,100,30));

}
offset = offset + 10.0f;
strip.Show();

}

// This function converts the "color" object to the equivalent RGB values of
// the hue, saturation, and luminance passed as h, s, and l respectively

RgbColor HSLtoRGB(float h, const float s, float l)
{
int tmpR,tmpG,tmpB;
unsigned int r = 0;
unsigned int g = 0;
unsigned int b = 0;

float L = ((float)l)/100;
float S = ((float)s)/100;
float H = ((float)h)/360;

if(s == 0)
{
r = l;
g = l;
b = l;
}
else
{
float temp1 = 0;
if(L < .50)
{
temp1 = L_(1 + S);
}
else
{
temp1 = L + S - (L_S);
}

float temp2 = 2*L - temp1;

float temp3 = 0;
for(int i = 0 ; i < 3 ; i++)
{
  switch(i)
  {
  case 0: // red
    {
      temp3 = H + .33333f;
      if(temp3 > 1)
        temp3 -= 1;
      HSLtoRGB_Subfunction(r,temp1,temp2,temp3);
      break;
    }
  case 1: // green
    {
      temp3 = H;
      HSLtoRGB_Subfunction(g,temp1,temp2,temp3);
      break;
    }
  case 2: // blue
    {
      temp3 = H - .33333f;
      if(temp3 < 0)
        temp3 += 1;
      HSLtoRGB_Subfunction(b,temp1,temp2,temp3);
      break;
    }
  default:
    {

    }
  }
}

}
tmpR = round((((float)r)/100.0)_255.0);
tmpG= round((((float)g)/100.0)_255.0);
tmpB = round((((float)b)/100.0)*255.0);
return RgbColor(tmpR,tmpG,tmpB);

}
static void HSLtoRGB_Subfunction(unsigned int& c, const float& temp1, const
float& temp2, const float& temp3)
{
if((temp3 * 6) < 1)
c = (unsigned int)((temp2 + (temp1 - temp2)_6_temp3)100);
else
if((temp3 * 2) < 1)
c = (unsigned int)(temp1_100);
else
if((temp3 * 3) < 2)
c = (unsigned int)((temp2 + (temp1 - temp2)(.66666 -
temp3)_6)_100);
else
c = (unsigned int)(temp2_100);
return;
}

On Tue, Sep 15, 2015 at 7:03 PM, Michael Miller [email protected]
wrote:

Ok, your problem is how you have connected the hardware. This is a common
issue and several of the closed issues are the same problem.

You can't drive the NeoPixel at 5v and also use 3.3v data line. The data
line MUST be within 0.5v of the vcc.

Thus, either you need to either run both the esp and neopixels at a common
usable voltage level (3.8v) or you will need level shifters to convert the
3.3v IO from the esp to 5v for the esp (these can be hade for a few dollars
from most places that also sell the esp)

—
Reply to this email directly or view it on GitHub
#26 (comment).

Mads Høbye
PhD in Interaction Design
hobye.dk
[email protected]
+45 26223408

from neopixelbus.

Please be specific. Which sample? What isn't working? What code did you replace?

The HSLColor object either takes uint8_t values between 0 and 255 or if you change to use floats, it will require values between 0.0 and 1.0. Your code above is assuming 0-360 for H, and not sure about the others.

from neopixelbus.

If you are using the UART branch, then you will to adjust the running speed of the esp to 160mhz. There is timing issue with the hardware uart that shows up at 80mhz due to the way the code is using it.

from neopixelbus.

Note, there are now two WiFi compliant branches, UartDriven and DmaDriven, with the latest IDE and EspArduino they no longer are sensitive to the esp speed (the issue got fixed). Please let me know if you are still seeing problems.

from neopixelbus.

I have used the Uardriven and i works like a charm even over wifi.

http://fablab.ruc.dk/controlling-neopixels-with-processing-via-wifi-to-nodemcu/

On Sat, Jan 23, 2016 at 8:16 PM, Michael Miller [email protected]
wrote:

Note, there are now two WiFi compliant branches, UartDriven and DmaDriven,
with the latest IDE and EspArduino they no longer are sensitive to the esp
speed (the issue got fixed). Please let me know if you are still seeing
problems.

—
Reply to this email directly or view it on GitHub
#26 (comment).

Mads Høbye
PhD in Interaction Design
hobye.dk
[email protected]
+45 26223408

from neopixelbus.

Sorry for commenting on the closed issue, but could you briefly explain in which scenarios the master branch does not work? With any wifi communication, or just when something specific is done?
Somehow with the UART-driven branch - the blue led on the esp is always on, and with the DMA driven, i cannot use the Serial receve.

from neopixelbus.

feel free to create a new issue.
Please include which esp module you experience the issue with.
Basically the master and NeoPixelAnimator branches can and often are interrupted by WiFi activity and thus can not maintain reliable updates to the pixels, causing flashing, incorrect colors, and even pixels not being updated at all. The WiFi activity is not just what the esp creates, but could be any communications between the esp and the router to maintain a connection, so you can't just "not communicate" for a bit and get reliable pixel updates, as the router and esp have to periodically communicate to keep the connection alive; all outside the control of any user program running on the esp.

from neopixelbus.