Output is sometimes glitchy with ESP8266

[AlbertGBarber]

Hi, this project is excellent, but I've run into some issues when using the system with an ESP8266 (a Wemos D1 Mini specifically). Basically the output "glitches" constantly depending on the effect I'm running. It seems to happen for some effects but not others. I don't believe it's my code as I've tested it using an Arduino Nano, which works perfectly. Likewise, the Wemos works correctly with physical LEDs. I am using the FastLED library if that helps.

See the attached gif below for an example output. The effect should just be bands of color moving across the strip, with the colors changing over time.

Things I've tried:

• Re-syncing either by using "s" or by re-plugging the USB.
• Powering the esp via DC input. I thought maybe the ESP was sending serial data back and screwing up the Bluepill.
• Linking/unlinking the grounds.
• Different ESP pins.
• Different ESP8266's (both Wemos's).
• Using with/without a level shifter.

It seems like it may be a timing issue?

Thanks for any help, and I apologize if I've missed something obvious!

[relwin]

Hi Albert! I haven't tested NeoPill with ESP8266 yet. However I recently ported code from Nano to ESP8266 with FastLED and had glitches due to using analogWrite(), which is a known problem: https://forum.arduino.cc/t/fastled-library-on-esp8266-conflicts-with-analogwrite/613170

There may be further ESP8266 timing issues that cause problems on the NeoPill but are tolerated by LEDs. The YAML file configuration supports modifying timings T1H and RES, for example: timing_T1H: 550
timing_RES: 48000

You may try tweaking these values a bit.

Thanks, Randy

[AlbertGBarber]

Hi Randy,

I'm not using analogWrite() anywhere, so that shouldn't be any issue. I've tried tweaking the timings in the YAML files, but they don't seem to make any difference to the output (except at extremes, where the output gets cutoff). The ESP must be doing something weird in how it outputs the pixel data. I guess the LEDs just filter it out, but it is captured by your code. Unfortunately I'm not knowledgeable enough to know how to debug this.

I should add the output behavior is looks very similar to when you have too much voltage drop to your first LED or are missing a level shifter. I'm not sure if this correlates at all to how the Bluepill reads the pixel data.

Best, Albert

[relwin]

Hmmmm...

Of course there's multiple points of failure available - host device, bluepill, computer running python, and cables in between.

Some things to try: 1-Try the failing pattern without LEDs connected (if not tried already). The Bluepill runs at 3.3V but uses 5V tolerant inputs, so a level shifter isn't required to operate without LEDs connected. 2-Try a simple test of single color up to max LEDs. 3-Configure for 1 or 2 LEDs, see if problems still occur.

Can you send me your code for the glitchy pattern? However I won't be able to investigate for a few weeks...

--r

[AlbertGBarber]

I've tried it with different USB cables, pin connections, etc.

Things like single colors do seem to work, and not all of the effect's I've tried glitch. Changing the number of LEDs didn't make a difference.

The code is part of some examples for an LED library I'm developing. It is public, but not yet available on the Arduino Library manager, so you'd need to install it manually. The library is pretty complicated, but I've almost finished the wiki documentation.

Both the Cycling Multiple Effects and Color Modes examples reliably glitch, while the other examples do not. Note that you'll need to comment out all of the Serial stuff in both examples, which definitely interferes with the Bluepill, and increase the brightness to 200, which helps display the colors correctly.

You could also try running a "Streamer" effect in the "Basic Setup" example, which is a bit simpler: "StreamerSL myStreamer(mainSegments, cybPnkPal_PS, 0, 4, 3, 8, 80);" for the effect constructor.

Since all the code seems to work on basic Arduino's, and outputs fine to physical LEDs (for ESP8266's and Arduino's), I have a feeling that the issue lies either with the ESP specifically, or FastLED's implementation of the WS281x protocol.

[relwin]

Ok, one thing to try is tap the data line from the 2nd LED, or just use 1 LED in "front" of the NeoPill data input. If there are any "stray" serial bits being sent the LED might filter them out. The NeoPill can't handle extraneous data bits after RES delay, i.e. starting a partial frame. The firmware can detect but you'd have to run it in a debugger to verify.

Other suggestions involve ESP interrupts, but I think they're disabled anyway...

define FASTLED_ALLOW_INTERRUPTS 0

https://github.com/FastLED/FastLED/wiki/Interrupt-problems

--r

[AlbertGBarber]

Adding a physical LED in "front" of the data works! Thanks for the suggestion! There must be some extraneous frame data putout by the ESP for some reason.

[relwin]

This workaround hopefully lets you progress. The NeoPill is not a good Neopixel driver debugging device.