Array of IRremote objects

Projects Programming
1

In another thread in which I am involved we have just about got to the point where the OPs requirements regarding use of an IR receiver have been met. However, the OP of the thread has just made it known that the code needs to work with 4 separate IR receivers. Oh, joy !

My thoughts immediately turned to creating an array of IRrecv objects so I tried this

#include <IRremote.h>

IRrecv irrecv[] = {12};
decode_results results;

void setup()
{
  Serial.begin(115200);
  Serial.println("Enabling IRin");
  irrecv[0].enableIRIn();
  Serial.println("Enabled IRin");
}

void loop()
{
  Serial.println(irrecv[0].decode(&results));
  if (irrecv[0].decode(&results))
  {
    Serial.println(results.value, HEX);
    irrecv[0].resume();
  }
  delay(100);
}

Before anyone points it out I know that the array only has one element. The program works as expected but if I add a second pin number to the object creation like this

IRrecv irrecv[] = {12, 11};

then
irrecv[0].decode(&results)never returns true

Has anyone got any ideas how to get this working or can spot anything obvious wrong when the array has 2 or more elements in it ?

2

Have you tried to enable debug mode for the library? Have you tried to explicitly declare an array size (IRrecv irrecv[2] = {12, 11};)?

3

You can't use the IRremote library for more than one instance. I quickly checked the library implementation and it seems they are using an interrupt to receive the raw data. However, the interrupt routine samples the pin contained in the global irparams struct:

// Allow all parts of the code access to the ISR data
// NB. The data can be changed by the ISR at any time, even mid-function
// Therefore we declare it as "volatile" to stop the compiler/CPU caching it
EXTERN  volatile irparams_t  irparams;

Therefore, when you create your second instance of IRrecv, the pin in irparams will be set to 11. Every instance of IRrecv will now try to receive data from that pin.

IRrecv::IRrecv (int recvpin)
{
	irparams.recvpin = recvpin;
	irparams.blinkflag = 0;
}
4

You can't use the IRremote library for more than one instance.

Oh dear. So that is my idea of using an array of objects scuppered

5

UKHeliBob:
Oh dear. So that is my idea of using an array of objects scuppered

Yes. You could, of course, change the IRremote library implementation to support multiple instances. I'm not particular happy about this approach from the IRremote library developers. If you can only use one instance, it should be impossible to create more than one (e.g. implement it as a singleton).

6

You could, of course, change the IRremote library implementation to support multiple instances.

That had occurred to me, but I am unlikely to take the idea forward unless I suddenly get interested

7

Is there anything stopping all receivers connected to the same pin? I seem to remember that technique was used somewhere to connect receivers for different IR frequencies.

Another technique that I have used is to only power the receiver when you want it to receive an IR signal by connecting the receiver voltage pin to one of the MCU output pins. Set the pin HIGH when the receiver should work. In my application the current was well within the MCU pin limits, but an interposed transistor would solve that issue if it arises. This may not work, of course, if you need to be receiving all the time.

8

Thanks for the suggestions