Docstoc

Remote Door Lock Project

Document Sample
Remote Door Lock Project Powered By Docstoc
					  Remote Door Lock Project
                                     Final Report
                                           Scott Velivis
                                           Rob Lee-Own
                                            Max Sobell
                                            Vincent Lin
                                             5/9/2010




I pledge my Honor that I have abided by the Stevens Honor System
Contents
Table of Figures .............................................................................................. Error! Bookmark not defined.
Introduction .................................................................................................................................................. 3
Technical Information ................................................................................................................................... 4
   Functional Description: ............................................................................................................................. 4
       Overview: .............................................................................................................................................. 4
       SMS/MMS ............................................................................................................................................. 5
       Hardware Detail: ................................................................................................................................... 6
       Use Cases: ............................................................................................................................................. 7
       Case 1: Unknown User Requesting Access .......................................................................................... 7
       Case 2: Client Directly Controls Access .................................................................................................. 7
   Technical Description: ............................................................................................................................... 7
       Server: ................................................................................................................................................... 7
       SMS/MMS: .......................................................................................................................................... 10
       Door Lock Circuit ................................................................................................................................. 11
       Software Implementation - Microcontroller: ..................................................................................... 14
       ZigBee .................................................................................................................................................. 15
       Security ............................................................................................................................................... 16
   Performance Expectations ...................................................................................................................... 16
   Future Planning: ...................................................................................................................................... 17
Critical Evaluation ....................................................................................................................................... 18
   The Good:................................................................................................................................................ 18
   The Bad: .................................................................................................................................................. 18
   The Fun: .................................................................................................................................................. 18
   The Funding: ........................................................................................................................................... 19
Summary ..................................................................................................................................................... 20
Vita .............................................................................................................................................................. 21
   Scott Velivis ............................................................................................................................................. 21
   Rob Lee-Own ........................................................................................................................................... 21
   Max Sobell............................................................................................................................................... 22
   Vincent Lin .............................................................................................................................................. 23



                                                                                                                                                                    1
Figure 1 Functional Server Software Overview ............................................................................................ 4
Figure 2- Door Circuit Functional Diagram ................................................................................................... 6
Figure 3 - Use Case 1 ..................................................................................................................................... 7
Figure 4 - Use Case 2 ..................................................................................................................................... 7
Figure 5- Server Software Flowchart ............................................................................................................ 9
Figure 6- SMS Overview .............................................................................................................................. 10
Figure 7- Door Lock Circuit .......................................................................................................................... 11
FIgure 8- Arduino Pro .................................................................................................................................. 12
Figure 9 - XBee Module and Shield ........................................................................................................... 122
Figure 10 - Electric Strike Plate ................................................................................................................... 13
Figure 11- Microprocessor Software Flowchart ......................................................................................... 14
Figure 12 - Component Price Breakdown ................................................................................................... 19




                                                                                                                                                           2
Introduction
Home automation is a rapidly growing field in the U.S. After hearing about the smart home throughout
the late nineties and the beginning of the 2000s products are finally appearing on the market. The
remote door lock project is designed to give users an easy to use, highly accessible and affordable
solution to one aspect of home automation, namely unlocking and locking the front door to the user’s
residence remotely.

 The most comprehensive system on the market is currently the Schlage LiNK1 system. This includes the
ability to remotely turn off the lights, appliances and remotely lock and unlock the client’s front door. To
access these features the user can use a web portal or an iPhone application. However enabling these
features costs the user a monthly fee, currently priced $12.99 per month. More services than ever are
turning to the subscription model. Currently people pay monthly tv, internet, cell phone, home phone,
Netflix, Xbox Live, home security system, credit monitoring, and Game Fly just to name a few of them.
Consumers will feel burdened by increased monthly fees, leading them to eliminate some services. Our
produce purposefully avoids the monthly feed model; we hope this will lead to larger market share.

Another downside to the current model building applications for smartphones is that most Americans
still do not own a smartphone, let alone an iPhone to be specific. Currently 17% of American’s with a cell
phone own a smartphone2 and 33% of adults own a smartphone. In the U.S. 90% of American’s own a
cell phone3 leaving a large number of Americans who want to manage their door locks needing to invest
in a cell phone. There are no more AMPS cell phone providers anymore. All of the carriers use a 2G or
higher digital cell phone system. This means that any of these cell phones are capable of receiving text
messages and most can receive multimedia messages as well. Therefore the team has decided to focus
on developing a system that uses text message (SMS) and picture messages (MMS) for communication
rather than mobile web or a dedicated smartphone application.

The remote door lock project is designed to help the client in two ways. The first is to check the status of
the lock to make sure the user locked the door when they are away and to allow them remotely lock and
unlock the door for them to enter the house. The second feature happens when someone rings the
client’s doorbell. At this point a camera will take the person’s picture and send a picture message to the
client’s cell phone. The client will then reply to the picture message with a text message to allow or deny
them access.

The system is comprised of several components. The first component is the server. The server is small
computer, not much bigger than an ac-dc power converter, plugged into a wall within 100ft of the front


1
  http://link.schlage.com/Pages/home.aspx
2
  http://blogs.forrester.com/consumer_product_strategy/2010/01/2009-year-of-the-smartphone-kinda.html
3
  http://news.cnet.com/8301-30686_3-20004142-266.html

                                                                                                           3
door. Next is the door locking mechanism that is installed on the door frame. This is connected to a
microcontroller that wirelessly connects to the server. The doorbell is also connected to this
microcontroller to allow it to notify the user when someone is at the door. The final component is the
WiFi enabled camera that communicates with the server and sends pictures when requested.


Technical Information

Functional Description:
Overview:
                                            daemon                                                lock
         The group has a server running a daemon which interacts with a microcontroller, door lock, a
         ,                               server.
doorbell, and a camera attached to the server. The microcontroller regulates voltages and signals to and
                                                    server-readable messages. All of this interacts with
from all components and translates the signals into server                                in
the client who is using a cell phone with SMS and MMS messages.

Software




Figure 1 Functional Server Software Overview


                                                                                                      4
The server will be running a software program that can communicate with the microcontroller, the
camera, and to the internet. The program will communicate to the microcontroller using a ZigBee
wireless module. The software will send requests to lock and unlock the door. The program will also
send SMS and MMS picture messages to the client’s cell phone. The server will communicate with an
API that formats the data correctly to send the message. The final piece of the software application will
be to request pictures from the wireless camera. The server will be WiFI enabled and connected to the
client’s home WiFi network.

The microprocessor will trigger a ring() function that will alert the server that a unlock/lock request is in
progress. The microprocessor will then wait for the server to communicate with the client for the
appropriate decision. The client can send two functions to the server: lock() and unlock(). Lock is the
default state and unlock can be activated temporarily to allow passage.

The team has decided to use a plug computer. Plug computers are extremely small and efficient
computers that are about the size of a wall wart transformer. The name used for these plug computers
are SheevaPlugs. We will be using an IconicsPlug version of this computer, however the names are
interchangeable for the purposes of this paper.


SMS/MMS
To use SMS/MMS to communicate with our system, we need two way communications. It is easy to
send email from the server to the client's mobile device using the user’s phone number and the
addresses below:

          ##########@txt.att.net (ATT/Cingular Wireless)
          ##########@vtext.com (Verizon Wireless)
          ##########@tmomail.net (T-Mobile)
          ##########@messaging.sprintpcs.com (Sprint PCS)
          ##########@vmobl.com (Virgin Mobile)
          ##########@email.uscc.net (US Cellular)
          ##########@messaging.nextel.com (Nextel)
          ##########@myboostmobile.com (Boost Mobile)
          ##########@message.alltel.com (Alltel Wireless)
To communicate from client to server, however, is more challenging. Using a dedicated mail server
(which could easily be included on our SheevaPlug server), we could use incoming email to trigger an
event. The workflow is as such:

      1. Person 1 rings the "doorbell", which triggers a message to be sent to the user's mobile device
         using the method above.
      2. The user elects to allow or deny access by sending a text message back to the server's email
         address
      3. The return message is filtered and parsed using the .forward file built into Linux mail systems4.


4
    http://evolt.org/incoming_mail_and_php?from=50&comments_per_page=50

                                                                                                             5
Hardware Detail:




                                   Figure 2- Door Circuit Functional Diagram

        The remote door lock project requires a microcontroller to communicate between the server
and the door lock components. The microcontroller receives two different commands from the server.
These commands are unlock and lock. After a command is executed an acknowledgement message will
be sent back to the server. The other functionality of the microcontroller is to receive a signal from the
doorbell when it is pressed. The microcontroller sends a message to the server that the doorbell was
pressed. The status LED is red while the door is locked; after the doorbell is pressed and pending a
response from the owner the LED status turns to yellow. If the person requesting access is granted
access to the residence and the door becomes unlocked the LED will turn green (along with the sound of
the lock clicking).

                                                                                                        6
Use Cases:

Case 1: Unknown User Requesting Access




Figure 3 - Use Case 1



In the case of an unknown user requesting access, the user activates the doorbell, causing the system to
notify the client through the server and provide a photo of the person requesting access. The client can
allow or deny access. The user is given acknowledgement through the status LEDs and the client is given
acknowledgement through a notification.



Case 2: Client Directly Controls Access




Figure 4 - Use Case 2

In the case of the client directly controlling access, the client notifies the server to send the appropriate
lock or unlock command to the microprocessor. The client is given acknowledgement that the
lock/unlock has occurred through both the status LEDs and a notification sent to the client.



Technical Description:


Server:
         The team decided to use the IonicsPlug Stratus computer. The Stratus model is a full-featured
ultra-compact wall wart server. The IconicsPlug Stratus is one of many “plug computers” or
“sheevaplugs” that are growing in popularity for applications such as this. These plug computers
contain fairly powerful processors, onboard RAM and several connectivity options all in a very small
form factor that can be plugged directly into an AC wall socket like a wall wart. The reason the group
chose the Stratus model is because of its built in ZigBee module. Other options for connectivity include
Wifi , USB2.0 and Bluetooth. Since the group had decided on the use of ZigBee for wireless
communications between the server and the microprocessor, this model was chosen. Along with the
ZigBee module, this model also has a 1.2 GHz Marvell processor (a 2.0 GHz version will be available

                                                                                                           7
soon, perhaps before implementation of this project), 512 MB DDR2 RAM running at a clock speed of
400 MHz and 512 MB NAND Flash memory. The Stratus can also interface with other devices using WiFi
or Bluetooth. The ZigBee module will communicate with the microcontroller and the camera using the
Wi-Fi connection. It is extremely efficient: its average power consumption is 5-6W5.




5
    http://www.ionicsplug.com/stratus.html


                                                                                                     8
             Start                            Receive “ring”




                                         Execute C program to get
                                          still frame from stream



                                          Retrieve image
                                          from MJPEG
                                          stream



                                          Send image to client via
                                                  MMS
              Client directly                                                   Client directly
              sends unlock                                                        sends lock
                  request                 Client decides to confirm                 request
                                                   or deny




                                                  Receive
                                                 confirm or
                                                 deny from
                                                   client




                  Send unlock                                                     Send lock




Figure 5 - Server Software Flow Chart

The previous flowchart describes the software that will be running on the server. The ringing of the
doorbell causes the microcontroller to send a message to the server. Once that is received, the server
(running a linux OS) processes this, and then executes a program in C that makes use of an MJPEG codec
to take a still frame from the activated video stream to act as the picture (as a JPEG image). The server


                                                                                                        9
then proceeds to send an MMS message containing the captured photo to the client’s mobile phone.
Once the message is received, the client views the image (sent from the server via MMS) and returns
either yes (unlock) or no (lock). Once the return message is received, the door is then locked/unlocked
based upon the response. The client can also unlock or lock the door directly without a prompt from the
server by sending the server a message to unlock or lock the door.



SMS/MMS:
The SMS (Short Message Service) standard is built into all modern cellular phones. A single SMS message
can be up to 160 characters and a full 160 character message takes up as much bandwidth as a 1 second
voice call6. The MMS (Multimedia Messaging Service) is a standard of the Open Mobile Alliance extends
the core functionality of SMS to allow sending of picture messages7. This standard could possibly replace
part of the TCP/IP transport system in our design. Using the SMS/MMS standard would allow a picture
to be taken with the camera, send to a SMS server via TCP/IP and the transported to the user's mobile
phone via the cell network. SMS/MMS can be sent and received simultaneously with GSM voice and
data calls because the SMS/MMS message uses the “signaling path” to travel above the radio signal [5].
The GSM SMS standard also includes SMS contcatenation which is useful for sending and receiving
messages over 160 characters8. The user could then respond with a command to open the door or
ignore the request.




Figure 6 - SMS Overview




6
    http://ewh.ieee.org/r10/bombay/news6/SMSAndMMS/SMS.htm
7
    http://mbuni.org/userguide.shtml#Section_.1.1.1
8
    http://ewh.ieee.org/r10/bombay/news6/SMSAndMMS/SMS.htm

                                                                                                      10
Door Lock Circuit
The door lock circuit is a fairly simple implementation. The team decided on using a Arduino Pro
development board. The Arduino series of boards are very popular with electronic enthusiasts because
of their low cost, high flexibility and performance, and large community of developers willing to help out
others learning. The Arduino Pro board has an Amtel ATmega328 microprocessor on board. This
processor will communicate with all of the other components in the circuit. One of the inputs to the
microprocessor is a door bell. The doorbell can be configured to be normally high or normally low,
whatever is already installed in the clients house the program can adapt for. An output of the
microcontroller goes to the door lock. The output from the Amtel cannot unlock the door by itself.
Applying a voltage to the chosen power supply will unlock the lock device. The final outputs of the
microprocessor go to three status LEDs. These change depending on the status of the program.




                               Xbee Module




                        Vcc       Gnd     Rx Tx



                                                          Locked
                                                        Decision pending
                               ATmega328                  Unlocked




                                                          Lock Signal               Door Lock



                         Vcc
                                                                             Lock Power



                                    Gnd
                                                                        +16VAC
                +5VDC




                                             Figure 7 - Door Lock Circuit


                                                                                                       11
The microprocessor must also communicate with the SheevaPlug server. In order to increase the
versatility of the project the team decided to use a wireless communication method. ZigBee was
determined to be the best protocol for the performance desired. Other popular methods of wireless
connectivity such as Bluetooth or Wi-Fi were considered too robust and power hungry for this system.
High speed communication that these protocols offer are not required for this application and could also
further complicate the design of the system. A further explanation of the ZigBee protocol is given later.
In addition to the previous advantages of choosing the Arduino board there was another major gain. The
XBee Shield and XBee Module are both made specifically for the Arduino boards. The XBee Module is a
low cost and low power solution9. The XBee Shield is designed to fit on top of the Arduino board. This
saves space and requires no hardware development to add ZigBee communications.




                                                            Figure 5 - XBee Module and Shield


Figure 8 - Arduino Pro




While there are a few different types of automatic locks available, the team decided to go with an
electric strike plate style. Electric strike plate locks do not require that the user’s locks on the actual door
be replaced. Instead only the striker plate (metal plate with indentation to allow deadbolt or door lock
into) is replaced. To use the lock the tenant locks their door so that the door knob does not turn. When
a voltage is applied to the electric strike plate then hinge unlocks so the tenant can push or pull their
door to open it. The hinge then locks again after about 5 seconds. The lock can come in two versions,
normally open (NO) or normally closed (NC). The team will opt for the NC version. This means that 0VAC
across it keep the door locked. An advantage to this method is that the door stays locked during a power
outage. However the tenant can still access their residence by simply using their key to unlock the door
handle and open the door as normal.


9
    http://www.digi.com/products/wireless/point-multipoint/xbee-series1-module.jsp#overview

                                                                                                             12
The team decided to go with the Electric Door Strike 8-16vac10. This lock pairs with the Hardwired 16VAC
Power Supply for Electric Door Strikes11 power supply. This power supply is a simple transformer that
activates to unlock the door; it receives its signal to unlock from the Amtel microprocessor. This power
supply is placed in the wall and is hard wired into a 120VAC circuit in the home.




                                        Figure 6 - Electric Strike Plate

To power the Arduino board 5V DC is required. A DC-DC power supply is used in this case. The
ECL05US0512 from XP Power will meet the design specifications. The power supply can take an input
from 85-264VAC and output a steady 5VDC. The power supply measures 2” x 1” x 0.910” which means
that it will easily fit into the wall and can run off the same taps from the 16VAC door lock power supply.

The team decided on the TRENDnet ProView Wireless Internet Camera to go with this project13. Only a
still image is needed from this camera however it is capable of video capture. This could be useful for
future expansions of the project discussed later. The images are 640 x 480 which allows a quick
download to the server and a small enough image appropriate for cell phone screens. The camera
communicates over 802.11b/g to the SheevaPlug server. Most tenants already are using WiFi which
simplifies the setup process. However if the user does not have a WiFi network already the server and
camera can be set up in an ad-hoc network style to communicate directly. The team originally thought
to have the microprocessor control the camera directly, however it was decided that this may require
more processing power to encrypt and compress than the Amtel has available.


10
   http://www.smarthome.com/5190/Electric-Door-Strike-8-16VAC-220/p.aspx
11
   http://www.smarthome.com/5191/16VAC-10VA-Power-Supply-323-M/p.aspx
12
   http://www.xppower.com/pdfs/SF_ECL05-25.pdf
13
   http://www.trendnet.com/products/proddetail.asp?prod=150_TV-IP100W-N

                                                                                                       13
Software Implementation - Microcontroller:




                                Figure 11 - Microprocessor Software Flow Chart

There will be some very low-level software running on the microcontroller that will operate the basic
functions of the door. The program will wait for a doorbell ring as a digital input to the Arduino board,


                                                                                                      14
and then report the ring to the server over the ZigBee data connection. The status LEDs will be updated
to the ‘Waiting’ status (Yellow) and the program will wait for feedback from the server through the
ZigBee data connection. If the remote user denies access to the local user, the status LEDs will be
returned to ‘Locked’ and the program will wait for another doorbell ring. If the user allows access, the
unlock signal is sent in the form of an analog voltage output that controls the flow of power between
the 12 VDC Power Supply and the electric strike plate. This will grant the user access so the status LEDs
will be updated to ‘Enter’ (Green) for five seconds until the strike plate is locked again. At this point the
program waits for another doorbell ring.



ZigBee
The team decided to use ZigBee as the means of communication between the door lock microprocessor
and the server. ZigBee is a low data rate wireless personal area network (WPAN) that is built on top of
the IEEE802.15.4 standard. One of the mission statements by the ZigBee alliance is for the protocol to
assist in home automation. The remote door lock project falls into that category.

The ZigBee protocol can operate in the 2.4 GHz or 900 Mhz frequency band. The 900 MHz band
provides less interference than the 2.4 GHz band. However ZigBee will work even while there is a Wi-Fi
network in the same area14. ZigBee modules that operate in the 2.4 Ghz band have a raw data rate of
250 kb/s. While this data rate is much lower than the > 54Mb/s that Wi-Fi currently offers, it is more
than enough for transmitting a few bytes at a time to and from the server.

Wireless security is a very important issue. When dealing with a device that allows access to a user’s
home security must be extremely strong. Zigbee uses AES-128 encryption algorithms which the security
community believes will be very hard to break for the next couple of decades15. The team does not
believe there is a security threat to undermine the use of ZigBee in this project.

A ZigBee network uses very little power. The ZigBee protocol allows modules to enter a sleep mode
when they are not in use. Even though the device is hard wired into the houses electrical grid, it is still
advantageous to operate with the least amount of power needed. The power saving techniques that
could be employed would allow the ZigBee module to operate on only a few mW per hour16.

Finally ZigBee is a low cost solution. The technology is only a couple of years old however modules can
already be purchased for under $20. This price will come down with time and as the quantity purchased
rises. This is in contrast to Wi-Fi and Bluetooth which has a much higher power consumption and
module cost.




14
     http://www.zigbee.org/imwp/idms/popups/pop_download.asp?contentID=13184
15

http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=&arnumber=5385074&queryText%3Dzigbee+security%26op
enedRefinements%3D*%26searchField%3DSearch+All
16
   http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04147055

                                                                                                          15
Security
The remote door lock project deals with the locking of the entrance in the user’s residence. Naturally
the project must be well secured from outsiders trying to see authorized access. As mentioned before a
power failure will not unlock the door unless the user has their key to unlock the door knob. ZigBee uses
AES-128 encryption. This will prevent anyone from outside the residence from cracking the code. The
server and the door lock circuit will be uniquely paired together. Another concern would be the
connection between the camera and the server. If the two devices are in an adhoc network they will
default to use WPA2 which is currently the strongest encryption available for Wi-Fi networks.

The biggest security flaw to this system is the human element. If a user loses his or her phone it is
imperative that they deactivate the phone as soon as possible. In order to make this system convenient
there is currently no plans to implement a pass code into the SMS message to unlock the door. However
if the phone falls into the wrong hands someone could conceivable enter the residence, the same as if
the user lost their keys and the finder knows where they live.

Performance Expectations
The overall remote door lock system can be broken down into two performance components. One is the
performance of the system in the home. The other is the performance of the system using
communication methods such as SMS and MMS.

The XBee ZigBee module is in the door lock circuit and communicates to the built ZigBee module of the
Stratus SheevaPlug. As of this time detailed specs of the SheevaPlug ZigBee module are not available,
however that is expected to change within the next month or two. The performance of the XBee module
should be fairly similar so it will be assumed they are the same for the performance evaluation.

The XBee module operates on the 2.4Ghz unlicensed band. Many other devices also operate on this
frequency such as microwaves, WiFi, Bluetooth and some cordless phones. This is not expected to be a
problem because the ZigBee protocol was designed to operate with interference from the
aforementioned devices17 18. The module can transmit at up to 1mW (0dBm) of power. This will allow
for data transmission of up to 100 ft indoors. The SheevaPlug therefore has to be within this range to
function properly. The receiver can operate at a 1% packet error rate with a receiver sensitivity of -
92dBm. The module uses less than 10μA during sleep mode and has a wakeup delay out of sleep mode
of only 200μs19. From when a doorbell is pushed till the server is notified should be about 1 second, if
not less. This time period will be negligible compared to the time it takes the average user to respond to
a text message.

The ATmega328 can operate up to 20Mhz however it is believed after testing that they speed should be
able to be scaled back significantly to conserve power. Most of the software features will be interrupt

17
     http://www.zigbee.org/imwp/idms/popups/pop_download.asp?contentID=11745
18
     http://www.zigbee.org/imwp/idms/popups/pop_download.asp?contentID=13184
19

http://www.google.com/url?sa=t&source=web&ct=res&cd=4&ved=0CCQQFjAD&url=http%3A%2F%2Fbwrc.eecs.b
erkeley.edu%2FSeminars%2FSeminars_Archive%2FBahl-
10.25.02%2FZigBee.ppt&ei=YorlS7K9IIH58AadppCrBA&usg=AFQjCNEA7EGCcg2CT3ZKfpZ7f4hEqA0-Yw

                                                                                                       16
based so an extremely fast polling routine is not required. The doorbell will be a hardware interrupt and
UART communication with the SheevaPlug should act as a serial interrupt. Power consumption should
not be higher than 0.2mA at 1Mhz and only 0.1μA during a power-save mode. Even with the clock speed
an order of magnitude higher the power consumption levels will still be acceptable. The main goal here
is to reduce energy consumption to save the user money, instead of design the system with no regards
to power.

The other area of performance of the system is using an external service to send SMS and MMS
messages over the internet. During Use Case 1 mentioned earlier someone rings the doorbell and the
notification is sent to the server. The server downloads the picture and formats it into an MMS message.
This message is sent to the tenant and then the tenant replies with an SMS message back. If there is a
big delay between these messages then this could irritate the person wanting access to the residence. If
the delay between these events is too great then the system will become unusable. If using the phone
number-email service described earlier in the paper is not sufficient then exploring the idea of a
dedicated 5 or 6 digit short code would be worthwhile. This would assure prompt delivery to the user,
however at the cost of $1000.00 a month, a viable business plan would need to be developed before
considering this option.

Future Planning:
When the team first decided on working on this project it was conceived that the lock would be
controlled by an iPhone application. However not long after the project got started the team saw an
advertisement for a home automation solution that can control the front door by an iPhone app. This is
the Schlage LiNK system20. The team then looked into this solution and discovered it is only controllable
through a web browser or an iPhone. The group decided to give functionality to all through the
SMS/MMS solution. However after the initial development is complete then extras such as an iPhone,
Android and Blackberry app can be created.

 Using the iPhone's push notification system a user can be alerted to a person at the front door.
Unlocking the device will open the application and display the unknown person’s photo from the
camera. This can be done over TCP/IP instead of SMS/MMS. A dedicated application can also give a log
of locks and unlocks, current status of the locks and a video feed from the camera. The group has left
this functionality in the hardware design of the project and it can be added by implementing additional
software features. Both the IconicsPlug computer and the microcontroller will have plenty of resources
left. The microcontroller is also capable of being programmed wirelessly through ZigBee. This could
allow future firmware updates to be pushed to the server and then the microprocessor.




20
     http://link.schlage.com/Pages/home.aspx

                                                                                                       17
Critical Evaluation

The Good:
There are many aspects to the remote door lock project that the team believes will be easy to
implement. The software on the microcontroller is very simple and should not be a problem to
implement. Also the development using the Arduino Pro board should be very straightforward with
ample documentation and tutorials online21.

Programming the serial UART ZigBee connection should be fairly simple as well. There are already
developed libraries that will translate any serial communication into the appropriate ZigBee protocol
format. The XBee shield requires no extra modifications to fit right over the Arduino board and the
SheevaPlug will have its ZigBee module built into the enclosure.

The Bad:
The most worrying aspect of the project is the delay time in sending and receiving the SMS and MMS
messages. While the system the team has chosen is proven to work and is supported by almost all the
wireless carriers in the United States these messages may experience significant delay. The first cause of
this could be simple network congestion. In highly populated urban areas network traffic is always very
high. Much has been made recently of AT&T's poor New York City and San Francisco coverage. While
most carriers are continually improving their network, SMS and MMS messages can never be
guaranteed to arrive by a certain time. Another cause of delay is that these external messages are most
likely much lower priority for carriers to send. Finally sending messages across multiple networks, i.e.
Verizon to AT&T may have a delay. It is not certain where the delay occurs because both carriers blame
the other's network for the problem.

The Fun:
The current team is divided evenly between people enthusiastic about hardware and those who like to
focus more on software. Vincent Lin and Max Sobell are more focused on the software side of the
project. They both have a lot of experience programming in the Linux OS. This is advantageous because
they have the experience needed to create a working program that has all of the features needed. Rob
Lee-Own and Scott Velivis both enjoy working on the hardware design and development of the system.
Both have done other academic and hobby projects involving microcontrollers and both have worked
for various engineering firms throughout their time at Stevens Institute of Technology. Rob also has
experience in programming microcontrollers which will allow him to make great progress on the door
circuit software.

Also all of the team members have gotten behind the project from the start. There were multiple
brainstorming meetings that were discussed on how to make this project better than any existing
products on the market. Questions were ask on how to make the device simple, inexpensive, low power
and subscription free. All believe that this system can be completed given the information we have
researched and our various expertise.

21
     http://www.arduino.cc/en/Tutorial/HomePage

                                                                                                       18
The Funding:
The remote door lock project is a fairly inexpensive system. The Arduino Pro board can be found for
under $2022. The XBee ZigBee wireless communications module can be found between $20-$2523. The
XBee Shield without the module costs about $2524. The AC-DC power supply for the Arduino board is
approximately $20. The SheevaPlug Stratus computer should be between $100-$150. This is the model
with built in ZigBee communications. Current SheevaPlug development kits start at $9925. The power
supply is currently $8.37 for the Electric Strike Plate door lock and the lock itself is $23.60. A simple
housing with 3 different color LED's can be made or bought for under $5. Finally the security camera
costs about $15026. The total price of the components is summed together below.

                          Component                    Price (Approximate)
                          Arduino Pro                  $               20.00
                          XBee Module                  $               23.00
                          XBee Shield                  $               25.00
                          AC-DC Power Supply           $               20.00
                          Electric Strike Lock         $               23.60
                          AC-AC Power Supply           $                8.37
                          SheevaPlug Stratus           $               99.00
                          Wi-Fi Camera                 $              150.00
                          Total                        $              368.97
Figure 7 - Component Price Breakdown

With an ECE department team budge of $250.00 this leaves about $120.00 for the team to secure for
the funding of the project. All four team members are willing to contribute at least $50 to the project
individually for any additional expenses occurred. The team is also considering outside funding sources.
Contacting certain companies such as Master Lock, American Lock Company and other lock
manufacturers that do not yet have a home automation package available might be willing to sponsor
the project. Additionally other companies not in the home automation business but have interest or
infrastructure to do so can be contacted. These include cell phone carriers, home phone companies,
cable companies and more that may want to integrate a product such as this into their array of services.




22
     http://www.trossenrobotics.com/store/p/5931-Arduino-Pro-328-5V-16MHz.aspx?feed=Froogle
23

http://www.adafruit.com/index.php?main_page=product_info&products_id=128&zenid=0b436ac2f90fc4806b901
5d0ec2f9bbf
24

http://www.solarbotics.com/products/51835/?utm_source=Google&utm_medium=Product+Search&utm_campai
gn=Product+Search+%28May10%29
25
   http://www.globalscaletechnologies.com/c-2-globalscale-technologies-products.aspx
26
   http://www.trendnet.com/products/proddetail.asp?prod=150_TV-IP100W-N

                                                                                                      19
Summary
The remote door lock project is an idea that the team believes they will be able to come into fruition if
developed further next year. The group also believes that there is a lot of potential for the project to set
it apart from other devices on the market. However more research must be done in to other companies’
intellectual property. If every idea the team wants to implement is already patented then the project
may take a different direction. As mentioned previously, the one idea that the team believes is fairly
novel and a non-obvious change over the other systems is the communication via SMS/MMS between
the remote user and the system in the home. All other implementations have been over web-based
applications that are brought only to the mobile phone through mobile access of the internet. The
Remote Door Lock project proposed by the team is designed to be used by all [digital] mobile phones
including non-smart phones.

The team believes this project to be attainable since all of the technology involved is currently available
and merely needs to be interfaced and closely integrated using methods that are already popular and
that the team is already familiar with. There will be plenty of work to keep the team busy including both
high and low level software to write and circuits to develop but the strength of this project is the
strength of the idea rather than the novelty of technology. All of the team members look forward to
developing this project next year or at least working in similar areas for Senior Design.




                                                                                                         20
Vita
Scott Velivis
Scott Velivis is a fourth year undergraduate at Stevens Institute of Technology. He is enrolled in the
cooperative education program and will be graduating in May 2011 with his bachelor’s of engineering.
Scot is also starting to pursue his master’s degree in electrical engineering concentrating in wireless
communications.

On campus Scott has been a member of multiple clubs and organizations. He has been a member of
CSA, IEEE, C2GS and is an avid bowler in the Bowling Club. He was also vice president of Stevens Silk
Screener and will become the Recording Secretary of Eta Kappa Nu, the electrical engineering honors
society, in fall 2009.

The cooperative education program at Stevens has given Scott over 16 months of experience in the
workforce. His first term was at Panasonic North America as a technical liaison to Japan research and
development division. During his second co-op period Scott worked as a systems engineer intern at
Datascope Patient Monitoring. There he developed strong LabVIEW skills simulating waveforms on a
DAQ to give preliminary test results for the ECG machine development team. During this time he also
developed a simple printed circuit board to allow various scopes and meters to tap into the output and
inputs of a newly designed power supply.

For Scott’s third and fourth co-op terms he worked at the Naval Air Warfare Center (NAWCAD or
NAVAIR) in Lakehurst, NJ. During that time he worked with the Visual Landing Aids team. He developed
a test set using LabVIEW to give simulated, dynamic inputs into the Improved Fresnel Lens Optical
Landing System (IFLOLS) to give sailors dynamic training on land instead of the static system they were
using previously. He also traveled to Virginia to work on a service change to the IFLOLS system on the
newest U.S. Navy aircraft carrier the George HW Bush and to train sailors on how to use the new
equipment. Scott also worked with the Night Vision Device (NVD) compatible team. He traveled to San
Diego, Missippi, New Orleans and Alabama to survey ships on where to install NVD compatible filters.
His next co-op will be at G3 Technologies in New Providence, NJ. There he will work on CDMA based
products for the military.

Scott is very interested in the field of home automation. The field is still relatively new and there will be
many more products on the market in the coming years. This project is a good start to decide if he
would like to pursue this field further after college.

Rob Lee-Own
Rob Lee-Own is a 4th year undergraduate student at Stevens institute of Technology. He is pursuing a
Bachelors of Engineering in Electrical Engineering as well as a Masters of Engineering concentrating in
Wireless Communications. His expected graduation date is May 2011 due to his extensive work
experience in the Co-Operative Education program.

Rob is a member of Tau Beta Pi, the National Engineering Honor Society and Eta Kappa Nu, the National
Electrical and Computer Engineering Honor Society. Beginning in the September 2010, he will serve as

                                                                                                           21
Corresponding Secretary for the Stevens chapter of Eta Kappa Nu. He is involved in several clubs on
campus including the Archery Club, the Computer and Console Gaming Society (C2GS) and the bowling
club, in which his team was 2nd place in the Spring 2010 campus-wide tournament. Off-campus he
enjoys camping, canoeing, hiking and biking. He actively serves as an Assistant Scoutmaster of Boy
Scout Troop 53 in his hometown of Bedminster, NJ.

Due to his involvement in the Stevens Co-Operative Education program, Rob has had widely varied work
experiences. In his first co-op assignment Rob worked for Cooper Notification, a company that provides
fire safety notification and voice evacuation equipment. He built and tested analog and digital
prototype designs for the engineering department and performed tests on existing and future products
to the standards of UL, ULC, FCC and other regulatory bodies. He also gained experience in firmware
programming of microcontrollers using assembly and driver circuits for high power LEDs.

For Rob’s second and third co-op assignments he worked in the Integrated Communications Networks
and Sensors department of the MITRE Corporation. He designed and developed a MATLAB-based
software tool for the US Army that allows for planning allocation of spectrum and judging performance
of wireless communications networks, contributing to the development of an algorithm that optimizes
automated spectrum allocation. He enhanced the organization’s modeling and simulation capabilities
by prototyping, testing and implementing new features in the existing tools such as the capability to
investigate the deployment of Unmanned Arial Vehicles. Also, he coordinated and performed tests to
evaluation commercial communications equipment including UHF radios interfaced with portable GPS
equipment for possible tactical use by the US Military as part of a DOD-funded research project. He also
participated in presentations and demonstrations to MITRE corporate leadership and US Government
Sponsors.

Rob’s fourth co-op assignment was with the Naval Air Warfare Center- Aircraft Division (NAWC-AD) at
the Naval Air Engineering Station at Joint Base McGuire-Dix-Lakehurst in NJ. He worked on the
Integrated Diagnostics and Automated Testing Systems (IDATS) team, developing new technologies and
transitioning technology from laboratory-proven concepts to use by the US Navy. He built and tested
prototype designs for projects focused on bringing new technology to the field of diagnostics of avionics
data buses including ARINC-429 making use of Printed Circuit Board (PCB) layout software and PCB-
Fabrication equipment. He will return to NAWC-AD this summer and continue work on projects within
the IDATS group.

Rob believes that his experience in hardware and microcontrollers will be his most valuable asset to this
team. He expects to contribute to the hardware development and the low-level software specific to the
microcontroller.

Max Sobell
Max is entering his 5th year out of 5 in NYU’s dual degree program pursuing degrees in Computer Science
and Computer Engineering. He is interested in integrated hardware and software projects and enjoys
low level programming. He has experience working on robotics projects using several different robots,
including the 3π robot, the Rovio Robot and the E-Puck Educational Robot. His favorite robotics project


                                                                                                       22
so far was built on the Rovio robot: the Rovio recognizes a ball and a goal and (ultimately) shoots the
ball into the goal to score a point. Max is currently working on a robotics project using the E-Puck
Educational Robot, utilizing its proximity sensors and microphones to allow two robots to work in
tandem.

Max is the president of the ACM and the Programming Team at NYU. NYU’s ACM recently built a 3D
printer from a Makerbot 1st generation kit, which involved many late nights and hardware hacking, an
experience he looks forward to with this project as well. Max is looking forward to this year’s New York
Regional programming competition in the Fall. He hopes his team can advance to the finals or at least
beat Columbia this year.

Max has experience working as a Financial Engineer where he worked on proprietary trading algorithms
for his company’s clients. However, he has more pertinent experience working as a server administrator
and a technical writer. Max wrote chapters for A Practical Guide to Linux: Commands, Editors and Shell
Programming and its Red Hat Enterprise Linux counterpart. He has experience programming in a Linux
environment and is excited to configure the team’s SheevaPlug server. He is currently employed by a
company working on mobile device penetration testing and believes he will be able to help create a
secure RDL system.

Max has been developing software for several years and looks forward to contributing to the software
portion with of this project with Vincent Lin while learning more about the hardware aspects from Scott
Velivis and Rob Lee-Own. Max prefers to write in Java, C or Python, and plans to develop prototypes of
the RDL software in Python with Vincent. Max also plans to work on shell scripts for the server to
process incoming emails to trigger the proper function.

While not staring at a computer screen, Max enjoys playing soccer, ultimate frisbee and hiking. He is an
organizer for PickUpSoccer NYC and a member of the Appalachian Mountain Club. Max is a strong
proponent of free software and a member of the EFF, ACM and IEEE.

Vincent Lin
Vincent Lin is in his fourth year of a five-year joint program between NYU and Stevens. He is pursuing a
Bachelors degree in Mathematics at NYU and a Bachelors of Computer Engineering at Stevens.
Vincent’s primary area of study at Stevens is in Information Systems Security and in Computer
Programming. He attended Saunders Trades and Technical High School where he majored in Chemistry.

Vincent’s interests include following professional sports, solving Sudoku and Crossword puzzles, and
writing/debugging computer programs. It is his interest in puzzles that led him to algorithms and
computer programming, and he is proficient programming in Java and C++, and also has experience
programming in MATLAB and .net. Vincent has also been exposed to languages such as assembly, VHDL
and BASIC while learning how to integrate the computer programming with hardware components at
NYU and Stevens.




                                                                                                          23
Vincent hopes to one day continue his education and receive a Masters degree in a field related to
Computer Science, as well as becoming employed as a certified computer programmer in a higher-level
language such as Java.

Vincent commutes to campus from his hometown in Yonkers, NY where he does volunteer work on the
weekends. He has previously been employed part-time at a local pharmacy and learned some of the
intricacies of the workplace and pharmaceuticals. He is a part of the NYU Society of Engineers and plays
Tennis, Soccer, Baseball and video games in his spare time. Vincent has also played the clarinet for the
past 6 years and was the clarinet section leader in his high school band. In addition, nearly every
summer when he is not taking summer courses, Vincent travels back to Taiwan with his family to visit his
extended family.




                                                                                                     24

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:878
posted:8/24/2011
language:Dutch
pages:25