IR Encoder/decoder are there any limitations or rules?

[rohit_sane]

Hello!
I am trying to build a small IR remote control module. It has 8 keys, attached to port b of PIC16F886. Same controller used to receiver IR data and display it into binary for bcd to 7seg display.
I have written whole code for PIC in CCS C. Code simulates perfect in MPLAB. I have a few questions.
1) I read on some website that I should not send continuous pulse train of 38k for more than 70 cycles. and I must pause for at least 14 cycles and then send the train again. Is it correct? I am using 555 astable for 38k generation(with diode to r2 so 50% duty cycle approx) and my mcu operated reset input to enable and disable 555.

2) Is there any limit on the minimum width of high and low of modulating signal(reset input operated by mcu which will define my envelope.)? Right now I am using 500us for each bit. My format is :
High * 1000us
Low * 500us
High * 500us
3-bits each of * 500us.
and then if button is still pressed, steady wave of 500us low and 500 us high until button is released.

Is this ok or what changes do I need to make to make it work?
3) I am not using any existing format or any encoder decoder ICs so I have a liberty to choose my own format so that’s what I did.
I could not get output directly from my ir detector and I am using the one locally available so neither me nor the guy who sold it knows anything about its model number. Therefore I am using LM358 as comparator to get clean digital output to be fed to my mcu. It seems to be working but I still could not get my mcu to decode it. Is LM358 capable of handling frequency of my envelope or is there any other problem? What I mean is can it switch at these speeds from high to low and vice versa?
Please help I need to finish this as quickly as possible. All the tools I have are components, programmer, breadboard and multimeter. And after I make it work and attaching this to my pc through usb so I also need to sleep with that literature later. Thanks in advance.

 

[FvM]

Why don't you refer to known working IR remote control protocols like RC5? Why not generating the 38k in software respectively by a PWM output?

You definitely don't need analog components besides IR-diode, current limiting resistor and IR receiver.

 

[Darkcobra]

1) Op-amps typically shouldn't be used as comparators. They seek to adjust their output in a way that makes the voltage on both inputs equal. In comparator use, this can never happen, since there's no feedback from the output to the input. But they try regardless, in the process "saturating" their internal circuits (progressively attempting harder and harder to output a voltage far beyond their supply rails); a condition which takes them a relatively long time to recover from when the input changes.

2) A comparator should not be needed anyway, all IR receiver modules I've seen have digital outputs.

3) There is not a single frequency standard for IR. Your unknown receiver may be tuned for 38Khz, or 36, or 40, etc. If you haven't already done so, attach a LED to the output of the receiver and verify that it's receiving something.

4) Do not expect the receiver's output timings to exactly match the input. There can be significant deviations, especially with the first high bit; usually a disposable header containing no actual info is used to get past this. If you can output the levels/timings of the received signals over the MCU's serial port to a PC or such for manual examination, it will be invaluable to you.

Regarding timing limitations, it's worth it to understand why these exist when creating a protocol from scratch.

An IR receiver continuously receives some amount of noise. To avoid constantly outputting this noise on its output pin in the absence of a real signal, it has an internal gain control. This gain is adjusted, based on a time average of the recently received signal, to tend towards outputting nothing. So if you output high too long the gain goes down, your signal is considered noise, and is lost.

Excessively short transitions are also considered noise, and filtered out.

In addition, the best signals are those with an nearly equal amount of on and off time over a short time average - regardless of what ones and zeros it represents - which keeps the gain neatly adjusted to what it should be to properly receive. Here's an example that would achieve this:

"One":
High 250uS
Low 250uS
High 250uS
Low 250uS

"Zero":
High 500uS
Low 500uS

An examination of some existing IR protocol standards can provide further examples and inspiration. I did create my own protocol many years ago, and learned much of this the hard way through experience.