the_buckeye,
Ok. First, most IR circuits are designed to reject ambient IR sources. Without a lot of rejection, you have no control over the circuit behavior. The most typical form of rejection is to send 15kHz to 50kHz pulses of IR. Let's choose 36kHz for this example. The pulse train of 36khz is either "on" or "off" to indicate a particular data state.
We have to stop here and look at serial communication for a moment. We will assume simple Host to Slave communication. In this protocol the Slave waits in an idle loop for a "start condition" to occur. Once the start condition is received, the slave receives some number of data bits. Various protocols define the parameters of the data bits, but at the end of the day eventually some number of data bits from the host are received and the communication cycle terminates. From this point we move to the function of the Host.
We might define a serial protocol as follows:
Start Bit = 500uS 36kHz Signal Followed by 500uS No 36kHz Signal
Low Data Bit = 50uS 36kHz Signal Followed by 150uS No 36kHz Signal
High Data Bit = 150uS 36kHz Signal followed by 50uS no 36kHz Signal
Stop Bit = 100uS 36kHz followed by 100uS no 36kHz Signal
End Transmission = 50uS 36kHz followed by 450uS no 36kHz Signal followed by 50uS 36kHz on
8 Data Bits + 1 Parity Bit + 1 Stop Bit per Byte Bytes can be separated by a defined signal, but this is not required for a simple IR device like yours. Additional redundancy measures can be added to improve rejection (for instance sending the 1's complement of each byte or word etc), but we will ignore these for now.
In your case, you want your receiver (Slave) to either turn a relay on, or turn a relay off. So you might be tempted to just define an "Action Byte", but in practice this is a very bad idea, and has very little rejection to other devices. In practice you would want at least a "Device Byte" and an "Action Byte", and I would add an ACK byte, but this is not strictly needed, so we will ignore it for brevity.
Now, to IR modules for a moment. Rather than build a circuit to convert the pulsed signal to data bits many designs simply use an IC to accomplish this task:
http://media.digikey.com/pdf/Data Sheets/Vishay IR PDFs/TSOP 17...pdf
Sending the IR signal is fairly easy, you would use a 36kHz clock to source an IR transmitter, and mux the diode's input with a control signal from a uController or other device capable of timing/sending your serial protocol.
Now, while your receiver does not HAVE to have a uController to decode your signal, it is by far the easiest choice. You simply have the uController poll the IR Rx Module's output looking for a "start condition", in our case a pulse lasting longer than 150uS followed by a 500uS "pause". From there the data bits are all initiated by the leading edge of the bit, and a "sample" can be taken 100uS after the leading edge. The bits are shifted in until 8 bits have been Rxd. The data byte is then moved out of the shift register and the parity bit is shifted in. The data byte parity is then calculated and compared to the parity bit. If they match then the Rx routine continues to the next data byte, if not, then the routine is terminated and the uController returns to polling for a "start condition".
Once the data has been Rxed, it is tested. If the first data byte matches your device code, then the next data byte is tested. If the first data byte does NOT match your device code then the uController returns to polling for a "Start condition". Assuming your device code matches, the uController then tests the Action Byte. If the Action Byte matches an Action Code (in your case, "Device = On", or "Device = Off"), then your uController turns an I/O pin High/Low to change the state of the Relay. (Obviously you would NOT want to drive the relay directly from your uController.)
It is possible to build a coded IR Receiver w/o a uController using Flip/Flops and timing circuits, but this would be considerably more complicated/less flexible than simply using a uController, at least IMHO. I can also imagine building an IR transmitter w/o a uController. But until I am certain you have a firm grasp on how simple serial communication protocols are implemented, and WHY you would have to use them for your device, I see little reason to explore this venue.
If your project is not limited to building an IR detector/Transmitter, you might consider the much simpler task of building a device to "map" the IR signals from various remotes and send them to a PC. This project is still easiest achieved with a uController, but it is really very simple with very little uController code and a simple PC interface.
When you are ready to move from theory to actual design, let me know, but since this is a school project, you will need to demonstrate you understand what I have discussed so far.
Fish
