Introduction

This project creates a programmable device that can control a DVD player on scheduled times by sending infrared signals.

The uControl allows the user to control their DVD player as if they are using a remote control. However, unlike remote controls, uControl allows the user to program a sequence of button pushes that will automatically run at a time that they can set. To schedule the sequence of button pushes, the user can use the computer to program the device, or use their remote control to have the device record the sequence of button pushes. These are done after setting the execution time of the button push sequence. When the time arrives, the device will automatically execute this sequence of button pushes.

 High Level Design

 Rationale

As Cornell Engineering students, we are so busy with homeworks and projects that we tend to miss a lot of television shows. While recording the shows does get around this problem, keeping track of it is very troublesome. Therefore, we decided to create a device, uControl, that can automatically turn on a television at a scheduled time, switch to the correct channel, and start recording at a desired time. uControl can do more than this however. The user can program the series of actions to be executed by the television at a time that they also specify. However, due to time constraint, we can only afford to test this device on one electrical device. Testing this on a television alone definitely limits the range of actions that we can demonstrate. So, we chose to test the device on a DVD Player.

 Logical Structure

The project was completed in several stages. We started by implementing the most crucial elements of uControl: the EEPROM and the IR Photo Detector. The EEPROM was used for storing scheduled events. The IR Photo Detector was used for detecting the type of signal emitted by the DVD Player remote control, so that we can learn the bit pattern for each button press and the format of the infrared signal. Once we got the EEPROM to receive and transmit data, and the IR Photo Detector to read IR signal from the remote control, we implemented the infrared LED. Finally, we implemented the real time clock.
The hyperterminal input is the main way for user to interact with the device. By entering Unix like commands, the user can control the DVD player, edit the event scheduling, as well as edit the setting of the device. The remote control input is used only when recording a scheduled event. When the user creates a new scheduled event, they must specify the actions to be taken. One way to do this is by entering commands corresponding to each action. However, since this method can be tedious, an alternative way would be to use the remote control to enter the actions.
The hyperterminal output is mainly used for feedback to the user after they have entered a command. The IR LED Output is used to control the DVD Player by sending the same signal that the remote control of the DVD Player would send.
The EEPROM is used to store scheduled events. uControl periodically checks EEPROM for events to be run, and make add or remove events by the users request.

   Hardware / Software Tradeoff

One of the tradeoffs was whether to handle modulating the IR LED using the AtMega, or a separate frequency generator. Since the CTC timer on the AtMega allowed us to generate approximately the correct waveform without any additional hardware we chose to use it. Also, we had to choose whther to keep track of times on the AtMega, or whether to use an external clock. Because we wanted the device to continue functioning when power was removed, we chose to us an RTC (DS1305) with a backup battery.

 Relationship to Standards

There are several standards for Infrared remote communications. Most use a byte based code that is modulated on top of a 30-40Khz carrier wave. To find out the protocol of the signal, we connect an oscilloscope to the output of the IR photodetector and analyze the signal for a button press of the remote control. Any signal sent by the remote control contains three main parts: header, body, and trigger. A bit 0 is represented by 600s high pulse followed by 500s low pulse. A bit 1 is represented by 600s high pulse followed by 1.6ms low pulse.
The header part starts with a 9.2 ms of high signal, followed by 4.4 ms of low signal. After this, eight bit 0 are sent, followed by eight bit 1s.
The body part contains 16 bits of instruction in binary format, each corresponding to a button on the remote control. This part is followed by 39.9 ms of low signal, before the trigger part.
The trigger part consists of 9.4 ms of high signal, followed by 2.2 ms of low pulse, 600s of high pulse, and 96 ms of low pulse. When a button on the remote control is held down, the remote control only send the header and body once, and the trigger part is send multiple times, once for each repetition.
In addition to the standard RS-232 Serial that we have used in previous labs, this project makes use of two synchronous serial busses. These two busses (I2C and SPI) both clock data one bit at a time. Serial Peripheral Interface (SPI) uses a chip select line to control which chip on the bus the master is talking to. It also allows full duplex communication with the master talking on Master Out Slave In (MOSI) and the slave talking on Master In Slave Out (MISO). Every time the master drives the clock, one bit of data is transmitted in each direction. I2C uses only 2 wires for both addressing and sending data. This works by first sending an address byte to indicate which slave device is being addressed. The master can then either clock data in or out (but not both at the same time). I2C is a protocol developed by Phillips Semiconductors.

3.5.      Existing Patents and Trademarks

The following are patents related to the device that have not expired:
Patent 6989763: Web-based universal remote control (2006)
Patent 5691710: Self Learning Infrared Remote Control Transmitter (1997)
Patent 5684471: Infrared Remote Control Transmitter with Power Saving Feature (1997)
 
The following patents are related, but they have already expired (at least 20 years old):
Patent 4425647: Infrared Remote Control System (1984)
Patent 4426662: Infrared Remote Control Detector / Decoder (1984)
Patent 4377006: Infrared Remote Control System (1983)

 Program Details

The software consists of seven main parts:

1. The Serial Communicator is responsible for sending and receiving messages from the hyperterminal.
2. The Parser is the main part of the program. It is responsible for interpreting the commands sent by the user through the hyperterminal and executing them. This means that it is also responsible for controlling the real time clock, the EEPROM, and the IR LED. It also process the IR LED input signals after the IR Receiver has converted it to binary code.
3. The CLK & SPI Protocol act as interface to the real time clock for the rest of the device. It allows other modules of the program to read and set values to the real time clock.
4. The IR Receiver converts the analogue IR signal to digital form to make sure that other modules can use the signal.
5. The Event Runner periodically checks the EEPROM if there are any scheduled events that need to be run.
6. The TWI Protocol, like the SPI Protocol, acts as an interface to the EEPROM.
7. The IR Transmitter transmits any bit patterns using the IR LED after formatting the bit pattern to the correct IR Signal form, as outlined in section 3.4.

Serial Communicator

This part follows the same scheme as the one used in Lab 3: Security Systems. The scheme follows as outlined ECE 476 Website, and the implementation is a modified version of the example given in that page.

 Parser

The parser periodically checks if the user has entered any commands, and executes the command once it detects any commands from the user. The available commands and their formats are listed in Table 1 – Table of Commands and Their Formats..
The parser can run in two modes: Normal and Recording Mode. The modes determine the behaviour of the commands and which commands are available to the user. In the normal mode, the user can execute all commands, except for evfin, which is the command to finish recording an event, and therefore can only be executed when the parser is in recording mode. Executing any DVD Player Control commands will immediately send the command to the DVD Player as IR signal. The evnew command switches the parser to recording mode and cannot be used in this mode. This command creates a new event and uses the recording mode to record a sequence of button presses to be executed when the scheduled time has arrived. Hence, any DVD Player Control commands entered will be recorded and will not be echoed as an IR signal. The recording mode also allows user to enter these commands using the remote control. Every detected button push from the DVD Players remote control will be recorded as another item in the sequence. Once the user has finished recording the event, evfin will save the event to the EEPROM and switches the parser back to normal mode.
When initializing the parser, the program scans the EEPROM while looking for the last event block that is empty / invalid. This address is saved, and it is assumed that any blocks with address less than this address are not empty. This makes writing new events to EEPROM very easy; the program only needs to write to the location pointed by the saved event address, and then move the saved address forward by one. When an event is deleted, to make sure that the assumption is still correct, another event block needs to be moved to the location where an event was deleted. A way to do this would be to move the last event in the EEPROM to this location. While this destroys temporal locality in the data structure, this method is much faster than having to move a large number of blocks, especially since writing to EEPROM requires at least 5 ms delay before the next write. Without this delay, the next writing to EEPROM will not occur.
Since writing to EEPROM needs at least 5 ms delay, commands that involve writing to EEPROM must implement a delay scheme. This delay scheme must allow other state machines to run during the delay. This is especially important for the IR Transmit state machine, since stopping the state machine will mess up the timing for the signal, thus distorting the IR signal. The delay scheme is implemented by using another state in the parser state machine. Whenever a delay is needed, the state machine sets the next state that it should go to after the delay, and enters the delay state. After 5 ms of delay in the delay state, the state machine goes to the state that has been set before entering the delay state. This way, 5 ms of delay can be provided after writing and reading from EEPROM without blocking other state machines.
he parser also needs to take into account the delay caused by reading and writing into the real time clock. Since the read and write methods are blocking, we need to make sure that the IR Transmitter is not transmitting anything before reading or writing into the real time clock. So, the state machine will wait until the transmit buffer of the IR Transmitter is emptied before executing these commands.

   CLK & SPI Protocol

