Introduction
The goal of our project was to develop a remote control whose buttons would be readily programmable by recording the signal from another remote control.
After revising several standards on infrared signals, we determined that the approach to take was to record the signal by determining the width of the transitions in the waveform, so as to be able to record any standard that exists as of now, and that may exist over the future. It is important to mention that all standards, however, have a common trait: they use 40 KHz modulation to transmit information. This constituted a challenge in terms of output generation, since the devices that are being dealt with are very sensitive to timing variations in both modulation and wave envelope.
The hardware consists of the following parts:
1. STK 500 It is the heart of the design, records and replays the signal.
2. Infrared receiver Demodulates the 40 KHz Infrared input signal from the remote control, outputting a 5V-0V waveform.
3. Infrared transmitter Outputs the Infrared waveform to be received by the device when played by the STK 500.
4. LCD display Prompts the user for input.
5. Keypad Reads input from the user.
The software consists of the following parts:
1. Record signal This segment of the code is in charge of detecting wave shapes, and recording them.
2. Play signal This segment of the code is in charge of taking the recorded signal width transition values, and outputting a 40 KHz wave that follows such measurements.
3. User interface This segment of the code is in charge of communicating with the user: it controls the LCD, reads from the keypad and calls other sections of the code as appropriate.
High Level Design
Rationale:
This project envisions a new generation of remote controls: ones that truly satisfy the demands of the modern consumer by adapting to each persons needs. The main feature of our product is its ability to record any other remote controls signal and reproduce it at will. In this manner, our remote would be able to control several devices at the same time, and customize which button performs which action at its users will. This allows the user to truly organize the actions it can perform with a single device both physically and logically: button organization and device/signal selection.
Logical Structure:
Our project was divided into several logical tasks: signal detection/recording, signal reproduction, and user interfacing. As mentioned, on our signal detection/recording phase we use an IR receiver to do analog demodulation of the signal emitted by the remote control. We then, via the Input Capture pin on the Mega32, record the widths of the 5 and 0V signals input from the receiver, and record them into memory. On our signal reproduction, we read from the values previously recorded and output a waveform modulated at 40 KHz by using timers and interrupts in the Mega32 processor. Our user interfacing consists of a keyboard and an LCD display; in order to read input from the user we constantly poll the keyboard using timers in the Mega32 processor and taking advantage of the ability of the ports to read and write to the same pin.
Hardware/Software tradeoffs:
The main trade-off on our design was whether to stick to one standard, or to support more of them. The former was found far more desirable. The tradeoff wouldve meant that the compactness of the recorded wave representation wouldve been greatly improved had we decided to support only one, but given the nature of our product we decided that the latter was far more versatile and useful. Thus, we decided that recording the shape of the wave as opposed to the encoding that the wave would have represented on a given standard was the most effective way to go about implementing our product.
Standards:
As mentioned before, there are several standards for infrared transmission; the ones for remote control communications include pulse coded, where the length of the pulses determine the unique signals, space coded (or RECS80), where the time between constant pulses are used, and shift coded (or RC-5), where all the pulses and times are constant but the direction of the transitions determine individual signals. Other standards include NEC, RC6. As mentioned before, our project is designed to support these standards, and any future standard whose carrier frequency is around 40 KHz.
This is achieved by recording the shape of the wave, as opposed to the bits that are being transferred. Again, remote control signals are essentially digital signals that are either on or off, modulated with a carrier wave. They are not dependent on signal strength, for is they were, distance would affect their operation. More information on individual standards and the manufacturers that use them can be found on the websites registered within our references. By using time to dictate all digital signals, however, we are theoretically able to replicate an IR signal of any standard. We only tested ours on a Sony appliance, however, which uses the pulse coded standard.
All remote controls probably have patents on them, but that should not make our device illegal to use. This remote control may well be for a company that wants to make a universal remote control and have already bought up the rights to make the product. If it was for consumer use, the consumer needs to already have the remote, so duplicating it should not present any legal issues.
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.
For more detail: Programmable remote control
