Project Report Wireless Home
Automation - Senior Design |
ECE 445
Electrical and Electronics Engineering
University of Illinois - Urbana-Champaign
35 pag.
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
Wireless Home Automation
By
Douglas Brown
Eric Livergood
Chris Lotysz
ECE 445, SENIOR DESIGN PROJECT
SPRING 2006
TA: Ishaan Gupta
May 1, 2006
Project No. 36
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
ABSTRACT
In this project, we designed a system to wirelessly control the lights in a house, as well as to monitor the
statuses of the doors. The design consists of several modules communicating with a base station via the
wireless protocol that we developed. The base station then communicates with the computer software
via our serial protocol.
The system is controlled by the computer software. The software has a control loop that is responsible
for initiating requests for device statuses, as well as collecting and sending user commands.
While the system worked fairly well, there are a few areas that the project could be improved in. There
is also a great deal of functionality that could be added to the system. Many other control modules could
be added, such as a garage door controller, a window blinds opener, or a home stereo controller. In
addition, the status of many other devices could be reported using other sensor modules, such as the
temperatures in different parts of the house or window statuses.
One of the biggest improvements that could be made to our project is the cost. The high cost of our
wireless development boards greatly increased the overall cost of our project. By taking the project and
putting only the necessary parts onto PCB, the cost could greatly be reduced.
ii
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
TABLE OF CONTENTS
1.
2.
INTRODUCTION....................................................................................................................1
1.1 Purpose...............................................................................................................................1
1.2 Specifications......................................................................................................................1
1.3 Subprojects.........................................................................................................................2
1.3.1 Power Supply Module...............................................................................................2
.................................................................................................................1.3.2 Base Station
2............................................................................................................................................
1.3.3 Door Module.............................................................................................................2
...............................................................................................................1.3.4 Light Module
2............................................................................................................................................
1.3.5 User Interface............................................................................................................2
..............................................................................................................................................
DESIGN PROCEDURE...........................................................................................................3
2.1 Power Supply Design….....................................................................................................3
2.2 Base Station Design............................................................................................................3
2.3 Door Module Design..........................................................................................................5
2.4 Light Module Design..........................................................................................................5
2.5 User Interface Design.........................................................................................................6
3.
DESIGN DETAILS..................................................................................................................7
3.1 Power Supply…..................................................................................................................7
3.2 Base Station........................................................................................................................7
3.3 Door Module.....................................................................................................................10
3.4 Light Module....................................................................................................................10
3.5 User Interface....................................................................................................................11
4.
DESIGN VERIFICATION.....................................................................................................13
4.1 Testing..............................................................................................................................13
4.1.1 Power Supply..........................................................................................................13
4.1.2 Sensors.....................................................................................................................13
......................................................................................................................4.1.3 Dimmers
13..........................................................................................................................................
4.1.4 Base Station.............................................................................................................13
..............................................................................................................4.1.5 User Interface
14
5.
COST......................................................................................................................................16
5.1 Parts..................................................................................................................................16
5.2 Labor.................................................................................................................................16
6.
CONCLUSIONS....................................................................................................................17
APPENDICES........................................................................................................................18
Appendix A – Block Diagrams........................................................................................18
Appendix B – Schematics................................................................................................20
Appendix C – Software Flow Charts...............................................................................23
iii
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
Appendix D – Pictures.....................................................................................................24
Appendix E – Parts and Cost............................................................................................26
REFERENCES.......................................................................................................................31
iv
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
1. INTRODUCTION
1.1 Purpose
The purpose of this project was to create a home monitoring solution that could be controlled using a
home computer. While the exist several commercial products that can control lights, as well as perform
several other home monitoring duties, we found that no available product was very expandable. Many
were controlled by a remote control, or something of that nature. We wanted to create a very expandable
system, where the user could create their own personalized home monitoring solution and control all of
it via the same computer program.
The reason we chose this area was a mutual interest in wireless communication. We also realized that
this was a unique project in that we could go many different ways with it. We chose the light module
and door module because we felt they were great representatives of the different types of modules that
could be created and integrated with our system. The door module shows that we can create a very
small, wireless module that simply reports a status when requested. The light module is demonstrative of
the control that we can have over an external appliance.
The system is designed around a base station connected to the computer via a serial connection. The
base station is also communicating with the light and door modules via wireless transceivers.
1.2 Specifications
The specifications of our project were based on the fact that an end user does not like waiting. When he
clicks a button, he expects to see the change almost instantaneously. Knowing this, we set our
specification for system response time. Since our control module was the light module, we focused on
having the light respond to a command within one second of the command being input by the user.
While this was not a critical specification, meaning that the project would still function if it was not met,
we decided that a slow response time would greatly deduct from the overall project.
Another key specification of the project was the range of the devices. Obviously, an end user is not
going to be controlling devices only in one room. As a result, the modules need to communicate through
the average walls of a house, as well as a reasonable distance from each other. According to the website
www.residentialarchitect.com, the average house size built in 2005 was 2,412 square feet [1]. Since a
home is not always a perfect square, we will assume the average length of a house was about 50-65 feet,
while the width was about 35-45 feet. We would like to have a computer in one corner of the home be
able to control a light on the other corner. This tells us that our wireless network should reach at least 70
feet.
1
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
1.3 Subprojects
The key to this project is the modularity of the design. The system is broken down into different
modules that function independently of each other, communicating their status, or command, when
required. Within each module, there are also several different subprojects that are combined to make the
specified module.
1.3.1 Power Supply Module
The power supply module takes in a DC voltage of around 10V and converts it down to 3V. It also must
use current limiting to protect the rest of the circuit from unexpected current spikes.
1.3.2 Base Station
The base station must communicate with both the computer and the external modules. It needs to receive
a command from the computer via a serial connection, and then forward that command on to the
appropriate external module. It also needs to receive an acknowledgement from the external module, and
forward an appropriate success message back to the computer.
1.3.3 Door Module
The door module needs to report the status of the door when a request is sent to it.
1.3.4 Light Module
The light module needs to be able to turn an ordinary lamp on and off. It also needs to be able to dim the
lamp to different settings, as requested by the user.
1.3.5 User Interface
The user interface needs to control the information flow of the whole system. It needs to collect
commands from the user, and ensure that they are attempted by the external modules. It also is
responsible for constantly requesting and receiving device statuses, and displaying them on the user’s
screen.
2
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
2. DESIGN PROCEDURE
2.1 Power Supply Design
At each of the Base Station, the Light Module, and the Door Module a transceiver needed to be powered
at a regulated +3V with less that 500mA. At the Door Module the source of all power needed to be
battery derived. The Door module must also properly power an interrupter sensor. The interrupter
sensor requires VCC = 10DC. The Light module must properly control relay switches. The relay
switches turn on at VOH = 2.95 VDC. The Light module must also deliver 120 VAC to a standard light
bulb.
To obtain the required voltages we used the LM317T adjustable voltage regulator which allowed us to
have input voltage up to +37V. For the Base Station and Light Module the 12V AC/DC used has built
in 500mA current limiting. The 9v Alkaline Battery had maximum short circuit current of 1.5A. The
LM317T itself has short circuit current limiting and will shut down to protect the device and load.
The 120 VAC for the light bulb and relays was taken from the wall outlet. Both the light bulb and the
relays are designed to work well with wall power variances. The relays are rated up to 400V.
2.2 Base Station Design
The initial design for the base station was to use the PIC16F877A with a wireless transceiver to do all of
the communication. We decided to use a 2.4 GHz transceiver because it provided a higher data rate and
also integrated transceivers were readily available as opposed to designing with a receiver, transmitter
and a multiplexer. After preparing to use Nordic’s 2401 RF transceiver with the PIC16F877A, we
discovered that Nordic also produced a wireless transceiver with an 8051 based microcontroller
integrated into it. We chose to use this instead (Nordic nRF24E1) because it simplified the
communication between the microcontroller and the RF transceiver.
The design with the nRF24E1 began on the evaluation boards which included an external oscillator (16
MHz), an RS232 (serial communication) converter, IO pins, Analog to Digital conversion pins, a
programming interface, a parallel data port, EEPROM and the necessary 50 Ω matched antenna
circuitry. The serial interface was especially useful because we chose to use the serial port as the means
of communication between the base station and the PC. The alternatives to serial communication were
to use USB, modem or Ethernet or Bluetooth. The advantages to these alternatives are that they all
provide a higher data rate; however they all also involve more complex circuitry. In this application, the
data rate of 256 kbps that serial communication provides is completely sufficient, given that only 2 bytes
are sent to the board for an instruction and 1 byte is returned as a response. The other alternatives
provide much higher data rates, 480 Mbps for example in the case of USB, but they all exceed the 1
Mbps link which the transceivers can communicate at, effectively limiting the overall transfer rate to 1
Mbps, if more bandwidth were required.
The Transceivers themselves provided 124 channels to use, each 1 MHz wide, starting at 2400 MHz and
ending at 2524 MHz. To decide which channel to use, starting out, we looked at what frequencies
would be most likely already in use. The primary pollutant of our frequency spectrum would be 802.11
wireless network communication. Table 2.1 shows the frequencies occupied by each channel in the
802.11 specification.
3
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
Channel
Frequency
1
2.417 GHz
2
2.422 GHz
3
2.427 GHz
4
2.432 GHz
5
2.437 GHz
6
2.442 GHz
7
2.447 GHz
8
2.452 GHz
9
2.457 GHz
10
2.462 GHz
11
2.467 GHz
Table 2.1: Channels and Frequencies used by 802.11
Given that 2.400 GHz to 2.412 GHz is left unused as well as 2.472 GHz to 2.524 GHz we were left with
64 channels to use which would be free of 802.11 communication. However, according to the product
documentation, channels above 2.483 GHz are not legally allowed to be used in the US so that limits the
second range listed to an upper bound of 2.483 GHz lowering the total number of available channels to
23. We decided to initially use 2.400 GHz and see how it performed, if it was constantly a problem, we
would try others and if we were always having trouble we would have to implement a frequency
hopping protocol which would try to find channels that were not in use dynamically.
Communication between the base station modules was designed to guarantee the reception of messages
via a simple acknowledge protocol. Essentially, the sender sends its message and waits for an
acknowledge message, it resends the same message until an acknowledge has been received or a
specified error count is reached in which case that receiver is deemed unreachable and marked as
inactive. This is used to ensure that when a command is issued, it is actually executed because in an
automation system it does the user no good to be able to issue commands which may not ever reach their
destination. The other functionality which the chip provides is an onboard CRC (Cyclic Redundancy
Check) which can correct and detect bit errors in the data, which helps to guarantee that the data
received is valid and the fact that it is built into the chip means it is faster because it is in hardware and
also reduced the amount of code which needed to be written and also stored in the EEPROM.
In order to effectively implement the communication protocol, using timeouts was necessary to detect
that another device had not received a message. The nRF24E1 provides 3 timers internally, labeled
Timer 0, Timer 1 and Timer 2. Due to the fact that the base station uses the serial port, Timers 0 and 1
are in use to clock the baud rate; therefore Timer 2 was used to generate timeouts. By setting it to count
at a rate of CLOCK/4, we were able to get 4 million counts per second. In order to convert this into a
usable quantity, we had to set a reload value which the counter would start out at. Using the formula in
Figure 2.1, we calculated the reload value of 65,136. The parameters inserted were that the clock value
was 4,000,000 and we desired a Ticks/Second of 10,000, which would give the “tick” a resolution in the
tenths of milliseconds.
4
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
CLOCK
Ticks / Second
(65536  reload )
4,000,000
10,000
(65536  reload )
reload 65,136
Figure 2.1
2.3.1 Door Module Hardware Design
The Door Module required a battery power supply, a transceiver board and proper powering of a photo
interrupter. The module combines the above mentioned voltage regulator powered by a 9V alkaline
battery and a photo interrupter. The interrupter is blocked by a physical obstruction attached to the door.
When the door is closed the interrupter is blocked and remains off while the door is closed. This design
was in effort to conserve power since this device is battery powered.
2.3.2 Door Module Software Design
The door module software design was very similar to that of the base station as the framework of the
software would be the same. One thing we did have to look at was the available IO pins on the board
and what the uses would be. The solution we picked for the base station had many IO ports and most
were available when operating the wireless and serial equipment. It was also decided that the door
module would respond only to a request for data operation as it had no output functionality and only
monitored the status of a sensor.
2.4.1 Light Module Hardware Design
The Light Module requires the same +3V power for a transceiver board, as well as the ability to digital
switch on/off a 120VAC line. A relayed was added to control the 120VAC line based on DC input. The
DC input comes directly from a transceiver I/O port. To add a dimming feature we decided to use a
TRIAC to control current flow. The gate of the TRIAC would be triggered by one of a series of relays.
Between the relays and the gate of the TRIAC would be resistors to raise the trigger voltage of the gate.
This original design was based of a simple physical design where a light bulb is toggled by a TRIAC
with the gate control coming from the 120VAC+ line. The variable control is a potentiometer between
the gate and the 120VAC+ line. The design was then modified to include a digital potentiometer.
However since 120VAC digital potentiometers are scarce and expensive we retooled the design to select
preset resistances where the potentiometer would be.
2.5.2 Light Module Software Design
The basic design for the software for the light module was identical to that of the door module. The
only change between the two would be the operations it responds to. While the door module only
responds to requests for data, the light module would respond to this as well as an instruction to either
turn the light on or off or dim the light.
5
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
2.5 User Interface Design
The User Interface was designed to provide the user with a very simple control over the home
monitoring system. Keeping this in mind, we decided to give each type of control its own tab in the user
window. All of the user interface design was strictly the result of making something that was easy to use
for an average computer user.
The real design of the user interface is the control loop that is running in the background. The user
interface software is the catalyst for all the interactions between the rest of the components. To design
this loop, we needed to specify everything that needed to be done. Specifically, the software needed to
perform any requests specified by the user, and also get the current statuses of the devices on a regular
basis. The flow chart in Appendix C shows the control loop.
The first big decision was how to handle a user’s request. Obviously, the user’s request must not be
missed by the software, so it was clear that an interrupt must be used. Java’s ActionListener class
provided a great solution for detecting user requests. The next decision was when to handle the user’s
request. There were two options: handle the user request right when the interrupt occurred, or add the
request to a queue and carry it out later.
As is the case with all interrupts, it is never known exactly when they will happen. We did not want this
interrupt to occur at the wrong time and disrupt the whole system. Considering that our system response
requirement was 1 second, and that device statuses could be received in milliseconds, we determined
that the safest approach was to use the request queue. The interrupt would occur, and the appropriate
request would be added to the queue. Then, the control loop would continue where it left off. When the
loop repeated, it would find an event in the queue and perform it at that time.
Once the control loop was completed, the software actually needed to communicate with the base station
via a serial connection. To do this, a serial protocol needed to be created. We wanted to keep the number
of bytes of communication to a minimum to help keep the system response time down. We came up
with the following format for the protocol. The user software would send 2 bytes to the base station.
Byte 1 would be the address of the device being requested, and byte 2 would be the actual request to be
carried out. After sending this, the software would wait and receive 1 byte containing the updated status
of the device. This status helps let the software know whether the action was properly carried out or not.
As with all communication, precautions need to be taken to keep the system running when a device
stops responding. The wireless protocol has its own timeouts built in. They will be further discussed
later in this report. If the wireless protocol detects a timeout in wireless communication, it will send
back an error code instead of a status code. This lets the software know that an error has occurred
elsewhere in the system and it can respond accordingly.
The other timeout is written into the software. After it sends data to the base station, it will wait for a
response. If it does not receive a response from the base station within the specified time, the software
will acknowledge that a timeout error has occurred between it and the base station, and it will move on
to its next task. Having these timeouts allows the system as a whole to continue to function while some
devices may not be functioning properly.
6
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
3. DESIGN DETAILS
3.1 Power Supply Module Design
To obtain the required voltage we used the LM317T adjustable voltage regulator which allowed us to
have input voltage up to +37V. This allowed us to take the same +3V regulator design and power it
with either a wall block 12V AC/DC converter or with a 9V battery. To control current we first chose a
12V AC/DC with built in 500mA current limiting. The 9v Alkaline Battery had maximum short circuit
current of 1.5A. The LM317T itself has short circuit current limiting and will shut down to protect the
device and load.
To obtain the near +10V needed for the VCC of the photo interrupter we directly linked the 9v battery.
The 9v battery normally outputted more than 9V, but always less than 10v. The photo interrupter
worked for all voltages between 8-10Vs. The 9V battery became a natural choice for powering both the
transceiver and the sensor. The amount of current flowing directly from the 9v through the interrupter
was a function of a resistor choice.
The 120 VAC for the light bulb and relays was taken from the wall outlet. Both the light bulb and the
relays were designed to work well with wall power variances. For example, the relays were rated up to
400V.
For all three +3V regulators resistors of values R1=220ohms and R2=330ohms were chosen to obtain
+3V. These choices were based off of availability and the Voltage output function of the LM317T:
Vout=1.25(1+R2/R1)
(1)
Vout=1.25(1+R2/R1) = 3.125V
(2)
The result from (2) fits our criteria since the boards used operate properly between +2.1V and 3.6V.
For powering the CNZ1120 photo interrupter a 9V battery was chosen since the typical VCC=+10V.
Also VCC had absolute ratings of +20V with device failure below +5V.
7
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
3.2 Base Station Design
Once the specific hardware had been selected, the only thing required for the base station was to write
the software that it would run, which would be responsible for the wireless communication and serially
communicating with the PC. This implementation followed the flow chart shown in Figure 3.1.
Wait For
Instruction
Process
Instruction
Transmit
Instruction
Return
Results
Figure 3.1: Base Station Software Flow
3.2.1 Wait For Instruction
In this section of the code, the software is waiting for data from the PC. Specifically, it is looking for 2
bytes, the first being the address of the device which the instruction is being issued to and the second
byte is the actual instruction. This is implemented through a simple call to GetChar(), which is a
blocking function call, so it does not return until it has gotten the data the program is looking for. The
method for doing this is illustrated in Figure 3.2.
char GetChar(void)
{
while(!Data_Ready_Flag)
;
Data_Ready_Flag = 0;
return Serial_Buffer;
}
Figure 3.2: Internals of GetChar
3.2.2 Process Instruction
This is the section of code which examines the data sent from the PC and determines what the base
station needs to do. For more complex operations, some calculations may need to be done here. For our
application, the instruction was examined and an appropriate action was taken via a switch statement,
8
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
specifically either a call to SendInstruction or SendRequestForData. Also in this section, a packet is
built using the message structure illustrated in Figure 3.3.
struct message
{
unsigned char address;
unsigned char operation;
};
Figure 3.3: Message Structure
3.2.3 Transmit Instruction
Once the message has been constructed and either SendInstruction or SendRequestForData has been
called, the base station starts the wireless protocol illustrated in Figures 3.4(a) and 3.4(b). First, it
transmits the instruction and starts the timer for the timeout. If the message is just an instruction, it
waits for an acknowledge message. If it times out or receives an NACK message, it resends the
message. It repeats this process up to 10 times, after which it determines that the device is unreachable
and the status to be returned is FAIL. If the message is a request for data, it sends the message and waits
for an acknowledge message, just like an instruction. However, after it receives an acknowledge
message, it then waits for data from the device. If either of these operations timeout, it returns a FAIL,
and resends up to 10 times on a NACK. If the data is successfully received, the base station sends an
ACK message to the device indicating it has received the data. If the data is not valid, it then sends a
NACK message and waits for the device to resend. Each of these internal message codes is shown in
Table 3.1.
Operation
Base ACK
Base NACK
Device ACK
Device NACK
FAIL
TIMEOUT
Code
0x20
0x21
0x30
0x31
0xEA
0x54
Table 3.1: Internal Message Codes
9
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
a.
b.
Figure 3.4: Wireless Protocols a) Instruction b) Request for Data
3.2.4 Return Results
Once the data or a failure has come back from the wireless communication operations, the results need
to be passed back to the PC from the base station. This is achieved by a call to PutChar, which takes a
byte of data as a parameter and sends it via the serial port. The PC User Interface at this point should be
waiting to receive the data. The data sent back to the PC is one of three things. First, if the operation
failed either via a timeout or continuous corruption, a FAIL code is sent back, shown in Table 3.1.
Second, if the operation being executed by the base station was an instruction, it simply sends back the
status which it changed the device to, for example if the operation was to turn on a light, the base station
returns LIGHT_ON. Finally, if the operation was a request for data, the data sent back by the device is
then passed on to the PC.
3.3 Door Module Design
The Door Module utilizes the previously mentioned regulated power supply with a 9V alkaline Battery
serving as the source. The interrupter chosen was a CNZ1120 (Panasonic) photo interrupter. This
component was chosen for its low price and simple design. The interrupter is just a photo emitting
diode lined up with a photo transistor. The transistor will turn on unless the photo stream is blocked
physically.
For powering the CNZ1120 photo interrupter a 9V battery was chosen since the typical VCC=+10V.
Also VCC had absolute ratings of +20V with device failure below +5V. The output of the interrupter gets
sent to an I/O port on the transceiver board.
To determine proper values for R3 and R4 (Appendix B.3) we first considered the properties of the
CNZ1120. The diodes forward current has maximum rating IF = 50mA. Since we know that the diode
will be receiving 3.125V: R3 > 62.5ohms. But since we would like less current and thus less power
dissipation we chose R3 = 220ohms. This makes expected current equal to 14mA. Thus the design will
10
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
survive unexpected variances in voltage. We note that since the diode is non-ideal that the current will
be even less than this since VD,ON > 0.
Next we chose R4 to meet the specification that IC < 20mA. This implies that at +9V R4 > 450ohms.
Since we know that the actual output of a 9V battery is greater than 9V, but less than 10V we assume
that VCC is +10V. With VCC =10V and IC,MAX =20mA we know that R4,MIN = 500ohms. We choose then
selected R4 = 2kohms. The larger choice for R4 prevents damage from unwanted variances. Also the
larger R4 lowers power consumption when the door is ‘open’. We know that the transceiver will only
sink the necessary current at the I/O port.
3.4 Light Module Design
The Light Module again uses the same power supply as specified above, with a 12V AC/DC as a source.
This power supply only powers the transceiver in this circuit. The I/O pins on the transceiver board
control the relays of the dimmer circuit (Appendix B.2). Since we know that the relays need +2.95VDC
to turn on we much ensure that transceiver’s I/O pins put out that much voltage on a ‘high’. Typical
output voltage = VDD. Since VDD = 3.125 no adjustments need to be made. Its important to note that
VIH,MIN = VDD-0.3v = 2.825. This leaves the possibility of malfunction due to output variance of the
transceiver. To correct this VDD must be raised, but this lowers the board’s tolerance to variances.
The dimmer circuit component of the Light Module uses 120VAC from the wall directly. This
component controls a light bulb (resistive load) via current control. Current is limited in either direction
by a BT137F Triac. The gate turns on when it receives a voltage > 5V. The gate is attached to the
120VAC line with a resistance in-between. The greater the resistance, the higher the 120VAC line has
to get in its cycle in order to make VGATE > 5V. Resistor choices R4, R5, and R6 (Appendix B.2) were
experimentally determined using a potentiometer. The potentiometer was adjusted until the light
reached an acceptable dim. From this test resistive values were chosen as: R4 = 13.4Kohms,
R5=13Kohms, and R6=12.4Kohms. These resistors had to be power rated to handle 120VAC. Since
VMAX=120V and RMIN =12.4Kohms IMAX=10mA. Thus PMAX = 1.16W. For resistor choices R4, R5, and R6
a 2W rating was chosen. Also not that IGATE,MAX = 2A. This is not a concern since with the values chosen
we expect IGATE < 10mA.
As means to select between resistors we load four relays with the 120VAC line and then take the output
to one of the resistors above. For a full brightness one relay has no resistance between it and the gate.
The relays are controlled by the above mentioned I/O pins.
3.5 User Interface
The user interface is programmed using the Java Swing GUI. This library of components was used to
create the visible interface where the user can view real time statuses of the devices, as well send
commands to the system.
The interface is actually a multi-threaded program. The program loads any necessary data from a
property file, and sets up the GUI components. Once the data is loaded, the program sends out requests
for current devices statuses. Once they are received, the program loads the main GUI for the user. At
this point, another thread is created. The main thread is responsible for keeping the GUI up to date with
current statuses, as well as listening for user input. The other thread is responsible for communicating
with the base station. This is the thread that actually implements the control loops presented in Appendix
C.
11
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
The first step in this thread is to check the event queue, which exists in the form of an ArrayList. An
ArrayList is very much like an array, but its size is dynamic, making it ideal for creating a queue. If
there are any events in the queue, the control thread will attempt to carry them out. From the queue, the
control thread will receive the device address, as well as the command of what needs to be done. Using
this information, the appropriate 2 bytes of information will be created and sent to the base station. The
device addresses and device commands that were actually implemented in our system are shown in
Table 3.2.
Device
Base
Light
Door
(a)
Address
0x00
0x01
0x02
(b)
Command
Light ON
Light OFF
Get Light Status
Get Door Status
Door Open
Door Closed
Dim Setting 0
Dim Setting 1
Dim Setting 2
Dim Setting 3
Check Dim Setting
Error Code
Code
0x00
0x01
0x02
0x10
0x11
0x12
0x40
0x41
0x42
0x43
0x4F
0xEA
Table 3.2: (a) Device Addresses (b) Command Codes and Responses
One important note about the protocol is that the same code can be used for a command or a status, in
some cases. For example, to turn a light on, the software would send the light module address, followed
by 0x00 to tell the base station to turn that light on. The base station would then reply with 0x00,
indicating that the current light status is “on”.
After all of the user requested events have been carried out, the control thread uses the serial protocol to
request updated statuses of all devices. Upon receipt of a changed status, the control thread will make a
call to the main thread and tell it to update the screen.
In order to ensure that the serial communication takes place, interrupts are used to signal when data has
been sent or received. Using Java’s SerialPortEventListener, the software can know when the data has
been sent to the base station. The loop will then begin waiting for a response from the base station.
When data is received on the serial port, a SerialPortEvent occurs and a flag is set to indicate that a
response has been received. The control loop will take the data that has been received, interpret it, and
move on to its next task.
12
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
4. DESIGN VERIFICATION
4.1 Testing
Each component of our design was designed, built, and tested independent of the rest of the system. This
was done for several reasons. First of all, especially in the case of the Power Supply Modules, we did
not want to damage other parts of the system if another part was faulty. The other reason this was done
is because we wanted this system to be as modular as possible, to allow for easy expansion. Thus, each
part of the system should operate regardless of what the rest of the system is doing.
4.1.1 Power Supply
After creating the power supplies, they were loaded with both the battery source and the 12V AC/DC
source. Both operated at a steady 3.10 volts with little variance. Through component testing and the
entirety of the project the voltage on the regulator was tested. At no point did the voltmeter ever
measure anything outside of 3.10 volts +/-.05v.
4.1.2 Sensor Testing
The sensor was attached and its output voltage was consistent and stayed at 3 volts. When the door was
opened the voltage dropped to less than 0.3 volts, usually at about 0.1 volts. The 0.1 volts fell well
below the VIL,MAX of the transceiver I/O ports. Since the sensor could never be physically toggled
quickly the response times were irrelevant to this project. No noise ever caused issue and therefore was
never checked for its exact value. The only issue arrived if the sensor was only partially obstructed.
This is fixed by proper installation of the block on the door.
4.1 3 Dimmer Testing
First the relay was tested with the power supply to see if the VDD of the power supply was enough to turn
on the relay. Once the relay worked properly the triac was tested with a potentiometer. After obtaining
a proper dim the circuit was left running for several minutes. After a short while the dim level changed
on its own. This was due to poor heat dissipation by the triac. A heat sink was added to the triac and the
triac was then retested. The second test showed stable output for at least 30 minutes. Next the
potentiometer’s resistance was measure at different levels corresponding to different dim settings. Once
these values were determined and the final circuit was constructed it was trial and error tested too. The
final circuit worked as expected though the dims were slightly different than they were in the
potentiometer setup. This was cause because the relays always allow some current to flow. This was
not accounted for in the calculations, but does not impede the overall functionality of the dimmer circuit.
4.1.4 Base Station Testing
The testing of the base station was done in conjunction with the testing of the software on the door and
light modules because much of the testing involved verifying the correct operation of the wireless
communication. The development process was broken up into 7 phases after each of which testing was
done. The first phase was to get the serial connection working. To ensure its correct operation the
board was connected to a PC and hyperterminal was used to communicate with the board. The specific
testing was just to verify that what was being sent and receive was correct. The second phase was to get
simple wireless communication working. Testing on this phase first involved ensuring that data was
being sent and received correctly, which was indicated by an LED being on or off depending on whether
data had arrived and if it was what was expected. Also tested in this phase were interference and range.
The tests were performed in close proximity with 802.11 wireless routers and also 2.4 GHz cordless
13
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
phones. The result was that there was little or no interference with these devices, indicating that a
frequency hopping protocol was unnecessary. The range was tested by moving the receiver module
around to different distances in different environments. The LED on the board would turn off if it was
out of range. Results can be found in Table 4.1. The next phase was to integrate the serial and wireless
phases to enable more complex wireless communication. Verification of this phase was accomplished
by running the same tests as phase 1, but with the wireless configuration running as well. Once this
phase was completed, we moved on to the next phase which essentially was implementing a messaging
type program in which each board was attached serially to a PC and they would send a message and then
wait to receive a response. Verification was determined by the message sent showing up in
hyperterminal on the other PC. Also, interference tests similar to those done for on phase 2 were done
after this phase was deemed operational. The fifth phase was to build a framework of the wireless
protocol that was to be driven by user input. The messages would be sent back and forth and then the
other board would choose whether to respond with ACK or NACK. This step in and of itself was a test
to ensure that the internals of the protocol were functioning properly. For example, it verified that each
device responded properly to an ACK message or a NACK message. The sixth phase was to take the
framework from phase five and remove the user input and make it autonomous. This step ensured that
the protocol would operate properly on its own. This was tested by letting it run, but having each board
output serially the messages it sent and received and verified that it was working according to the
protocol. This phase also was tested for interference with several wireless devices just as in previous
phases. The final phase was to actually attach the devices to the device module boards and link the PC
software to the base station. In addition to the interference testing, we also ensured that the devices
responded correctly to commands issued. At this phase we ran into problems with the door sensor as it
at some point after it had been verified to be working, a solder point broke and ended up putting 9V on
an IO pin which was maximum rated for 3.6V, effectively frying the board. The other issue we
discovered with this testing was an extremely slow response time. This issue was resolved by increasing
the timeout resolution in the user interface and lowering the timeout values of both the user interface and
the base station and device modules.
(a)
Distance
1 ft
10 ft
50 ft
100 ft
200 ft
500 ft
(b)
Distance
1 ft
10 ft
50 ft
100 ft
200 ft
500 ft
Result
Success
Success
Success
FAIL
FAIL
FAIL
Result
Success
Success
Success
Success
Success
FAIL
Figure 4.1: Range Tests
(a)In Everitt Lab (Cinder Block walls) (b) In an apartment (Drywall walls)
4.1.5 User Interface
Since the User Interface requires communication with the base station to properly function, a base
station simulation program was created. By running this simulator on another computer and connecting
two computers with a null modem via the serial port, the user interface could be run and tested
thoroughly. The base station simulator would receive the address and command, and reply with an
appropriate response. Thus, it would “carry out” and actions requested, and report back the current status
of any device requested. Running this with the user interface allowed us to completely test and debug
the software before it was connected to any other part of the system.
14
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
Another useful tool in the verification of the user interface was the output sent to the console. When the
user runs the program, no console is displayed so the user cannot see the text that is being output as the
program runs. However, when run in a test environment, we can see this output and use it to determine
the cause of errors in the system. As the control thread is running, it is constantly outputting what it is
currently doing. It outputs the data that it is sending right before it sends it, as well as the data received.
It also outputs how the received data is interpreted by the software. Using this output, it was very easy to
ensure that the proper data was being sent to and from the base station, and that this data was being
handled properly by the software.
Below is an example of output, created by running the user software with the base station and all other
modules powered off:
Checking Queue
Queue is empty....
Gathering system statuses...
GETTING LIGHT STATUS
1
Getting Light 0 Dim Setting
Requesting Info...
SENDING DATA: 1:79
Data Has Been Sent
Waiting For Response...
Waiting For Response...
Waiting For Response...
TIMEOUT ERROR!
As you can see, the program immediately checks the event queue and recognizes that it is empty. From
these it begins to gather the light dim settings, by sending 1:79 (which corresponds to 2 bytes: 0x01 –
Light Address, and 0x4F – Get Dim Setting). Once the data has been sent, the program begins to wait
for a response. No response is received from the base station, so a timeout error is reported. Looking at
this code, we could easily determine that there was a communication problem between the computer and
the base station.
Once the user interface ran flawlessly with the simulator, and the PIC programming was completed, the
software was tested with the base station. We tested it with different combinations of modules of being
on and off to ensure that the software appropriately handled each situation. After thorough testing, the
software was determined to be working to our satisfaction.
15
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
5. COST
5.1 Part Cost and Module Cost Breakdown
The total cost of all components obtained is listed in Appendix E.1. This cost ($730) includes unused
and unnecessary items. The next three sub sections of Appendix E (E.2,E.3, and E.4) are breakdowns
for the cost of constructing each of the three hardware modules. This breakdown is the cost of
constructing each module as it was actually created in this project.
The next three subsections of Appendix E (E.5,E.6, and E.7) breakdown the approximate cost of
implementing one of each of the three modules on a PCB. The additional component costs are listed
along with a conservative build fee estimate ($50). Note the cost of each module drops significantly
since the development boards ($200) are removed and a streamlined PCB is built instead.
Subsections E.8, E.9, and E.10 show approximations of producing the above PCB version but on a
larger scale where the estimated PCB Build fee drops from $50 to $20. On this scale of production the
Base Station and Door Module prices become reasonable however the light module remains quite
expensive. An alternate deign of the light module could include no physical dimming feature, just an
on/off feature. The estimated cost of that design is shown in section E.11 of Appendix E. This version
is much cheaper ($61 as compared to $135) but lacks the dimming feature. This could be compensated
in software with duty cycle control. Thus a cost effective version of the Light Module could be quickly
built.
5.2 Labor
Tabulated estimated hours spent on this project we get total labor cost of:
Labor Cost = (Hours/Person) * Persons * (Dollars/Hour)
70 hrs * 3 * 50$ = $10,500
Total Cost = Labor + Parts (Base, Light, Door)
10,500 + 231.63 + 217.03 + 313.27 =$11,261.90
*Total cost was derived using the three modules as we implemented them, not as possible PCB
configurations.
16
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
6. CONCLUSIONS
Overall, we are extremely pleased with the turnout of this project. First, everything we set out to
accomplish from a functionality standpoint was completed, with the only problem being the broken
solder point frying a board, thus limiting our ability to demonstrate its functionality. Second, we
successfully laid out an extremely scalable and easy to use framework in which future additions can
easily be implemented. Additional light and door modules can be added by changing one line of code in
the device software and adding only a few lines to the user interface software. New devices can also
easily be added by implementing several lines of functionality in the base station software, rewriting the
operation code in the device modules and adding only a few lines of code to the user interface, just like
adding an existing module.
For this to become a consumer use product several features need to be added or modified. First, the
range is somewhat limited, especially given the use of the large whip antenna. To make the device
modules more discrete and improve the range, the addition of a signal amplifier to boost the signal
power to larger than 0 dBm would increase the range and the use of a small ceramic antenna as opposed
to the whip antenna would make the device much more discrete, while not affecting the range all that
much. Second, issues of security must be addressed, especially if more complex devices are to be
added. A consumer would not want an outsider to be able to control devices within his home and also
would not want his neighbor’s system interfering with his own. The use of hardware encryption and
password protecting the commands would eliminate other system’s interference and also unwanted user
access, similar to the way WEP does with 802.11 wireless networks.
While the user interface worked perfectly for our demonstration application, much more functionality
would be necessary for it to be useful to an end user. More automated features for the lighting, such as a
scheduling form, would greatly improve its appeal. Also, the ability to set alarms on doors through the
software and also log the use of doors would allow the door monitoring feature to be used for security
purposes rather than just a monitor.
The applications which can be built around this framework are endless. Incorporation of video and
voice technologies would expand both the convenience and security capabilities of the system. Video
streams would allow the user to monitor what is going on in each room. Voice technologies would
allow the user to simply say what they wanted done in whatever room they were in as opposed to having
to use the computer. Also, the addition of a remote control could aid in this convenience feature. If
equipped with the wireless solution we have implemented as well as a cellular module to communicate
with a cellular module within the house, the user would be able to control all of the devices in their
home from anywhere where they receive a cell phone signal. Finally, just about any device which
utilizes electricity could be added to the system if appropriate control circuitry was designed and thanks
to the simple, scalable framework, this control circuitry can be quickly and painlessly added to the
system.
17
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
APPENDIX A – BLOCK DIAGRAMS
A.1 System Block Diagram
A.2 Base Station
18
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
A.3 Door Module
A.4 Light Module
19
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
APPENDIX B – SCHEMATICS
Figures below represent parts that make up the base station, the light module, and the door switch. The
layout of the transceiver for implementation on PCB has been included. Those images (B.4 & B.5) are
property of Nordic Semiconductor and were taken from the data sheet for the nRF24E1 and used here as
reference. The below power supply was used in some form at each of the three components. The battery
was replaced with off the shelf 12V AC/DC converter when wall power was available (Base and Light).
Figure B.1 Schematic 9v powered 3v regulated wireless power supply
Figure B.2 Schematic of the Light Switch/Dimmer Module
20
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
Figure B.3 Schematic of Door Monitoring Module
Figure B.4 Schematic of Suggested Transceiver Power Supply (Nordic)
21
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
Figure B.5 PCB suggested Schematic for transceivers (Nordic)
22
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
APPENDIX C – SOFTWARE FLOW CHARTS
Control Loop
23
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
APPENDIX D – PICTURES
Pictures of the finished modules can
Figure D.1 Transceiver Development Board
Figure D.2 Transceiver Programming Dongle
Figure D.3 Battery Power Supply and Sensor
24
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
Figure D.4 Full Light Module (1)
Figure D.5 Dimmer Circuit
25
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
APPENDIX E – PARTS AND COST
The parts and cost of the entire project are listed in E.1. This includes unused parts from
alternate/abandoned designs. Tables E.2-E.4 are price breakdowns for recreating exact designs using the
development boards used for this project. Tables E.5-E.7 are cost estimates of re-implementing this
design on a PCB. Tables E.8-E.10 are cost estimates of implementing this design on PCBs but at a large
production size. Table E.11 is a cost estimate of implanting the light switch with out the hardware
dimmer feature.
Table E.1 Total of all Parts Purchased
Part
12VDC Adapter
MFD Tantalum
PK4 Binding Posts
7805 5v Regulator
LM317T Adj. Volt. Reg.
Solder Station
TO-220 Heatsink
12.6CT1.2A UL XFM
1.5z Solder
Silicone Grease
120VACRLY
4pk 9v batteries
1/4 2x2 Oak
Photo Interrupter CNZ1120
36v 1w Zener Diode
22v 1w Zener Diode
18v 1w Zener Diode
9.1v 1w Zener Diode
5.6v 1w Zener Diode
200v 1a Rectifier Diode
24v 5w Zener Diode
12v 5w Zener Diode
10v 5w Zener Diode
4.7v 5w Zener Diode
3Amp Rectifier Diode
25K .5w Trimpot
15A 400V Triac
2.2x6.5in Breadboard
24-280VDC Solid State Relay
12K -2W Resistor
1K-2W Resistor
500K -2W Resistor
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
2kOhm-1/4w Resistor
0.1uF -35V Capacitor
1.0 uF -50V Capacitor
nRF24E1 Evaluation Board (x2)
nRF24E1 Evaluation Board (x2)
Provider
Radio Shack
Radio Shack
Radio Shack
Radio Shack
Radio Shack
Radio Shack
Radio Shack
Radio Shack
Radio Shack
Radio Shack
Radio Shack
Radio Shack
Lowes
Spark Fun
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
ECE Part Shop
ECE Part Shop
ECE Part Shop
ECE Store
ECE Store
ECE Store
ECE Store
ECE Store
Nordic Semiconductor
ECE Dept.
Quantity
4
4
1
4
8
1
1
1
1
1
1
1
2
5
1
1
1
1
1
3
3
3
3
3
3
1
1
1
5
3
3
3
10
10
10
10
10
2
1
Unit Price
16.99
1.59
3.99
1.59
2.29
22.99
1.69
8.39
3.99
1.99
8.39
10.99
3.7
1.95
0.73
0.15
0.15
0.15
0.15
0.16
0.16
0.32
0.4
0.74
0.17
0.21
6.78
6.61
18.61
0.73
0.73
0.73
0.15
0.15
0.15
0.55
0.21
Free
419
TOTAL
Table E.2 Parts and Cost for the Base Station (Development Board)
26
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
Total Cost
67.96
6.36
3.99
6.36
18.32
22.99
1.69
8.39
3.99
1.99
8.39
10.99
7.4
9.75
0.73
0.15
0.15
0.15
0.15
0.48
0.48
0.96
1.2
2.22
0.51
0.21
6.78
6.61
93.05
2.19
2.19
2.19
1.5
1.5
1.5
5.5
2.1
0
419
730.07
nRF24E1 board
12VDC Adapter
LM317T Adj. Volt. Reg.
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
1.0 uF -50V Capacitor
0.1uF -35V Capacitor
PC Board with 417 Holes
TOTAL
209.5
16.99
2.29
0.15
0.15
0.55
0.21
1.79
231.63
Table E.3 Parts and Cost for the Door Module (Development Board)
nRF24E1 board
9V battery
LM317T Adj. Volt. Reg.
Photo Interrupter CNZ1120
LM317T Adj. Volt. Reg.
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
1.0 uF -50V Capacitor
0.1uF -35V Capacitor
PC Board with 417 Holes
TOTAL
209.5
3.29
2.29
1.95
2.29
0.15
0.15
0.55
0.21
1.79
217.03
Table E.4 Parts and Cost for the Light Module (Development Board)
nRF24E1 board
9V battery
LM317T Adj. Volt. Reg.
LM317T Adj. Volt. Reg.
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
1.0 uF -50V Capacitor
0.1uF -35V Capacitor
PC Board with 417 Holes
4x24-280VDC Solid State Relay
TOTAL
209.5
3.29
2.29
2.29
0.15
0.15
0.55
0.21
1.79
93.05
313.27
Table E.5 Parts and Cost for the Base Station (PCB Estimate)
nRF24E1 transceiver chip
nRF24E1 eprom
nRF24E1 oscillator
nRF24E1 serial
nRF24E1 antenna
PCB Build Estimate
12VDC Adapter
4.5
0.96
2.3
0.95
2.95
50
16.99
27
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
LM317T Adj. Volt. Reg.
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
1.0 uF -50V Capacitor
0.1uF -35V Capacitor
PC Board with 417 Holes
TOTAL
2.29
0.15
0.15
0.55
0.21
1.79
83.79
Table E.6 Parts and Cost for the Door Module (PCB Estimate)
nRF24E1 transceiver chip
nRF24E1 eprom
nRF24E1 oscillator
nRF24E1 serial
nRF24E1 antenna
PCB Build Estimate
9V battery
LM317T Adj. Volt. Reg.
Photo Interrupter CNZ1120
LM317T Adj. Volt. Reg.
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
1.0 uF -50V Capacitor
0.1uF -35V Capacitor
PC Board with 417 Holes
TOTAL
4.5
0.96
2.3
0.95
2.95
50
3.29
2.29
1.95
2.29
0.15
0.15
0.55
0.21
1.79
74.33
Table E.7 Parts and Cost for Light Module (PCB Estimate)
nRF24E1 transceiver chip
nRF24E1 eprom
nRF24E1 oscillator
nRF24E1 serial
nRF24E1 antenna
PCB Build Estimate
9V battery
LM317T Adj. Volt. Reg.
LM317T Adj. Volt. Reg.
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
1.0 uF -50V Capacitor
0.1uF -35V Capacitor
PC Board with 417 Holes
4x40-280VDC Solid State Relay
TOTAL
4.5
0.96
2.3
0.95
2.95
50
3.29
2.29
2.29
0.15
0.15
0.55
0.21
1.79
93.05
165.43
Table E.8 Cost Estimate for the Base Station (PCB Mass Production)
nRF24E1 transceiver chip
nRF24E1 eprom
nRF24E1 oscillator
4.5
0.96
2.3
28
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
nRF24E1 serial
nRF24E1 antenna
PCB Build Estimate
12VDC Adapter
LM317T Adj. Volt. Reg.
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
1.0 uF -50V Capacitor
0.1uF -35V Capacitor
PC Board with 417 Holes
TOTAL
0.95
2.95
20
16.99
2.29
0.15
0.15
0.55
0.21
1.79
53.79
Table E.9 Cost Estimate for the Door Module (PCB Mass Production)
nRF24E1 transceiver chip
nRF24E1 eprom
nRF24E1 oscillator
nRF24E1 serial
nRF24E1 antenna
PCB Build Estimate
9V battery
LM317T Adj. Volt. Reg.
Photo Interrupter CNZ1120
LM317T Adj. Volt. Reg.
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
1.0 uF -50V Capacitor
0.1uF -35V Capacitor
PC Board with 417 Holes
TOTAL
4.5
0.96
2.3
0.95
2.95
20
3.29
2.29
1.95
2.29
0.15
0.15
0.55
0.21
1.79
44.33
Table E.10 Cost Estimate for the Light Module (PCB Mass Production)
nRF24E1 transceiver chip
nRF24E1 eprom
nRF24E1 oscillator
nRF24E1 serial
4.5
0.96
2.3
0.95
29
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
nRF24E1 antenna
PCB Build Estimate
9V battery
LM317T Adj. Volt. Reg.
LM317T Adj. Volt. Reg.
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
1.0 uF -50V Capacitor
0.1uF -35V Capacitor
PC Board with 417 Holes
4x40-280VDC Solid State Relay
TOTAL
2.95
20
3.29
2.29
2.29
0.15
0.15
0.55
0.21
1.79
93.05
135.43
Table E.11 Cost Estimate for the Light Module (PCB Mass Production)
Without full dimmer and using only one Relay
nRF24E1 transceiver chip
nRF24E1 eprom
nRF24E1 oscillator
nRF24E1 serial
nRF24E1 antenna
PCB Build Estimate
9V battery
LM317T Adj. Volt. Reg.
LM317T Adj. Volt. Reg.
220Ohm-1/4W Resistor
330Ohm-1/4W Resistor
1.0 uF -50V Capacitor
0.1uF -35V Capacitor
PC Board with 417 Holes
40-280VDC Solid State Relay
TOTAL
4.5
0.96
2.3
0.95
2.95
20
3.29
2.29
2.29
0.15
0.15
0.55
0.21
1.79
18.61
60.99
REFERENCES
[1]
February 2006, http-://www.residentialarchitect.com.
[2]
Nordic Semiconductor. Datasheets, code samples, schematics. http://nordicsemiconductor.com.
30
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)
31
Document shared on www.docsity.com
Downloaded by: endryas-zewdu-1 (endriyas00@gmail.com)