Interesting thought (counting bursts within a time period). I was looking more into this, and realized that I also need to select the specific wavelength of the IR emitter, to match the receiver (eg: 850-950nm). This leads me to believe that commercial electronics use the same wavelength, so that universal remotes can be used. Do you (or anyone else here), know which wavelength that is? Reason is that if I have a choice, I'd like to select a different wavelength. Cheers, -Neil. Adam Field wrote: > > IR signals are usually a modulated over a 35KHz-40KHz carrier that's > manchester encoded. You could probably get away with sending a plain > old square wave out over the IR carrier. Hook the IR decoder up to > your TIMERx in external clock mode. If you have so many pulses within > a, say, 1 second time frame you know the button is being held down. No > decoding overhead but you'd probably want to make use of an interrupt. > Stray noise is unlikely to trigger this. But any remote will be liable > to trigger it. > > If you do decide to decode an IR protocol, using an internal clock > source is fine. The clock drift won't matter because you have to > account for all sorts of drift anyways to get a reliable decoder. The > distance from transmitter, the battery level in the transmitter, > temperature or possibly a reflected signal all change the timing. The > protocols I've used (Philips RC5 and Sony) send start bits which you > must time fairly accurately to work out the rest of the signal. I've > seen significant drift between even subsequent button presses. > > On Fri, Oct 10, 2008 at 12:18 PM, PicDude wrote: >> >> Hi all, >> >> I'm adding an IR receiver to PIC project (16F883) using an basic IR >> transmitter (that I will also build), and wondering if I need to use some >> type of protocol/encoding for this. Hoping someone here has experience >> with >> this. >> >> Essentially, I just need the application to recognize 1 signal (from a >> remote IR transmitter that will have 1 button), and the PIC should >> recognize >> a button that is held down continuously. This is done with a simple >> tact-switch to the input of the PIC currently, which pulls the input to >> ground, (and uses the internal pullup). >> >> There is a lot going on inside the PIC already, so not using a >> protocol/encoding would be nice, and any of the regular/commercial IR >> protocols may be very tricky to implement. But stray IR noise (from >> sunlight) may be a problem. The PIC app uses the internal oscillator at >> 8Mhz, so any IR protocol will have to allow for a bit of sloppy timing. >> I >> would think some type of simple duty-cycle protocol (as in a duty-cycle >> of >> x% is considered a valid signal) will allow for the variation/tolerance >> of >> the PIC's oscillator frequency, but will it help? Still be a problem? >> Or >> do I really need to use some type of patterned bit-stream? >> >> Cheers, >> -Neil. >> >> >> -- >> View this message in context: >> http://www.nabble.com/-PIC--Sloppy-IR-protocol--tp19921465p19921465.html >> Sent from the PIC - [PIC] mailing list archive at Nabble.com. >> >> -- >> http://www.piclist.com PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > > -- View this message in context: http://www.nabble.com/-PIC--Sloppy-IR-protocol--tp19921465p19949281.html Sent from the PIC - [PIC] mailing list archive at Nabble.com. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist