[PDF] Final Report.docx This task unfortunately also did

View - Download Final Report.docx

Previous PDF

Next PDF

Sensor Technology Interface

Final Report

Sponsor

FitnessMetrics, LLC

ECE 480 Team 1

Nick Henry

Kelton Ho

Nick Huff

Robert Pollum

Brian Wirsing

1

Executive Summary

Modern society is interlinked through a network of not only people, but their respective someone without an electronic device, be it a watch, a cellphone, a computer. Yet, these devices have not even touched the surface of what is possible. ordinary, everyday gadgets that together with sensors widely broaden the possibilities of what is capable. However, there are just as many types of sensors as there are electronic devices. To communicate with each of these sensors through custom hardware is an expensive and tedious process. Hence, there is a need for a system that can flawlessly connect different sensors and make sense of this data. We have developed an open source microcontroller on which users can connect a wide variety of sensors to their smartphone. Our design creates a cheap and easy interface in which everyday people can connect the sensors in their lives while making that data meaningful. The microcontroller paired with the included Android app will give people the tools they need to bridge the data collected by electronics with the reality, widening the gap for what is real and possible.

Acknowledgments:

The scope for this project was wide and the possibilities far. Without the support of the sponsors, facilitator, and others, this project could not have been completed. Specifically, the team would like to thank: their continuing support for a developing project. Arduino microcontrollers to be open-sourced and available for all. 2

Table of Contents

Chapter 1 - Introduction and Background 4

Introduction 4

Background 5

Chapter 2 - Solution Exploration and Selection 7

Section 1 - FAST Diagram 7

Section 2 - House of Quality 8

Section 3 - Budget 9

Section 4 - GANTT Chart 12

Chapter 3 - Technical Work Performed 15

Section 1 - Hardware Design Efforts 15

Section 2 - Hardware Implementation 16

Section 3 - Software Design Requirements 20

Section 4 - Software Implementation 20

Subsection 1 - Microcontroller Program 21

Subsection 2 - Android Application 25

Chapter 4 - Testing 32

Section 1 - Hardware Testing 32

Section 2 - Software Testing 33

Chapter 5 - Conclusions 36

Section 1 - Final Prototype 36

Section 2 - Cost 36

Subsection 1 - Prototype Cost 36

Subsection 2 - Production Cost 37

Section 3 - Schedule 37

Section 4 - Findings 37

Section 5 Future Work 38

Appendix 1 - Technical Roles 40

Nick Henry 40

3

Kelton Ho 41

Nick Huff 42

Robert Pollum 43

Brian Wirsing 44

Appendix 2 - References 47

Appendix 3 - Technical Attachments 47

4

Chapter 1 Introduction and background

Introduction

Sensors are becoming increasingly prevalent in our everyday lives. 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, 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. One solution to this problem is to consolidate the information from these sensors onto 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 adoption while programmers can add new features. Since its inception, the Sensor Interface has been an open source platform, creating the unique advantage of possibly having thousands of developers all working on this product. By designing with the open-source philosophy in mind, people can contribute 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 types of 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 of a high priority as keeping the Sensor Interface low cost allows for larger adoption rates and long term lower costs once they are hopefully mass produced. We are hoping to sell 10,000+ of these microcontrollers within the next few years with an expected cost around $25. As more people adopt the microcontroller into their everyday lives, the cost could potentially lower even further. When a portable device is being designed, the size-to-power ratio will always be of concern. Designing with the small size in mind allows the microcontroller to be used in 5 applications where larger designs would not be feasible . This microcontroller could be put into appliances, toys, clothes, etc. A smaller size remains a higher priority over power consumption, but power use is still important. The design allows 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 an SD card slot. This enables the microcontroller to store data and send it in intervals specified by the user.

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 [1]. 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 know how to program, and an impractical solution for those that can program, but -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 [2]. 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. 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 6 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. 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 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. 7

Chapter 2 Solution Exploration and Selection

Section 1 FAST Diagram

The complete system design with its logical components is more easily presented by utilizing the FAST diagram. The FAST diagram is able to take what could possibly be a complicated project and break it down to an easy to follow format. Having a recognizable format

such as this enables the designer to best focus their efforts on what is needed in the final product.

The FAST diagram developed by the team is shown below.

Figure 2.1 - Fast Diagram

