I’m having a flickering problem with my WS2812s when driving them with an Adafruit Feather Huzzah. I’m using a logic converter to change the 3.3v signal to 5v.
These LEDs work perfectly fine when being driven by an Ardunio Uno. Anyone have any ideas?
https://i.imgur.com/VX6TUIP.png (Schematic)
https://i.imgur.com/vHLskbi.mp4 (Video of the flicker)
The problem is, that the CPU of the 8266 does not only run your code, but has to manage WiFi in real time, therefore your datastream to your WS2812 may be corrupted from time to time.
There is a solution that relies on the I²S module of the ESP8266 using DMA without the CPU bit-banging the data stream.
@Frank_Sautter I should have mentioned above that my Sketch doesn’t have any WiFi code in it yet. It’s flickering with the same sketch I loaded on the Uno. Does that change your opinion? Or could I still have this problem regardless?
You can use the NeopixelBus library which provides several programming methods to prevent flickering when using the ESP8266. It works great for me on a Huzzah using the NeoEsp8266Uart800KbpsMethod method. You have to use the 80MHz CPU freq as I just discovered.
It’s probably the logic level shifter, it doesn’t look like you’re using an SN74HCT. Try just missing it out, or use either a SN74HCT245N or a SN74HCT125N.
http://happyinmotion.com/?p=1247
This is a common issue that deserves a sticky(pinned?) thread/post to help people out. I feel like there is at least 1 post on here and an issue added to GitHub every week with ESP8266 and flickering issues.
At the top of your sketch before #include “FastLED.h” add:
#define FASTLED_INTERRUPT_RETRY_COUNT 0
At the beginning of the setup function add:
WiFi.setSleepMode(WIFI_NONE_SLEEP);
With those 2 lines of code you should no longer see any flickering.
@Brian_Lewis Thanks, I will try that out asap. Sorry for posting a repeat/common question.
@Paul_Wieland Any luck?
@Brian_Lewis Your solution worked. Thanks a ton!
@Paul_Wieland Good to hear. Happy blinking.
@Brian_Lewis I suppose I have one question though - what is the net effect of (downside) of having FASTLED_INTERRUPT_RETRY_COUNT set to 0?
@Paul_Wieland None that I’ve noticed. By default the library tries 2 times to retransmit a frame if it was held up by interrupts for too long so this line sets it to not retry.
