Wireless Home Security System

University of Connecticut ECE 290 Spring, 2004 Sponsor: ECE Department, University of Connecticut Advisor: Lei Wang David Crouse (EE)
david.crouse@uconn.edu

Michael Diaz (EE)

michael.diaz@uconn.edu

Darko Budimir (EE)

darko.budimir@uconn.edu

I. ABSTRACT Our group investigated wireless security system design for home use. The target market is composed of lowincome individuals who cannot afford the services of a security company such as ADT. Ideally the sensor nodes would communicate their status to a base station through mesh networking, however, after experiencing a few difficulties, only an IR barrier sensor, and a motion detector, powered by PIC microprocessors were completed along with a sample program for UART communication. Hardware was designed and built to demonstrate a star network of sensors communicating to a base station, via aRadiotronix WiSE network, however communication difficulties with the Radiotronix boards occurred and the boards were unable to send. II. INTRODUCTION Be it a priceless heirloom or silverware acquired in better times, many low-income individuals own valuable property. Sadly, the poorest communities are often the ones with the highest crime rates. Though residents of such areas might benefit from home security services, such as ADT, most are not able to afford the high costs of installing and maintaining such services. Also, many such services require wires to be installed within the walls of the house. Many people, especially the poor, rent their homes. In such an instance, the tenant might be unwilling to invest in a security system if they cannot take it with themselves when moving and the lease might forbid such alterations. The ideal home security system for the poor would not require professional installation nor would it be expensive to purchase or maintain. Our work looked into a solution to these issues in the form of a WIRELESS SENSOR NETWORK (WSN). III. BACKGROUND The Wireless Sensor Network (WSN) system in development today, has a main predecessor and several related wireless network models: specifically Packet Radio technology, cellular networks, and Bluetooth. All these related models have either physical or implementation constraints that differ to our proposed system, but we mainly wanted to focus on the fact that none of them deal with a multi-hop topology. None of these models require their sensor nodes to depend on another sensor node to communicate with the central base station.

The main predecessor to the current Wireless Network Sensor (WSN) system is a technology called Packet Radio. It was first introduced in the 1960s, in two main research organizations: The Rand Corporation, the original non-profit think tank helping to improve policy and decision making through objective research and analysis; and the Defense Advanced Research Projects Agency (DARPA), a military agency devoted to national security through weapons development. These two corporations set out to develop a system that would interconnect a research computer network, spread across the islands of Hawaii. In this system, the sensor nodes were computer terminals, arranged in a Star Topology (refer to 1 Figure 1) , that computed data and transmitted results to a central base station.

Figure 1. All nodes in a star network communicate directly with the base.

As one would expect, the system was not without faults, specifically collisions were occurring between their
1

The terminals in Packet Radio were arranged in a Star Topology, where the terminals are all distributed around one main and central base station. In a wired system, synchronizing all the terminals with the base is not a difficult task, and thus controlling the order of transmission does not allow for collisions.

computer terminals. In packet radio, these collision happened when a terminal attempted to contact the base station at the same time the base station was transmitting out to the terminals, resulting in the transmissions colliding and being lost, requiring them to be retransmitted. Their solution was to incorporate a repeater system, where all the terminals would transmit on the base (repeater) input frequency and receive on the base (repeater) output frequency. The system worked, but did not allow terminals to communicate between each other, and furthermore, did not deal with our main proposed challenge, which is organizing the sensor nodes. Because the terminals are not constrained by size or power consumption, they can be equipped with a transmitter that can reach the base, without depending on another terminal for a relay or retransmission. Next, in the model networks, is the cellular network, consisting of both stationary and mobile sensor nodes. The stationary sensor node, or base, receives the data form the mobile sensor nodes, and relays it to some fixed network via a wired backbone. The mobile sensor nodes outnumber the base by a factor of at least a hundred, and are located randomly. Yet the only issue they have with organization is encountered in terms of cell-to-cell or as theyre called, handoffs, as the mobile sensor node moves from the range of one base station to another. Again, because the mobile sensor nodes are not constrained by size or power consumption, they can be equipped with a transmitter that can reach the base, without depending on another mobile sensor node for a relay or retransmission. Bluetooth 2 is another network model, consisting of a short-range wireless networking system created to replace the cable between electronic devices with a RF connection. Bluetooth is also arranged in a Star Topology, where a base sensor node can have several sensor nodes attached to it. All these nodes (including the base) create what is called a piconet. To organize itself, the piconet uses a time division multiple access (TDMA) schedule and frequency-hoping pattern to determine which device can talk or not. This may seem like a partial solution to our problem, but using frequency-hopping would require our sensor nodes to be equipped with a transceiver that is capable of operating a wide range of frequencies. Bluetooth does have mechanisms in place for multiple piconets to interconnect and form a multihop topology, but these mechanisms are no more than fancy repeater stations. Again, we see that the actual sensor nodes cannot depend on each other for a relaying function. All of the models that are in place either require a dedicated repeater system, or mobile and non-mobile sensor nodes that are equipped with transceivers that are capable of high power or operating on a wide range of frequencies (for frequency-hoping). Either case requires huge amounts of power, be it from a power supply or in processing power.

There are only a few methods of network organization that solve this problem. One is an open source project at University of California at Berkeley (UCB) called Tiny OS3 and the other is the recently completed Zigbee4 standard. Both TinyOS and the Zigbee standard were developed specifically for wireless systems, with an emphasis on sensing applications, and low-power consumption (i.e., idle and sleep modes). Both of these methods take into account our issues with multi-hop topologies, and both of these technologies support mesh networking, instead of star networking. The nodes will relay the message signal between each other back to the base station so that not all of the nodes must be in range of the base station, in a manner similar to that depicted in Figure 2.

Figure 2. Nodes in a mesh network communicate directly with each other and relay messages from far nodes back to the base station.

Zigbee is a new standard that defines the basic hardware and software layers needed to implement a simple wireless network. The hardware standard is the IEEE 802.15.4

The Bluetooth standards group may be found online at: \url{http://www.bluetooth.org

3 The project homepage for the TinyOS may be found at: http://today.cs.berkeley.edu/tos/ 4 The home of the Zigbee standard may be found at: http://www.zigbee.org

standard. A designer, using a microcontroller and transceiver, which are in full compliance with the Zigbee standard, would have a working, self-organizing network out of the box. The designer need only program the microcontroller to send data, along with and address, to the transceiver to be transmitted across the network and also to handle received data. The Zigbee standard defines networking protocols for star networks, in which all nodes talk to the base station directly, as well as for mesh network, in which nodes will relay messages between each other on the way to the base station by means of the shortest available path. The Zigbee standard specifies a synchronous networking method, thus averting packet collisions since no two nodes, within range of each other, will broadcast simultaneously. The required hardware is quite cheap and since local nodes do not broadcast simultaneously, little bandwidth is required for the network to operate.[1] However, at the time we began our research there were no free implementations of the ZigBee networking stack available. Currently, there are a few such stacks available. On the other hand, The Tiny OS defines only the software aspect of the wireless network. The choice of hardware is left up the designer. The Tiny OS solution also involves the assignment of different frequencies to each of the nodes. A WSN with potentially hundreds, if not thousands of nodes, each having a distinct frequency assignment, would require sensor nodes with transceivers and processors that could deal with any combination of possible frequency assignments. While this solution avoids packet collisions, it also requires sophisticated hardware to be able to keep track of all of the frequencies, which have been assigned, as well as the ability to broadcast on all possibly assignable frequencies. The use of so many frequencies also requires a good deal of bandwidth. Both the main predecessor and several related wireless network models are mentioned, in order for the reader to obtain a genuine understanding of our intentions and goals in developing our proof of concept Wireless Home Security System. The intention is not to indicate that said network models will be implemented or improved, but instead to indicate what could be accomplished with seemingly infinite resources and time. Our actual research is focused on an affordable and simple implementation of current technologies. For our research, an all together different model was implemented: the Radiotronix5 Wi.232 DTS module, which implements a wireless serial engine (WiSE) that combines an RF transceiver with a microcontroller designed to be a complete solution to the WSN issue (as noted in Figure 3). Every WiSE module is programmed at the factory with a unique 48-bit MAC address and is capable of supporting TCP/IP and ARP protocols.

Figure 3. Wireless Serial Engine (WiSE)

Specifications may be found at: http://www.radiotronix.com/products/prodwi232.asp

The Wi.232DTS module is designed for wire-replacement applications (i.e., home automation, building automation, mobile AMR, and wireless RS-232/422/485 applications); it can support three main network protocols: 1) point-to-point, 2) point-to-multipoint, 3) multipoint-to-multipoint. The module is intended to interface directly to a base station via the UART standard. In order for data transfer, three signals are used: TXD, RXD, and CTS. TXD is the data output; RXD is the data input; and CTS indicates the status of the modules data interface. If CTS is low, the module can accept data; if it is high, the module cannot accept data because it is busy. For the received data, the module has a 192 byte buffer for incoming characters from the UART base station. Various registers may be programmed to modify the manner in which the incoming data is handled. Options range from 1) automatically transmitting when the buffer reaches a predetermined limit, 2) transmit based on a delay between incoming characters, or 3) a transparent transfer via a streaming data mode. To avoid collisions between neighboring modules, the transceiver uses a carrier-sensemultiple-access (CSMA) protocol to determine if another module is transmitting. If transmission is detected, the module is programmed to receive the incoming data before attempting to transmit. For further avoidance of data collision, each module has an 8-bit group ID which is linked to other modules on the same channel. Therefore, all modules on the same channel will operate together and collisions will be prevented on modules transmitting on same channel but different group IDs. When a transmission occurs, all modules on the same channel receive the same signal, if the group ID matches the signal is accepted, otherwise it is rejected. For our particular application, we take advantage of the modules Master/Slave network mode, which allows the Master module to talk to Slave modules, and Slave modules to talk to Master module, but Slaves cannot communicate with other Slaves. This is merely another form of a star network topology. A typical network is noted in Figure 4.

Figure 5. Wi.232DTS Pin Diagram

Table 2. Pin Description

Figure 4. Wi.232DTS Typical Network.

The TX power is unique in that the Wi.232DTS module employs the use of the digital spread spectrum provision in FCC part 15 rules. This allows the transmitter to operate in high power if the bandwidth is at least 500kHz. Through a unique encoding method, called DirectSPREAD, the model can operate at a maximum of +12dBm in high power mode. In low power with a bandwidth of 200kHz the transmit power is 0dBm, allowing for a respectable range of slightly above half the range of high power. Table 1. Wi.232DTS Specifications Wi.232DTS Frequency 902-928 MHz Data Rate .3-152.34kbps # channels 32 TX Power 0-12dBm RX Sensitivity -102dBm Hi Power -105dBm Low Power Battery Life 2 years (AA)

The actual pin layout of the Wi.232DTS module is noted in Figures 5, with a pin description in Table 2.

IV. PRELIMINARY REQUIREMENTS To facilitate unskilled installation, a system should consist of low-power wireless sensors, which report back to a base station. This eliminates the problems associated with altering a building, as well as allowing the system to be moved to other residences. The only recurring cost of our system shall be the purchase of batteries for the sensors. In order to keep this cost low, our sensors use little power. The sensors are motion sensors with a minimum range of 1 meter. As opposed to hiring a security service to monitor ones home, our system provides a visual alerting system via flashing LEDs. These LEDs could just a likely be an audible siren or the trigger to an automatic telephone dialer. But as our research is not focused on said applications, the LEDs will suffice.

V. RESULTS AND DISSCUSSION The results for our Wireless Home Security System, were limited because of delays in acquiring parts and debugging the circuitry. Although we achieved two significant accomplishments: design and construction of two distinct motion detectors and the basis for a Master/Slave network comprised of a base station and a transceiver module. The motion detectors were both original designs using passive infrared (PIR) detection and an infrared barrier. The PIR motion detector was composed of the KC778B Master PIR Control Chip6 which is designed for easy implementation of PIR motion detectors. Our design for the PIR Motion Detector can be found in Appendix I. The second motion detector was comprised of two portions: a TX and RX modules. These two modules created an IR pulsed beam, which detected an obstruction between the two separate modules. Effectively creating a invisible light barrier for motion detection. Ideal applications for this would be in a door way. Our design for the IR Light Barrier can be found in Appendix II. The core of our research is found in the assembly code that controlled the PIC microcontroller in both our base station and detection modules. Our design for the Base Station can be found in Appendix III Our design centered on the PIC16F874 microcontroller. It works as the brains of both of the sensors. The base design for wireless sensors is shown in Appendix III. The PIC microcontroller may be programmed while on this board through the use of the RJ-11 port. The PIC receives a single input line form the sensors on pin B0 and connects to the WISE wireless module through its UART interface, on pins C7 and C6. Pins B1 and B2 are used for control signals to the PIC. The programs in the following appendices, which D2, D3, C4, and C5 are connected to LEDs to indicate the status of the system. On the IR barrier the LEDs are on until the barrier is broken, on the motion detector, the LEDs briefly flash when motion is detected. Appendix III also contains the code for a sample program to test the UART capability of the PIC. It is meant to echo back all data that is received. Unfortunately, for reasons we have yet to determine, it does not work with the WISE chips. However, if the UART output from the PIC is connected to a MAX232N RS232 interface chip, and subsequently to a PC, it will successfully echo data back to a terminal. Appendix IV contains an alternative design for the IR receiver for the IR sensor. After testing various designs, this topology was abandoned because, due to the fact that it works off of an RC delay, it would have required a higher frequency signal to be sent from the transmitter. An 85Hz frequency was chosen for the transmitter because we found that it worked with the widest range of infrared phototransistors. Specifications can be found at: http://home.pacific.net.hk/~kcyeung/kc778b.pdf
6

In all, we have designed a programming board for the PIC which can be interfaced to various sensors. We have also designed 2 sensors, an IR light barrier as well as a motion sensor. The designed hardware should be able to network perfectly, with only slight modifications to the program code. The base circuit design, utilizing the PIC, could be used as a base station, if the sensor were omitted. If we were to do this project over we would not use a WISE network due to its inability to mesh network. Rather, we would try a new design utilizing the TinyOS. VI. REFERENCES [1]''The ZigBee Buzz is Growing: New Low-Power Wireless Standard Opens Powerful Possibilities''. (A supplement to the magazine.) Jan. 12, 2004.

APPENDIX I

-Passive Infrared (PIR) Motion Detection Circuit Using The KC778B Control Chip.

APPENDIX I: CONTINUED

-Passive Infrared (PIR) Motion Detector Using The KC778B Control Chip [Enclosure].

-Passive Infrared (PIR) Motion Detector Using The KC778B Control Chip [Exposed View].

APPENDIX II: CONTINUED

-IR Transmitter: Transmit Portion Of The IR Barrier.

APPENDIX II: CONTINUED

-IR Receiver: RX Portion Of The IR Barrier.

-IR Transmitter [Left] and IR Receiver [Right]. (Enclosed View)

APPENDIX II: CONTINUED

-IR Receiver (Exposed View)

-IR Transmitter (Exposed View)

APPENDIX II: CONTINUED

Assembly Code For IR Barrier //Begin
list p=PIC16F874 #include P16F874.inc __config(_CP_OFF & _BODEN_OFF & _PWRTE_ON & _WDT_OFF & _XT_OSC & _DEBUG_ON) ;;;;;;; Macro definitions ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; movlf macro movlw literal movwf dest endm literal,dest ;Copy literal to a register, though W.

movff macro source,dest movf source,W movwf dest endm BANK0 macro bcf STATUS,5 endm BANK1 macro bsf STATUS,5 endm

; Copy from one register to another, though W

; Select page 0

; Select page 1

;;;;;;; Memory for interupt usage ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; cblock H'20' ;Bank0 InterruptCount endc

;;;;;;; Begin Program Code ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; org 0 ;The program begins executing here nop ;Needed to use the debugger goto Start ;;;;;;Branch to IntService when interrupts occur;;;;;;;; org H'004' ;Interrupt vector goto IntService ;Branch to the actual routine Start ;;;;;;Initialize Ports;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; clrf PORTB clrf PORTC clrf PORTD clrf TMR0 ;Clear Timer0 clrf InterruptCount movlf b'10000000', RCSTA ;UART enabled BANK1 clrf TRISD ;Set port D as all outputs movlf b'00000011', PORTB movlf b'10000000', TRISC ;Set UART pins for I/O

APPENDIX II: CONTINUED

movlf b'00100100', TXSTA ;Enable Asynchronous transmit on UART movlf d'103', SPBRG BANK0 ;;;;Make the buffer on the transciever as small as possible;;;;;; bcf PORTB, 2 ;Put the transceiver into program mode. ;send 0xff 0x02 0x54 and 0x01 to set the buffer to the min size movlw 0xff call Send movlw 0x02 call Send movlw 0x54 call Send ; movlw 0x01 call Send btfsc PORTB, 1 ;Wait until the transceiver says that it is done with whatever goto $-1 bsf PORTB, 2 ;Put the transceiver back into transmit mode. BANK1 movlf b'00000110', OPTION_REG ;Start the timer BANK0 movlf b'10110000', INTCON ;Enable interrupts, including RB0, and TMR0 ;;;;;;Main Loop;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; MainLoop ;Do nothing nop goto MainLoop

;;;;;;The actual Interrupt service routing;;;;;;;;;;;;;; IntService ;Begin Handling the interrupt. btfsc INTCON, INTF call HandleRB0 btfsc INTCON, T0IF call Timer0Overflow ;Restore the previous state retfie Timer0Overflow bcf INTCON, T0IF movf InterruptCount, w btfss STATUS, 2 ;If InterruptCount was not 0, turn on the lights call SystemTripped movlw 0 btfsc STATUS, 2 ;If InterruptCount was 0 turn off the lights movwf PORTD clrf InterruptCount clrf TMR0 BANK1 movlf b'00000110', OPTION_REG ;reset the prescaler BANK0 return

APPENDIX II: CONTINUED

HandleRB0 incf InterruptCount, f bcf INTCON, INTF return Send BANK1 btfss TXSTA,TRMT goto $-1 BANK0 movwf TXREG return SystemTripped bsf PORTD, 2 bsf PORTD, 3 movlw 'B' call Send return end ;Reset the flag that caused the interrupt

; Wait until can send

; Send data in W

;turn on the lights

//End IR Barrier Assembly Code

APPENDIX III:

-Base Circuit Design Using the PIC16F874.-

APPENDIX III: CONTINUED

-Base Station Enclosure [Note PIR Motion Detector Is Enclosed Within The Base]

-Base Station (Exposed)

APPENDIX III: CONTINUED

Base Station Assembly Code: Echo Of Received Signal Back To Base Station/PC. //Begin list p=PIC16F874 #include P16F874.inc __config(_CP_OFF & _BODEN_OFF & _PWRTE_ON & _WDT_OFF & _XT_OSC & _DEBUG_ON) ;;;;;;; Macro definitions ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; movlf macro literal,dest movlw literal movwf dest endm movff macro source,dest movf source,W movwf dest endm BANK0 macro bcf STATUS,5 endm BANK1 macro bsf STATUS,5 endm ;Copy literal to a register, though W.

; Copy from one register to another, though W

; Select page 0

; Select page 1

;;;;;;; Memory for interupt usage ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; cblock H'20' ;Bank0 W_TEMP STATUS_TEMP PCLATH_TEMP endc

;;;;;;; Begin Program Code ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; org 0 ;The program begins executing here nop ;Needed to use the debugger goto Start ;;;;;;Branch to IntService when interrupts occur;;;;;;;; org H'004' ;Interrupt vector

APPENDIX III: CONTINUED

goto IntService ;Branch to the actual routine

Start ;;;;;;Initialize Ports;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; clrf PORTC movlf b'10010000', RCSTA ;UART and continuous reception enabled BANK1 movlf b'00000011', PORTB movlf b'10000000', TRISC ;Set UART pins for I/O movlf b'00100100', TXSTA ;Enable Asynchronous transmit on UART movlf d'103', SPBRG movlf b'00100000', PIE1 BANK0 movlf b'11000000', INTCON ;Enable interrupts, including peripheral ;;;;Send an Alive Message;;;;; movlw 'A' call Send movlw 'l' call Send movlw 'i' call Send movlw 'v' call Send movlw 'e' call Send movlw 0x0D ; CR call Send movlw 0x0A ; LF call Send ;;;;;;Main Loop;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; MainLoop nop goto MainLoop ;;;;;;The actual Interrupt service routing;;;;;;;;;;;;;; IntService btfsc PIR1, RCIF call HandleRXInterrupt retfie HandleRXInterrupt movfw RCREG bcf RCSTA, 4 bsf RCSTA, 4

;Receive the data ;These 2 instructions cause it to ignore any overrun errors.

APPENDIX III: CONTINUED

;Now echo the data back call Send return Send BANK1 btfss TXSTA,TRMT goto $-1 BANK0 movwf TXREG return end //End Base Station Assembly Code

; Wait until can send

; Send data in W

APPENDIX IV

-Alternate IR Barrier Receiver Circuit