2
\$\begingroup\$

I need to receive signal from IR transmitter LED. I am not sure how to program the microcontroler. I am looking for some concept, how to do that. Whether I have to use A/D conversion? How to synchronize transmitter and receiver? What structure will be in coming data? Let's say that I assumed 600us for 0 (binary 0) and 1200 for 1 (binary 1) when I was programming a transmitter. What are the common steps to receive infrared transmission on PIC18F microcontroler?

\$\endgroup\$

4 Answers 4

3
\$\begingroup\$

Here's a good introduction to IR reception. It's aimed at Arduino, but the concepts are all applicable to any microcontroller.

IR detectors are little microchips with a photocell that are tuned to listen to infrared light. They are almost always used for remote control detection - every TV and DVD player has one of these in the front to listen for the IR signal from the clicker. Inside the remote control is a matching IR LED, which emits IR pulses to tell the TV to turn on, off or change channels. IR light is not visible to the human eye, which means it takes a little more work to test a setup.

In this tutorial we will show how to

  • Test your IR sensor to make sure its working
  • Read raw IR codes into a microcontroller
  • Create a camera intervalometer
  • Listen for 'commands' from a remote control on your microcontroller
\$\endgroup\$
1
\$\begingroup\$

http://www.dwelch.com/arduino

http://lmistuff.blogspot.com/2008/01/irecho.html

The above are a bit dated now, and luminary micro (where I got lmi from) is now ti, the stellaris name stayed the same though. Your pic is likely not as fast and certainly not as efficient to run the same C code, not that you would anyway, the point was to show a couple of ways to decode (and in one case transmit) IR from remote controls.

I would recommend an ir receiver module, it does the hard part for you, you feed it power and ground and it gives back a demodulated high or low. You feed that into your microcontroller and measure the time between state changes. The protocols are documented a number of places, if you are not trying to decode a specific remote controls protocol I recommend trying a few protocols and isolating the one you like. Some protocols are easier to decode, some protocols are better than others as far as how they work.

both for receiving and transmitting you kinda need to know what protocol and/or remote. There are a few frequency differences, the receivers will still work but you get a tighter, cleaner signal (on the receiver) if you choose the right frequency. When transmitting, you also need to know what the carrier frequency is. For transmitting you only need a IR led, no special modules. Well, lets talk about that. There are two states, on and off if you will when off you ground or zero volt the output of the gpio pin tied to the led. But to turn it on you dont just drive to VCC, you need to pulse at the carrier frequency, if the frequency is 40khz then you need to generate 40Khz on the I/O line for the period that you want the led "ON". These on/off periods are the same on and off periods you get on the receiver, except the receiver module has removed the carrier frequency. I am sure there are a number of websites on the subject. So your simple choices are 1) your software generates, as accurately as you can, the carrier frequency for the on periods. 2) your microcontroller offers a way with a timer to generate the frequency and lets you gate that on and off somehow inside the chip. 3) your microcontroller can generate the carrier frequency but does not let you gate the output, you can choose to use an external and gate of some flavor, or feed the outputs back into other microcontroller inputs and you provide the and function and output that on yet another gpio pin (need to have the microcontroller horsepower to do it which means you probably could have just generated it yourself). 4) use an external oscillator of some sort at the carrier frequency, an external and gate of some sort and you generate the outline of the output that is filled in with the carrier when anded.

IR, is quite simple, and a very good beginner microcontroller project. First learn to blink some leds (not IR), use timed code and internal chip timers (without and then later if you wish with interrupts) and THEN, try to receive some IR. At first I would take the ir receiver input and whatever you read on that input write it to a non-ir led. When you press the button on an IR remote you should see the led blink. If you have a protocol with a start pattern, you can then use the timer to measure pulses and when you see that start pulse, then blink the led, eventually working your way up to decoding the whole IR pattern.

\$\endgroup\$
1
  • \$\begingroup\$ sbprojects.com/knowledge/ir/index.php along the left side are pages describing each of the popular protocols. I disagree that RC-5 is the most popular, and would recommend against it being your first protocol as it has no start pattern and you have to do that much more work to figure out where you are, with a start pattern you can greatly simplify your receiver/decoder. Later, learn how to decode RC-5. \$\endgroup\$
    – old_timer
    Jul 4, 2011 at 0:20
0
\$\begingroup\$

Are you in control of both sender and receiver, or does the sender use an existing protocol? If you are in control you can choose a simple data format, like a 1 ms pulse for a 0, 2 ms pulse for a 1. If not: check the protocol specs.

Beware that you can not simply transmit a bit stream, because the common IR receivers require pulses an pauses in the datastream.

Check http://www.voti.nl/DB038/DB038-1-1.pdf chapter 6 (p 60) for some info. Focusses on RC5.

\$\endgroup\$
-1
\$\begingroup\$

I think generating a known frequency on IR permits the designer to eliminate the effects of background IR (from Sun and CFL's etc.) So, suppose we use 40 kHz for a '1' and 25 kHz for a '0', the IR receiver needs to figure out the received frequency. We need pauses between frequencies to separate the received bits. How fast would the interrupts come frokm IR, for 40 kHz, an interrupt every 25 microseconds. If you run the PIC 18F2550 at 20 MHz, the instruction cycles would be .1 microseconds or 10 instructions per microsecond. Assuming, minimum latency, this would approximately allow the processor to execute 150 instructions between interrupts. The timer interrupts will be needed to calculate elapsed time to figure out the frequency of received signal. I think getting all this done in a Pic18F2550 is too tight a specification. We need to run a 40 MHz processor for better performance. Other option is to do a frequency to voltage conversion and read the voltage through an Analog to Digital port. This needs calibration and an adaptive algorithm would be useful here for calibration.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Actually that's not how ambient light rejection is typically done for IR communications: Two oscillation frequencies adds unnecessary overhead, the standard is to use a single frequency such as 38 KHz or 56 KHz, and use an integrated sensor designed for sensing presence / absence of IR signal at that frequency: See for instance datasheets for TSOP1738 or TSSP5756. The sensor output is a straight pulse stream for (chopped) IR present or absent. \$\endgroup\$ Apr 28, 2013 at 10:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.