Project Proposal.docx - Rochester Institute of …edge.rit.edu/edge/C12404/public/docs/Project Proposal.docx · Web viewTWx TWx is a tweeting, sensor-agnostic data logger with an

TWxTWx is a tweeting, sensor-agnostic data logger with an array of weather sensors.

Jeffrey MyersCasey SchaertlFloripe Padua

February 16, 2013

TWx 2

Table of ContentsOverview..........................................................................................................................................4

Needs Statement.......................................................................................................................4Objective Statement.................................................................................................................4Description...............................................................................................................................4

Requirements Specification.............................................................................................................5Concept Selection............................................................................................................................6

Existing Sensing Systems.........................................................................................................6Patent Search............................................................................................................................7Concepts...................................................................................................................................8

Overall.................................................................................................................................8Communications..................................................................................................................8User Interface.....................................................................................................................10Code Development............................................................................................................10Power.................................................................................................................................10Types of Sensors................................................................................................................11

Design............................................................................................................................................12Engineering Standards............................................................................................................15Background............................................................................................................................15

Computer Engineering Coursework..................................................................................15Multidisciplinary Background...........................................................................................16Outside Contributors..........................................................................................................16

Other Constraints and Considerations...........................................................................................16Extensibility............................................................................................................................16Manufacturability...................................................................................................................16Reliability...............................................................................................................................16Global.....................................................................................................................................16

Cost Estimates...............................................................................................................................17Testing Strategy.............................................................................................................................18

Subsystem Testing..................................................................................................................18Communications.....................................................................................................................18

Unit Tests...........................................................................................................................18Integration Tests................................................................................................................19

TWx 3

User Interaction......................................................................................................................21Unit Tests...........................................................................................................................21Integration Tests................................................................................................................22

Power/Hardware.....................................................................................................................23Unit Tests...........................................................................................................................23Integration Tests................................................................................................................23Acceptance Testing............................................................................................................24

Risks..............................................................................................................................................25Milestone Chart.............................................................................................................................25

TWx 4

Overview

Needs Statement

Current data loggers offer no easy means of accessing the information they are collecting without immediate physical access to the device. Furthermore, they tend to be expensive, tied to specific sensors, and offer limited means of extending the system. Weather stations suffer some of the same drawbacks and some sensors are expensive. There is a need for a low-cost, embedded, sensor agnostic data logger with a means of remote access to the data being collected and the ability to connect to a number of weather sensors.

Objective Statement

The objective of this project is to produce a low-cost, sensor agnostic data logger that can remotely access information from a number of weather sensors.

Description

TWx will combine an array of pre-made transducers for such data as relative humidity, temperature, and barometric pressure. These sensors will be modular in nature and will be hot-pluggable for the addition of new sensors on the fly. The host will be a configured Raspberry Pi communicating with sensors through other microcontrollers. These microcontrollers will do the necessary harvesting of data and act as generic endpoints, which will push updates to the Raspberry Pi host. The Raspberry Pi will also expose an interface for remotely dispensing the data. This interface will include a Twitter command/update set and may include a local GUI for local configuration and management of sensors.

Figure 1: High Level Diagram

TWx 5

Requirements Specification

Table 1: Marketing Requirements

# Description1 Sensors should be able to be easily added or removed.2 Sensors should be able to have remote placement.3 The system should support sensors regardless of the data provided.4 The system should be low cost.5 The system should Tweet results.6 The system should be responsive to incoming Tweets.7 The system should be remotely accessible.8 The system should have weather related sensors.9 The remote sensors should have a long battery life.

Table 2: Marketing and Engineering Requirements

Marketing Requirements

Engineering Requirements Justification

8, 2, 4

1. There should be temperature, humidity, and barometric pressure sensors.

2. The system should leverage a low-cost means to provide remote sensing capabilities.

The system should have a number of available sensor modules which can be remotely placed.

5, 6, 73. There should be a unit, which is

connected to the internet.In order to access the data remotely and to Tweet, an internet connection is needed.

1, 2, 3, 4

4. The system should abstract sensors as “Endpoints.”

5. Endpoints should be permitted to perform any action they require, which does not interfere with any other host to endpoint operations.

6. The system should leverage a low cost means to communicate to endpoints.

An abstraction of sensors allows data to be passed without the Host knowing what the sensor is. An endpoint would also be able to have better remote placement and could allow for hot-plugging of sensors.

6 7. The system should respond to incoming tweets.

8. The system should respond within 30 seconds for update requests.

9. The system should configure

The system needs to have some useable time limits; if it takes too long to update, it is of no real use. If it takes too long to configure, the system may enter an unstable state.

TWx 6

within 15 seconds of an incoming configure command.

4,2,9 10. The power source for the sensors should be a battery.

The use of batteries in the sensor units would be cheaper than any solar panel, which would be able to supply enough power to operate. The use of batteries would also make it possible to move the sensors where they would be needed, and, with the correct battery, the unit would be able to operate for a relatively long period of time.

7 11. The host should have an AC/DC power supply.

In order to access the data remotely and to tweet an internet connection is needed. With an internet connection needed the host is going to need a constant supply of power. Therefore a power supply, which is connected to a wall outlet, would fulfill the power requirement the best.

1 12. The transceivers that are connected to the host should be connected to a USB power hub.

The use of a USB power hub would supply enough power to the transceivers, which connect directly to the host. The host would not be able to supply enough power, and since these transceivers are stationary, a battery would not be the best option.

Concept Selection

Existing Sensing Systems

Wireless Thermometers (example: Springfield Instruments 91455 Wireless Thermometer): These typically measure temperature and humidity via a remote sensor and a base unit with an LCD display. These relate to the project in that they have a temperature sensor remotely communicating with a base station. However, they do not typically support additional sensors and have no capacity for reporting status via the internet.

Weather Stations: Although these do report to a centralized website, the scale of these is outside our budget. They also do not allow users to move the sensors or add their own.

TWx 7

AccuWeather Twitterbot: This service does allow you to check weather via a twitter message (as our project will), but tweets are public, and the most precise location allowable is city location since users do not have their own customizable sensors.

Tweeting Letterbox: James Medd used a Raspberry Pi to tweet an image when it detected movement. Using a webcam, he configured it to tweet him an image of mail when it was delivered through his mail slot. His program used the Python language and libraries. Like our project, the letterbox used a sensor connected to a Raspberry Pi to tweet information.

Oregon Scientific WS831DL: Allows the user to take several measurements from a remote location. It only supports the addition of up to five extra temperature/humidity sensors. It operates using the 433-MHz RF band. Presumably, the 433-MHz band is used as it is reserved as license free in most locations and is designated for short range, low power devices such as a weather station. Since the device is proprietary, it cannot be determined how the measurements are taken or in what way the measurements are transmitted.

SparkFun USB Weather Board: Performs data logging as a USB device. It contains on the board temperature, ambient light, relative humidity, and barometric pressure sensors. The device has expansion headers for connecting rain gauge, wind speed, and wind direction sensors. It expects specific sensors on the board, but the computer reading the information for relaying and actually logging can be configured appropriately to relay and dispense the data as desired. Everything is performed over wired connections.

General Tools WMR200A: Similar to the WS831DL but it allows for up to 10 additional temperature/humidity measurements.

Patent Search

US patent #8,339,901 specifies a mechanism for remotely controlled weather stations; it uses GPS signals to convert time information for a particular location when weather data have arrived. The devices being remotely controlled in the patent are the receiving/display devices rather than the weather station itself. It does not utilize any pertinent technology to this project as time information is always taken locally at the station. Additionally, the project does not infringe on the patent as this project intends on controlling and configuring the host data logger remotely.

US patent #8,321,337 defines methods for identifying embedded systems to a central server on the premise that embedded systems connected to the internet do not possess the necessary resources to complete complex transactions. The embedded systems could then be queried through the central server, which would provide a relation between queries to the embedded devices, the person querying the device and a price associated with the lookup. This patent assumes the embedded devices are connected directly to the internet.

US Patent #8,330,596 protects the wireless transmission of waveform information from wireless biological sensors. It is a more complicated system, which also describes a means to store temporary information at the sensor in the event wireless transmission is unavailable in addition

TWx 8

to various compression techniques. Data from this system may not be described in waveforms but care must be taken to ensure the transmission of information does not infringe.

Concepts

Overall

Table 3 below shows the main design decisions we made with this project. Several ideas were considered, and the favorites were chosen and are highlighted.

Table 3: Concept Table

User/Client Interface with Base

Sensor connection to Base

Base connection to Internet

Power Types of Sensors

Remotely via Twitter USB Wired Ethernet Solar Wind Direction/Speed

Remotely via smartphone app

I2C WiFi Wind Humidity

ZeroMQ or other Message Passing Middleware

Ethernet (WiFi) Cellular Battery Barometric Pressure

Wall power Rain GaugeTemperature

Each specific section of the project involved more detailed concept selection, and those are explained below in their respective sections. Note that not all decisions require tables, and are simply explained in text.

Communications

The decision matrix shown below in Table 4 indicates the best Host to Endpoint communication mechanism is USB. It provides an inexpensive means of producing a hot-plugging modular design and allows for relatively easy implementation. I2C loses on ease of implementation due to the difficult algorithm that would be required to allow hot-plugging of devices. It also fails to allow slaves to push updates and would require constant polling of the devices. WiFi connections could also be used but significantly increase the cost of each sensor.

Table 4: Decision Matrix for Host to Endpoint Communication

USB I2C EthernetCost (.4) .35 .5 .15Modularity (.3) .6 .05 .35Ease of Implementation (.3) .4 .3 .3Score: .44 .305 .255

TWx 9

To achieve a wireless connection, if desired, the microcontroller endpoint could communicate with the host via USB and the sensor via XBee, WiFi or generic RF communication. These three options are weighed in Table 5 below.

Table 5: Remote Sensor Decision Matrix

Generic RF XBee Wireless EthernetCost (.4) .6 .25 .15Ease of Implementation (.3) .25 .35 .4Modularity (.2) .2 .4 .4Expandability (.1) .2 .4 .4Score: .375 .325 .3

The result shows a generic RF protocol is the best option for enabling remote sensing capabilities. The cost savings associated with a generic RF connection outweigh the difficulty in configuration to make the system more expandable and modular. Because the sensors will be communicating on a common RF band, the sensor package may be a single endpoint to simplify the protocol being developed. This is similar in nature to the sensors’ existing systems use; typically they are bundled in a single package, which is set in a known location. Additional sensors are limited and exist on different channels in the band. XBee and WiFi effectively allow an unlimited number of devices as they offer a larger network at a significant price and complexity increase.

Connecting the Raspberry Pi itself to the internet will be done via wired ethernet or WiFi. WiFi is preferred as it is often more convenient than running wires to a particular host base station. Cellular connectivity loses as it is significantly more expensive. Since the host is a Raspberry Pi, it would be relatively easy to add support for other connectivity. The choice of Wifi adaptor was narrowed to two choices based on recommendations of other Raspberry Pi developers, and the final decision was made using the weights in Table 6. The Edimax adaptor was chosen as the better choice.

Table 6: Choice of Wifi Adaptor

AirLink Edimax

Cost (.3) .4 .6

Ease of Use (.5) .5 .5

Availability (.2) .5 .5

Score: .47 .53

TWx 10

User Interface

A smartphone app may present a better user experience, but would require more development time and require that the end-user have a smartphone with a supported OS. Since this project interfaces with the user via Twitter, the user has the option of using a wide variety of devices to communicate with the product. The decision matrix for this choice is shown below, in Table 7.

Table 7: Decision Matrix for User/Client Interface with Base

Twitter Smartphone App Message-Passing MiddlewareDev Time (.5) .4 .2 .4User Experience (.2) .4 .4 .2User Accessibility (.3) .7 .2 .1Score .49 .24 .27

Code Development

The choice of language was limited to the ones that the Twitter API would support. Of these choices, a few languages were chosen based on the developer’s familiarity with the language and expected ease of implementation. Java was chosen for its strong type safety and being an object oriented language. This mitigates software development issues as it is less lenient than Ruby or Python. Additionally, Java offers numerous libraries to add features as well as the Oracle Embedded JRE, which is capable of producing a much faster and more responsive application than Ruby or Python.

Power

There are many ways to power a device such as by wind, solar, battery, and standard wall outlet. Each of these power sources has its advantages and disadvantages. When deciding which power source to use a few conditions must be considered. The cost of the device (how much it will cost to purchase the component/device or kit), the simplicity of implementation (how easy it will be to tie the power source with the device), and modularity (how portable the device would be with the given power source). These characteristics are rated below with the higher number being more costly, harder to implement, and harder to move, respectively. A table of these design choices is shown below, in Table 8.

Table 8: Decision Matrix for Power Sources

Wind Solar Battery Wall Outlet

Cost(.4) .40 .40 .08 .12

Ease of Implementation (.3)

.50 .30 .10 .10

Modularity(.3) .35 .20 .10 .35

Total .42 .31 .09 .18

TWx 11

Wind: Using a wind power source requires some construction of the device and a source of wind. It can also operate only within a range: its minimum and maximum wind speed conditions. Mobility is also limited due to its relatively large size. Due to all the components it entails, using wind as a power source can also be costly.

Solar: Using a solar power source requires sunlight and a large surface area to get enough output power, which, in turn, decreases the mobility of the device. Requiring a larger surface for more power output can also increase the cost of the device.

Battery: Using a battery as a power source is very low-cost and can be easily implemented into the system. Batteries are relatively small, which increases mobility and portability.

Wall outlet: Using a wall outlet as a power source is also very low-cost and can be easily implemented into the system. There is a constant supply of power so there is no need to adjust the source once it has been plugged in. However, the mobility of the source is limited as the device needs to be near a wall outlet at all times.

Taking all these characteristics and specifications into consideration, the best power sources are the battery and the wall outlet. Batteries are best for the sensors because they are low-cost and easily implemented, but more importantly, they are extremely mobile and portable. The wall outlet is the best power source for the host because it is also relatively low in cost, can be easily implemented into the system, provides a constant flow of power, and does not need to be mobile as the host will be placed in a stationary location.

Types of Sensors

Due to the modular nature of our project, we have a wide variety of sensors to choose to develop. These we rank in order of importance in Table 9 and will develop as many sensors as time allows. The “Importance” row is an extra category, which gives weight to how necessary some features are to the product. Higher numbers indicate lower cost, more availability, more importance, and lower development time.

TWx 12

Table 9: Decision Matrix for Sensor Modules

Wind Direction/Speed Humidity Barometer Rain Gauge TemperatureCost (.3) .15 .15 .15 .05 .5Availability (.3) .2 .2 .2 .2 .2Dev Time (.25) .2 .25 .25 .05 .25Importance (.15) .15 .3 .2 .05 .3Score .1775 .2125 .1975 .095 .3175Overall Rank 4th 2nd 3rd 5th 1st

Design Figure 2 (below) shows the overall system. The inputs to the system are the current weather status, tweets from the user, and middleware requests. The outputs are middleware messages and Twitter updates. The functionality of the TWx system is it reads the current weather conditions and publishes a Twitter update at regular intervals or when the user tweets at it.

Figure 2: Level 0 Diagram

Figure 3 is a more detailed look at the parts of the TWx system from Figure 2. The major parts of this design are the sensors and their host. The sensors read the weather information and transmit their formatted results to the host. The host in turn tweets this information at appropriate time intervals. When the user tweets at the system, the host reads the tweet and sends out the most recent report it has received from the sensors.

TWx 13

Figure 3: Level 1 Diagram

Figure 4 below represents the power distribution and layout for the sensor units. This particular instance shows an RF module placed between the data acquisition microcontroller (an MSP430) and the Endpoint. The microcontroller will receive data from the sensor which will the send it through the RF transceiver to the Host/Endpoint. This unit is powered by three AA batteries and a voltage regulator to supply a constant 3.3 V.

TWx 14

Figure 4: Example Sensor Module Subsystem

The primary user interface for the system will be through Twitter. Various commands will be issued by authorized users using directed tweets. The system will react to these tweets to configure the system or to immediately issue updates. This software flow is detailed below, in Figure 5. A GUI may be added for local configuration and management of sensors in addition to display of information.

Figure 5: Software Operational Flow Diagram

A timing diagram between the Sensor microcontroller and the Endpoint Microcontroller is shown in Figure 6.

TWx 15

Figure 6: RF Protocol Operation

Engineering Standards

This project will incorporate USB for hot-pluggable sensors; the protocol is well defined and designed for that purpose. Some sensors may utilize the Serial Peripheral Interface (SPI) bus. It will also utilize wifi for connection to the internet and Twitter.

Background

Computer Engineering Coursework

This project has several aspects that fall directly into Computer Engineering curriculum. Applied programming will be useful for low-level programming of microcontrollers. Software engineering will be useful to develop a high quality framework to extend the sensor system with documentation for future development.

TWx 16

Multidisciplinary Background

In addition to the CE curriculum, Principles of Distributed Software Systems will also be applicable in this project as the sensor network and the interaction between users and host will be done in a distributed manner. Real-Time and Embedded Systems and subsequent courses will be of use in development. The only other multidisciplinary aspect foreseen is in developing the sensor hardware. However, we can draw on our electrical engineering coursework and lab work to accomplish this if additional sensors are to be developed.

Outside Contributors

We do not plan on including outside contributors at this time.

Other Constraints and Considerations

Extensibility

The design is highly extensible. It allows additional sensors to be developed and added. The host will be developed to accept inputs in several forms, agnostic of the actual sensor doing the measurements.

Manufacturability

This modular design also adds a high degree of modularity making the device more manufacturable. Each module is an independent subsystem, loosely coupled to the host of the end product.

Reliability

Reliability of the end system is dependent on the reliability of the sensors used. While high reliability is desirable, components wear out over time and break. Due to the high degree of modularity and hot-plugging feature, the device is easily repaired on the fly if necessary. The end result will be an open-source framework for remote data logging. The product strives to provide developers a solution that can be extended as needed rather than a solution with a limited set of tools.

Global

The project also connects the world on a smaller scale through the internet. The ability to lookup personal, local weather information on any phone from any location is unique. The device will not be marketed for military or espionage reasons, as it will not be designed with concealment in mind and has a limited range between sensors and the (rather large) Raspberry Pi. The degree of private or public access to information is a user decision, as the product will support either. This project could be used for environmental reasons, to closely monitor climate trends or habitat conditions.

TWx 17

Cost Estimates

Part Name Part Description Quantity Unit Cost Total Cost Our Cost Availability

Transceiver Module (430BOOST-CC110L)

A low-power RF wireless transceiver extension kit for use with the MSP430G2

1 $19.40 $19.40 $19.40 Ordered-Awaiting arrival

Digital Barometer (MPL115A1SPI)

A simple barometer with digital output and high performance targeting low cost applications.

1 $15.94 $15.94 $15.94 Received

Humidity Sensor (HIH-5030-001)

Low voltage humidity sensor, operates down to 2.7 Vdc. Near linear voltage output.

1 $6.03 $6.03 $6.03 Received

Temperature Sensor (TMP36)

Low voltage, precision centigrade temperature sensor. Provides a voltage output, which is linearly proportional to the Celsius temperature

1 $1.50 $1.50 $1.50 Received

TI MSP430 Launch pad (MSP430G2553)

Ultra low-power microcontroller with built in 16-bit timers, up to 24 I/O touch-sense-enabled pins, a versatile analog comparator, and built in communication capabilities.

4 $4.30 $17.20 $8.60 2x Already Owned

2x Ordered - awaiting arrival

TI Stellaris Launch pad (LM4F120)

Low-cost microcontroller. Features programmable user buttons and an RGB LED for custom applications.

2 $12.99 $25.98 $0 Already Owned

Raspberry Pi(Model B)

A little PC-like device, which can be used for many small applications. In our case a data logger.

1 $35.00 $35.00 $0 Already Owned

USB HUB (F5U233-APL)

BELKIN F5U233-APL Hi-Speed USB 2.0 4-Port Hub

1 $23.00 $23.00 $23.00 Ordered-Awaiting arrival

Other Miscellaneous Components (USB Cables, Batteries… )

N/A $15.00 $15.00 N/A

Total $159.05 $89.48

TWx 18

Testing Strategy This section is separated into two primary sub-sections; the first section is the list of subsystem tests which are to be performed for the three main subsystems in the weather station. These individual subsystem tests are broken into two separate parts. The first part consists of the unit tests for the subsystem components. The second part consists of the integration tests, which combine the components that compose the subsystem. The document concludes with a description of the acceptance tests that also act as the integration tests for the individual subsystems.

The tables are organized by the components being tested or integrated. The “Test” heading contains the procedure for testing the component(s). This heading includes an overview of the steps and the expected input. Sub-bullets represent the expected outcome of a particular step for verification of the functionality. The “Requirements Tested” heading maps the test to a specific requirement.

Subsystem Testing

Testing is performed on subsystems before integration in the final product; furthermore, within the individual subsystems testing is done on a unit-by-unit basis with smaller integration to test the subsystem completely before integration.

Communications

Communications in the system are composed of a few distinct steps. First, the sensor information is collected either by digital transfer in the form of SPI communication or by analog-to-digital conversion. This information is then passed via RF, as is the case with most weather sensors, or directly via USB. The USB interface between endpoints and the host are tested individually as is the RF communication.

Unit Tests

Component Test Requirements Tested

USB Communications

1. A simple program will exist to detect connecting USB devices.

2. This program will be capable of issuing commands to the device.

a. The program will output when a device is connected and provide some description of the device.

b. The program will be capable of communicating with the USB device and receiving information from it.

1. Auto-detection of sensor endpoints

2. General USB transfer of data

TWx 19

RF Communications

1. A simple program will exist between 2 microcontrollers.

2. The first microcontroller will transmit at a regular interval of 5 seconds. The second microcontroller will be listening for data.

3. When a button is depressed on the first one, it will transmit “255.”

a. When “255” is received by the second microcontroller, it will turn on an LED.

4. When the button is not pressed, the first will transmit “0.”

a. When “0” is received by the second microcontroller, it will turn off the LED

1. Remote sensor placement

2. Data transfer to and from the remote location

Sensor Communications (ADC)

1. A testbench consisting of a microcontroller and resistor with a potentiometer configured to produce a divided analog voltage will be used.

2. The microcontroller will continuously poll the ADC for the value being driven.

3. Output of this value will be sent to a virtual COM port to determine if the value is changing.

1. General sensor data acquisition

Sensor Communications (SPI)

1. A testbench consisting of a microcontroller and the SPI sensor module will be used.

2. The microcontroller will continuously poll the SPI sensor module for the value being read.

3. Output of this value will be sent to a virtual COM port to determine the validity of the signal.

1. General sensor data acquisition

Integration Tests

Integration will be performed in several phases. Integration of the RF module and the SPI-based sensor will be performed to determine if any conflicts exist on the SPI-bus between the RF module and sensor. Another, separate phase of RF testing, will take place as the remote microcontroller communicating via RF, will transmit to an endpoint connected via USB, which will report to the host. Connecting further with the ADC, the remote sensor will be able to update the USB endpoint with actual data.

TWx 20

Component Test Requirements Tested

RF + SPI Sensor 1. This test involves 2 microcontrollers, the RF transceivers and the SPI-based sensor.

2. See RF Communications Unit Test. The first microcontroller will no longer be looking at a push button; instead, the value obtained via the SPI sensor will be transmitted to the second microcontroller.

a. The second microcontroller will output this value to a virtual COM port to determine the validity of the sensor reading and RF communication.

1. The interoperability of certain sensors with the RF communications system.

RF + USB 1. This test involves 2 microcontrollers and the RF transceivers.

2. See the RF Communications Unit Test. The second microcontroller will not turn on and off an LED but instead communicate the status via USB.

a. Input shall be visible through the console.

1. This should uncover any issues with remote sensing applications.

ADC + RF + USB

1. Similar to the RF + USB test; this test will transmit actual read values over RF to be communicated via USB.

a. The second microcontroller will output the value to a virtual COM port.

1. This should uncover the effects of noise on sensors.

ADC + SPI (RF/Sensor) + USB

1. Final integration builds on all prior tests.2. Tests multiple packages simultaneously.

a. Should produce similar results from the above.

1. Tests interaction between modules if it exists.

TWx 21

User Interaction

Unit Tests

Description Test Requirements Tested

Connection to Twitter (write)

1. A simple program should run on the Raspberry Pi, which will tweet a short message when run.

a. The tweet should be visible on Twitter from an outside source.

1. The system should be remotely accessible.

2. The system should Tweet results.

Connection to Twitter (read tweet)

1. User tweets at RITWx.2. Raspberry Pi acknowledges the tweet

and prints the text to the terminal within 30 seconds.

1. The system should be responsive.

Connection to Twitter (read direct message)

1. User sends a direct message to RITWx.

a. Raspberry Pi acknowledges the message and prints the text to the terminal within 30 seconds.

1. The system should be responsive.

Posting status at regular intervals

1. A simple program should run on the Raspberry Pi, which tweets a message on a certain time interval.

a. When run for a sufficiently long time, there will be a record of tweets which can be verified.

1. One feature of the system is automatically updating without needing a request.

Software Configuration via Tweet

1. The user tweets a configuration message specifying the time interval to tweet.

a. When run for a sufficiently long time, the Raspberry Pi should tweet messages on the new time interval as verified by the log of messages on Twitter.

1. This tests the ability of the system to make software configuration changes.

TWx 22

Integration Tests

These tests will be repeated for each sensor we design to make sure they all function. The user should be able to configure each sensor via Tweets, and the system should be able to report the data from the sensors.

Description Test Requirements Tested

Configure a sensor via Twitter

1. The user tweets a message to the Raspberry Pi to configure a sensor (Ex: turning off the sensor or frequency the sensor data should be updated).

2. The Raspberry Pi parses the command and communicates with the sensor.

a. The Raspberry Pi returns the result (success or fail) to the user.

b. The sensor should act as specified by the user.

1. Tests if the Raspberry Pi program can interpret a Tweet as a command for the sensor and execute it.

Get a sensor’s information 1. The user tweets which sensor information they need.

2. The Raspberry Pi communicates with the sensor or a cache of existing data to find the needed value.

3. The value is formatted and tweeted.

a. The tweet is received and verified for its properly formatted content.

1. Tests if we can get and report useful data.

TWx 23

Power/Hardware

Unit Tests

Description Test Requirements Tested

Power Distribution

1. Apply a battery pack to the voltage regulation circuit.2. Attach a multimeter to measure the voltage at Vcc.

a.Voltage should be 3.3V.

1. Remote placement of sensors.

Sensors 1. Apply a voltage to the divider circuit.2. Measure the output.3. Translate the voltage measured by hand.

a.Verify the sensor reading’s viability.

1. The system should have an array of weather sensors.

Integration Tests

Description Test Requirements Tested

Sensor Battery Life

1. The sensor unit will be turned on, in the transmission mode, to pull the most power from the battery source.

2. The time it takes for the batteries to run out would be the worst it will ever do.

a.Some calculations with some educated guessing can give a rough life expectancy for the batteries.

1. The sensor module shall have a long battery life.

RF + Launchpad + Sensor + Battery

1. Once the individual units have been tested, then all can be physically connected together.

2. The Launchpad should be able to communicate to the RF transceiver and establish a connection.

3. The microcontroller should then be able to read the output from the sensor, run it through the ADC and then transmit that data through the RF transceiver to a USB endpoint.

a.The USB endpoint should report the value read by the sensor on ADC.

1. Sensor should be able to have remote placement.

2. System should be remotely accessible.

3. System should have weather related sensors.

4. Remote sensors should have relatively long battery lives.

TWx 24

Acceptance Testing

The acceptance tests are to determine if the functionality of the system meets the requirements specified. The table below maps a test to a particular component and the requirements, which should be met by the features tested.

Component Test Requirements Tested

Host Responds to User Query

1. Host connected to Internet.2. User tweets at host with request

a. Ensure a new message is posted with correct information from sensors.

1. The system should be responsive to incoming Tweets.

Posting Status at Regular Intervals

1. Host connected to Internet.2. User tweets instruction specifying

time interval for reports.a. Ensure reports are posted at

appropriate intervals with correct information from sensors.

1. The system should Tweet results.

Pluggable Sensors 1. Check status of system and last data received.

2. Plug in new sensor endpoint.3. Check status of system and last data

received.a. Ensure the new sensor has

registered with the system and is updating.

1. Sensors should be able to be easily added or removed.

Sensor-agnostics 1. Connect multiple, non-related sensors.

2. Allow data to be logged.a. Check status of the system

to see sensors and data to ensure all are communicating properly.

1. The system should support sensors regardless of the data provided.

TWx 25

Risks On a system-wide scale, the risk of overcommitting to features without adequate knowledge of the cost may result in a more expensive device than anticipated. This can be alleviated by not developing additional new sensors, or by carefully researching the components of each sensor to find lower-cost alternatives.

At a lower level, the hot-plugging of sensors is a feature which may pose problems. The ability to detect a new device is complicated and may result in expensive sensor modules as they require USB or WiFi or a complicated software solution to address shortcomings in simpler protocols like I2C. Experimentation and backup plans may be needed to implement this feature. Additionally, USB development can be difficult. If a proper USB device and device driver framework for data passing proves to be too difficult, the project will not have a reliable means of obtaining sensor information. This can be mitigated by using virtual COM ports and passing information over the virtual COM port. This severely diminishes throughput and reduces the amount of information which can be passed but simplifies communication.

Sensor agnostic operation may also pose a challenge. A framework for the host to accept and configure several parameters regarding sensors it knows nothing about will need to be developed, as well as a reasonable way to handle errors and provide the user or developer with information needed to possibly correct the problem.

Remote configuration and access will also be challenging. Several message passing middlewares exist to simplify the transfer, and adequate research will ensure a simple yet powerful enough library is used.

Milestone Chart

Task Deadline ContributorTweet from Embedded Device - From the chosen host device, ensure Twitter can be reached.

March 11 Casey

Design an extensible software system for accepting data providers, configuring data providers and updating users of the system via Twitter and possibly other means.

April 15 Casey

Pluggable Sensor Endpoints - Using the chosen bus, endpoints where sensor data will come from should be hot-pluggable and detected by the software.

March 22 Jeffrey

RF based protocol between sensor endpoints and remote sensor devices developed and tested.

April 5 Jeffrey

Abstract data provider interface defined, constructed and tested in the context of Twitter updates.

March 8 Jeffrey, Casey

Product can fully detect a new sensor and report its information April 15 Jeffrey, Casey

TWx 26

to the user when requested.Power Source – Battery based power management circuit designed and prototyped.

March 15 Floripe

Complete sensor module circuit designed and built. March 22 FloripeADC programming on the MSP430 to use multiple sensors on one microcontroller.

March 29 Floripe

Construct a housing for the sensor unit. April 19 FloripeAll testing complete. May 6 Casey, Floripe,

Jeffrey