Can't understand how this can not work.

[Pommie]

I have an Arduino Nano that is pulsing an IR LED at 38kHz in hardware and a TSOP4136 IR receiver. To stop the AGC from stopping the signal I am sending 20mS bursts followed by 20mS gaps. If I look at the signal on the LED I see 20mS bursts of 38kHz. If I look at the output of the TSOP I see 20mS square waves. If I vary the on/off times I see this reflected on the scope. The IR LED and TSOP are on a breadboard facing each other and appear to be working exactly as expected. However, if I put a barrier between them the (TSOP) signal persists. If I turn of the LED in software the signal disappears, if I disconnect the ground from the LED the signal disappears. It's as though powering the LED causes the TSOP signal - not the IR light.

This is the code I'm using,

#include <mwI2C.h>

#define IR 11
#define sense 2

uint32_t tickLED;
uint8_t onOff;
LCD lcd;

void setup(){
  Serial.begin(115200);
  Serial.println("\n\nHello");
  lcd.init(0x3f,20,4);
  pinMode (IR, OUTPUT);
  pinMode (sense, INPUT_PULLUP);
  // set up Timer 2
  TCCR2A = _BV (COM2A0) | _BV(WGM21);  // CTC, toggle OC2A on Compare Match
  TCCR2B = _BV (CS20);   // No prescaler
  OCR2A =  207;          // compare A register value (210 * clock speed)
                        //  = 13.125 nS , so frequency is 1 / (2 * 13.125) = 38095
                        //adjusted using scope to give 38kHz
}

void loop(){
  if(millis()-tickLED>20){
    tickLED=millis();
    if(onOff++&1){              //alternate
      pinMode(IR,OUTPUT);       //turn on 38kHz
      delayMicroseconds(500);
      if(digitalRead(sense)){
        lcd.setCursor(0,1);
        lcd.print("Sense = 1");
      }else{
        lcd.setCursor(0,1);
        lcd.print("Sense = 0");
      }
    }else{
      pinMode(IR,INPUT);       //turn off 38kHz
      //tickLED-=10;              //will change the on/off time ratio
    }
  }
}

The LCD I'm using uses an I²C backpack of my own design so just ignore that bit.
The LCD displays "Sense = 0" but if I remove the delayMicroseconds(500) it reads "Sense = 1" which also suggests the IR is being seen.

OK, while writing this I just stuck a 1/4" sticky note pad in the beam and noticed that for a very short time it register a high. This is the opposite of what I was expecting,
I was expecting that if I used a continuous 38kHz signal then it would initially go low but then return high when the AGC kicked in.
The 20mS doesn't seem to be too long as changing to 2mS gives the same result.

Can anyone explain this behaviour?

Thanks

Mike.

 

[Nigel Goodwin]

It sounds like the TSOP is simply receiving the IR signal even when you try and block it - the gain and sensitivity of a TSOP is huge, and the IR will pass through quite a lot of different materials, and will bounce round the room and thus get around the barrier if you're not careful.

If you've got a piece of black plastic plumbing pipe (15mm or so) try sliding it over the TSOP - or a piece of black heatshrink (although I've never tried heatshrink).

If you check my old site:



Notice the aluminium backed cardboard over the TSOP, as I was struggling finding something suitable to block the direct IR from the LED's, and also that I used 1K resistors so the IR output was weak.

 

[gophert]

Most plastics transmit IR. With significant power input, even mineral-filled or glass filled opaque plastics can conduct enough IR to trigger a high-gain IR sensor. Use a metal foil to make sure. Also, the back side (bottom) of bullet-shaped indicator LED shaped IR emitters emit a lot of light. Cover that as well. Heat shrink with lots of carbon-black blocks pretty well. Red heat shrink, not always.

Your hand is not a good blocker of all near IR frequencies. For a visual example, try putting your thumb over a high brightness RED LED.

On the other hand, if your IR emitter is drawing a lot of current and your circuit is not powered by a beefy power supply and high-value capacitors across the power rails your IR sensors can be tricked into thinking they are sensing an input and give a false output.

Also, CFL lamps can interfere and cause false triggers - make sure you have a newer version TSOP with internal circuitry to reduce it.

 

[JimB]

Your hand is not a good blocker of all near IR frequencies. For a visual example, try putting your thumb over a high brightness RED LED.

That is how a Pulse Oxymeter works using the differential absorption of two different wavelength red lights.
(A device for measuring oxygen concentration in blood).

JimB

 

[gophert]

That is how a Pulse Oxymeter works using the differential absorption of two different wavelength red lights.
(A device for measuring oxygen concentration in blood).

JimB

Yea, Usually a red and a near IR or two IR frequencies.

 

[granddad]

What about the ambient light levels.

 

[Nigel Goodwin]

What about the ambient light levels.

Not a problem, a TSOP has an IR filter body, and requires a carrier frequency to detect (about 38KHz usually) - it's a VERY well designed and mature component, and completely revolutionised remote control systems for domestic electronics.

 

[gophert]

I still like the "clicker" or, as Zenith called it, the "Space Command" remote control. Never need to replace batteries. It was literally a clicker (and a set of ultrasonic tuning forks).

 

[Nigel Goodwin]

I still like the "clicker" or, as Zenith called it, the "Space Command" remote control. Never need to replace batteries. It was literally a clicker (and a set of ultrasonic tuning forks).

Ultrasonic remotes were never very good

And the mechanical one was even worse.

I did have one of the first Teletext TV's ever made, a Bush model using a TIFAX module - and that had one of the first 'huge number of buttons' style remotes, and at that time was still ultrasonic. I don't recall ever seeing another full function ultrasonic remote?, they all seemed to be slightly later after IR took over.

I've always though it's not coincidence that IR remotes use similar modulation frequencies to the older ultrasonic remotes, presumably just a matter of using the same chips

 

[Dr_Doggy]

when i tried to pulse a led direct i found the wave was not stable at the pic output on a scope and resorted to a flasher circuit to do the 40k stuff and let the pic do the easier pulses

 

[Nigel Goodwin]

when i tried to pulse a led direct i found the wave was not stable at the pic output on a scope and resorted to a flasher circuit to do the 40k stuff and let the pic do the easier pulses

What language were you trying to use? - in assembler it's absolutely trivial - check my PIC tutorials for an example of Sony SIRC. But the transmitter side is easily alterable to any IR remote signal, and I've used for many different types of IR remote.

Assembler gives you perfect accuracy to within the resolution of the clock, so 1uS in the case of a 4MHz PIC - as in the tutorial.

 

[Pommie]

I'm generating the signal in hardware using timer2 and turning it on and off by setting the pin to output or input. On the scope i see all the signals correctly even when my hand is between the transmitter and receiver. Not had time to work on this more but I suspect they're too close together and a bit of distance plus guiding will fix the problem.

Mike.

 

[Dr_Doggy]

just mplab, i forget if it was on hdw timer or not,