Possible Conflict with IRRemote

[scodavis]

Hi - I've spent all day creating a program that controls a strip of 150 2812B LEDs. The actual program control works great, and I've come up with 9 effects and an "off" effect. Now, I want to control which is the active effect using an IR Remote.

I have a 1838-based IR sensor that I got with my kid. I have installed the IRRemote 1.0 library by Ken Shirriff. So here's the thing - when I wire everything up and use the IRRecvDemo on the library, I'm able to get the IR codes from my remote, and it shows the same exact code every time I press each button.

However, when I use the exact same commands on the program I've written to control the LED strips, I get a different result every time I press the same button - sometimes it actually is the correct code gotten with the IRRecvDemo, but usually it isn't.

I'm stumped - any ideas on what I can look for?

[focalintent]

The timing protocol for WS2812 leds requires disabling interrupts while writing out led data, and the IR library relies on interrupts to read the IR data, which means that if you're using the remote while the library is writing out led data, then it is going to miss part of the ir signal and misinterpret it.

There isn't really any way around this - switch to 4-wire leds (like the APA102 (adafruit sells them as Dotstars) or the LPD8806 or WS2801) or, alternatively, use the teensy 3/3.1 as your controller, where I have a solution that allows interrupts to run, even while using WS2812 leds.

[scodavis]

Do you happen to know if the TLC5940 library also has this issue? I plan to create some TLC5940 projects that are controlled by remote. Furthermore, in relation to your library, are there other means of communication that do work - such as external Bluetooth transmitters and receivers?

[focalintent]

It has less to do with the library and more to do with the chipset protocol - chipsets that use both a clock and a data line don't need to have interrupts disabled (which is why I recommended the APA102 or LPD8806 as alternatives). I believe the TLC5940 uses both a clock and a data line, so it shouldn't have this problem. (It's on my list of chipsets to add, but it's been a pretty low so far)

As for other means of communication, it really depends on how the hardware that's used for the communication talks to the arduino. If it's something that is constantly transmitting in the background and requires an interrupt handler to handle incoming data, then it is going to have problems with the WS2812 family of led chipsets.

If, instead, it is something where you can ask the device "is there data? If so, send it to me" and then read the data before writing out the next frame of led data, you shouldn't have any problems.

(Or, alternatively, switching to something like the teensy 3.0/3.1 which has a high enough clock rate that I can allow interrupts to run while writing out WS2812 data).

[scodavis]

I also have a bunch of extra ATMEGA328 chips - I'm thinking that another solution would be to use one of them (basically a standalone Arduino) and its output pins (with the IR Sensor attached to it), to talk to the second one's pins as input, and use those as the triggers for a program change on the second Arduino (the one controlling the LED strips).

Either way, I really like your library, and I also really appreciate your help on this!

[focalintent]

I am aware of many projects that have done the double device solution like you describe. (I'm sorry that the ws2812 chipsets pose such a problem - I'm looking forward to a world where they are replaced by the apa102 :)

[VorpalLemur]

I ran into this same issue, integrating a 1838-based IR sensor to remote control an Arduino driving WS2811's. The solution I found is to simply check the idle status of the IR receiver before kicking off FastLED.show() and, if we're in the process of reading a IR remote code, wait till it completes. It's not a 100% solution as there's still a race condition where a remote code can start during a LED update, but it does seem to at least get us to the 95%+ reliable level.

IRrecv irrecv(RECV_PIN);
decode_results results;

loop() {

    /* do effects here */

    while (!irrecv.isIdle());  // if not idle, wait till complete

    if (irrecv.decode(&results)) {  
        /* respond to button */

        irrecv.resume(); // Set up IR to receive next value.
    }

    FastLED.show(); 
}

[focalintent]

Also, some of the ir libraries allow you to flush the ir receiver, to basically block it from receiving a partial code (it will throw away what it has, and then cycle back to waiting for the start).

[marcmerlin]

I'm seeding google results (including this one) with a solution page I wrote for this after a few days of work.
This page and video explain the issues between IR and neopixels, and how to make it work on teensy v3.1, ESP8266, and ESP32:
http://marc.merlins.org/perso/arduino/post_2017-04-03_Arduino-328P-Uno-Teensy3_1-ESP8266-ESP32-IR-and-Neopixels.html
this short video shows how trying this on AVR is an exercise in frustration and handling failures :)
https://www.youtube.com/watch?v=62-nEJtm070

[niklas]

With IRMP one can use irmp_IsBusy to skip a frame.