High-Level Design

Remote Controlled Outlet Strip
High-Level Design
Hardware Design
Software Design

Daniel Warren

Heidi Ng

Rationale and Sources of Project Idea

Dan has a lot of decorative lightings in his dorm room, and he finds it troublesome to have to reach for switches or plugs that are not very accessible when he wants his room to look pretty.  So we thought that our project idea could simplify such tasks for people that experience similar problems.  The outlet strip has 4 outlets which can be controlled individually or as a group, without needing direct access.

Logical Structure

Our project creates a simple light show from a 120VAC power outlet strip which encloses four solid-state relays from Omron, capable of powering four 2A loads (lamps).  We have two circuit boards, each with an ATMega16L microcontroller, which communicate via radio transmission at 433.92MHz.  The transmitter and receiver came as a pair, prefabricated, and we used a 17cm piece of wire as the antenna (1/4 wavelength).  There are status LEDs on both boards to indicate the state of the system, and that everything is functioning normally.

Logical Block Diagram:

The transmitter is normally in a power-down sleep state, to conserve battery life.  All components were selected to have low-quiescent current, to minimize the power wasted when nothing is happening.  The pushbuttons cause an external interrupt, which wakes up the MCU, and reads the port.  It then sends the port state through the UART to the RF transmitter if only one button was pressed.  This makes detecting data errors simpler, since the data byte must have seven 1s and one 0.

The receiver gets the data in through the UART, and decodes it.  Only if a certain set of error correction steps are met does the MCU actually change the state of the system.  That error correction basically consists of frame errors, parity errors, a specific start and end byte, and the data byte as described above.  Concurrently with the data reception, the MCU is processing blink modes, and toggling LEDs and the relays appropriately.

Since we don't have two way communication, the transmitter does not know the state of the receiver, and if the desired result isn't achieved (signal loss), the user just pushes the button again.  This is very similar to a TV remote control - the user pushes power, which toggles the power state - he doesn't push on or off.  The remote doesn't know the state of the base.

Hardware/Software Tradeoffs

Our project was much more heavily biased towards hardware complexity rather than software.  The nature of the project, controlling high-voltage loads, lends itself to it much more.  The software is basically error correction on the data transmission and relatively simple state machines to toggle the outlets.  We chose to sleep the transmit microcontroller, and used an 8-input NAND gate to edge trigger the external interrupt when a button is pushed.  This was more responsive and used far less power than periodically waking up the MCU to check for buttons, which wouldn't work very well.  It's also much better, power-wise, than leaving the MCU always running.  Neither end of the system needed much memory or horsepower in the microcontrollers - they're basically glorified UARTs with error correction and debouncing.

Relationship to Standards

Our project used two main standards.  One was the 60Hz nature of standard wall power outlets.  The other was the FCC regulations governing unlicensed radio transmission.

The 60Hz alternating current power entered our circuit through a wall plug, and normally we didn't have to worry about it.  The only time it would matter is during a state transition, on to off.  There could be a large power spike if we cut the power in the middle of the wave.  To mitigate this, we used relays that had zero-cross circuitry, and only switched when the incoming signal crossed the zero point -- basically ensuring there wouldn't be a power spike.  Our loads are designed to be primarily resistive, so there shouldn't be any lag.  If anything was not as expected, the relays can handle a bit of a jolt anyway.

The main standard that we were concerned about was the FCC regulation to have our transmitter operate at low range and at a frequency that does not interfere with other radio communications such as aircraft radio navigation, radio astronomy, and search and rescue operations.   Our transmitter and antenna complies with Part 15 of the FCC code, outputting an acceptable level of radiation.  The antenna we use is just a piece of wire we cut to a quarter of a wavelength long (17cm), which is low powered. The transmitter we use is low-powered also and operates at 433.92MHz.  In that unlicensed band, our output is well below the limit for intermittent control signals.

For detailed info, see the FCC file in the appendices.

Existing Patents, Copyrights, and Trademarks

There weren't any.  Our design isn't patentable, nor did we use any copyrighted code.  Nothing we used violated any trademarks either.

Home | High-Level Design | Hardware Design | Software Design | Results | Conclusions | Pictures | Appendices

 ECE 476 Final Project
Spring 2004 Daniel Warren and Heidi Ng
Problems? Questions?  Contact sleepdeprived@cornell.edu.
Last updated: 05/03/04.