Relative Newbee here. In my project the leds are not lighting up steady, they appear to be pulsing/jittering (I don't know the correct term). Using the following hardware:
Generic WeMos D1 mini
1 meter of WS2812B 144 pixels
5v 5amp Power supply
1000uf cap and 470ohm resistor between board and Neopixels
Things I've tested/tried
I've swapped Wemos boards ( I have 3 of them)
I've swapped (does the same when powered by PC, 1amp wall wort, and 5a benchtop PS.
I've swapped string of neopixel with 40 light string (same issue)
Tryed both data pins 2 and 4
synched up all FastLED settings with working code that I run on a NANO board.
Observation made.
disconnecting the datapin to the neopixels, the pulsing stops. Guessing that eliminates it being an issue with power supply. So data seem to be bugged up.
Any help here will be greatly appreciated. Not sure what other info you might need to help. Below is the code I'm currently using.
#define BLYNK_PRINT Serial
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
#include "FastLED.h"
//---FastLED definitions and CRGB---
#define LED_PIN 4 // GPIO pin for RGB LEDs.
#define NUM_LEDS 144 // Number of LEDs connected.
#define BRIGHTNESS 50 // Default LED brightness.
#define LED_TYPE WS2812B
#define COLOR_ORDER GRB
CRGB leds[NUM_LEDS];
//---variables for our RGB values---
int r = 500;
int g = 500;
int b = 500;
//---variables for On/Off, and Auto/Manual toggle
int masterSwitch = 1;
int autoMode = 1;
//--- int/byte for automatic hue incrementation---
uint8_t gHue = 0; // rotating "base color" used by many of the patterns
//---Blynk auth code and wifi details---
char auth[] = "xxxxxxxxxxxxxxxxxxxxxxxxxS-2jC";//Blynk authorisation
char ssid[] = "JB_n_Missy";
char pass[] = "xxxxxxxx";
void setup()
{
// power-up safety delay
delay( 3000 );
Serial.begin(9600);
//--- add the LEDS to FastLED and set the brightness---
FastLED.addLeds<LED_TYPE, LED_PIN, COLOR_ORDER>(leds, NUM_LEDS).setCorrection( TypicalSMD5050 );
FastLED.setBrightness( BRIGHTNESS );
#define FRAMES_PER_SECOND 120
//---start communication with the Blynk server ---
Blynk.begin(auth, ssid, pass);
}
void loop()
{
Blynk.run();
if(masterSwitch==0) // Power Down Cube
{
for (int i=0;i<NUM_LEDS; i++)
{
leds[i] = CRGB::Black;
FastLED.show();
delay(25); // Controls the speed pixels turn off.
}
}
if(autoMode==0 && masterSwitch ==1) // Use the Zebra to control the color of Cube
{
for (int i=0;i<NUM_LEDS; i++)
{
leds[i] = CRGB(r, g, b);
FastLED.show();
delay(5); // Controls the speed pixels change color.
}
}
if(autoMode==1 && masterSwitch ==1) // Runs the FastLED scripts
{
fill_rainbow( leds, NUM_LEDS, gHue, 255/NUM_LEDS); // Set to full rainbow per length of strip
// send the 'leds' array out to the actual LED strip
FastLED.show();
// insert a delay to keep the framerate modest
FastLED.delay(1000/FRAMES_PER_SECOND);
EVERY_N_MILLISECONDS( 2 ) { gHue++; } // slowly cycle the "base color" through the rainbow
}
}
//---Master On/Off---
BLYNK_WRITE(V0)
{
masterSwitch = param.asInt();
}
//--- Red slider value---
BLYNK_WRITE(V1)
{
r = param.asInt();
}
//--- Green slider value---
BLYNK_WRITE(V2)
{
g = param.asInt();
}
//--- Blue slider value---
BLYNK_WRITE(V3)
{
b = param.asInt();
}
BLYNK_WRITE(V4)
{
autoMode = param.asInt();
}
BLYNK_WRITE(V5)
{
int g = param.asInt();
if(g==1)
{
for(int a = 0; a < 10 ; a++)
{
for (int i=0;i<NUM_LEDS; i++)
{
leds[i] = CRGB(1023, 0, 0);
leds[i+1] = CRGB(1023, 1023, 1023);
leds[i+2] = CRGB(1023, 0, 0);
FastLED.show();
delay(5);
FastLED.clear();
delay(10);
}
}
}
}
You need to go and read the forum instructions so that you can go back and modify your original post (not re-post it) - using the "More -> Modify" option below the right hand corner of your post - to mark up your code as such using the "</>" icon in the posting window. Just highlight each section of code (or output if you need to post that) from the IDE and click the icon.
In fact, the IDE itself has a "copy for forum" link to put these markings on a highlighted block for you so you then just paste it here in a posting window. But even before doing that, don't forget to use the "Auto-Format" (Ctrl-T) option first to make it easy to read. If you do not post it as "code" it can as you now see, be quite garbled and is always more difficult to read due to the font.
It is inappropriate to attach it as a ".ino" file unless it is clearly too long to include in the post proper. People can usually see the mistakes directly and do not want to have to actually load it in their own IDE. And even that would also assume they are using a PC and have the IDE running on that PC.
Also tidy up your blank space. Do use blank lines, but only single blanks between complete functional blocks.
The WeMos D1 mini has an operating Voltage, 3.3V. This is often not sufficient to drive these 5V powered strips. You need to boost the signal level up to above 3.8V for it to work reliably.
Do not go for the "level Shifters" designed for I2C devices these are not fast enough to work reliably. I use a 74LS14 or a 74HCT14 buffer to do this.
I was reading the exact same article myself last night. I also saw a "hack" using a sacrificial led that I might try. The 74LS14 looks like the way I need to go with these boards though. Now only if I had some.
In my experience, esp8266 is not a good candidate to run larger amounts of LEDs because control authority over the chip is in its boot loader and not with the end user. The software on the chip interrupts the program you are running in order to do wifi related tasks, and if this is done while your leads are being written out, it can cause the jitteriness.
Qdeathstar:
The software on the chip interrupts the program you are running in order to do wifi related tasks, and if this is done while your leads are being written out, it can cause the jitteriness.
That's a good point.
Better to use DotStar LEDs with two control lines - the 74HCT14 has enough gates to buffer these also.
Thanks for the info on the DotStar. I'll keep them in mind of the next project, but for this one, it is definitely cost prohibitive (plus, the LEDs are already permanently mounted in a sealed unit). I paid under $10 (shipped) for a meter of WS2812B (144led/m). It appears that the DotStar will run me over $50 for the same thing .
Idea... Since this issue is only happening with my Wemos D1 mini boards, is there anther WiFi board out there that might be a better candidate for this project?. Size is a bit of a concern (ie a full size board will not work).
Sacrificial LED /w diode - was hopeful, but no help.
74HCT14 - On order - Who know when I will see them. (slow boat from China). IF I could get one to test with from someone local, that would be great. On that note I found this product today that I am considering on trying: ESP8266 Level Shifter Shield
Also - looking to try a couple new boards (can never have too many). Ordering Wemos D1 mini PRO, as well as a NodeMCU. Open for suggestion on others to try.
Relatively minor success with knocking the FRAMES_PER_SECOND setting down from 120 to just 10. This slowed down the presentation considerably, but almost eliminated to pulsing effect. A reseasable compermise, but certainly not a fix.
74HCT14 - On order - Who know when I will see them. (slow boat from China). IF I could get one to test with from someone local, that would be great.
What is local for you? Most major distributors have them, like Farnell, Digikey and Mouser, as well a hobby electronics shops.
The Tindi thing should also work.
Relatively minor success with knocking the FRAMES_PER_SECOND setting down from 120 to just 10. This slowed down the presentation considerably, but almost eliminated to pulsing effect.
Interesting, that should not happen, maybe you need to look at the power supply or the capacitor across the strips.
By he way what is the “Sacrificial LED /w diode” thing?
Grumpy_Mike:
By he way what is the “Sacrificial LED /w diode” thing?
Since the CMOS logic thresholds are a proportion of the supply voltage rather than a strict voltage, if you lower the supply voltage of the NeoPixel, it will operate at the lower HIGH level. But its output levels are the full supply voltage. The easiest way to lower the supply voltage by 0.7 V is with a diode in series.
The output of this LED will not be 5 V, but will be much higher than the 3.3 V levels and can drive the rest of the strip reliably. And you can use its light also.
This is the counter to the problem that driving NeoPixels from an ESP8266 becomes unreliable when the LED supply voltage goes above 5 V.
Grumpy_Mike:
Interesting, that should not happen, maybe you need to look at the power supply or the capacitor across the strips.
That was my first thoughts as well, but you can see from the OP that I've try multiple power supplies, multiple LEDs strips (manufactures and # of pixels), and with and with/out caps. The only things left are the code used and the signal I get from the WEMOS D1 MINI (btw, I have tried three of)
Grumpy_Mike:
By he way what is the “Sacrificial LED /w diode” thing?
JimBobNW:
BTW: The ESP8266 Level Shifter Mini Shield has also been ordered from Tindle. I will report back the results when I get them.
As far as the correct logic levels are concerned, that should work perfectly. It is much more expensive than simply wiring a 74HCT14 on stripboard but you are of course paying for a neat ready-made design.
Whether it fixes the problem - or whether it is in fact the matter noted in reply #5 which is more likely - we will indeed see.
all the boards you got are the same chip, so they should all perform about the same. I would use a teensy 2.0 with an esp8266-01 as a daughter board. Not as elegant but it works.
You could also split the 144 leds into multiple strings on parallel to shorten the amount of time it takes to write the data out to limit the risk of interruption.
Also, the fastled library has tools for dealing with the esp8266 shortcomings, which helps a lot for smaller amounts for leds, and might help in your case.
Qdeathstar:
all the boards you got are the same chip, so they should all perform about the same. I would use a teensy 2.0 with an esp8266-01 as a daughter board. Not as elegant but it works.
Gotcha, Any ideas on how an Arduino YUN board might perform?
Qdeathstar:
You could also split the 144 leds into multiple strings on parallel to shorten the amount of time it takes to write the data out to limit the risk of interruption.
Unfortunately, this is not an option. And to be clear, I have the exact same issue with a 20 pixel strip I have been using for testing.
Qdeathstar:
Also, the fastled library has tools for dealing with the esp8266 shortcomings, which helps a lot for smaller amounts for leds, and might help in your case.
look at the fastled webserver example.
I'm still a Newbie here, I am not sure where to find appropriate tools or how to use them.
Any ideas on how an Arduino YUN board might perform?
I suspect not very will. The YUN is a Linux board with an embedded Arduino, but based on my experience with the Raspberry Pi the operating system screws up the real time aspect. So you have to resort to things like DMA drivers.
This is likely a problem. CRGB wants three byte values 0-255. Also, you set leds[i+2] to a value.
When i is at the end of the array, say i is 29 and your number of LEDs is 30, i+1 and i+2 are being written outside of the memory allocated for the array.
You either need to check if i+1 and i+2 are less than The number of your Leds minus one or so this a different way.
Qdeathstar:
Can you post a video of what you are seeing?
not the easiest thing to video, but here we go.
Here is a single color sent to a string of 40 pixels.
if(autoMode==0 && masterSwitch ==1) // Use the Zebra to conrol the color of Cube
{
for (int i=0;i<NUM_LEDS; i++)
{
leds[i] = CRGB(r, g, b);
FastLED.show();
Please do not even attempt to buy any; that would be rather foolish!
.