8 The Sensor Interface can be broken down into three main components: The Android app, the microcontroller, and the sensors which it communicates with. The Android app and microcontroller are essentially the support behind the sensors to collect, store, transfer and display data. Designing more advanced sensors was beyond the scope of this project, so the Android app and microcontroller became the areas of focus. The Sensor Interface was designed to accept a wide variety of sensors, Bluetooth, analog, digital, wired and I2C. Any of the sensors can also be connected to another Bluetooth module to allow a wide variety of wireless sensors to communicate with the central Sensor Interface microcontroller. Once the microcontroller has logged data from the microcontroller, it stores the data via a microSD card. Storing the data in with an onsite microSD card has several advantages, most of which that it allows for minimal power consumption by not constantly transferring the data to the Android phone. Logging data in this way allows the microcontroller to store data for weeks or months without any communication to the Android phone if desired. Once the data is wanted, simply connecting the Android phone to the microcontroller will transfer the data to the phone once the Android app is launched. From there, the phone can display the data and use it as the user sees fit.

Section 2 House of Quality

The House of Quality provides excellent insight into translating what the customer wants effectively gauge how our design can be improved against measurable engineering field data. This methodology forces the designer to look past the obvious and really learn to put out a product that can match and exceed the expectations. The House of Quality completed for the team is shown below. 9

Figure 2.2 - House of Quality

Section 3 Budget

The team was provided with the standard budget of $500 for the ECE 480 design class. As shown in the information below, the team used $450.77 out of $500 to construct the prototype. Although it was a higher cost than initially expected, several designs were tried to best implement what the sponsors requested, thus several microcontrollers were ordered. Beyond this, a few items for display purposes were donated by team members and our sponsors. All the 10 software chosen for design was open-sourced or free. The budget summary table and pie chart of purchased expenditures is shown below:

Software: Hardware:

EAGLE PCB

Design $0 Donated: $180

Eclipse Android

IDE $0 Purchased: $290.38

Sensors: Microcontroller Fabrication:

Donated: 2.68 Parts Cost: $34.82

Purchased: 84.93 Fabrication Cost: $0

Logistics:

Shipping and

Handling $40.64

Donated Total: $217.50

Purchased Total: $450.77

Table 2.1 - Budget Summary

11

Figure 2.3 - Purchased Product Expenditures

If the unit was to be made in full production, the cost in parts for each unit in quantities of ten thousand would be $20.83. The cost of manufacturing the board would be $0.54 when using the company 4PCB. The cost of assembly would be about $5 for each board using Advanced Circuits. Thus, the total per unit cost of each microcontroller would be $26.37. The breakdown of the microcontroller costs are shown below.

BLE Module 4.0 10.15 Capacitors 0.066

microSD Socket 0.502 Resistors 0.138

USB Mini 0.8 LEDs 0.218

8-Bit 32KB MCU 1.77 Schottky Diode 0.042

USB to Serial UART IC 2.05 Voltage Regulator Parts 0.208

Crystal 16MHz 0.173 Coin Cell Battery 3V 4.32

PCB Board Manufacture 0.54 PCB Board Assembly 5

Full Production Cost $26.366/Unit

Table 2.2 - Final Production Costs

12

Figure 2.4 - Final Production Expenditures

Section 4 GANTT Chart

This project was ambitious, and it was determined part way through the semester that others would most likely follow the work done by the team at a later date. In order for the needed to be utilized in order to properly draw small lines on the PCB and add more than two layers. Lead times for getting the PCB board manufactured with parts assembled could be as long as a month, so it was decided to make a two layer board with a larger layout for testing purposes with the facilities at MSU. The software side of our project has been for the most part successful, but the hardware side fell short due to the high learning curve and the resources available. Due to this, the team is still in the chip design/testing phase of the project. Another group next semester should be able to start from where the team left off and build a tested microcontroller to interface with the software developed by the team. 13

Figure 2.5 - Initial GANTT Chart Part A

14

Figure 2.6 - Initial GANTT Chart Part B

15

Chapter 3 Technical Work Performed

Section 1 Hardware Design Efforts

