File	Version	Platform	Content	Modified
ir_transmitter.zip	1.0	AVR 2313-10PC	EAGLE (CadSoft) schematic	Aug 2005

This IR circuit uses a 4x4 sized keypad for the user. The 74C922 chip can encode these types of keystrokes into a 4-bit number. Use the keypad encoder sub-circuit to read key data from the 4x4 matrix.

The operating frequency is critical since it directly controls the bitrate. The AVR program on this page was designed for a 4.00MHz clock. If you need a different bitrate, please view the software section below for details on how to rewrite the program for other clock rates.

Be aware of how much current will be drawn by your infrared emitter, especially when using "high-output" or "high-brightness" diodes. Often, these diodes require 100mA for peak emission, which is much greater than the 20mA or 30mA garden-variety controllers are designed to take.

Not all infrared emitters are created equal. Like visible LEDs, each has a distinct wavelength (measured in nanometers), which would corespond to a color if we could view it. Before choosing an emitter, know that your receiver will have an "infrared passband" that will filter out any wavelengths that don't fall within that range.

My receiver had an advertised passband of 940nm +/- 50nm--or 890nm to 990nm. The emitters I purchased were rated 915nm. Not an ideal match, but well within the limits. On the market, I've seen diodes with wavelengths as long as 1550nm, so beware if purchasing an unknown diode.

Thanks to the software-generated carrier, no signal mixing is required and the engineering burden is mostly shifted onto the software aspect. In general the system's simplicity makes it possible to build a highly robust transmitter out of nearly any grade of electronic component.

For a description of the RC5 remote control protocol, and the a description of the protocol I used in this device, view the Basic Infrared Receiver Software Design section.

Creating the Carrier with Software

Since we are applying the RC5 protocol, we need the data to modulate a 36kHz carrier signal. Normally this carrier would be generated by a seperate oscillator and combined with the output of the AVR. But to minimise circuit size, we will generate the carrier within the AVR program itself.

My AVR is operating with a 4.00MHz clock frequency. If we invert 4x10^6, we can see that the clock period (or "T state") is 0.25us. Most AVR instructions take only 1 or 2 clock periods to complete. By looking at the data sheet, I could tell exactly how long each instruction lasts and use that to toggle the output pins precisely at 36kHz.

Doing the math, take the inverse of 36,000Hz--which yeilds 27.8us. To express this in terms of T-states, multiply the clock frequency by the delay we want:

...So at 4MHz, there needs to be approximately 111 T-states between each carrier wave period. So for example: we could raise the line for 55 T-states, and lower it for 56 T-states. Once again, at 4.00MHz, one T-state spans 0.25us.

By adding additional components to the circuit, you can use an oscillator set to produce 36kHz, and eliminate the need to have the software generate the carrier. This would speed up developement time and free up critical processor time for other tasks. Since the square wave carrier is created on an on/off basis, a 555 timer or similar signal source could be used. The AVR allows you to use such an external signal source and an interrupt trigger, so this can free up an additional amount of processing time.

The software-generate carrier operated at 37.037kHz rather than the nominal 36.0kHz due to software restrictions. Despite this, the IR output still visible to Phillips devices at ranges averaging 10 meters indoors. The max operating range with the IR receiver project was slightly farther under the same conditions, with the range being about 12 meters. A minimum operating range of 7 centimeters was also observed.

In summary, the system worked very well with Phillips equipment and the IR receiver project. However, for future reference, I would only suggest using an external carrier signal source over the software-generated carrier approach. This move would free up significant processing time and other resources (timers, registers) for the AVR. If the software-generated carrier is still required, I would suggest using an AVR hardware timer to control bit flow, as this would allow the AVR to carry out other tasks between bit transitions.

1. SB Projects. San Bergmans, Oisterwijk http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm

3. Koninklijke Philips Electronics N.V. http://www.remotecontrol.philips.com/index.cfm?id=105. 2004-2005