Post by thread:[PIC]: What's the best way to decode IR?

Ok, since I can't seem to find anyone that's really done exactly what I want to do, I seem to be forging new ground. Unfortunately, I'm not that great at it, so I have a few questions. I plan on using one of the little IR modules to decode the actual IR signal and give me a ttl out. The question now is, what's the best way to deal with it? I'd like to stay away from just polling, because the PIC will be doing a bunch of other things, and I don't want to run the risk of missing IR pulses. I could use the external interrupt, so that every time there is a pulse I'd check a TMR. The problem I see there is that I have to set the interrupt to trigger on rising edge or falling edge, I can't do both. I don't want to mess with portB interrupt on change. I was thinking I could use the CCP module, but I don't really know how. I guess it would trigger when it receives a pulse from the IR module, then captures the value in the TMR. Then I could check the value of that against what my high and low timings should be, and go from there. Again I think I run into the rising/falling edge thing though. I'm really confused here. I'm sure that there is a solution somewhere, I just can't quite figure it out. If you have any ideas or suggestions, they will be appreciated! Thanks, Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

> If you have any ideas or suggestions, they will be appreciated! An IR data stream from a dedicated IR transmitter IC will have a pretty accurate data clock. You can use one of the timers to sample the data bits, same as you would with s/w RS232. This could be in the background, possibly all the time if you use it in conjunction with INTF to find the start of a block of data -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu

Josh Koffman wrote: >Ok, since I can't seem to find anyone that's really done exactly what I >want to do, I seem to be forging new ground. Unfortunately, I'm not that >great at it, so I have a few questions. I plan on using one of the >little IR modules to decode the actual IR signal and give me a ttl out. >The question now is, what's the best way to deal with it? I'd like to >stay away from just polling, because the PIC will be doing a bunch of >other things, and I don't want to run the risk of missing IR pulses. > missing IR pulses? Most modules produce TTL at about 1200 baud MAX! (think about how many macine cycles happen during 1 "pulse" at 1200 baud.) {Quote hidden}> I could use the external interrupt, so that every time there is a pulse >I'd check a TMR. The problem I see there is that I have to set the >interrupt to trigger on rising edge or falling edge, I can't do both. I >don't want to mess with portB interrupt on change. I was thinking I >could use the CCP module, but I don't really know how. I guess it would >trigger when it receives a pulse from the IR module, then captures the >value in the TMR. Then I could check the value of that against what my >high and low timings should be, and go from there. Again I think I run >into the rising/falling edge thing though. I'm really confused here. I'm >sure that there is a solution somewhere, I just can't quite figure it >out. > >If you have any ideas or suggestions, they will be appreciated! > >Thanks, > >Josh >-- >A common mistake that people make when trying to design something >completely foolproof is to underestimate the ingenuity of complete >fools. > -Douglas Adams > >-- >http://www.piclist.com hint: To leave the PICList >piclist-unsubscribe-requestKILLspammitvma.mit.edu > > > -- * | __O Thomas C. Sefranek .....tcsKILLspam.....cmcorp.com |_-\<,_ Amateur Radio Operator: WA1RHP (*)/ (*) Bicycle mobile on 145.41, 448.625 MHz ARRL Instructor, Technical Specialist, VE Contact. hamradio.cmcorp.com/inventory/Inventory.html http://www.harvardrepeater.org -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu

You can set the interrupt on both rising edge and falling edge , first set it on rising edge , when the interrupt occurs set it on falling edge in the rising edge interrupt routine and vice versa , I think I did my reception this way and I recall that the ir stream has a start bit of 20 us then 16 bit code then 16 bit key code , depending on your remote control of course . and the output is always hi the pulses are low. first you have to check that the start bit is the right length otherwise you just ignore the rest and the hi is 4 usec pulse and the low is 7 u sec , check it with a DSO or logic analyzer . if u keep the key on the remote pressed down you get just the start bit and 1 pulse of certain duration and not the rest of the code , this is useful for things like volume up and volume down etc . {Original Message removed}

> An IR data stream from a dedicated IR transmitter IC will have > a pretty accurate data clock. Not in my experience. They tend to be RC based and will drift a fair amount. There is measurable drift over the length of a transmission but not enough to cause too much trouble. You also have to watch the rise and fall times of some IR detectors. They aren't the same so measuring a pulse width gives you wrong information, but edge to edge is OK. The method I used recently was to use a single edge interrupt and each timen preload a timer with 0xff minus the value halfway between a 0 and 1 bit time. Each time you get an edge interrupt, the data bit to record is the value of the timer overflow flag. Steve. ====================================================== Steve Baldwin Electronic Product Design TLA Microsystems Ltd Microcontroller Specialists PO Box 15-680, New Lynn http://www.tla.co.nz Auckland, New Zealand ph +64 9 820-2221 email: stevebspam_OUTtla.co.nz fax +64 9 820-1929 ====================================================== -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

True...I always seem to underestimate the PIC. I hope eventually I get over it heh. Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams > >The question now is, what's the best way to deal with it? I'd like to > >stay away from just polling, because the PIC will be doing a bunch of > >other things, and I don't want to run the risk of missing IR pulses. > > > missing IR pulses? Most modules produce TTL at about 1200 baud MAX! > (think about how many macine cycles happen during 1 "pulse" at 1200 baud.) -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu

> > An IR data stream from a dedicated IR transmitter IC will have > > a pretty accurate data clock. > > Not in my experience. They tend to be RC based and will drift > a fair amount. There is measurable drift over the length of a > transmission but not enough to cause too much trouble. Those I've been familiar with have at minimum a 455kHz resonator as the clock source. All operations of, and data from, the IC are based on Tosc. They have different formats for data streams, eg pulse-width (say 10 x Tosc for "0" and 5 x Tosc for "1") or the more conventional "0" & "1" level equi-time bits like RS comms > > You also have to watch the rise and fall times of some IR > detectors. They aren't the same so measuring a pulse width gives > you wrong information, but edge to edge is OK. Using a 3-terminal (inverting) receiver-filter-amplifier like the Sharp IS1U60, particularly if the data is sent with a 38kHz carrier, makes for a pretty good long-range reliable transfer. Nice clean edges and ambient light immunity. Alternatively an IR diode and LP311 work well together for a lower cost short-range application -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

I like this method...seems simple enough even for me to understand. Does anyone have any comments about the method itself or changing the leading/falling edge setting in the middle of the program? I'd assume I'd have to disable the interrupt before I changed it. Can I change it from inside the ISR? Josh Mahmood Elnasser wrote: {Quote hidden}> > You can set the interrupt on both rising edge and falling edge , first set > it on rising edge , when the interrupt occurs set it on falling edge in the > rising edge interrupt routine and vice versa , I think I did my reception > this way and I recall that the ir stream has a start bit of 20 us then 16 > bit code then 16 bit key code , depending on your remote control of course > . and the output is always hi the pulses are low. first you have to check > that the start bit is the right length otherwise you just ignore the rest > and the hi is 4 usec pulse and the low is 7 u sec , check it with a DSO or > logic analyzer . if u keep the key on the remote pressed down you get just > the start bit and 1 pulse of certain duration and not the rest of the code > , this is useful for things like volume up and volume down etc . > > {Original Message removed}

Hi Jinx. I think I sort of understand your method. Keep in mind I've never done bit banged serial reception. I'm saving up to buy Serial PIC'n...someday I hope. (BTW if anyone has one for sale, let me know). Anyway, if I understand correctly, you set a timer for some value smaller than the length of a bit, then sample the pic every interrupt right? But what if my timer interrupt lands right on a port change or something? Also I don't understand the INTF statement. Thanks, Josh Jinx wrote: {Quote hidden}> > > If you have any ideas or suggestions, they will be appreciated! > > An IR data stream from a dedicated IR transmitter IC will have > a pretty accurate data clock. You can use one of the timers to > sample the data bits, same as you would with s/w RS232. This > could be in the background, possibly all the time if you use it in > conjunction with INTF to find the start of a block of data > > -- > http://www.piclist.com hint: To leave the PICList > spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

> I like this method...seems simple enough even for me to understand. > Does anyone have any comments about the method itself or changing > the leading/falling edge setting in the middle of the program? I'd > assume I'd have to disable the interrupt before I changed it. Can I > change it from inside the ISR? Don't see why not. The data line will be static during the ISR (if it's a slow data stream that is) and there won't be any edges to miss. Just make sure you exit the ISR before the next edge is due -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

> Anyway, if I understand correctly, you set a timer for some value > smaller than the length of a bit, then sample the pic every interrupt > right? But what if my timer interrupt lands right on a port change or > something? Also I don't understand the INTF statement. Well, first you need to know the format and timing of the data coming in. If it's a regulary timed data stream (ie the same length for a "0" or "1") then the convention is to sample each bit at least three times, although if you're confident about the timing at both ends (Tx and Rx) you could sample just once, right in the middle of the bit. This does leave you open to errors though To keep it simple, say a data bit length is 6ms and you want to sample each bit 3 times. After the first edge detection (which is where INTF comes into it), you wait for 1ms, sample, wait 2ms, sample, wait 2ms, sample. You have then got 3 equi-distant samples, (at 1ms, 3ms and 5ms) which if you have to, can be checked for a majority decision in the case of a noisy environment or if you just want to be absolutely sure. Many micros sample 16 or more times per bit and then get a majority decision. Getting the PIC's code timing in synch with the data stream should mean that nothing unexpected will happen whilst you are sampling. If the data is that important, it should be given the highest priority you can -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu

> beginning of the > isr. Not recommeded, it however should still work a-ok. > The key point is to re-set the hi-lo or lo-hi a.s.a.p. then perform the rest > of > decoding. I think ? > > /tony You could be right. Depends on the IR pulses coming in. Some remote controls use just a few microseconds for each pulse (to get more range) but have quite a long time between pulses, perhaps 100us. The only necessary function of the ISR is to capture the edge and toggle the trigger polarity for the next one. The data bit itself can be determined and worked on outside the ISR. Personally I prefer to have the ISR over and done with just to keep things tidy -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

The only problem I see with this method is that if I receive a an edge while I'm in the ISR (for whatever reason, could be for doing other things). I will still get an interrupt once I exit the ISR, but my objective here is to time the pulses, so I'll be getting the interrupt late, and it will throw off my time. If I was a better coder, I could do some sort of error checking. :) Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams K|bek Tony wrote: {Quote hidden}> > Hi, > > Jinx wrote: > >Don't see why not. The data line will be static during the ISR (if it's > >a slow data stream that is) and there won't be any edges to miss. > >Just make sure you exit the ISR before the next edge is due > > I don't see that so crucial ( given that there are enough time to actually > handle the data in time ). As long as the edge detect are setup correctly > for the *next* pulse then the isr flag will be set wether or not you > are inside the isr or not. Ofcource if an edge is detected while inside > the isr the retfie will just 'waste' 4 cycles to vector back to the > beginning of the > isr. Not recommeded, it however should still work a-ok. > The key point is to re-set the hi-lo or lo-hi a.s.a.p. then perform the rest > of > decoding. I think ? > > /tony -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> Agreed, however sometimes one needs every single cycle. > Let's say that the pulses actually are shorther than possible to > s/w decode on the fly, then it might do the trick to use the isr > flag as a 'bit-buffer' Yeah, that's an option - rotate the bits through a buffer and worry about it later. Sooner or later though high baud rates will mean moving to a faster/bigger micro or some external h/w -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics