Searching \ for '[PIC]: What's the best way to decode IR?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'What's the best way to decode IR?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: What's the best way to decode IR?'
2001\12\02@144200 by Josh Koffman

flavicon
face
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-requestTakeThisOuTspammitvma.mit.edu


2001\12\02@151024 by Jinx

face picon face
> 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-requestKILLspamspam@spam@mitvma.mit.edu


2001\12\02@154201 by Thomas C. Sefranek

face picon face
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}

--
 *
 |  __O    Thomas C. Sefranek  .....tcsKILLspamspam.....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_OUTspamTakeThisOuTmitvma.mit.edu


2001\12\02@155031 by Mahmood Elnasser

flavicon
face
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}

2001\12\02@155237 by steve

flavicon
face
> 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: stevebspamspam_OUTtla.co.nz      fax +64 9 820-1929
======================================================

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\12\02@160937 by Josh Koffman

flavicon
face
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-requestKILLspamspammitvma.mit.edu


2001\12\02@163331 by Jinx

face picon face
> > 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-requestTakeThisOuTspammitvma.mit.edu


2001\12\02@163757 by Josh Koffman

flavicon
face
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}

> {Original Message removed}

2001\12\02@163951 by Josh Koffman

flavicon
face
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}

--
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-requestEraseMEspamspam_OUTmitvma.mit.edu


2001\12\02@164806 by Jinx

face picon face
> 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-requestspamTakeThisOuTmitvma.mit.edu


2001\12\02@170128 by Jinx

face picon face
> 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-requestEraseMEspam.....mitvma.mit.edu


2001\12\02@170953 by Jinx

face picon face
> if you just want to be absolutely sure. Many micros sample
> 16 or more times per bit and then get a majority decision

I meant to say that the 16 samples are part of their in-built USART
h/w. In s/w you can sample as many times as you like

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu


2001\12\03@131119 by Jinx

face picon face
> 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


2001\12\03@143002 by Josh Koffman

flavicon
face
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}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\12\04@185200 by Jinx

face picon face
> 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


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...