Rick wrote:
>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.

Do you *really* need to cover *all* of the possible remotes out there?
Some remotes even swap some of the bits every second time you push the
button! Pioneer does this on some CD players IIRC. Any only on some buttons!

>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:

The vast majority of systems use 38/40 KHz.

>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.

Matching codes from vastly different protocols will be difficult.

>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).

Just use 2 demodulators, one for 40KHz & one for 550KHz.
You shouldn't need to sample the IR carrier - just the de-modulated data.

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

Not if you want to sample the IR carrier.

>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.

Why do you need to know the carrier frequency? For re-transmission?
If you OR the outputs from the two de-modulators, you will catch either.

>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.

If you limit it to a smaller range you can store the on/off bits packed
into bytes.
A header byte could indicate what timing/protocol the compressed data is for.

>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!

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