To all, I appreciate your responses. Let me try to clarify a few things.
Many people have explained how typical remotes (Sony et al) work. That I
understand already, although the extra explanations have helped clear up
some questions.

As one person mentioned, I don't have any particular remote in mind. I want
my device to be able to learn the code of whatever remote someone chooses,
and then to respond to that code.

What I'm looking for really is an algorithm to encode a (carrier) pulse
train and a suitable representation of that train. The representation needs
to allow quick searches of a table of such representations. It also has to
allow for calculation errors.

Ideally, it will support any carrier frequency, be it 40kHz or (as someone
mentioned for B&O) 550kHz. There are two problems:

One is learning a code, which is relatively easy because the user puts the
device into a "learn" mode. In this mode, the process can devote all of its
resources to sampling the IR port, and it can receive the repeated signal as
many times as necessary. In this mode, a representation of that code is
built and stored, associated with whatever function was selected by the user
(BTW, I've got the user interaction all sorted out).

The other problem, possibly more difficult, is matching a received code. The
PIC will only get it once, and might also be probing button input pins and
waiting for serial data. Assuming the algorithm can pick up on an arbitrary
carrier in time to make a representation (in the same manner as during the
learning phase) with just one transmission of the IR code, the
representation has to be one that can be accurately looked up in a table of
reps.

Note that in my application the PIC doesn't have to respond to an IR code if
it's actually responding to a button press or serial data; each of these
things can be processed separately, on a first-come, first-served basis. The
PIC just needs to be "listening" all at once to IR, buttons and serial. As
soon as any one of these shows activity, the others can be ignored until the
activity is dealt with.

Now, in general, it seems like I'll have to sample the IR port at double the
highest carrier frequency of interest (which appears to be 550 kHz). I'm
guessing I'll have to count some minimum number of carrier cycles to
determine the actual carrier frequency, and at the same time start keeping
track of how long the IR is modulating (and how long it's not).

How does this sound (can it be done on a 20 MHz PIC?):

Upon the first noticed IR transition, start two counters (A & B). One
counter will be used to determine the carrier frequency, the other to
determine the length of the mark or space. Count out some number of carrier
transitions (3? 5? 15?), calculate the carrier frequency, and store it in a
byte.

When the carrier stops, mark the time and store the length of the mark or
space in another byte. Continue in this fashion, until there is a
sufficiently long space (indicating the end of the transmission), or until
some limit of mark/space lengths has been reached (say 16).

The problem is, 16 mark/space pairs makes for 8 bits in all of the encoding
schemes I've seen. But it's the only way I can think of to decode an IR
transmission without actually knowing how a 0 or 1 is encoded. Is it
possible to figure it out from context?

I need 13 codes. 13 codes * 17 bytes/code = 221 bytes. I need 1 byte for
other data storage, that leaves precious few bytes in Data EE prom for
increasing the code length.

Anyway, I don't think that scheme will work exactly, but it's what I've come
up with so far. If anyone has any ideas, I'd love to hear them!

Kent Johansen:

You sent me a zip file of things for the HP48, including a program to learn
IR codes. Unfortunately, there was no source code, and your ISP considers my
mailserver to be blacklisted, so I can't send you email (they suggested I
contact abuse@infomine.com, but that email bounced, too). My mailserver is
"mail.earthlink.net", nothing much I can do about that.

Anyway, do you have the source code for the learn program?

TIA,

--
Rick
rmann@latencyzero.com.sansspam

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu