Sensor Technology Interface Final Proposal

Transcription

1 Sensor Technology Interface Final Proposal Sponsor FitnessMetrics, LLC Team 1 Nick Henry Kelton Ho Nick Huff Robert Pollum Brian Wirsing Facilitator Shantanu Chakrabartty February 21, 2014 Executive Summary The objective is to design a system that buffers data from both wired and wireless sensors and then transmits the data to a mobile device. This is achieved using a microcontroller to format and store information in ROM. The interface contains a library and application programming interface (API) to promote future independent expansion from private users. This all is done in a package that is small enough to remain portable and convenient.

2 Table of Contents 1 - Introduction 2 - Background 3 - Design Specification 4 - FAST Diagram 5 - Conceptual Design Descriptions 6 - Ranking of Conceptual Designs 7 - Proposed Design Solution 8 - Risk Analysis 9 - Project Management Plan 10 - Budget 11 - References

3 Sensor Technology Interface Final Proposal Nick Henry, Lab Coordinator, Kelton Ho, Document Prep, Nick Huff, Manager, Robert Pollum, Presentation Prep, Brian Wirsing, Webmaster, Shantanu Chakrabartty, Facilitator, FitnessMetrics, LLC, Sponsor Abstract -- The objective is to design a system that buffers data from both wired and wireless sensors and then transmits the data to a mobile device. This is achieved using a microcontroller to format and store information in ROM. The interface contains a library and application programming interface (API) to promote future independent expansion from private users. This all is done in a package that is small enough to remain portable and convenient. Table of Contents 1 - Introduction 2 - Background 3 - Design Specification 4 - FAST Diagram 5 - Conceptual Design Descriptions 6 - Ranking of Conceptual Designs 7 - Proposed Design Solution 8 - Risk Analysis 9 - Project Management Plan 10 - Budget 11 - References Introduction Sensors are becoming increasingly prevalent in everyday lives. Already, members of society are surrounded by various kinds of sensors that send and receive information. The protocols used by these sensors can vary drastically; variations include sensors that are wired or wireless, analog or digital. Viewing the data from all of these sensors was shown to be of high priority. Usually, each sensor is connected to a unique user interface which displays that sensor s information. Therefore, in order to view the information from five different sensors, one needs to get it from five different UIs, which is not ideal. This causes clutter and creates a hassle for users who are increasingly trying to become more connected to their personal networks. The solution to this problem is to consolidate the information from these sensors onto one platform, which can then display all of the sensors data in one UI. This platform consists of two components: a sensor interface (SI) to receive the sensor information, and an Android app to display the information to the user. Having a user friendly UI will aid in its adoption while programmers can add new features. Creating this as an open source platform creates the unique advantage of having thousands of developers all working on this product, pouring in their personal skills and creativity in order to create a one-of-a-kind product that will continuously evolve into a more advanced and efficient platform. The constraints of the Sensor Technology Interface Project were broad, and left a lot of room for creative input. The four main constraints were cost, size, power, and sensors. Keeping the microcontroller open source was also a high priority so that others can build off of what the project will start. Low cost was a high priority; the sponsors wanted the final microcontroller to cost around $20. Keeping it at a low cost allows for larger adoption rates and long term lower costs once they are hopefully mass produced. The sponsor is hoping to sell 10,000+ of these microcontrollers within the next few years as more people adopt the microcontroller into their everyday lives. As each sensor requires a microcontroller to function, the sponsor wanted to have the ability to communicate with the sensors via Bluetooth to be as cheap as possible. Size is a main constraint, and the product should have maximum dimensions of 1 x 1 x 0.5, in order to make the interface easily portable. Designing with the small size in mind allows the microcontroller to be used in applications where larger designs would not be feasible. This microcontroller could be put into appliances, toys, 2

4 clothes, etc. Keeping the size within this limitation opens up the possibilities to which this technology can be used. When a portable device is being designed, the size-to-power ratio will always be of concern. A smaller size remains a higher priority over power consumption, but power use is still important. The design in consideration requires the microcontroller to last several months on one charge, which will allow it to be kept in use for long periods of time without any form of maintenance. Having the microcontroller constantly communicate its data over Bluetooth would drastically reduce this battery s lifetime. Therefore, the microcontroller should have local storage in the an SD card slot. This would enable the microcontroller to store data and send it in 15 minute to 1 hour intervals. 2 - Background On the hardware side, there are a number of products currently on the market that can perform some of the requirements of this project. The RFDuino is the best example [3]. The RFDuino is a small microcontroller with a built-in Bluetooth module. It is able to perform many of projects functions, such as communicating with wired and wireless sensors, transmitting information to an Android device via Bluetooth, and storing data to an SD card. However, the main problem with this solution, along with many others like it, is that the RFDuino must be programmed to perform this operation. This makes the RFDuino an impossible solution for users who don t know how to program, and an impractical solution for those that can program, but don t want to. A better product would already have the code pre-compiled, the input ports clearly labeled, and require little to no setup from the user. On the software side, there are some Android apps that interface with certain microcontrollers. One example is ArduDroid [6]. This app communicates with an Arduino microcontroller via a Bluetooth connection. Using ArduDroid, users can read data coming from an Arduino board, send data back to the Arduino board, and configure Arduino GPIO pins to function as either input or output. The main problem with this app is that it does not perform the specific functions required, such as listing multiple Arduino port outputs, saving data, and graphing data history. To accomplish these tasks, an app should be designed from scratch with these functions in mind. Prior work has shown that specific feature sets are possible, however the proposed design of the team will bring all these separately created ideas together. Given that the assigned project can be used in such a broad manner it was decided that several criteria must be met in order to call the project complete. This list contains not only the essentials but also many additional features that will improve the user experience as well as the functionality of the device. The most basic ideas are the cost, size, power, and features of the sensor interface installed. One major goal of our final design is for it to be open source, because of this low cost is a large factor in our decision making. For an open source piece of hardware it needs to be readily accessible to a large number of people in order to get creative minds collaborating on how to improve the current design and writing interesting and unique new programs for the device. It is very hard to predict where this technology will go; Open source software and hardware will keep this idea growing beyond its initial conception into new and unexpected places. The sensor interface will ultimately work with smart phones, specifically Android devices, which pride themselves on being sleek, stylish, and above all, open. The portability and creative nature of the design needed to match the idea of the internet being in more and more products. The bulk of our design was not our only convenience issue; The design should also not require constant maintenance in the form of charging or changing batteries too frequently. A power management system needs to be implemented in order to not drain batteries too quickly. All of these features would be beside the point if no one had an interest in using this device, so we had to create interesting functionality and innovative features to draw people into wanting to have this attached to their phones at all times. In order to implement this functionality, a list of required parts for the microcontroller to interface with was created. There will need to be many forms of inputting and outputting data via wired and wireless connections. This data must be able to be stored until it is able to be buffered and sent to the phone. The data collected had to have a reasonable level of quality and real time streaming capabilities which meant time stamping all of the 3

5 information collected as well as sampling frequently in order to get a smooth plot of whatever information a sensor might be transmitting. All of this data would mean nothing without a user interface for the Android devices. The Android device must be able to input the data from the microcontroller and organize and display it in a way that is convenient for the user. Once it has displayed this data it will then upload to a cloud form of storage to be further processed. There are many other features that an optimal, but not realistically viable given our time frame and other constraints. Some of these possible features include solar charging for the batteries of the microcontroller, storage to a SD card, and keeping the device in a low power state when not in use in order to better save battery life. 3 - Design Specification There are three tiers of specifications to be met given for this project: the minimum requirements, the preferred feature set, and the desired goals. Furthermore, there are a couple of stretch goals that may or may not be met. These feature sets are also separated into two subcategories: the sensor interface features, and the android UI. The minimum feature set includes two general input-output channels, with a separate analog input and a separate analog output. The system must be able to hold 1 hour of buffered input, and be able to receive 20 samples/second on each channel. Furthermore, the input data must be time stamped such that data aggregation and time-based parsing is possible. Furthermore, the android interface must be able to configure the various input and outputs, including the sample rate. It must also be able to change the buffer size, including clearing the buffer memory completely. Finally, the UI must be able to log and display the data. The preferred feature set includes the minimum requirements, as well as the ability to work with ANT. The same specifications for the basic wired requirements exist for the ANT-compatible sensor interface: it must be able to take 1 hour of buffered sensor output. Similarly, the UI must be able to configure these sensors and memory, and process data in a meaningful way, including a way to display the data. The desired feature set builds about the preferred feature set in that it does the same thing with Bluetooth on top of ANT, but it also requires that the SD card is removable. The UI has similar requirements. Some stretch goals are to be able to charge the battery, and how to optimize the data structure for storage in the SD card. Also, if necessary, the sensor interface should be able to power wired sensors within reason, as well as use many sensor technologies. Figure 1. Project Components The Sensor Technology Interface needs three components to function: Sensor Interface (SI) Android User Interface (UI) Sensors Each of these sections have their own needs and restrictions. The main design work will be centered around the SI and UI as these are the most essential components. The only requirements for the sensors was that they should be able to communicate using Bluetooth, ANT+, other RF technologies, wired connections, or I2C. Size and cost were ranked as top priority, with power consumption being a lower priority. For the SI portion, the following parameters below are all ranked as top importance. 4

6 Priority 5 Requirements SI UI 2 GPIO Channels Configure SI GPIO channels 1 Analog Input Configure SI analog input sample rate 1 Analog Output Configure SI buffer memory 1 Hour of Buffered Input Enable/Disable SI input data collection 20 Samples/Second per Channel Clear SI buffer memory Timestamp Sample (Input) Data TRRS Communication between UI module and SI Trigger SI GPIO and analog output Display SI input data (numerically or graphically) real time 1 x 1 x 0.5 dimension Log sensor data Priority 3 Requirements SI ANT wireless sensor system to operate 2 or more wireless sensors UI Configure ANT wireless sensors (as needed) 1 hour of buffered ANT sensor input Configure SI buffer memory Enable/Disable ANT input data collection Clear ANT buffer memory Display ANT input data (numerically or graphically) real time Priority 1 Requirements SI Bluetooth in addition to the ANT wireless sensor system UI Configure Bluetooth wireless sensors (as needed) 5

7 1 hour of buffered Bluetooth sensor input (2 or more) Configure SI buffer memory Bluetooth communication with UI Removable SD Card or microsd Card Enable/Disable Bluetooth input data collection Clear SI buffer memory Display Bluetooth input data (numerically or graphically) real time 4 - FAST Diagram Figure 2. FAST Diagram 5 - Conceptual Design Descriptions The design will incorporate various analog and digital sensors, both wired and wireless. These sensors will transmit data to a microcontroller. Some of the sensors will be I 2 C-compatible, so the microcontroller will have to have this functionality as well. Furthermore, some sensors will communicate via Bluetooth, so the design will include a Bluetooth module for the microcontroller, as well as for the sensors that will communicate this way. The microcontroller will use this Bluetooth module to also communicate with the Android device. In addition, the design includes an SD card reader to store the sensor data until it can be transmitted to the Android device. There are a number of possible microcontroller prototyping platforms considered for this project such as 6

8 the Arduino Uno[1], the Arduino Due[2], the RFDuino[3], Texas Instruments MSP430[4], and Texas Instruments C2000[5]. These boards are readily available and give the designer access to most if not all of the available functions of the chip used. The Uno is readily available, well-documented, and inexpensive using only an 8-Bit ATMega microcontroller. The Due is a more powerful (but larger and more expensive) version of the Uno, featuring more inputs and a 32-bit SAM M3 Cortex also produced by Atmel. The RFDuino uses a 32-bit ARM Cortex M0 MCU and has an onboard Bluetooth module. The RFDuino is smaller than both the Uno and Due, however it has the fewest available inputs of the group, making prototyping wired sensors more difficult. These microcontrollers all use the Arduino programming platform and have copious support available through forums, tutorials and external modules and libraries. The Texas Instruments MSP430 is a 16-bit MCU with many variants to suit the needs of individual projects. It has been proven to be a cheap alternative, is used in many projects and also has available support directly from Texas Instruments for a multitude of projects as well as forums. The Texas Instruments C2000 is a new 32-bit MCU and is very cost effective in terms of power and speed versus price. As it is a new product, documentation on possible projects may not be as easily available as on the MSP430 and even less would be available on the forums. A multitude of wireless communication methods are available as well, allowing for numerous possible methods of transmission. The communication methods best suited for the project include Bluetooth, ANT+ and ZigBee mesh network communication. Bluetooth modules are readily available for purchase in two different versions of the standard: Bluetooth 2.0 and Bluetooth 4.0 Low Energy (BLE). BLE is more advantageous to use in terms of power consumption, but because the Bluetooth 2.0 standard has been available longer, there is more support for it, more products that can interface with it, and the modules are less expensive than the BLE counterparts. ANT+ modules are available and the standard has all the capabilities of BLE but is also open source. ANT+ is also capable of transmitting data through multiple communication styles such as broadcast, acknowledge and burst transmission. Zigbee modules allow users to communicate through Personal Area Networks which would allow sensors to communicate with each other in order to get the data to the Sensor Interface Device. The power consumption however, depends on the use of the module and the transmission rate of other local devices which could be a severe drain on the available power. Using these components we have come up with several design solutions to test in a feasibility matrix. The first proposed solution incorporates the bare bones design using only what must be done in order to accomplish the tasks required. Using a 8-bit MCU such as the Arduino Uno. In order to communicate with the sensor network a Bluetooth 2.0 module will be installed. The second design involves a more sophisticated processor which uses a 16- bit MCU but will continue using a Bluetooth 2.0 module. The third design proposal uses the most advanced processor, the C2000 which involves 32-bit processing and low power consumption, however the support for this is not quite on par with the 4th and final design solution. The fourth design also implements a 32-bit processor by using an Arduino Due MCU. The final two designs will both use the new low power Bluetooth 4.0 low power communication protocol as well. 6 - Ranking of Conceptual Designs Feasibility Matrix Arduino Uno Arduino Due RFDuino TI MSP430 Cost (3 ) Size (3 ) Power (1 ) Features (2 ) Support (2x) Total

9 7 - Proposed Design Solution The primary goal is to receive simple data from a sensor and transmit it to an Android device which will display the data. An application to receive the transmitted data is to be developed concurrently with the program for the Arduino Uno prototyping board. This allows for separate development of the application and interface device code making the ability to develop easier. None of the group members have Android programming experience. As such, beginning development of the application will require large amounts of work from each of the members, following tutorials and researching the resources available within the Android development environment. Simple sensors will be used as the base for gathering data, using available parts and the internal Analog to Digital Converter or the microcontroller to read available data. The communication between a Bluetooth module and the Arduino Uno is required in order to make communication between the Android Device and the Sensor Interface Device possible. Following this phase, the system will be optimized to accommodate more sensor interfaces, improve processing speed, and reduce power consumption. The work done will continue on the Arduino Uno, adding the capability to communicate with a sensor wirelessly and maintain a connection. The Atmega328p microcontroller that is used in the Arduino can be tested for use with the Pico-Power features that are available, which should then allow the team to reduce power consumption. An SD card module to increase sensor data storage on the microcontroller will be added allowing for data to be collected and stored without the need to interface with a phone. Further development on the application will be done, making the application display results, save the files, and work towards having a usable interface. Transmission rates of the data being sent to an android device via Bluetooth will be tested in order to find the maximum transmission rate with the current setup. When this is completed, the Uno will be replaced with a more powerful microcontroller, along with this replacement, members will decide whether upgrading the Bluetooth 2.0 module to a BLE module is feasible. Provided there is time left at the end of these two design phases, the team will develop a more capable prototype adding more wireless modules as time permits. 8 - Risk Analysis Any project has risks associated. In creating the sensor interface, we will encounter not only high risks, but medium and low risks as well. The high risks include the size restriction, PCB design. The medium risks include the testing of the PCB, processing power, and the lack of Android programming experience. The low risks include the memory allocation/management challenges, and ANT+ integration. Below, each of these risks are presented in detail. High Risk Size Restriction The most difficult aspect of this project will be attaining the size required while balancing processing power, power consumption, ruggedness. All of the design specifications have to surround around the idea that size is the most important factor when designing our microcontroller. There has to be adequate processing power in the microcontroller to be able to receive input from a myriad of different sensors. Utilizing more processing power will enable us to add more and complex sensors, but will contribute to the growing size of the PCB. A balanced medium needs to be found or the design will end up being over 1 x 1. PCB Design No person on the team has designed a microcontroller from scratch before, and it is uncertain if we can deliver a final microcontroller of our own design. That is why we are first using already available microcontrollers, and optimizing them as far as we can go. If there is enough time left after optimizing the microcontrollers available to us, then we can design the PCB. Medium Risk PCB Testing Due to time constraints, testing time for the PCB microcontroller is limited. It takes about two weeks for 8

10 the PCB to arrive after sending out the design. If there is an error detected, there may not be another chance to wait two more weeks for a design change. It needs to be right the first time. Processing Power To fit into the size constraints, the microcontroller will have to sacrifice processing power. Trying to find balance between size and adequate processing power for the sensors will be carefully considered. Lack of Android Programming Experience Prior to this project, every person in the group has had little experience programming Android apps and coding with Java. The project cannot go forward unless there is a functioning Android app. Every person in the group has had previous programming experience with similar languages, so by following online tutorials there should be a well-designed app between the five members. Low Risk Memory Allocation/Management To save power consumption on the microcontroller battery, the sensor data will be stored locally on an SD card and sent to the phone in batches. The downside is that this data storage will use valuable processing power, and until testing begins it is hard to predict how much additional processing power will be needed. ANT+ Integration Adding ANT+ for greater communication possibilities may be an option, but it could also add too much to the size and complexity of the microcontroller. If everything else has been completed on schedule, there may be time to do an analysis for ANT+ integration. 9 - Project Management Personnel and Timeline Each team member will be able to play a varied, but equal part in contributing to the overall project. We have our critical path divided into two main parts; hardware and software. The hardware side is divided into four parts, focused on the Microcontroller Prototype, Optimization, Chip Design, and Testing. The software side is mainly focused on the Android UI development, and this is divided into three parts, Basic, Advanced, and Full Package Android UI. Below is each critical path section with the assigned tasks and dates. Please refer to the Gantt chart page for further detail on the project timelines. Completed By February 18th: Android UI Basic and Microcontroller Prototype: Brian has already completed the Microcontroller Prototype and Android Basic section by showing Bluetooth communication between and Arduino microcontroller with an Android phone app. Completed By March 12th: Android UI Advanced and Microcontroller Optimization: 9

11 We are all going to be learning Java and Android programming using Eclipse IDE by completing the basic tutorials for the Android UI Advanced section which should be completed by March 12th. The Android UI Advanced section deals with storing SD card slot data from the microcontroller to the phone, and sending this data at specified intervals. Nick Huff and Nick Henry will be working on this section concurrently with the hardware task of Microcontroller Optimization under the hardware critical path. Brian and Robert will focus on furthering the Advanced Android UI development by adding the ability to select different sensors using a TI Bluetooth SensorTag, and making a more user friendly UI. Kelton has already begun work on the database backend, which creates a library for added sensors. He will be working on this until the completion of Advanced Android UI by March 12th. March 17th Presentation: By March 17th, we should be able to show an Android app being able to communicate with our microcontroller and the TI SensorTag. We should be able to see the data for each sensor in the SensorTag displayed on the Android App. Completed By April 18th: Robert will begin the chip design in Eagle as he has the most microcontroller experience. Nick Huff and Nick Henry will aid in the design process and microcontroller battery integration. Brian will continue to add more functionality and sensor compatibility for the Android UI full package while Kelton with work on greater database integration with the Android software. Once the chip design has been sent to the PCB manufacturer, we will continue to optimize the programming in our Arduino or TI microcontrollers until the chip arrives. Once the chip arrives, we will begin testing and integrate the new microcontroller with our Android software; we will all be working on this portion until Design Day. Anytime a person finished their section early, they can develop more advanced sensors beyond the TI SensorTag or begin work on a 3D printed case. April 18th Presentation: By April 18th, we should be able to demonstrate our chip working with several sensors via Bluetooth. We can see the sensors update in real time with a user friendly Android GUI. By this time we should have a custom case for the microcontroller that can fit onto several different Android phones. The microcontroller will be self-powered with a battery for easy separation from the phone. We will continue to work on any issues until Design Day on April 25th. Resources We already have an extra TI launchpad and Arduino UNO board. We ve found the sensors and Bluetooth module we need from Amazon. We will be sending our chip design to an online custom PCB manufacturer. The Eclipse IDE environment we are programming the Android app is free, as well as the Btool program from TI. 10

12 Figure 3. GANTT Chart 11

13 10 - Design Budget Cost of Project Item Description Qty Unit Price Initial Allocated Budget Item Subtotal Subtotal Budget Remaining - - $0.00 $0.00 $ Notes Arduino Uno 1 $0.00 $0.00 $0.00 $ Pre-owned by Team Member Analog Light Sensor Analog Temperature Sensor 1 $0.00 $0.00 $0.00 $ Provided Free of Cost From ECE Shop 1 $0.00 $0.00 $0.00 $ Provided Free of Cost From ECE Shop Potentiometer 1 $0.00 $0.00 $0.00 $ Provided Free of Cost From ECE Shop Android Phone 1 $0.00 $0.00 $0.00 $ Pre-Owned by Team Member Bluetooth 2.0 Module 2 $15.93 $31.86 $31.86 $ SD Card Module 2 $6.99 $13.98 $45.84 $ I 2 C Temperature Sensor 2 $5.95 $11.90 $57.74 $ I 2 C Light Sensor 2 $5.99 $11.98 $69.72 $ Arduino Due 2 $53.51 $ $ $ Bluetooth 4.0 Module 2 $7.50 $15.00 $ $ SensorTag CC $25.00 $50.00 $ $ May Be Provided by Sponsor Shipping & Handling - $ $ Final $ $ Cost of Manufacturing Item Description Qty. Unit Price Notes PCB Microcontroller Based off of final Eagle chip design. 10,000+ $20 Target price and quantity within two years. 12

14 11 - References [1] "Arduino - ArduinoBoardUno." Arduino - ArduinoBoardUno. N.p., n.d. Web. 21 Feb < [2] "Arduino - ArduinoBoardDue." Arduino - ArduinoBoardDue. N.p., n.d. Web. 21 Feb < [3] "RFduino - Home." RFduino - Home. N.p., n.d. Web. 21 Feb < [4] "MSP430F2131 (ACTIVE) 16-Bit Ultra-Low-Power Microcontroller, 8kB Flash, 256B RAM, Comparator." MSP430 Ultra-Low Power 16-bit MCUs. Texas Instruments, n.d. Web. 21 Feb < [5] "TMS320F28335 (ACTIVE) Delfino Microcontroller." C bit Real-time Control MCUs. Texas Instruments, n.d. Web. 21 Feb < [6] "ArduDroid: Simple Bluetooth control for Arduino and Android - TechBitar" ArduDroid. N.p., n.d. Web. 21 Feb < 13