I admit I'm probably just a little screen-fatigued, but I'm running the following code and having trouble catching the results.value accurately every time. I need to grab the IR data fluidly between each FastLED.show(), without a delay requirement of its own, because I later use that delay as a result of a calculation that sequences FastLED calls, which has an inherent lower-bound delay. In otherwords, I need a particular frequency range on the LED sequence, so I can't afford to slow down operation of the program any more than the inherent FastLED time-to-update.
The FastLED show function disables interrupts while it sends data to the LED strip. If any IR data comes in while interrupts are disabled, the signals will be missed or corrupted.
Please do not post screenshots of program output or your program. Copy and past the program output as text.
Please read the forum guidelines to see how to properly post code and some information on making a good post.
Use the IDE autoformat tool (ctrl-t or Tools, Auto format) before posting code in code tags.
Thanks, wouldn't have gotten that on my own guesswork.
you are halting execution of the program by adding delay in the loop, delay stops everything, if you transmit at this point IR your received data is corrupted
this is a documented issue see on GitHub Problems with Neopixels, FastLed etc.
Problems with Neopixels, FastLed etc.
IRremote will not work right when you use Neopixels (aka WS2811/WS2812/WS2812B) or other libraries blocking interrupts for a longer time (> 50 µs).
Whether you use the Adafruit Neopixel lib, or FastLED, interrupts get disabled on many lower end CPUs like the basic Arduinos for longer than 50 µs. In turn, this stops the IR interrupt handler from running when it needs to.One workaround is to wait for the IR receiver to be idle before you send the Neopixel data with
if (IrReceiver.isIdle()) { strip.show();}
.
This prevents at least breaking a running IR transmission and -depending of the update rate of the Neopixel- may work quite well.
There are some other solutions to this on more powerful processors, see this page from Marc MERLIN
Using (the more costly) APA102 instead of WS2812 would decrease/remove the pressure on the MCU to handle the update of the LEDs, giving plenty of time for the IR receiver to work fine.
no, the (usual) IR library uses a 50 µs timer ISR that would work during delay()
I see
while (ms > 0)
{
yield();
….
not sure what you mean.
The IR library uses interrupts, so unless interrupts are disabled, every 50µs the ISR will be called and poll the receive pin to see if something is going on - regardless of what the main code is doing, wether a delay() or something else.
That was part of delay source code
OK - so it does not block interrupts, we are fine
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.