IR receiver ignoring IR pulse

Hi, I'm using a TSOP48 IR receiver (TSOP48 datasheet). I've setup a PIC and IR emitter to output 10 cycles with a 50% duty cycle at 38KHz then pause for 40 cycles (as per the datasheet). I've measured the frequency at the PIC's output pin and it's fairly stable at 38.06KHz during the 10 cycles. The emitter and receiver are about 2.5 meters apart.

The receiver receives the signal perfectly and I can even angle the emitter slightly to the side and it still receives without any issues.

Now the weird part. When I put my hand between the emitter and receiver, the signal stops being received. If I move my hand away *slowly* then the signal is never received again. After cutting the beam off and moving my hand away at medium or fast speeds, the signal will be received again. I'm using this as a realtime beam break sensor so this could prove quite problematic if the beam appears to remain broken.

I suspect the problem relates to the auto gain and filtering circuitry in the receiver. If I leave a 200 cycle pause between each burst then it always works fine but this significantly reduces my sample rate.

Things I've already tried:-
Using 1 emitter
Using 2 emitters
Over powering the emitter(s)
Changing the carrier frequency duty cycle to various values between about 10 and 90%
Changing the cycles per burst. 3-4 seems to be the lowest value that will work at all but nothing up to about 30 makes any difference
Pointing a TV remote at it. It can see the remote fine but continues to ignore my emitter as if it were background noise. I can't reproduce the problem with the TV remote since it has pauses much longer than 200 cycles.

from the data sheet

Suitable Data Format
• Burst length should be 10 cycles/burst or longer.
• After each burst which is between 10 cycles and 70
cycles a gap time of at least 14 cycles is necessary

• For each burst which is longer than 1.8 ms a corresponding
gap time is necessary at some time in the
data stream. This gap time should be at least 4 times
longer than the burst.
• Up to 800 short bursts per second can be received
continuously.

their optic test indicates a stream of 60uS on 600uS off pulses try that

I'm currently reading 759 short bursts per second.

Do you mean 60uS burst length (about 3 cycles at 26.32uS each) and a 600uS gap?

I've found the optical test signal in the datasheet (600uS on, 600uS off). I've tried outputting that signal and it works for about a second then stops. This is without me putting my hand between. If I do block the beam and unblock it then it works for another second and stops again.

I was just looking at their optical test signal for the 60/600 ratio but it does contradict the suitable signal requirement of 10 cycles or longer burst. but looking further it seems after a "disturbance" a 1.8ms gap is required , if a beam gap of that length is unacceptable then maybe the device is unsuitable as a beam break detector

Quote:

---

When a disturbance signal is applied to the TSOP48..
it can still receive the data signal. However the sensitivity
is reduced to that level that no unexpected
pulses will occur.
Some examples for such disturbance signals which
are suppressed by the TSOP48.. are:
• Continuous signal at 38 kHz or at any other frequency

---

what happens if you send a cycle of say 100 10cycle bursts then a pause for 400uS then repeat

With 10 cycles per burst I set the gap to 1.8ms but I still get the problem. I also tried a 2.63ms gap and it didn't happen as easily but it still happens. I could deal with a gap of 1.8ms but it seems I need a gap of about 5ms or more before it's reliable enough.

I tested with bursts of 100 and 1,000 cycles with a pause of 400uS. This worked for a second then stopped on it's own as with the 600/600 test.

Not sure if this helps but I've been watching the receiver on my scope and I've noticed that if I cover the emitter slowly then the received pulses get progressively shorter in the split second before it loses the signal completely.

I guess it doesn't want to be a beam break detector it wants to talk to remote controllers