FastLED flickering/stuttering with GW6205 addressable LEDs

jerano commented 2 years ago

The problem

Issues with FastLED light component.

Rainbow effect flickering a whole lot, Scan effect is stuttering and skipping LEDs.

Which version of ESPHome has the issue?

2021.11.4

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2021.11.5

What platform are you using?

ESP8266

Board

NodeMCU & Wemos D1

Component causing the issue

light

Example YAML snippet

light:
  - platform: fastled_clockless
    chipset: GW6205 # or WS2812B
    pin: GPIO0
    num_leds: 14
    rgb_order: RGB
    max_refresh_rate: 100ms
    name: "rgb-strip"
    effects:
      - addressable_rainbow:
      - addressable_scan:

Anything in the logs that might be useful for us?

Nothing, no errors at least.

Additional information

Tried with both Wemos D1 and straight NodeMCU - Same issue. Tried with both GW6205 and WS2812B strips , only changing "chipset" in config - No issues with WS8212B Tried GW6205_400 instead for slower clock, but that does not work at all. Have tried disabling logging - No change. Have tried slower refresh rate, but it's still there, but slower & not as visible in Rainbow, but still easy to spot in Scan effect, the skipping and jumping around.

Slowed things down and attached my logic analyzer.

Configuration:

platform: fastled_clockless chipset: GW6205 pin: GPIO2 num_leds: 14 rgb_order: RGB max_refresh_rate: 16ms name: "rgb-strip" effects:
- addressable_rainbow:
- addressable_scan: move_interval: 1000ms

Stopped the analyzer right after a "missed step" in the Scan effect and it seems like there's something interfering with the data sending part of the code(?). The "BAD" data bursts are a little longer than the "normal" ones.

OK bursts : 667.0 us. BAD burst : 670.5 us .

I changed num_leds to 4 instead of 14, and checked again.

OK bursts : 189.4 us BAD burst : 192.9 us

For both test cases, seems like the burst is 3.5 us longer then it should be.

Below are screenshots of an OK burst (top) and a BAD bursts (bottom). You can clearly see the extra space between the last two packets in the BAD one. Seems like something is interupting the send routine?

GW6205_Packet_OK GW6205_Packet_BAD

In this particular test, the Scan sequence had reached the far end (last LED was lit) and was on it's way back. When the BAD burst was sent, the last LED was not turned off, so both the last LED and the one in front was lit until the next packet came and lit up the 3rd LED from the back and turned off the two behind.

martgras commented 2 years ago

Since esphome uses FastLED as library this sounds like an external issue with the library.

Have you tried using an esp32 instead of esp8266?

jerano commented 2 years ago

I don't have en ESP32 on hand but I have tried the FastLED library on the D1 Mini and NodeMCU without ESPHome and haven't seen any issue. (Haven't tried the EXACT effects though, but I can try to see if I can locate such code and try.)

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

esphome / issues