Multiple IR reciver problems

Okay, what I am trying to do: Recreate (sort of) Pololu's IR beacon (receiver part anyway)

I will be using 4 38kHz IR receivers and using the IR-remote library for multiple receivers.
I want to build a standalone board using an Atmega328p (I have a few laying around) or Attiny4313 (if possible, 328 seems like overkill.

So the principle is I have a beacon that I built using an ATtiny85 and 4 IR leds.

here is the code:

void setup()
{
  PORTB = 0;
  DDRB =  0b00000010;		// set PB1 (= OCR1A) to be an output
}

// Set the frequency that we will get on pin OCR1A but don't turn it on
void setFrequency(uint16_t freq)
{
  uint32_t requiredDivisor = (F_CPU / 2) / (uint32_t)freq;

  uint16_t prescalerVal = 1;
  uint8_t prescalerBits = 1;
  while ((requiredDivisor + prescalerVal / 2) / prescalerVal > 256)
  {
    ++prescalerBits;
    prescalerVal <<= 1;
  }

  uint8_t top = ((requiredDivisor + (prescalerVal / 2)) / prescalerVal) - 1;
  TCCR1 = (1 << CTC1) | prescalerBits;
  GTCCR = 0;
  OCR1C = top;
}

// Turn the frequency on
void on()
{
  TCNT1 = 0;
  TCCR1 |= (1 << COM1A0);
}

// Turn the frequency off and turn off the IR LED.
// We let the counter continue running, we just turn off the OCR1A pin.
void off()
{
  TCCR1 &= ~(1 << COM1A0);
}

void loop() {
  setFrequency(38000);
  for (int i = 0; i < 4; i++) {
    on();
    delay(1);
    off();
    delay(1);
  }
  delay(250);
}

Which outputs dbc8cb72. Great, I have my RX sketch receiving these values and comparing to make sure it is in fact the signal from the beacon, and not stray signals. The PROBLEM is that even with one receiver connected, it sometimes registers the value as coming from the second receiver, even though nothing is connected to that pin.

Should output a picture of an up arrow on the Nokia 5110 if detected from the first IR_recv and arrow down if from IR_recv2.
The final product will have four sensors, but for ease of testing, I am going for two at the moment.

Here is the code:

// LCD5110_Bitmap
// Copyright (C)2015 Rinky-Dink Electronics, Henning Karlsen. All right reserved
// web: http://www.RinkyDinkElectronics.com/
//
// This program requires a Nokia 5110 LCD module.
//
// It is assumed that the LCD module is connected to
// the following pins using a levelshifter to get the
// correct voltage to the module.
//      SCK  - Pin 8
//      MOSI - Pin 9
//      DC   - Pin 10
//      RST  - Pin 11
//      CS   - Pin 12
//
#include <LCD5110_Basic.h>

#include <IRremote.h>

int RECV_PIN = 2;
int RECV_PIN2 = 4;

IRrecv irrecv(RECV_PIN);
IRrecv irrecv2(RECV_PIN2);

decode_results results;
decode_results results2;

LCD5110 myGLCD(8, 9, 10, 11, 12);


String resultsStr;
String resultsStr2;

extern uint8_t SmallFont[];
extern uint8_t arrow_right[]; //arrow_right.c 
extern uint8_t arrow_up[];    //arrow_up.c
extern uint8_t arrow_left[];  //arrow_left.c 
extern uint8_t arrow_down[];  //arrow_down.c

void setup()
{
  irrecv.enableIRIn();
  irrecv2.enableIRIn();
  myGLCD.InitLCD();
}


void displayIR(decode_results *results) {
  myGLCD.clrScr();
  resultsStr = String(results->value, HEX);
  myGLCD.setFont(SmallFont);
  myGLCD.print(resultsStr, 0 , 0);

  delay(500);

  return;
}

void displayIR2(decode_results *results2) {
  myGLCD.clrScr();
  resultsStr2 = String(results2->value, HEX);
  myGLCD.setFont(SmallFont);
  myGLCD.print(resultsStr2, 0 , 8);

  delay(500);

  return;
}


void loop()
{
  decode_results  results;
  decode_results results2;
  if (irrecv.decode(&results)) {  // Grab an IR code
    displayIR(&results);

    if (resultsStr == "dbc8cb72") {
      myGLCD.clrScr();
      myGLCD.drawBitmap(0, 0, arrow_up , 84, 48);
      delay(100);
    }
    else {
      myGLCD.clrScr();
      myGLCD.print("NOPE", CENTER, 0);
    }
    irrecv.resume();
  }

  if (irrecv2.decode(&results2)) {  // Grab an IR code
    displayIR2(&results2);
    
    if (resultsStr2 == "dbc8cb72") {
      myGLCD.clrScr();
      myGLCD.drawBitmap(0, 0, arrow_down , 84, 48);
      delay(100);
    }
    else {
      myGLCD.clrScr();
      myGLCD.print("NOPE", CENTER, 0);
    }
    irrecv2.resume();
  }
  /*  myGLCD.clrScr();
      myGLCD.drawBitmap(0,0, arrow_right, 84, 48);
      delay(1000);
      myGLCD.clrScr();
      myGLCD.drawBitmap(0,0, arrow_left, 84, 48);
      delay(1000);*/
}

The short video below shows the one connected sensor triggering both up and down readings

Test Video

I couldn't figure out how to embed the video, everything I tried only displayed the text link. Sorry for the extra click and the Giant Post. I know you all are busy people just like me. Thanks in advance.

I would have copied your code into my IDE or Arduino simulator for testing, but I can't:-
"Copyright (C)2015 Rinky-Dink Electronics, Henning Karlsen. All right reserved"

We're an open-source community.

The IR library relies on timer interrupts to deal with incoming IR data. The 328 does not have 4 timers that you can dedicate to reading IR data.

Thanks for the replies. As for the copyright, this comes linked straight from the site of the library:
Creative Commons Summary - So it's my understanding that as long as the credit is given, I am free (as are you) to remix, or distribute the library.

The library I am using for the IR remote is a fork of the main library that is supposed to allow multiple receivers. It would seem the link to that tree of the IRRemote github is now 404'd. So I guess I will have to find another way. .

kdub:
Thanks for the replies. As for the copyright, this comes linked straight from the site of the library:
Creative Commons Summary - So it's my understanding that as long as the credit is given, I am free (as are you) to remix, or distribute the library.

The library I am using for the IR remote is a fork of the main library that is supposed to allow multiple receivers. It would seem the link to that tree of the IRRemote github is now 404'd. So I guess I will have to find another way. .

Oh right, I thought that was your code and your copyright notice.

I'm doing a similar thing at the moment, (IR homing), but only use 1 channel for my system.
I approached mine differently, to keep processing at the receiver end to a minimum, (it's busy enough already).
I have an ATtiny85 sending 38kHz modulated at 1kHz, then a 38kHz demodulating IR receiver and LM567 tone decoder tuned for 1kHz at the receiving end. (The IR receiver has a cover in front of it, with a pinhole in the centre, to make it more directional.) The receiver is will be mounted on my ultrasonic ranging 'head' servo, which swings back and forth.
The receiving ATMega328P detects the LM567 output using a pin-change interrupt. A bit crude, (not as elegant as sending coded IR), but it works well enough for my purpose, has minimal overhead and doesn't use any timers. I've run out of those.

That sounds perfect for my needs. I don't need the ability to send specific protocol codes, as I only plan on having one beacon. Although I am thinking about just scrapping this whole idea and using a Pixy CMUCam to track such things. I've wanted one since it was the CMU Cam1.

But anyway I'm not at all familiar with direct port manipulation, the code for my TX came from a forum post about using the Attiny to output 38kHz IR. Am I close in thinking that I would need to remove the for loop that sets the TX to 4 bursts of on() and off(), and replace it with a loop that performs the on() and off() at 1kHz?

If you only wanted a constant 1kHz, you could do this:-

void loop()
{
    setFrequency(38000);
    on();
    delayMicroseconds(500);
    off();
    delayMicroseconds(500);
}

You could probably move 'setFrequency()' up into 'setup()', too, for more accurate timing.

I didn't use a timer for generating 38kHz and simply 'bit-banged' mine, fine-tuned with a series of 'nop' until the 'scope showed exactly 38kHz.
Using a timer is more elegant, but since my ATtiny85 does nothing else, I didn't bother with the extra messing around setting up a timer.
The IR receiver demodulates the 38kHz, then the LM567 decodes/demodulates the 1kHz and it's output goes low when a 1kHz signal is received.

With multiple channels, though, cross-talk would be a problem, so I wouldn't recommend it for your system. Already, don't you need to synchronise your transmitters so they're not sending at the same time?
Edit: Sorry, I just re-read what you're doing. :- 1 TX, 4 RX.

Delta_G:
You can have copyrights and still be open source. The point is that you are licensing it under an open source license. You still own the copyright and you still get to set the terms of the license or decide what type of open source licensing you will use.

I wasn't aware of that. I thought that the "All Rights Reserved" meant that copying wasn't allowed at all.
(As you can tell, I know absolutely nothing about copyright law. :slight_smile: )

Thanks I will definitely order some 567's to start playing around with, as I also like the idea of putting the IR module on the sensor turret to determine where it was triggered.

I also didnt know anything about copyright law. It was more of an accident, I simply used the Nokia display for debugging output in order to test two things at one time.

I think the tone decoder option will be pretty easy to setup for 4 receivers, since I don't have to worry about timers on the Atmega to do so. But I still wanted to get this library working, I've read several posts about people getting 3-4 sensors to work, and I don't have a problem dedicating a 328p to it, maybe V2 will consolidate some, but my little robot I'm building is just to play with all my toys haha. I need an excuse to get some positive developer and sensitized boards and making some two sided PCBs.

All in all I probably should have just gotten the Beacon Pair from Pololu but this is infinitely more fun.

Edit: Steve, do you happen to have a schematic for your setup?

It's all very much a work in progress, so the only schematic I've bothered to draw is for the LM567.
The rest is straightforward. IR LED on ATtiny85, LM567 output to digital pin on UNO. (When I finish fine-tuning everything.)

At this stage, I'm waiting on some higher power IR LEDs for the transmitter, and meantime have only tested with the ATtiny85 on one breadboard, and the PIC12043 and LM567 on another breadboard driving a LED for testing, not yet connected to the UNO.
My present IR LEDs are a bit weak. I'm not sure of their max current rating and I was getting a pretty short range, so I have more coming, that can handle 100mA continuous, 1A peak. My 38kHz carrier is set at a 27% duty-cycle, so that I can drive the new LEDs at a good current level.

Here's the important bit, the LM567 circuit:-

I'm using an obsolete PIC12043 IR receiver, but any other 38kHz receiver should also work fine.

I used separate NPN transistors for driving my 4 IR leds and I get a good 15 feet or so using the driving circuit from a high power TV-B-Gone. It uses one PNP to drive the 4 NPN's to the 4 leds. I think I have the schematic somehwere.

As soon as I can order a tone decoder or pull one from my graveyard of pcbs, I will mock up a test circuit to play with, thanks!

I find using the standard TSOP-looking sensor it is hard to fashion a light-tight cover. I had decent luck using black posterboard. If I can find a place to put my Prusa I3 (apparently the kitchen table is not acceptable anymore, :D) I am going to try to print a little shroud

kdub:
I used separate NPN transistors for driving my 4 IR leds and I get a good 15 feet or so using the driving circuit from a high power TV-B-Gone. It uses one PNP to drive the 4 NPN's to the 4 leds. I think I have the schematic somehwere.

As soon as I can order a tone decoder or pull one from my graveyard of pcbs, I will mock up a test circuit to play with, thanks!

I find using the standard TSOP-looking sensor it is hard to fashion a light-tight cover. I had decent luck using black posterboard. If I can find a place to put my Prusa I3 (apparently the kitchen table is not acceptable anymore, :D) I am going to try to print a little shroud

I'm using a single IR LED, driven by a 2SK2231 MOSFET. Plenty of drive power, but since I wasn't sure of the IR LED rating, I was only driving it at about 45mA.

I have no trouble getting a 20 foot IR beacon range, but want more. I'm trying for 10 metres plus. (30 feet.)
That should be easy with the 27% duty cycle and a high-power IR LED.
I've just put that part of the project aside for now, and am working on a better algorithm for the US ranging calculations.
The 'head' swings side-to-side as I mentioned, stopping in 5 positions for a few mS to ping, then the robot decides which way to turn. Currently, I have it turn 90 degrees, in the direction with the longest clear path, but I'm changing it so it only turns as far as it needs to.
I'll continue with the homing as soon as those new IR LEDs arrive. The IR 'beacon' only needs to get it close to the charger ramp, then an IR obstacle-avoidance system kicks in, working with the US ranging, to guide it into place.
All good fun. :slight_smile:

That's pretty much the same workflow I'm going for. But the more I think about it, the hard data from the sensors is great, but I think the CMUCam could pretty much take care of all my requirements, as well as provide a base for human interaction. My girlfriend joked that she wanted a robot to tell her to do "her chores" so as a proof of concept that's what I'm working on. A little easier than "conquer the world" so we'll start there.

kdub:
That's pretty much the same workflow I'm going for. But the more I think about it, the hard data from the sensors is great, but I think the CMUCam could pretty much take care of all my requirements, as well as provide a base for human interaction. My girlfriend joked that she wanted a robot to tell her to do "her chores" so as a proof of concept that's what I'm working on. A little easier than "conquer the world" so we'll start there.

Nothing so fancy as a CMUCAM on mine. Just a cheap, basic robot car, mainly as a learning exercise before I try a more advanced robot.
And, in 'manual' IR-remote controlled mode, it's purpose is to chase my little dog around. :smiley: