First LED in addressable string does not fade when using scheme

[KDMcMullan]

PROBLEM DESCRIPTION

When using an addressable LED string, the fade is not happening for the first LED in the string. Instead, the LED flicks to the next colour in the sequence, while all the others fade.
This has been observed previously as issue #3480, but folk stopped reporting so the issue went stale. one user reported solving it by replacing the LED, but I'm not sure this wasn't coincidental.

REQUESTED INFORMATION

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in the docs
• Searched the problem in the forum
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): _____
• Tasmota binary firmware version number used: 8.5.1
  • Pre-compiled
  • Self-compiled
    • IDE / Compiler used: _____
• Flashing tools used: esptool 2.6
• [] Provide the output of command: Backlog Template; Module; GPIO 255:

12:55:24 MQT: generic/stat/RESULT = {"NAME":"Generic","GPIO":[255,255,255,255,255,255,255,255,255,255,255,255,255],"FLAG":15,"BASE":18}
12:55:24 MQT: generic/stat/RESULT = {"Module":{"18":"Generic"}}
12:55:24 MQT: generic/stat/RESULT = {"GPIO0":{"5":"I2C SCL"},"GPIO1":{"0":"None"},"GPIO2":{"6":"I2C SDA"},"GPIO3":{"0":"None"},"GPIO4":{"7":"WS2812"},"GPIO5":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"0":"None"},"GPIO13":{"4":"DS18x20"},"GPIO14":{"0":"None"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"}}

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:
12:57:11 MQT: generic/stat/STATUS = {"Status":{"Module":18,"DeviceName":"Tasmota","FriendlyName":["generic","Tasmota2"],"Topic":"generic","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":2,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
12:57:11 MQT: generic/stat/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://thehackbox.org/tasmota/release/tasmota.bin","RestartReason":"Power On","Uptime":"0T05:44:02","StartupUTC":"2020-12-02T07:13:09","Sleep":50,"CfgHolder":4617,"BootCount":22,"BCResetTime":"2020-11-01T23:01:20","SaveCount":93,"SaveAddress":"F6000"}}
12:57:11 MQT: generic/stat/STATUS2 = {"StatusFWR":{"Version":"8.5.1(display)","BuildDateTime":"2020-10-02T10:11:52","Boot":31,"Core":"2_7_4_1","SDK":"2.2.2-dev(38a443e)","CpuFrequency":80,"Hardware":"ESP8266EX","CR":"338/699"}}
12:57:11 MQT: generic/stat/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["Scrabo",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["000A8009","2805C8000118060000005A00000000000000","00000208","00006000","00000000"]}}
12:57:11 MQT: generic/stat/STATUS4 = {"StatusMEM":{"ProgramSize":558,"Free":444,"Heap":22,"ProgramFlashSize":1024,"FlashSize":4096,"FlashChipId":"164020","FlashFrequency":40,"FlashMode":3,"Features":["00000809","0FAAA59E","04049FA1","000000C1","00000000","00004080","00000020","00000000"],"Drivers":"1,2,4,5,8,9,10,13,16","Sensors":"1,2,5,6"}}
12:57:11 MQT: generic/stat/STATUS5 = {"StatusNET":{"Hostname":"iotGeneric","IPAddress":"192.168.1.121","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"80:7D:3A:3D:B0:6D","Webserver":2,"WifiConfig":4,"WifiPower":17.0}}
12:57:11 MQT: generic/stat/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.111","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_3DB06D","MqttUser":"device","MqttCount":1,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30}}
12:57:11 MQT: generic/stat/STATUS7 = {"StatusTIM":{"UTC":"2020-12-02T12:57:11","Local":"2020-12-02T12:57:11","StartDST":"2020-03-29T01:00:00","EndDST":"2020-10-25T02:00:00","Timezone":99,"Sunrise":"07:24","Sunset":"15:54"}}
12:57:11 MQT: generic/stat/STATUS10 = {"StatusSNS":{"Time":"2020-12-02T12:57:11","ANALOG":{"A0":105},"DS18B20":{"Id":"0315A25A3EFF","Temperature":0.0},"TempUnit":"C"}}
12:57:11 MQT: generic/stat/STATUS11 = {"StatusSTS":{"Time":"2020-12-02T12:57:11","Uptime":"0T05:44:02","UptimeSec":20642,"Heap":22,"SleepMode":"Dynamic","Sleep":10,"LoadAvg":99,"MqttCount":1,"POWER1":"ON","Dimmer":72,"Color":"166,77,184","HSBColor":"290,58,72","Channel":[65,30,72],"Scheme":0,"Width":1,"Fade":"ON","Speed":4,"LedTable":"ON","Wifi":{"AP":1,"SSId":"Scrabo","BSSId":"1C:AE:CB:C7:39:84","Channel":9,"RSSI":100,"Signal":-46,"LinkCount":1,"Downtime":"0T00:00:05"}}}

• Provide the output of the Console log output when you experience your issue; if applicable:
  (Please use weblog 4 for more debug information)

  Console output here:

TO REPRODUCE

Connect a LED WS2811 chain
set fade
set scheme (eg 7)

EXPECTED BEHAVIOUR

I would expect all LEDs to fade in sequence. Instead, only 49 of 50 do.

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

If I select the colour on the web interface front panel, ALL the LEDs fade. I suspect the problem is with the scheme routine, rather than the fading routine.

(Please, remember to close the issue when the problem has been addressed)

[arendst]

As was probably noted in the previous issue too this is a hardware failure. The string needs to receive the correct voltage and signal levels. In your case the first led will fix the signal levels for the next leds in the string.

Revisit your power source, voltage level (shift), serial resistor etc.

[arendst]

Oh and I'm not sure a WS2811 is supported. A WS2812 is supported.

[ascillato2]

Closing this issue as it has been answered.

---

Support Information

See Docs for more information.
See Chat for more user experience.
See Community for forum.
See Code of Conduct

[KDMcMullan]

My PSU is delivering 5.00V to the LED chain according to my DMM. The supply is rated at 3A. The cable is the manufacturer's own and is only 20cm long.
I'm at a loss as to why I can flawlessly set any colour manually (and fade even works on LED0 from the web interface). The only place I can't perform a fade is during a scheme.

[sfromis]

The point about voltage is not the power supply, but what signal voltage is used on the data pin. Most neopixel leds need 5v here (possibly less if it supports power lower than 5v), but ESP8266 only has 3.3v on outputs. One way of bridging this gap would be to use a level shifter, transforming the signal to another voltage.

[FearNaBoinne]

I saw a major improvement after inserting a level shifter to get the signal to 5V.
(Also, make sure you use capacitors and resistors to smooth out the voltage pulses to the LEDs so they don't fry...)

[KDMcMullan]

Is this more about the LEDs not being able to keep up with the fast data rate when the data voltage is a spit on the low side?

[sfromis]

I'd expect it to be an issue of the trigger voltage for detecting if bits are on or off. One not very good attempt could be if you can lower the power voltage, as detection of high bits often is relative to the power level, sometimes like 0.7 * vcc, which would be 3.5v.

[techman83]

As Theo noted, the first LED usually sorts the levels. You can even add an extra hidden one to use as an improv level shifter, by powering it with 3.3v, sharing a ground with the rest of the chain. In practice, I've always managed to get away with 3.3v signalling and 5v power on the strip. But, where the strip is grounded in relation to the the boards ground can upset the apple cart.

[vic42]

I was able to duplicate the issue on known-good hardware.
A fix will be available soon.