Fastled: ESP8266 Jitter

[ibaranov-cp]

Hey all,

Trying out the FirstLight demo (or any demo, but clearest there) with a 144 string of WS2812B, and the single white LED will jump forward or back by ~10 spaces, once or twice every second. Animation seems smooth, but the jump is sudden and distracting. After the jump, animation resumes from where it is supposed to be. I would suspect a buffer or processing delay if it was just a glitch (momentary pause) but this jitter speaks of some sort of timer inaccuracy possibly?

It gets worse when the entire string does this jitter back and forth.

Any thoughts on what direction to look into for this issue?
I am using PIN 5 btw, on a standard wired ESP.

Did a search for this, couldn't find an answer, but please link one if it exists!
Thanks :)

[bugilt]

I just ran it on a teensy hooked to 144/m led strip with no jitter. What is your power supply and what gauge is your data wire and how long.

[focalintent]

Try adding the line:

#define FASTLED_ALLOW_INTERRUPTS 0 before the #include <FastLED.h> -- what you're describing sounds like an interrupt that's running a bit too long (but that isn't being caught as having run too long by the code that allows interrupts)

[focalintent]

Also - where did you get your leds from? (I'm wondering if the led reset timing on the strip that you got is shorter than what I had timed with other WS2812's)

[ibaranov-cp]

Hey all,

Thanks for the fast reply. allow interrupts set to 0 seems to solve the problem just perfectly.

Here the stuff I got:
https://fr.aliexpress.com/item/1M-long-144leds-m-WS2812B-5050-rgb-led-with-WS2811-IC-built-in-led-pixel-strip/2047880507.html?detailNewVersion=&categoryId=200001051

Power supply is a 20A, 5V lab bench supply, wire gauge is not known on this strip, but fairly huge (would be surprised if voltage droop was the cause on a short strip like this.)

Might be worth adding this to the ESP8266 quick start notes, but otherwise seems solved!

[DeuxVis]

@ibaranov-cp your aliexpress link is not accessible to other users - it's from your order - can you confirm you are talking about this product please : https://fr.aliexpress.com/item/4m-DC5V-IP65-WS2812B-led-digital-strip-60pcs-WS2812B-M-with-60pixels-57-6W-BLACK-pcb/1077884982.html

[ibaranov-cp]

Sorry, fixed:

https://fr.aliexpress.com/item/1M-long-144leds-m-WS2812B-5050-rgb-led-with-WS2811-IC-built-in-led-pixel-strip/2047880507.html?detailNewVersion=&categoryId=200001051

[maru-sama]

Hello,

I am facing similar issues with a 32 led neopixel feather on top of a 8266 Huzzah. This used to work with an older version of fastled without any issues. I recently upgraded my build libraries and then noticed that I get "ghost" leds when I do something similar to the sinelon demo. The pixel moves forward and backward and fades out but every now and then several other leds shortly light up. Adding either of

define FASTLED_INTERRUPT_RETRY_COUNT 0

define FASTLED_ALLOW_INTERRUPTS 0

fixes this issue for me. I just wanted to mention this since this was not needed with earlier versions of the library.

[focalintent]

There's been a lot of work trying to tweak this stuff in the library over time (when the retry count is 0 you end up having leds near the end of the strips fail to ever update in the case of interrupts occurring).

The problem that I think is happening is there's some variation in WS281x production - where the differences in time that can exist between led data before an led latches are exacerbating problems.

There's a value in the library that is basically the threshold for how long an interrupt takes to run at which we have to stop writing led data for the current frame, otherwise the next led's worth of data written out will go to the first led because the leds will have latched and reset. If that value is too high, then it will be possible for an interrupt to run long enough to let the leds reset, which would mean writnig the rest of the frame starts back at the first led (experienced as flicker or ghosting near the front of the leds). If that value is too short, then leds towards the end of the strip will be less likely to update with any given writing of frame data. This value isn't exposed at the moment, and i'm working on that - but between having started a new job recently and just having had a close death in my family, basically all FastLED work is on indefinite hold for now.

[xsrf]

Hey,
I also had a terrible jitter on WS2812 modules I bought recently from aliexpress ( https://www.aliexpress.com/item/-/1666223973.html ) using FastLED on a Wemos D1 mini board.
A strip of WS2812 ( https://www.aliexpress.com/item/-/32337440906.html ) however has no jitter at all, connected to the same output in parallel. So there MUST be differences in production quality / timing...

define FASTLED_ALLOW_INTERRUPTS 0

solved the problem, the jitter is gone.

However: Using my scope, I found that FastLED is not producing an output that is in spec of WS2812 chips... I get T0L levels of 1080ns to 2000ns (spec is 800ns+150ns max), T1H of 950ns (spec is 700ns+150ns) and T1L of 420ns (spec is 600ns-150ns min). Only T0H is in spec with 310ns.
So... I wouldn't blame it all on the cheap LEDs.

[focalintent]

The timing being off is why I call the parallel output on the 2812's unstable :)

Also - I still need to re-tweak the timing for the esp8266's - I think the clock I'm working against has some jitter or resolution issues. Ideally what I would do is something like the asm code the arm m0 has. But unlikely anytime soon.

[focalintent]

Also the jitter you and others see (as opposed to clock/timing jitter which is invisible unless it swings the timings out) when not disabling interrupts is caused by different chips having a different amount of time that you can "gap" between leds without them latching and losing place. When I get back to working on the library, exposing this more easily as a config option is something I'd like to do.

[xsrf]

Thx for the information. It is quite hard to trigger and capture the glitches on the scope to analyze what timing actually caused the issue. Guess to do that it is best to update the LEDs not periodically but manually until a glitch occurs.
Just also wanted to add video, showing the different behavior of the different WS2812 LEDs: https://youtu.be/NDo2KPu6q5Q
The display is updated with 50fps, 1st LED is on the left.

[nethoncho]

I am having issues with the 8266 Huzzah also.
Adding FASTLED_ALLOW_INTERRUPTS 0 or FASTLED_INTERRUPT_RETRY_COUNT 0 above #include dose not help with my setup

Arduino version 1.6.10
Arduino esp8266 board package 2.3.0
FastLED version 3.001.005

Using the ParallelOutputDemo example with the following changes

define NUM_STRIPS 4

LEDS.addLeds(leds, NUM_LEDS_PER_STRIP);

Using 4 different sources of leds that are wired to Huzzah pins 12,13,14,15 through a 3.3v to 5v level shifter
My symptom is that the first two LEDs in each string flicker.

Using serial output via multiple addLeds(leds, NUM_LEDS_PER_STRIP); works flawlessly but is slower to update (obviously)

[EricMc1289]

Maybe i found one issue with the ESP. I have tried a lot of solutions to reduce the problem with jitter. Nothing seems to work, even the three commands
FASTLED_ALLOW_INTERRUPTS 0
FASTLED_INTERRUPT_RETRY_COUNT 0
INTERRUPT_THRESHOLD 1
to reduce problems with interrupts didn't seem to work.

So what to do is reducing interrupts or the time interrupts need to complete.
The solution for me is to set the wifi.sleepMode to WIFI_NONE_SLEEP. The default value from the SDK is WIFI_MODEM_SLEEP, which will set the modem to sleep between two beacons from the ap. So if there is an interrupt from the wifi core to respond to the ap's beacon to hold the connection.
My idea is, that if the modem is in sleep mode, it needs much more time to wake up and respond to the beacon. So i disabled the sleep mode and the jitter got reduced, but you will have a higher power consumption.

Hope this helps. Feedback would be nice.

[kriegsman]

Huh! Interesting and good find. How well are you finding it to work?

[EricMc1289]

The solution works so far for me. But i had two problems with jitter. First the LEDs lights up randomly in random colors, so there was a transmission problem which was solved after the solution i posted above.
I also reallowed interrupts and removed all the defines i posted above and the jitter is still gone. The second jitter i had was that when i dim down my leds only the ones that are on increases there brightness randomly, but i think that was a problem with the power source. I am using a 5V and 12A power supply to drive 120 WS2812 so it should be strong enough but the jitter on active leds was gone after increasing the capacitor at the supply from 680uF to 2200uF.
So from my testing i can say that it helps a lot to use a minimum capaciter of 1000uF and disable the sleepmode to shorten the interrupts for handling wifi connection.

[kriegsman]

Thank you for the experiments, and testing, and for sharing your findings here! Lots of people (including me) are starting to use the ESP MCUs more, and this helps.

[JonasVorwerk]

Here the WS2812 (from http://www.ipixelleds.com) leds are also flickering on the Adafruit's Huzzah esp8266.

Adding the line below solves the problem, but then wifi doesn't seem to work anymore.

define FASTLED_ALLOW_INTERRUPTS 0

Adding the line below keeps wifi alive, and does make the led's blink with "a bit of random" flickering but way less then before.

define FASTLED_INTERRUPT_RETRY_COUNT 0

[Blink515]

I've been able to completely get rid of the flickering by using the following:

define FASTLED_INTERRUPT_RETRY_COUNT 0

and by putting the following line in the setup function based on one of the comments above.
WiFi.setSleepMode(WIFI_NONE_SLEEP);

[dimitre]

In my case I've used the line

#define FASTLED_ALLOW_INTERRUPTS 0

which solved everything related to jitter but now wifi is very unstable. I think both are related. Anybody else having issues regarding FastLED + Wifi?

[Blink515]

@dimitre I've been able to completely get rid of the flickering by using the following:
#define FASTLED_INTERRUPT_RETRY_COUNT 0

and by putting the following line in the setup function based on one of the comments above.
WiFi.setSleepMode(WIFI_NONE_SLEEP);

Be sure to delete #define FASTLED_ALLOW_INTERRUPTS 0 otherwise you will run into WDT Resets

[dimitre]

Thank you @Blink515 this solved everything. I have about 10% the jitter but it depends a lot of the content I'm using. system is pretty stable now.

A curiosity, I'm using FastLED inoise8 in my scenes, and it is very smooth on ESP, but very different in Teensy 3.2 which I'm using to prototype the scenes.

[Blink515]

How is it different? I'd recommend posting on the Google plus group. Lots
of smart people on there that can probably get you an answer.

On Mon, Jul 24, 2017, 6:03 PM Dimitre [e-mail] wrote:

Thank you @Blink515 https://github.com/blink515 this solved everything.
I have about 10% the jitter but it depends a lot of the content I'm using.
system is pretty stable now.

A curiosity, I'm using FastLED inoise8 in my scenes, and it is very smooth
on ESP, but very different in Teensy 3.2 which I'm using to prototype the
scenes.

[image: img_1595]
https://user-images.githubusercontent.com/58289/28549843-513b5d4a-70b3-11e7-9065-bc353e581e21.JPG

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/FastLED/FastLED/issues/367#issuecomment-317589384,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7zshfAx3T_6kmYdf7WV8PvKLpdCWhJks5sRTDAgaJpZM4KpI9z
.

[RickTracer]

Another tip - I still got the jitter in a few cases (though reduced with the tips above). What completely fixed it for me was changing the frequency of the ESP8266 in the Arduino IDE (it was defaulted o 80Mhz but changed to 160Mhz and it now runs smoothly).

[freysup]

I have same Problem with an 5V 10A Power Supply. So when i used USB Kabel to Power WS2812B 1M 144 LEDS. No Problem. But i don't know the Reason. Could any help?

Best Regards
freysup

[jordanadania]

So far, the best combination of changes for me has been:

• #define FASTLED_ALLOW_INTERRUPTS 0 before #include
• Disabling Serial.begin(115200)
• yield() after FastLED.show()
• CPU Frequency from 80 Mhz to 160 Mhz

Going to test editing clockless_8266.h wait time from 50 to 5 if I get anymore jitters.