module, an SD card module, and a battery. The microcontroller is responsible for collecting connected sensor readings, altering sensor parameters, and transferring sensor readings to the other hardware components when necessary. It must be able to read both analog sensors and digital I2 readings over long periods of time, our minimum requirement was set at one hour. This module should both write to an SD card and read from an SD card when required. The Bluetooth module is needed to communicate with the Android device. It receives commands from the Android device and sends them to the microcontroller so that it can perform the correct task. The Bluetooth module also transmits sensor readings back to the Android device. These modules can all be purchased separately and connected with wires together in order to implement a design where all of this functionality is joined; however having separate modules would be clunky and ed solution was to design a microcontroller that included all of these parts on one board so that it can remain small and efficient in design. In order to create a customized microcontroller first a list was created containing every component the microcontroller would need on the board, first using through hole components in order to create a prototype design (see Table 3.1.1) and then using SMT package components in order to be prepared for future advances. The microcontroller board that was designed houses a micro USB port, a BLE module, a coin cell battery, and a microSD card shield along with the standard components necessary for a chip to control the incoming and outgoing data. Designing this product in the Eagle software takes careful planning and time to continually adjust where traces through the board will be routed. Eagle contains a large number of components in premade libraries. These built-in parts covered nearly everything needed to add to the design, however some of the more specific components had to be added to the design manually. The BLE module, coin cell shield, and micro SD shield were the only three parts not already included in the libraries. To get these designs to populate in the same space as the rest of the board the 16 eagle files needed to be imported from manufacturer websites which required use of the professional version of the software. These are imported as separate schematics but can be edited simultaneously with the main schematic and attached by using labels instead of wires to join the different ports. Even with separate schematics the physical layouts are represented in the same board layout page. Once all of the components are populated into the board they needed to be manually arranged in the board space we allocate prototype. In order to fit all of the components in the through hole style careful arrangement of parts was needed on both the top and bottom of the board, this proved to be a challenge when routing traces as the bottom is typically reserved for routing only. Routing traces can begin by using the auto-route function built into Eagle. This however will not make every connection necessary for the board to function if it cannot find an easy path from point A to B. With the remaining connection a path must be manually connected along with vias to connect the ports from the different components. This task should be done with utmost care as this is where errors are most likely to be made during this process for instance errors we discovered after our board had been manufactured were that some of the traces were drawn too close together and the machinery that was available to the team could not cut the copper with enough precision, this led to several pads being treated as one which shorted many connections. Using higher precision equipment could have solved this problem which would have required the team to send the design to an outside source to be manufactured which would require time and money that was unavailable at this point in the design process. This problem would have also been avoided if the SMT package components were being used instead of the larger through-hole versions. This would have saved valuable space which could have been used for routing. The schematic designs and board layout (pictured in Appendix III figures 3.1.1-3.1.6) that were manufactured are not able to replace the Arduino board for the team at this point in time, however reprocessing

these until they are fully functional is the next logical step in creating a product such as this for

the market. This would lower the cost and raise the utility and convenience for the product.

Section 2 Hardware Implementation

The microcontroller used is an Arduino Uno, shown in Figure 3.1. This is a popular microcontroller that is easy to wire and program. It has sufficient analog input ports to read from 17 various analog sensors simultaneously, and also features a Serial Data (SDA) line and a Serial Clock (SCL) line. Both an SDA line and an SCL line are required to support I2C sensors. With these input ports, the Arduino Uno is able to read from three different analog sensors and two digital sensors simultaneously. Furthermore, the Arduino Uno includes Serial Peripheral Interface (SPI) functionality, which allows it to interface with certain peripheral hardware devices, such as SD card modules. On top of this, the board also allows digital ports to be configured to act as Serial Receive (RX) or Serial Transmit (TX) lines. These are necessary to connect with a Bluetooth module correctly. Finally, because of its popularity, many hardware modules are designed to work specifically with Arduino microcontrollers, including those that the Sensor Interface requires, like Bluetooth modules and SD card modules.

Figure 3.1 - Arduino Uno

The Bluetooth module used is the Sunkee HC-05 Bluetooth Module, shown in Figure 3.2. This module is cheap, readily available, and quick to acquire. It is also designed to ensure compatibility with Arduino microcontrollers. Furthermore, it is highly customizable, such as allowing its name to be changed, modifying its access password, and switching from master mode to slave mode. This last feature is important because it will enable future development of the Sensor Interface to add wireless Bluetooth sensor reading functionality. To communicate with Bluetooth sensors, the module should be in Master mode. However, when communicating to switch between these 2 modes will allow the Sensor Interface to communicate with Bluetooth sensors as wired sensors. 18

Figure 3.2 - Sunkee HC-05 Bluetooth Module

Figure 3.3 depicts the connections between the Bluetooth module and the microcontroller. The module has both a 5.0V input pin and a 3.3V input pin. Although the module may operate correctly with only one of these supply pins connected, both are connected is P1 and the default RX pin is P0. However, these were not used for a couple of reasons. Most importantly, when P1 and P0 were used as TX and RX pins, the Bluetooth module would not communicate with the microcontroller. This meant that different pins had to be used. Fortunately, an Arduino library exists to change digital pins to RX/TX pins, called SoftwareSerial. Using this library, P3 was changed to a TX pin and P2 was changed to an RX pin. This decision has the added benefit of freeing up P1 and P0. This is beneficial because the Arduino has a useful debugging and monitoring feature called Serial Monitor. Using this, the Arduino can write messages to a computer screen when connected to a computer. However, this feature only works when P1 and P0 are not in use. Therefore, by using P3 and P2 for TX and RX instead of P1 and P0, testing and debugging was a much easier and faster process. The Bluetooth module has one more input pin, labeled KEY. This pin is used for changing its mode between Master mode and Slave mode, as well as customizing its other 19 properties. These options are not used currently, but they may be in the future. Therefore, this pin is connected to P4 on the Arduino Uno if property changes are ever desired. Figure 3.3 - Microcontroller - Bluetooth Module Connectivity The Bluetooth module used is the Kootek SD Card Module, shown in Figure 3.4. This is an inexpensive component that was designed to function correctly when connected to Arduino products. It supports both SD card reads and writes.

Figure 3.4 - Kootek SD Card Module

The connections between the SD card module and the microcontroller can be seen in Figure 3.5. The SD card requires both a 5V and a 3.3V supply to consistently operate correctly. During testing, only the 5V pin was connected, which resulted in correct SD accesses only every other time. This problem was corr output as well. 20 Serial Clock (SCK) pin, and P13 is its Master Out Slave In (MOSI) pin. These connect to the SD Chip Select (CS), which tells it whether or not it can communicate with the microcontroller. The default pin for this on the Arduino Uno is P10. Figure 3.5 - Microcontroller - SD Card Module Connectivity

Section 3 Software Design Requirements

The software design of the Sensor Interface is composed of 2 major components: the code describing the microcontroller program and the code describing the Android application. The microcontroller code is responsible for managing the sensors that are connected to it, as well as their readings. Determining which sensor ports to read from, how fast to read from them, when to store sensor readings to the SD card, and when to transmit sensor readings to the

Android device is all defined in this code.

ld display information about all of the sensors connected to the microcontroller, as well as allow the user to add sensors to monitor, delete sensors, and change sensor properties.

Section 4 Software Implementation

21

Subsection 1 Microcontroller Program

The primary role of the program on the microcontroller is to manage and monitor sensors, so a data structure called Sensor is defined. Table 3.1 shows the elements that make up a Sensor data structure. The microcontroller can monitor a maximum of five sensors, which consist of three analog sensors and two digital sensors. These sensors are kept track of in a 5- element array called mSensors. The first three elements are for analog sensors and the last two elements are for digital sensors. The number representing index of the mSensors array will be

Name Type Description

mPort int Which physical port this sensor is connected to (0-4) mValues[10] int Array of readings from this sensor. mIndex int Current location in the values array mLastSampleTime long Most recent time a reading was taken from this sensor mSampleRate float Number of times a second that a sensor reading should occurquotesdbs_dbs17.pdfusesText_23

[PDF] arduino uno projects

[PDF] arduino uno projects for beginners pdf

[PDF] arduino uno projects pdf

[PDF] arduino uno r3

[PDF] arduino uno r3 programmer is not responding

[PDF] arduino uno robot projects for beginners

[PDF] arduino uno schematic

[PDF] arduino uno schematic explained

[PDF] arduino uno tools programmer default

[PDF] arduino uno upload programmer is not responding

[PDF] arduino: 101 beginners guide pdf

[PDF] are 14 hour shifts legal

[PDF] are 3d printers safe

[PDF] are adobe signatures part 11 compliant

[PDF] are airbnb hosts independent contractors