The spi part of the software handles reading and writing into the real time clock using the Serial Peripheral Interface (SPI) as outlined in ECE 476 Website. There are three main methods in the SPI part: initialization, write, and read from the real time clock. We used the spi method form the SPI library that comes with CodeVision to implement this part.
Following the scheme outlined in the real time clocks datasheet, we implemented the write method by first setting the real time clocks cm pin to high, then sending two 8 bit characters, followed by setting the real time clocks cm to low. The first 8 bit sent is the address in the real time clock to write onto. The second 8 bit character is the value that the referred address should be set to.
Following the same scheme, the read method is implemented by first setting the cm to high, sending one 8 bit character, receiving 8 bit characters, setting the cm back to low, and returning the received 8 bit character. Like in sending, the 8 bit character sent is the address to read from. To read value from the real time clock, we used the fact that the spi method also returns the value received. So, after sending the 8 bit address, we send a junk value using the spi method and keep the returned value from that method.
Since the time values are kept in the real time clock in an unconventional way, we used the CLK (clock) part to handle the conversion between the format used in the real time clock and the normal format. The real time clock uses 8 bit characters to store the values of the time parameters. The highest four bits represent the 10s of the value, and the rest are the 1s. This means that 23 is stored as 0b00100011, instead of 0b00010111. Also, bit 6 of the hour value is used to indicate if the hour is represented in 12 format (with bit 5 being used for AM / PM) or 24 format (bit 5 is used as an extra bit to represent 20 23). For this project, the 24 hours format is used. The CLK part acts as an interface to the rest of the program when trying to read / write into the real time clock, so that other parts of the software do not need to deal with the different representation of number in the real time clock.

IR Receiver

The IR Receiver consists of two parts. The first part utilizes an external interrupt and Timer 1 running with prescaler of 64 to measure the time that the IR Signal from the photo detector is high. When the external interrupt detects a rising edge, it resets the counter of timer 1 (TCNT1) to zero. At this point, timer 1 will keep increasing its counter. When the external interrupt detects a falling edge, it reads off the counter value of timer 1 and adds this value to a receive buffer. This value represents the time that the signal is at a high state.

After filling 33 values to the receive buffer, the second part of the IR Receiver which keeps polling the receive buffer every 20μs will take the values stored in the receive buffer and translate them to a series of ones and zeros. First, it checks if the signal is valid by checking for the header part of the signal, as shown in Figure 2. If the signal passes this check, it will be converted to a series of ones and zeros. Because of noise, the timings cannot be exact. So, we used a range of time to check for the time period, by checking if a time falls within a certain range of time.

  Event Runner

The Event Runner state machine has only two states. In the waitEvent state, it goes through all valid entries in the EEPROM, reading data from the EEPROM only when the infrareds transmit buffer is empty. This is because when it reads from EEPROM, the even runner also needs to read from the real time clock to check if the saved event in the EEPROM should currently be run. As have been discussed, obtaining current time from the real time clock uses a blocking method. So, to avoid disrupting any IR Transmits, the state machine must make sure that the transmit buffer is empty.
If it is time for the checked event to be run, the Event Runner will switch state to waitBuffer. In this state, it waits for the transmit buffer to be emptied, not only because the executed event will be deleted from the EEPROM and this will need some delay, but also because it needs to make sure that there is enough place in the buffer to place instructions to be sent. Once the transmit buffer is empty, the Event Runner will read all 10 button pushes saved in the event and add all of them to the transmit buffer. Then, to avoid rerunning the same event, the event is deleted from the EEPROM.
 
For more detail: uControl DVD macro-controller Using Atmega32