These two paragraphs seem to contradict > 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. > 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) At 20MHz, the instruction time is 200ns. A 550kHz signal will be 909ns high / 909ns low. The simplest test lo btfsc carrier ;600ns if false, 800ns if true goto lo hi btfss carrier ;600ns if false, 800ns if true goto hi would leave no time to do anything else, and there's no test for the end of the carrier as you move into the "space" I think this would be a situation, certainly for 550kHz systems, where you should consider IR receiving hardware to extract the data. However, data in a 40kHz carrier IS extractable by a PIC but inexpensive hardware is available to do the donkey work I don't know how many carrier frequncies are in use but it is possible you could have a narrow-band receiver for each range. The 40kHz will probably work a few kHz either side and ditto for the 550kHz ones. Connect each receiver output to a PIC pin and look for decoded data. No carrier counting necessary, that was taken care of in the receiver, and the data itself could be done under interrupt with one of the timers or capture functions And there is always the problem of noise (ie ambient light). Even dedicated IR receivers struggle sometimes, but it's advisable to use them. And a consequence of this is that you also get the data extracted. Nice and clean ================================================ > 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? Wouldn't count on it being that simple. I've got RC-5 remotes that use 13.5 bits in an 18-bit time frame + sub-system commands. And others with 1000kHz, 455kHz or 200kHz timing bases. Manufacturers aren't concerned with their remotes operating someone else's gear and there is nothing at all to stop them picking any frequency they want. And they do Look here to get an idea of just how many remote control systems there are. Be afraid. Be very afraid http://www.remotecentral.com/ I think I understand what you're trying to do, but it sounds mighty ambitious for one lonely PIC. Rather than try to analyse the IR in real time, stick it into external RAM and then work on it at leisure. Simply use the PIC to address the RAM and apply /WE pulses. Taking the 18-bit stream as an example 1 bit time is 1.778ms > 18 bits is 32ms At even a generous 10 samples/ms that's only 320 bytes of RAM, so a little 6116 (2k x 8) would suffice -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu