Multiple Child Tracking System



Multiple Child Tracking System

May05-24

“Design Report”

Client:

Senior Design

Advisor:

Dr. Diane Rover

Team:

Benjamin Flessner CprE

Allan Hammell CprE

Iwin Lee CprE

Hua Shao EE

REPORT DISCLAIMER NOTICE

DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.

15 – December – 2004

Table of Contents

i. List of Tables ii

ii. List of Figures iii

iii. List of Definitions iv

1. Executive Summary 1

2. Introductory Material 4

2.1. Abstract 4

2.2. Acknowledgement 4

2.3. Problem Statement 4

2.4. Solution Approach Statement 4

2.5. Operating Environment 4

2.6. Intended Users and Uses 5

2.7. Assumptions 5

2.8. Limitations 5

2.9. Expected End Product and Documentation Deliverables 6

3. Approach Used 7

3.1. Design Objectives 7

3.2. Functional Requirements 8

3.3. Design Constraints 10

3.4. Technical Approach Considerations 10

3.5. Testing Approach Considerations 12

3.6. Project Continuation/Modification Recommendations 12

4. Detailed Design 13

4.1. Computations and Analysis to be Performed 13

4.2. Assumptions 15

4.3. Limitations 15

4.4. Communication Flow-Charts 15

4.5. List of Inputs 17

4.6. List of Outputs 17

4.7. User Interfaces 17

4.8. Testing Activities 18

5. Resources 19

5.1. Personnel Effort Requirements 19

5.2. Financial Requirements 20

6. Schedules 21

6.1. Project Schedule 21

7. Closure material 23

7.1. Client Information 23

7.2. Faculty Advisor Information 23

7.3. Student Team Information 23

7.4. Closing Summary 24

8. References 24

i. List of Tables

Table 5-1 - Previous Personnel Effort Estimation 19

Table 5-2 - Revised Personnel Effort Estimation 19

Table 5-3 - Original Project Cost Estimates 20

Table 5-4 - Revised Project Cost 20

ii. List of Figures

Figure 1-1 - Visual Representation of Tracking System 1

Figure 3-1 Gotcha Child Safety Device 11

Figure 3-2 - Crossbow MOTEs - MICA2 and MICA2Dot 11

Figure 4-1 Base Module Communication Flowchart 15

Figure 4-2 Caretaker Module Communication Flowchart 16

Figure 4-3 Child Module Communication Flowchart 16

Figure 4-4 - MTS300 Sensor Board 18

Figure 6-1 - Previous Project Schedule – Major Tasks Only 21

Figure 6-2 - Revised Project Schedule – Major Tasks Only 21

Figure 6-3 - Previous Project Schedule - Detailed 22

Figure 6-4 - Revised Project Schedule - Detailed 22

iii. List of Definitions

Emulate – Virtual representation of a physical interface

MOTE – Small, self-contained, systems or boards containing both a microprocessor and a radio transceiver.

GPS – Global Positioning System

PDA – Personal Data Assistant – Small, handheld computer used to store data and run simple programs.

Simulate – Give the appearance of functionality without hardware interfaces

Executive Summary

Keeping track of children can sometimes be very difficult in today’s fast-paced world. Families with multiple children face an even tougher task especially on outings to parks or shopping malls. Not only must caretakers keep children close to them, they must also be on continual alert to any number of dangers such and that child falling into a back-yard pool or lake at a park. Developing a tracking system for caretakers with multiple children could greatly ease stress and allow them more freedom during excursions with their children.

Figure 1-1 - Visual Representation of Tracking System

There are currently very few products on the market that help parents keep track of their children. Some use GPS technology to report on a child’s whereabouts over large areas, but are not very useful in keeping children near a parent such as in a back-yard or in a store. One particular product, Gotcha®, does track children near a parent, but it also has some limitations. First, it only tracks children’s location; it doesn’t monitor other conditions that could cause a child to be in danger. Also, it centers the area of “acceptable proximity” around the caretaker. This may be fine for mobile scenarios, but if a caretaker wishes to, say, track children in a back-yard, they could easily set off false alarms by moving near the front of the house.

This project is designed to add functionality to systems like Gotcha®. The first way is in creating a base station. This base station would be separate from the caretaker module and could be placed in a back-yard or center of a campsite. Children would then need to stay within a specified range of the base station, while the parent is free to move around without changing the acceptable proximity area. This project also plans to add sensors to the child modules. A water sensor would detect if a child falls into a swimming pool or lake, and a temperature sensor could detect if a child is too close to a fire or has accidentally been left in a hot car with the windows rolled up.

The goal of this project is to create a working prototype of the multiple child tracking system. Small devices, called MOTEs, will act as modular pieces to the system. Each will be identical, but with different programming to turn them into either a base station, a caretaker module, or a child module. These prototypes would only be operated in a safe, lab-environment, but future projects could create housings and smaller components to be actually worn by children and be weatherproof.

Several options were considered for developing this system. Initally, the idea was to build each module from the ground-up: select a microprocessor and radio transmitter and create the circuits to make the system work together. Unfortunately, the time given for the project would not permit the low-level design of components as well as programming them to function properly. Another plan was writing programs for PDA that could use existing radio technology to track the locations of other PDA’s. This option was discarded for two main reasons. First, the current wireless cards available for PDAs have no way of measuring distances without completely re-writing firmware. External sensors, such as water and temperature would also have to be created from scratch in order to interface with the PDA. Again, the project team felt there was not enough time to complete a fully functional system.

One hopeful method of developing was modifying the existing Gotcha® tracker by adding a base station and water sensors. Early communication with National Scientific Corporation, creators of Gotcha® seemed promising, but as design time approached without further communication, an alternative had to be chosen.

In the end, Crossbow’s MOTEs were selected for use in this project. These MOTEs are very small devices that contain a microprocessor, radio transceiver, and simple sensors. What’s more: they were available in a laboratory at Iowa State University for use throughout the course of the design project. These MOTEs are a new and quickly-growing technology, and working with them gives the team members a special niche in the wireless communications market.

The base module will be the hub of all communication and do a majority of the computations associated with this system. The base will, one by one, “ping” each child module. It will time how much time passes before it receives a “ping response.” The longer a ping response takes the farther away the child module should be from the base module. If a ping response is not received within the set amount of time a second ping, that is different from the first, will be sent and the ping response that the base expects will be different as well. Making the messages unique will avoid any confusion from a ping response from the first ping being confused as the ping response for the second ping. The practice of a second ping reduces the probability of false alarms due to dropped messages.

When a child is in an alarmed state, for any reason, an “alarm” message will be sent to both the child and the caretaker modules. This child will remain in the alarmed state until an “all safe” message is received from the caretaker module.

The child module will have the ability to receive ping messages and send ping responses. It will sound an alarm if it finds itself to be in an alarmed state due to its sensors or if it is told it is in an alarmed state due to an alarm message. If it is due to sensors it will send a “danger” message to the base.

The caretaker module has the ability to receive alarm messages and to send all safe messages. When it receives an alarm message it sounds an alarm. It will have the ability to differentiate which child modules are in an alarmed state.

The system in general is designed to accommodate more than a billion (2^30) unique child identification numbers. Although at this given time each system will only have knowledge of 6 of these child identification numbers, this can drastically reduce the probability of errors due to two systems in a close proximity. The current design only will have danger messages that result from water and extreme heat, but has left many message assignments unassigned for future use to correspond to dangers detected by other sensors.

After the initial programming has been done on the devices, they must undergo testing to ensure their proper functionality. Testing will be done in two phases: basic functionality in a lab environment, and real-world-effects testing. The first phase tests that all functions of the system work. For example: moving a child module out of range of the base station should set off an alarm, and putting to water sensor “leads” into a glass of water should set off the water alarm. Real-world tests include testing to learn what obstructions do to the range and functionality of the system. Of course, with exposed, bare electronics, these tests will be limited. For example: rain’s effects cannot be tested because it would immediately destroy the MOTEs.

Several end-products will be produced from this design project. A minimum of four programmed MOTEs will represent a caretaker module, a base station, and two child modules to demonstrate differentiation between children. A water-detection circuit will also be created to interface with the MOTEs through a standard connector. User’s documentation and a technical/maintenance manual will also be produced.

The project began in September, 2004 and will continue on to completion in May, 2005. The project team hopes to create a fully-working prototype of the multiple child tracking system, gaining experience with the Crossbow MOTE technology and creating the building blocks for a product of great use to caretakers with multiple children to keep track of.

Introductory Material

The introductory material will consist of an abstract, problem statement, solution approach statement, operating environment, intended users and uses, assumptions, limitations, and expected end product and other deliverables sections.

1 Abstract

Keeping multiple children safe and accounted for can be a daunting task. When someone loses track of a child, even for a little while, anxiety levels rise greatly. This project will develop a device to be worn by a child that will monitor certain conditions and a device that will be used by the child’s caretaker to alert them if the child is possibly in danger due to the certain conditions. These devices could drastically reduce caretaker-stress and improve child-safety.

2 Acknowledgement

Technical specifications for Crossbow MOTEs were taken from Datasheets publicly available at .

The project team wishes to thank Iowa State University’s Department of Electrical and Computer Engineering and Professor Daji Qiao for the temporary use of the Wireless Sensor Networks Lab in the development of this project.

3 Problem Statement

Current devices to track children are too limited in their functionality. While they may detect a child that has wandered away too far from a parent, they do not alert the parent to other dangers, such as a child falling into water or being left in a hot car.

4 Solution Approach Statement

The team will create an expandable system that will be portable enough to travel with a family, yet versatile enough to alert to different dangers to children. A stationary base unit will communicate with multiple child units and warn a caretaker unit if one of the children is out of range or in danger.

5 Operating Environment

Although further elaborations of this product will be expected to operate in an indoor or outdoor environment where conditions such as rain, water, snow could be present, the prototype that will be delivered in this elaboration will be used indoors in a laboratory setting. It will operate within a normal range of temperatures that could be described as “room temperature.”

The system will be expected to operate under interference from other systems running in the same frequency range.

6 Intended Users and Uses

The intended users will be caretakers who wish to monitor one or more children. The other users would be the children being monitored by the caretaker.

The system will be used to safeguard children from wandering too far away from a caretaker and encountering certain dangers, such as falling into water.

7 Assumptions

The following is a list of assumptions for the project.

1 The system should handle up to six children at one time.

2 The system can work indoors or outdoors.

3 The system should be able to handle additional caretaker modules.

8 Limitations

The following is a list of limitations for the project.

1 An alarm on the child module shall be loud enough to audibly track, but not painful or damaging to a child’s ears.

2 The MOTEs will operate at 3V via two AA batteries.

3 Batteries should last for at least 12 hours of continual use.

4 The caretaker module must be able to differentiate which child module is causing an alarm.

5 A water sensor will be responsible for detecting the presence of water

9 Expected End Product and Documentation Deliverables

The following end-product representations and documents will be produced by this project team

1 At least two MOTEs representing child modules.

Two MOTEs will be programmed as independent, wireless child modules to demonstrate communication, distance measurement, sensor boards, and differentiation between multiple children.

2 One base station MOTE

The base station will be an independent, wireless MOTE that communicates with the child modules and caretaker module. It will be responsible for calculating the distances of each child and alerting all units to danger conditions

3 At least one Caretaker Module

The caretaker will be a MOTE connected to a laptop for data representation. The parent will send and receive data to and from the base station and display necessary information via a terminal window on the laptop

4 Water Detector

A simple water detector will be connected to I/O pins on the child MOTE to signal the danger of the child module “falling” into water. Two leads would presumably represent two metal contacts on the outside of a water-proof child module.

5 User’s Manual

A user’s manual will instruct a typical end-user in the operation of the Multiple Child Tracking System. It should be understandable by anyone with a junior high or higher education level.

6 Technical/Maintenance Manual

The technical manual will include all the technical specifications of the Multiple Child Tracking System. Basic maintenance requirements will also be included with information on keeping the system functional. It will require a minimal high school level of education and a familiarity with electronic systems and communications.

Approach Used

The project team has decided to use Crossbow Technology Inc’s MOTEs. These small microprocessor/radio boards are easily programmable and have the basic requirements needed for this project, described in this section.

1 Design Objectives

1 Base Station

This module will be implemented on a MOTE. Using a computer it will be programmed to have knowledge of up to six 30-bit child module identification numbers. The base will send a “PING” message to the first child it has knowledge of. It will then start a clock counter. If the base does not receive a “PING RESPONSE” message within a set time it will transmit another but different “PING” message and start a counter. If the base does not receive the expected “PING RESPONSE” it will transmit an “ALARM” message which will be received by both the caretaker module and the child module. The base will set that child’s status to “ALARMED.” The base will cycle through each child-identification that it has knowledge of. If the module cycles to a child whose status is “ALARMED” it will resend the “ALARM” message. The retransmission of the “PING” message will improve the amount of false alarms at the cost of a slower response time.

The module will be ready to receive “DANGER” messages from any child module. If the base module receives an “DANGER” message from a known child module, the base will transmit an “ALARM” message that will be received by both the parent and the child modules. If the module receives a “DANGER” message from an unknown child module it would do nothing. This is a possibility if two systems were to be in close proximity of each other.

The module will receive “ALL SAFE” messages from the caretaker module. After receiving this message the base module will set all states to safe. It will also cease transmission for a set amount of time, so as to avoid thrashing of alarm states on the caretaker module. After the set period of time has past the module will continue cycling through sending “PING” messages.

The end product will have the ability to be connected to a computer to display the status of each child module as well as other relevant information such as the set amount of time allowed for response and response times of child modules. The end product will have the ability to function separated from the computer as well.

2 Caretaker Module

This module will be implemented on a MOTE. It will have a speaker connected. Using a computer it will be programmed to have knowledge of the same child identification numbers as the base unit. This module will receive “ALARM” messages from the base unit and sound an alarm using the speaker. When this happens it sets its knowledge of the child to a state of alarm. It will continue to sound the alarm until the caretaker trips a trigger, which signals an all safe state. When this trigger is tripped the caretaker module resets all the child states to safe and sends an “ALL SAFE” message to the base unit. After a period of time it will retransmit the message and set all the states to safe. This is to eliminate a thrashing effect between safe and alarmed states which could occur if the caretaker module and the base unit try to send an “ALL SAFE” and an “ALARM” message, respectfully, at the same time.

The caretaker can trigger the “ALL SAFE” message at any time. If a child module is still in a state of danger, the next time it receives a “PING” it will not respond, thus causing it to return to an ALARM state. This allows a caretaker to disable one alarm even if multiple alarms are triggered.

The end product will be able to be attached to a computer for demonstration purposes. The interface will show the states of each child as well as any other relevant information.

3 Child Module

This module will be implemented on a MOTE. Using a computer it will be programmed to have a unique 30-bit identification number. It will have a water detector and speaker connected to it. If the sensor detects water it will cause the child module to transmit a “DANGER” message to the base module and it will sound an alarm using the speaker. It will continue to retransmit the “DANGER” message until it receives an “ALARM” message, which indicates that the base module has received the “DANGER” message. It will continue to sound an alarm until it is no longer detecting water and it receives a “PING” message, which would indicate the base module informing the child module to disable the alarm.

After the child module receives a “PING” message, it will transmit a “PING RESPONSE” message. This response will echo back a section of the “PING” message so that the base module can differentiate which “PING” the response correlates to.

2 Functional Requirements

The following requirements are the basic operations of the Multiple Child Tracking System.

1 The base station shall be the center of the safety perimeter

The system tracks children within a specified distance from the base station. This allows the caretaker the flexibility of moving around without changing the area that is designated to be safe based on the proximity from the base unit.

2 The caretaker shall be alerted to any child wandering outside of the safety perimeter

The primary function of this system is to keep children within a certain radius of the base station. The system should alert the caretaker if this condition is not met.

3 The child module shall alert the base station, which in turn alerts the caretaker module, if a child falls into water.

Electrical contacts on the child module will detect the presence of water and relay this danger information on to the caretaker.

4 The base module should alert the caretaker module if the child unit loses battery power.

The base unit will interpret this as the same alarm as the child being outside of the acceptable proximity because the child will not be responding to the PING messages within the allotted time.

3 Design Constraints

The following constraints come from the Crossbow MOTEs’ hardware limitations as well as the projects assumptions and limitations.

1 The modules shall operate at a frequency of 433 MHz.

Crossbow MOTEs are available in 315, 433, and 916MHz modules. For this project, 433 MHz modules will be used because they have a larger outdoor range and fall within the unlicensed frequency allotted by the FCC.

2 The system shall be able to track children up to 750 feet away.

At 433MHz, the MOTEs have an out-door range of 1000 feet. An upper-limit of 750 feet should allow for variations in this device’s maximum range.

3 Programming for any module shall be no more than 128KB.

The MOTEs have 128KB of programmable flash memory, so, obviously, the programming cannot exceed this size. At runtime, an additional 512KB of memory are available for use, but cannot be programmed with operating instructions.

4 Technical Approach Considerations

The project team considered several approaches to producing the Multiple Child Tracking System before deciding on the final design.

1 PDA Programming / Using Existing Radio Modules in PDA’s

The PDA was thought to be used by interfacing sensors and other necessary devices to the PDA through its expansion slots. This will eliminate the need to implement a computational module for the system from a microcontroller or from scratch which will take a lot of time. Another attractive thing about the PDA that led to the consideration is its small size and portability, which fits in nicely as the role of the parent module of the system. Besides that, the computational power of the PDA may allow additional features that can be added to the parent module or base station such as computing the relative location of the child modules or displaying the positions of the child modules visually.

Unfortunately, it is not feasible to use PDA because at this time there is still no existing hardware in the market that we can used to fully implement the system along with the PDA. Although there are devices in the market that interface into a PDA, none of them has the sensors that can implement the features of the system or is flexible enough to allow add-ons of additional devices. It follows that an interface that can be used with a PDA to implement the system has to be built from scratch. However it will take a lot of time and effort to build this interface, which will possibly disrupt the project schedule and also defeats one of the main purposes of using the PDA in our system.

2 Modifying the Gotcha® RFID Child Safety Device

Figure 3-1 Gotcha Child Safety Device

Gotcha® is an existing system used to track children in a perimeter around the parent. Initial communications between the senior design project team and National Scientific Corporation (NSC), creators of Gotcha® indicated some possible assistance from NSC in the design project. Perhaps a water sensor could be created, along with a base station, so a safety perimeter could exist around a fixed point, rather than a mobile parent. Unfortunately, further communication and results did not occur in time for End-Product design. The team needed a design strategy and there was not yet enough information from NSC to consider proceeding in that direction.

3 Building distance-measuring modules from scratch

The project team had the opportunity to design and build modules that would have sensors, a transmitter, a receiver, and a microprocessor. The project team would have had to design a device that was effectively a simple MOTE before ever attacking any of the distance-measuring issues. Time and cost needed for designing, ordering of parts, and waiting for delivery were taken into consideration. Given the time constraint and the team’s background in communication, this approach was not considered favorable. The team does acknowledge the possibility of a future team building the mentioned simple MOTE specifically to have our design implemented on it.

4 Programming Crossbow MOTEs

The project team ultimately decided to use existing hardware from Crossbow Technology Inc. Existing processor/radio boards available in the Coover Wireless Sensor Networks laboratory will be programmed to act as a Multiple Child Tracking system.

Figure 3-2 - Crossbow MOTEs - MICA2 and MICA2Dot

The MOTEs were selected primarily because of their availability. Very little money will have to be invested in this project, and the team will greatly benefit from the experience of working with a new and emerging technology.

5 Testing Approach Considerations

End-Product testing is necessary to ensure correct functionality of the product. The team will test in two phases. The first phase involves testing the product in the laboratory where it was created. Each subsystem will be tested with a set of expected outcomes to be developed in the testing phase. At the end of lab testing, the basic functionality of the project should work

Once the system is fully operational, it will be tested in conditions more applicable to real use. The range will be tested outside as well as testing how different obstructions such as walls or trees affect it. The result of this additional testing will be a knowledge of how the product behaves in the real world. Recommendations can then be made concerning future work on the project including developing housings to contain the MOTEs and making the system work outside of a laboratory environment.

6 Project Continuation/Modification Recommendations

The initial scope of the project was to create a fully-functional multiple child tracking system. While this project is still creating a prototype of the final model, it will not be creating actual devices to be worn by children. A future project could be created to design the actual weather-proof housing for modules and a compact user interface from which to administrate the system. Also, the MOTEs used in this design are significantly more expensive than an average family could afford. Another step could include scaling down the system and creating mini-MOTEs designed for just this use.

Detailed Design

1 Computations and Analysis to be Performed

1 Radio Distance Measuring

Distance will be approximated by a time-of-flight system. The base sends the child a “PING” message and then the child will respond with a “PING RESPONSE” message. The base will measure the time from its transmission to its reception of the “PING RESPONSE.” During this time the message will have had to propagate to the child, been processed by the child, and then a new message will have propagated back. Therefore: [pic] Noting that the speed of propagation is equal to the speed of light. The Processing Time can be calculated once the modules are able to measure the time it takes to PING and PING RESPOND. By taking time measurements at one distance and then comparing them to time measurements at other distances an average processing time can be calculated. The modules themselves will have no actual knowledge of distance; they will be programmed with a maximum allowed time for a response. This time would correlate to a distance as the user is concerned. It could be possible to program different time allowances for different child modules. This could be used to allow more responsible children a greater acceptable proximity.

3 Bit Assignments

Each packet will contain 64 data bits

The first two bits (bits 0 and 1) will be the “TO TYPE” field

01 – indicates the message is to be received by a child unit

10 – indicates the message is to be received by a base unit

11 – indicates the message is to be received by both the child and caretaker

The next 30 bits (bits 2-31) contain the child’s identification number (CIN). This equates to which child a “PING” is directed to, which child a “PING RESPONSE” is from, and which child is the reason for an “ALARM” message.

The next 4 bits (bits 32-35) contain the type of message.

0101 – indicates a PING message

1010 – indicates a PING RESPONSE message

1100 – indicates an ALARM or a DANGER message

0011 – indicates an ALL SAFE message

For a PING or PING RESPONSE message bits 36-39 are used for an identifier. The base will assign a 4 bit value to send as part of the PING and the PING RESPONSE will echo this 4 bit value. In the event of a retransmit by the base this 4 bit value must be different than the original transmission’s 4 bit value.

For an ALARM message bits 36-39 will be used to indicate which type of alarm.

0011 – Indicates child not responding (dead battery) or not responding fast enough (out of proximity)

1100 – Indicates child is wet.

Bits 40-63 will alternate 0 and 1 value for this elaboration. Future elaborations of this project can use these bits to describe additional alarm messages or to transfer other information such as voice messages.

An “ALL SAFE” message will insert any of the known child identification numbers in bits 2-31. This way the base module will not set children status to safe due to another system’s all safe message.

2 Assumptions

1 Additional children can be added and differentiated by a unique ID

2 Walls, trees, or other obstructions will increase the time it takes to transmit a message

3 Caretaker modules could be added by programming two MOTEs as “caretakers” with the same ID.

3 Limitations

1 The maximum voltage for any sensor circuits will be 3V.

2 The system must be able to track children at varying distances up to 750 feet away.

3 Programming code for each MOTE must not exceed 128KB

4 Communication Flow-Charts

The following flow-charts illustrate communication in each of the three main modules.

Figure 4-1 Base Module Communication Flowchart

Figure 4-2 Caretaker Module Communication Flowchart

Figure 4-3 Child Module Communication Flowchart

5 List of Inputs

1 Base Station

• Power Switch

• Communication Packets from Caretaker/Child Modules

2 Caretaker Module

• Power Switch

• Communication Packets from Base Station

• All-Safe (Reset Alarms)

3 Child Module

• Power Switch

• Signal from Water Sensor

• Communication Packets from Base Station

6 List of Outputs

1 Base Station

• Communication Packets to Caretaker/Child Modules

2 Caretaker Module

• Communication Packets to Base Station

• Speaker to sound alarms

• Indicator of each child’s status

3 Child Module

• Communication Packets to Base Station

• Speaker to sound alarms

7 User Interfaces

1 Base Station

The base station has no needed user interface besides needing to be powered on and off, which is accomplished by a power switch on the Crossbow MOTE.

2 Caretaker Module

The user interface that is intended for the parent module will be represented by a textual user interface that will be used to monitor the operation of the system on the computer. The computer will be emulating a small LCD screen that will be used to display the settings, messages and alarms. There will also be six switches, one for each child module. Each switch will be used to enable or disable the respective child module at any time. Another switch will be used to stop an alarm when it has been set off.

3 Child Module

Figure 4-4 - MTS300 Sensor Board

The child modules primary user interface is the alarm that sounds to aid the caretaker in locating the child. This will be achieved through a sensor board that connects directly to the Crossbow MOTE.

8 Testing Activities

The following are the basic tests that will be needed to ensure accurate functionality of the system.

1 Communication between modules.

These tests will involve the radio communications between the MOTEs. They will include range tests to see how long it takes messages to travel to and from a destination and interference tests to see how the product handles different types of radio interference.

2 Distance Measuring

Once communication is working properly, the main goal of the project is to see if any children are outside of the set bounds. Distance testing will determine how different objects, such as trees or walls, affect the measurement algorithms.

3 Water sensor testing

Testing of the water sensor will determine if it can accurately detect the presence of water. It also involves finding out how much contact with water is needed to trigger the alarm.

4 Battery Life

The total run-time of the system should be tested by measuring the battery drain. The MOTEs have an internal system to check battery life, so tests can determine how long the product will function under normal conditions.

Resources

1 Personnel Effort Requirements

Early personnel effort were difficult estimations due to lack of prior experience with design projects. Most tasks were split evenly among group members. Through the last three tasks, different members’ strengths and weaknesses have arisen that contribute to a more accurate personnel effort estimation. Role differentiation has also occurred. One risk avoidance tactic, the team is using, is to not have one person be the sole member working on any one major component, therefore our efforts will overlap but some generalizations can be made about the roles of each member. Flessner’s effort level should reflect the fact that he is the lead on communications and documentation. Hammell is the team’s leader and some of his efforts will be organizational and concerned with the high level design. Shao will be taking the lead on the sensors, both the ones already on the MOTEs and the water sensor that will be built by the team. Lee will be the lead for the interfacing between MOTEs and the computer. These are just generalizations though and all members will put forth effort in all aspects of the project to some degree.

Table 5-1 - Previous Personnel Effort Estimation

|Task # |1 |2 |

|Project Poster |$50 |$50.00 |

|Existing system for review |$90 |$90.00 |

|Parts |$100 |$100.00 |

|Flessner | |$1837.50 |

|Hammell | |$1732.50 |

|Lee | |$1732.50 |

|Shao | |$1732.50 |

|Total |$240 |$7275.00 |

Table 5-4 - Revised Project Cost

| |w/o Labor |with Labor |

| | |@ $10.50/hr |

|Project Poster |$52.80 |$52.80 |

|MOTE Kits |donated |Donated |

|Parts (Sensors) |$15.00 |$15.00 |

|Flessner | |$2677.50 |

|Hammell | |$2467.50 |

|Lee | |$2205.00 |

|Shao | |$2257.50 |

|Total |$67.80 |$9,685.30 |

Schedules

1 Project Schedule

The following are comparisons between the early project schedule estimates and the new, revised schedule, including completed work, and refined scheduling with regard for new project scope and academic holidays

The first page shows comparisons in the major tasks only, while the next two pages display all sub-tasks.

[pic]

Figure 6-1 - Previous Project Schedule – Major Tasks Only

[pic]

Figure 6-2 - Revised Project Schedule – Major Tasks Only

[pic]

Figure 6-3 - Previous Project Schedule - Detailed

[pic]

Figure 6-4 - Revised Project Schedule - Detailed

Closure material

This closure material consists of client, faculty advisor, and team information, as well as a project summary and references.

1 Client Information

Senior Design, Iowa State University

Dr. John W. Lamont Prof. Ralph Patterson III

324 Town Engineering 326 Town Engineering

Ames, IA 50012 Ames, IA 50012

(515) 294-3600 (515) 294-2428

jwlamont@ee.iastate.edu repiii@iastate.edu

2 Faculty Advisor Information

Dr. Diane Rover

3227 Coover, Iowa State University

Ames, IA 50010

(515) 294-7454

drover@iastate.edu

3 Student Team Information

Benjamin Flessner – CprE

6118 Frederiksen Ct.

Ames, IA 50010

(515)572-7787 (Landline)

(515)460-3569 (Cell)

fessner@astate.edu

Allan Hammell – CprE

307 Ash Ave Apt 212

Ames, IA 50014

(515)231-0250 (Cell)

ahammell@iastate.edu

4 Closing Summary

Although there is no substitute for good childcare, which would include constant monitoring, the reality is that constant monitoring of children is not feasible, especially when a caretaker must monitor multiple children at the same time. When it comes to something as important as the safety of children, having another safeguard is a welcome assistance to any caretaker. Similar products on the market do provide some of this assistance but do not have all of the functionality that this project will provide.

1. References

1 CROSSBOW MOTES – WIRELESS SENSOR NETWORKS



2 Gotcha® by National Scientific Corporation

Product web site:

3 Senior Design Course Notes – Iowa State University

Available at

-----------------------

Iwin Lee – CprE

233 Sheldon Avenue #2

Ames, IA 50014

(515)292-1413 (Landline)

iwin@iastate.edu

Hua Shao – EE

207 Lynn Ave 10

Ames, IA 50014

(515)441-6172 (Cell)

shaohua@iastate.edu

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download