Findings regarding flickering issues and how to proceed #5264
Description
There was a lot of reports and discussion around the "xxx causes flickering/ flashing" issues.
I have spent quite some time trying to collect the information and correlate it to measurements. Here is what I found in a nutshell:
- RMT causes flickering in 0.15.0 (confirmed and fixed in 0.15.3 and nightly by high priority interrupt driver)
- ESP32 C3 still suffers from RMT interrupt latency as the fix can not be applied (causes crashes) - investigation ongoing
- First port / second port causes flickering: this is related to I2S and RMT outputs having slightly different timings, causing one or the other to work better.
So basically it all comes down to 0.15.x and 0.16 mixing I2S with RMT outputs which was not the case in 0.14.x: the first 8 outputs always used RMT.
Since user reports about different LED types and setups wildly differ it can not just be pin-pointed to a single cause. For some the RMT flickers, for other the I2S does.
0.15.0 with I2S is a special case as it seems to be using 4-step-cadece timing and has been reported to work better on some setups.
Here are the measured timings for WS281x:
| Mode / Version | 1 High | 1 Low | 0 High | 0 Low |
|---|---|---|---|---|
| I2S 0.15.1–0.16 | 840 ns | 420 ns | 420 ns | 840 ns |
| I2S 0.15.0 | 940 ns | 310 ns | 310 ns | 940 ns |
| RMT | 800 ns | 450 ns | 400 ns | 850 ns |
Proposal for possible fixes
First off we should use either RMT or I2S, mixing them "at random" leaves users puzzled as there is no clear indicator of what driver is being used.
I would propose to use RMT as a default and only pull in I2S if more than 8 outputs are used OR the already existing "Use parallel I2S" is checked, but rename it to "Enable I2S" and maybe even restrict to 8 outputs if that is not checked so users are aware they are enabling a different driver, helping them to narrow down the problems and also make better reports on what causes the issue (i.e. less of "I swapped stuff and reconfigured at random and it stopped").
Second I would add additional (maybe RMT only) timings for users to choose from. From a report the WS2813 seem to be a bit picky or the datasheet values are not really any good. Fastled uses a 1:4 (0bit) / 1:1 (1 bit) timing which was reported to work where as the default WS281x timing which is well withing datasheet bounds did not work for that user.
So adding different timings gives users options which may work better on some LED types. Ultimately I would like to see a "expert" type that just lets you manually enter timing of the RMT driver but this is currently not feasible as it needs a rewrite of the NPB library (different init structure).
I would propose to add these types as additional alternatives to the current WS281x:
- WS2811 - NPB already has adjusted timings for it, RMT only
- WS281x fast - decrease cycle period from 1.25µs by 10% to ~1.1µs
- WS281x slow - increase cycle period by 10% to ~1.4µs
- WS2813 - just a variation of WS2811 with shorter "1" pulses
these could be added to 0.16, probably not all of them are needed in the end but its impossible to know without user feedback.
@netmindz @willmmiles @softhack007 what are your thoughts on this? any additional insights?
CC: @blazoncek @Makuna