Glitching issues with patterns

[ntwallace]

First off, thanks for this port--this was the push I needed to migrate my big LED projects from Arduino to IDF with Arduino as a component. Let me know if I can be of help with the hardware SPI driver at all.

I'm testing out running WS2812FX patterns on WS2812B LEDs and noticing a few different glitching and ghosting issues:

1. The last pixel always glitches white when I run a pattern. This happens on all patterns and with both the RMT and I2S driver. Disabling WiFi and Bluetooth doesn't make a difference. Here's an example running a color wipe on a 256 pixel matrix, same thing happens on standard strips: GIF link

2. I think there may be a data overflow with the I2S driver while running patterns. When using the I2S driver, I get a bunch of extra glitching pixels on past the amount I have defined for the controller. I don't have this issue with the RMT driver. This is the same setup as above (256 LEDs on one output), when I attach additional LEDs I get all this extra glitchy stuff: GIF link

3. I see some ghosting on the leading pixels of animations when WiFi or Bluetooth is enabled. It's hard to capture with my phone camera, but in the above two GIFs there's also an issue where the leading few pixels of the animation don't clear/animate smoothly sometimes. Disabling both WiFi and Bluetooth fixes the issue, so I assume this is due to jitter. I noticed in the I2S driver you put fillBuffer in IRAM, but I don't think the 0 flag for the esp_inter_alloc call adds ESP_INTR_FLAG_IRAM, does it? I can explicitly call ESP_INTR_FLAG_LEVEL as 1, 2, or 3, but if I add | ESP_INTR_FLAG_IRAM I no longer get any output. Setting ESP_INTR_FLAG_LEVEL to 4 or greater also results in no output. Any thoughts on how to set the priority higher to avoid jitter issues?

Thanks again!

[BorisKourt]

I am also having these issues. The leading pixels are ghosting 'ahead' by a semi-random number.
The board I am using is Adafruit's Huzzah32. Data pin is set to 33 in the code, I haven't been able to find information on whether this pin is problematic or not.

I need WiFi for my application, and disabling just bluetooth on its own doesn't have an effect.

Since there is additional code running along side the FastLED animation, is there something that I should do to help isolate it from the rest?

Can I do anything to provide more details for the issue?

Thanks for any advice!

[bbulkow]

@ntwallace You can't set the FLAG_LEVEL to 4 or greater because the ESP-IDF framework doesn't allow C programs to run at those levels. This is documented https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/hlinterrupts.html .

1. "last pixel always glitches" - given that all my test patterns on I2S and RMT work except for a particular I2S issue, I would find it hard to understand that there's a code problem causing the last pixel that's caused by FastLED given how the code's so different between I2S and RMT.

2. Yes, we've now got 3 reports of something like this with I2S, but the issue is the pixel AFTER the size of the array. IE, if you have 3 pixels defined, but 4 in the string, the first or second channel on the subsequent pixel may be faulty. IE, if you have num_leds set to 2, but three actual pixels wired to that channel, you'll see that third pixel flicker. This is specific to the i2s driver, though, not what you're reporting.

Giving me the minimum code that shows your problem - or any code - is what will help me resolve.

3. Yes, first pixel flashes are usually jitter issues. The RMT driver has had lots of focus to remove jitter, and the I2S code hasn't. In the cases where you "don't see output" by raising the interrupt level, that's almost certainly because registering the interrupt has returned an error code, and Yve's code ignores errors. I'll put the error wrapper on that one function because it's a good one.

I don't have a lot of energy myself in fixing potential I2S jitter problems because I don't have them, but you can work with Yves, and I'll be happy to re-port his code fixes or yours.

In order to improve I2S with jitter, it'll be necessary to determine if the problem is Wifi or Bluetooth (I know you say Wifi only), to see if there's a way to increase the buffering of the I2S code (like we did with RMT), whether the core you run on matters (espressif has suggested this), whether detecting the jitter and "bailing" is enough of a fix (Sam has suggested it will because I2S always sends on LED boundries so you'll lose a little output but the glitch will not be seen), and if so add the "bail" code, whether you can lower the priority of wifi and/or bluetooth, and finally whether there's a section of code that can be changed to ASM in order to allow higher level interrupt access. Maybe there are other areas to explore but that makes sense to me.

[bbulkow]

@BorisKourt . I don't know what you could mean by "ghosting ahead". Ghosting is when you turn something (like a pixel) off, and it stays lit for a while, and then goes off ( like a ghost ).

As I've written above, there is a bug in the I2S driver where it will send a little extra data, randomly, and set the pixel which is later than the size configured. This is the only bug I've been able to verify and have talked to Yves about.

If you think you have a jitter problem, I believe the readme.md suggests that you switch from I2S to RMT, and then you turn on the "SHOWPIXELS" print so you can see if there are any "bailed" messages. It also allows you to see the number of microseconds between interrupts, and the amount of jitter, thus allowing you to raise the RMT buffer sizes to overcome.

The only code issue I know about right now which I can work on is the issue with I2S generating the wrong patterns - simply wrong. I have written some test code which doesn't show this, and I have some complex test code that might show the pattern, and one submission from a user that they claim does show the I2S pattern incorrect problem. If you can submit (simple) code that shows an I2S incorrect pattern ( which works fine on RMT ) that would be a great help.

[ShubhamS156]

Hey,
I'm having a weird problem that whenever I restart my ESP32 the leds show a different color+pattern even if the code just tells it to set a static color. I'm using WS2812B led strip.
``void staticColor(){
for(int i=0; i<NUM_LEDS; i++){
leds1[i] = CRGB(90,190,0);
}
FastLED.setBrightness(BRIGHTNESS);
FastLED.show();
delay(500);
}

void app_main() {
printf(" entering app main, call add leds\n");
// the WS2811 family uses the RMT driver
FastLED.addLeds<LED_TYPE, DATA_PIN_1>(leds1, NUM_LEDS);

// I have a 2A power supply, although it's 12v
//FastLED.setMaxPowerInVoltsAndMilliamps(12,2000);

// change the task below to one of the functions above to try different patterns
printf("create task for led blinking\n");

staticColor();

}
``

[psy0rz]

For anyone having glitching issues while using wifi: Try changing the core affinity: I configured "Main task core affinity (CPU1)" and all other stuff i could find to CPU0.

I only have a app_main() and i'm not creating any tasks.

No glitching while streaming data via wifi and spamming serial. :)