> I have done bits and pieces... I've used a Sharp module connected to
> a PIC 16C84.

Which Sharp module did you use and how did you connect it to the PIC ?
I've bought some samples of IS1U621, but havn't looked at them
yet.

Still, I feel that using receiver modules restricts your freedom
when it comes to decoding IR remotes. You will probably only get
signals modulated in the 36-42KHz range and miss those outside these
frequencies (that will cover most remotes, but still...). Also,
you might have problems with some of the very long
headers as well as headerless protocols, but that might depend on
the receiver. Given that you have enough RAM storage available,
an idea would be to sample the raw IR signal, and demodulate it
in software later. A sample rate of 100KHz would be enough for
most IR remotes, provided the processor can trigger on the start
of the IR sequence as it's being received. I assume sampling can be
performed with the remote to be sampled very close to the IR receiver
diode and with little other IR noise. That way it should be possible
to get good samples with a crude transistor amp and without a proper
filter.

On a PIC you will have to have a few K (2K) of external RAM to hold
the samples before analysis and a 1K or 2K EEPROM to hold the resulting
values for all the commands, but the program will be a tight fit on a
16C84. Whether analysis should only find the end of the IR command
sequence and remove the carrier and store the demodulated signal
or try to reduce it further is up to the programmer and the available
program/data space.

During playback one might let the PIC handle the modulation, since
you will at least be able to vary the modulation to a certain
degree (your accuracy will improve with CPU speed, but so your
current consumption will go up). This has been done and if the
receiver you transmit to is flexible enough, neither of you will miss
the 555.

I've never implemented raw IR capture on a PIC (and I don't intend to),
but I've done it on PCs and Amigas and it does work. PIC capture of
totally unknown remotes without IR receiver/demodulators can
probably be done, but I've never seen the need in my applications.

>    What the PIC does is to time
>    each mark/space and send a byte corresponding to the time period.
>    To keep the time period count down to 1 byte, I sacrifice accuracy
>    for higher counts e.g. 1-4 -> 1-4, (5,6)-(11,12) -> 5-8,
>    (12,13,14,15)-(24,25,26,27) -> 9-12 i.e. time periods 5 and 6 are
>    sent as 5, 7 and 8 are sent as 6, so on. Anybody have suggestions
>    for a better compression scheme? This was used just to get a rough
>    idea of the signal rather than to actually store and send
>    signals.

What unit are these values ? A good base value would be 25uS, since
that the modulation carrier speed. According to
http://falcon.arts.cornell.edu/~dnegro/IR/REMOTES/TABLE.HTML, the
longest signal from a Sony Remote is the 2.2mS header pulse, which
would correspond to 88 40KHz units. That should indicate that you may
send all values below 128 uncompressed and values between 128 and 200
divided by two, between 201 and 254 divided by 50 and 255 as any
longer period. According to the table, no remote will send
any signals (low or high) longer than (200 * 2 * 25)= 10000 uS,
so longer values are only of value to detect retransmission speed and
are (to my knowledge) not critical (a compression factor of 50 on
retransmission delay would pose no problem with any remotes I know
of).

Using this scheme, you will not loose any accuracy on the IR
signal (except for the actual modulation frequency which is lost in
the receiver), but loose some accuracy on the retransmission delays.

But, the IR remote overview table might be wrong and/or I might be wrong.


Regards,

Bob (tm)