Universal Programmable Remote Control

Cornell University, ECE 476

Hardware Design

Hardware Considerations:

The hardware we used centered around an IR detector module and an IR LED transmitter. In picking the parts, we noted that in past remote control projects, teams had difficulty in transmitting the remote signal back out, so we tried to find an LED that could sustain more power and had a larger angle of output, so as to be more versatile, as a real remote should be. The IR diodes also can sustain a current over 10 times as much as its maximum rated operating current if the current is applied in bursts, as our signal is. With this, we amplified the output of the port pin with an NPN BJT. We also connected another normal, yellow, LED so that we could see when we were actually transmitting data. The IR LED that we chose emitted an 880 nm wave, as do most remote control transmitters.

We also chose several receivers to test, although the first one that we tried worked well enough. The receiver demodulates the carrier frequency, so that we only get a digital signal out, far more convenient for us. The complete parts list is provided in the appendix.

One problem we had was memory. The array of integers that store the times initially overran the available SRAM memory so we had to scale back down the number of transition times we recorded. Fortunately, it was still enough for the detector module within the radio to detect. Also, the data in the SRAM is volatile and is not maintained over a power-down. This means that the remote control signals will have to be re-recorded, every time the unit was shut off. We wanted to store the stuff into Flash memory, where the program is but writing to it during operation is supposedly very tricky and not recommended. While the array is also too large to store into EEPROM, we were given the option of storing it an extra memory chip on the STK500 but writing and reading from that would have been extremely difficult since we would have to do all the memory management ourselves. This is another problem that real remote controls can avoid since they can store the correct times into a table in flash memory to begin with and would never need to write to it. The 32K that we have in flash would more than suffice for our signals.

Trial and Error:

For some time, we deluded ourselves with the fact that we were going to build an appropriate circuit on a solder-board to operate our chip on so that our remote can actually be remote and not tied to an STK 500 board tied to a power strip. That idea failed rather miserably as things were not soldering correctly and wire insulation and other plastic insulating object were melting. We discarded that idea and accepted the fact that our end product was going to be burdened by heavy peripheral devices. The soldering idea actually consumed a decent amount of time as we had first constructed the appropriate circuit to support the microcontroller on a breadboard which we had procured. However, the clock did not oscillate, due to the high capacitance between the sockets on the breadboard.