Report of Alpha Prototype Results

December 11th, 2015

EE 415 Senior Design Project Management
Instructor: Patrick Pedrow
Sponsor: Decagon Devices Inc.

Team Dromond
Michael Anderson
Travis Beagles
Vasiliy Kravtsov
Maxwell Carson
Mentors
Derek Holmes
Michael McCain
Andy OFallon
Ben Walden

Introduction
This document contains the description of the Dromond platform alpha prototype. The alpha
prototype specifications will be explained with an in depth analysis of the solution chosen for the
final design. A summary of the alpha prototype presentation with the clients and representatives
will also be discussed. This discussion will include a some of the feedback Team Dromond
received after the presentation and future plans for the Drummond platform. The alpha prototype
represents a stepping stone in a large process in advancing to the next stages in developing the
Dromond platform.
Alpha Prototype Description
The alpha prototype was developed by following the iterative design algorithm and impact
analysis tools to develop the best solution to address the client's and stakeholders needs. The
alpha prototype is thoroughly covered by dividing the Dromond device into separate sub
components and supporting the decision for each sub component using the iterative design
algorithm and impact analysis.
The Dromond device is in final stages of the iterative design algorithm represented below in
Figure 1.

Figure 1: Current status in the iterative design algorithm.

In Figure 1, the alpha prototype is represented by the three green squares, stepping into the
process of Function and behavior discerned by testing. Within this module to represent a proof
of concept, the alpha prototype will follow rigorous testing and possible refinement recycling
back to the first green square on the very right where the beta prototype will be a reiteration.
The impact analysis techniques used in defining the alpha prototype followed two concepts
pertaining to the application and practice of the Dromond platform. The analysis techniques
Design for the Environment and Use Case Scenarios were defined to be the most important in
the application of the Dromond platform. The design for the environment follows a consideration
is to make the construction of the device is to make it reusable, where the battery is replaceable

upon its depletion. However, this route will increase cost as the device would have to be user
serviceable. This route could include a method of updating firmware and calibration via the
Bluetooth and the iOS app. Modularity of the device is also a consideration, as it could be used
for different sensors in the future if the design would allow for it. This would allow for new uses
for the same platform, decreasing cost across the device family.
The use case scenario provided a sense of designing the alpha prototype to accommodate outside
of the required features it provides. Examples to consider are the consumer market, considering
the reduction in homeowners insurance for homes with the Dromond installed, or possible
increase in a homes retail value with easy verification of mold free walls from a house
inspector. An example outside of the scope of structure place such as a cargo container requiring
a log of the humidity and temperature values during the trip. These needs could be implemented
within the device as additional features such as internal storage. Another area to expand on the
Dromond device capabilities, the device could become a product improving upon the growing
idea of a smart home of devices that are linked up onto a home network of appliances in a
consumers home. The Dromond device could become a gateway product that opens up a market
for more devices.
The Dromond device can be split modularly into a physical body, a circuit, a Bluetooth module,
firmware, and a smartphone application. The technical specifications for each subcomponent
were derived from the Solution Approach document, following the process of the engineering
analysis Modeling and Simulation represented in the iterative design algorithm to choose the
following specifications.
Device Body
Although the Dromond body is an important design consideration, the Dromond platforms
electronics and the iOS application were the primary proof of concept goals in the alpha
prototype. The future application of applying a body is explained further in the document within
the Design Modifications Resulting from Alpha Prototype Testing section. The PCB board for the
alpha prototype is too large to accommodate a reasonably sized casing and time constraints
resulted in the decision to focus on a body after the alpha prototype.
Circuit Design
The circuit design of the alpha prototype consisted of designing the circuit to accommodate
several features for user interfacing, debugging, and component analysis. The alpha prototype
circuit offers a variety extra components that compliments the process of testing the PCB proof
of concept and allows possibility of expansion of functionality without a new board. With the
help and feedback from the electrical engineers at Decagon, the alpha prototype circuit schematic
was created and is shown below in Figure 2.

Figure 2: Schematic of alpha prototype Dromond device.

The alpha prototype circuit has two options for 3.3v power supply hook up through which a
battery pack with two AA batteries can be connected or two wires straight from a DC power
source. The external battery pack was chosen for the prototype because rigorous testing would
drain coin cell batteries too quickly.
Three LEDs have been added to provide an interface in regards to the state of the board. One
LED represents power. Another LED acts as an indicator to see any system feedback in regards
to loading, connecting and debugging. The remaining LED represents an indicator if there is an
error representing several possibilities such as low battery, no connection, etc. The LEDs were
important in providing feedback as the engineering analysis of the board.
Mechanical components on the prototype are a reset button for resetting the Bluetooth module if
a soft reset is required for development tests and 4 mounting holes for a chamber to be bolted
down over the SHT25 sensor.
A Jtag port was added to the board to allow a tag connector hooked up to a Segger j-link to
connect to the arm processor that is on the Bluetooth module. This allows firmware to be
uploaded to the onboard flash and the access to the Bluetooth debugger. Development test with

firmware can be done through single step of instruction on the processor to determine if the alpha
prototype is behaving properly.
The circuit board also features test points on the PCB for quick debugging and testing of
hardware. There are also extra pin pads for easy access to any extra GPIO pins we may want to
include in future concept testing.
The final components to mention on Figure 2 are the BGM111 Bluetooth module that is acting as
our microcontroller of the Dromond Platform and the SHT25 temperature and humidity sensor
that provides the Dromond board with all measurements needed for mold detection.
The next step in the alpha prototype circuit design was creating a PCB layout of the schematic in
Figure 2. Figure 3 was obtained after a few circuit layout reviews and shows the 3D layout of
the Dromond alpha prototype PCB.

Figure 3: PCB of the alpha prototype circuit.

On the leftmost region of the PCB in Figure 3, the Bluetooth module is shown. The reset button,
jtag pins, LEDs and other component parts are also contained within this left section of the
board. The right half of the PCB contains the temperature and humidity sensor. Separating the
board like this has two benefits, first it gives the concept of the sensor being on its own layer for
a sampling housing chamber to enclose it. The second benefit is the right half of the board has no
copper layer allowing the sensor to be thermally isolated from reset of the components to
decrease the effects of any temperature error in measurement accuracy. A parts list for the alpha
prototype is provided in the appendix Figure A.1.

Bluetooth Module
For the alpha prototype, the Silabs BGM111 Bluetooth low energy module was chosen. This
module was chosen due to its favorable technical specifications in comparison to the other three
Bluetooth Low Energy (BLE) possibilities. The BGM111 development board was used to create
the alpha prototypes firmware while the alpha prototype circuit was being designed and printed.
Firmware
The firmware for the device is coded in the BGScript language that is designed for use on Silabs
and Bluegiga Bluetooth modules. BGScript allows for interfacing with onboard sensors, LEDs,
and other peripherals. The firmware is divided across several files: Project, Hardware, GATT,
Source code, and Sensors. These files are used to compile a bin file that can be flashed to the
device
The project file is coded in XML and is used by the compiler to combine all the different files
into one bin file that can be flashed onto the Bluetooth module. The hardware file, also in XML,
is the file that defines the hardware configuration of the Bluetooth device. For the alpha
prototype, this file is used to set up UART and I2C for communication with the iOS device and
sensor, respectively. GATT, which stands for Generic Attribute Profile, defines the services,
characteristics, and related data used for BLE communication. In the GATT file is a list of the
various services and the service characteristics that can be seen by devices connected to the
Bluetooth. These services and characteristics are defined by a unique identification number
called a UUID. UUIDs can be either 16-bits if the service/characteristic is an officially adopted
BLE service or 128-bits if the service/characteristic is custom to the device. Certain services are
considered mandatory by Bluetooth. In the alpha prototype, these services, along with services
1809 (Health Thermometer), and 181A (Environmental Sensing) are used. Since these are
officially adopted services, a custom UUID is not needed.
The last file is the script file, which is coded in Bluegigas BGScript language. This file contains
the event handlers that allow the Bluetooth device to interface with other devices and sensors.
There are several event handlers used in the alpha prototype, such as advertisement configuration
commands on startup.
Smartphone Application
The alpha prototype features an iOS application that is compatible with all iOS devices capable
of communicating with BLE devices. The prototype application uses a modified third-party
library to connect to the BGM111 Bluetooth development kit that broadcasts a temperature value
to the iOS device through Bluetooth. After a connection is established, the application receives
the temperature value, parses and processes it, and creates a log of temperature values on the
screen. This application is only capable of communicating with one external BLE device and can
only receive temperature readings. However, a sufficient user interface and connection scheme
has been established and can be used to evolve the alpha prototype application into something
much more featured and functional.
Cost
The cost of the major components, considered being bought in bulks exceeding thousands, are as
follows: BGM111 ~$6.20, SHT25 sensor ~$7.44, CR2477 coin cell battery ~$2.00. That makes a

cost of ~$15.64 for major components and leaves a ~$10 budget for mundane components (can
vary throughout prototype development). For the alpha prototype the cost of components falls
under the $25-dollar bar even with use of added components for development support that would
be removed for a final beta version. Figure A.1 represents the components within the Alpha
prototype resulting in a total cost of $22 for each boards parts.
Design Modifications Resulting from Alpha Prototype Testing
Through testing and modifications, features in the alpha prototype such as size, casing, circuit,
application interface, and battery will evolve into the upcoming beta prototype. The following
components are items to address in modifying for the beta prototype.
Body
The final device body will be shrunk nearly 4 times smaller than the prototype PCB. The desired
goal of making the sensor the size of a silver dollar will require a large reduction in PCB layout
size. The intended body to encase the sensor is represented in Figure 4.

Figure 4: Intended physical body of the Dromond device.

The Dromond platform beta prototype will be encased in a 3D printed two-piece shell. This
meets the impact analysis goals, as the case provides a way to apply the use case scenario
making the sensor noninvasive and ability to apply to any given environment. The ability to open
the Dromond casing for changing the batteries meets the environmental impact analysis and
ensure reusability of the device.
Circuit
The beta prototype will require less power consumption, on board batteries and rearrangement of
components. The power LED will be removed as keeping a constant LED on for power will
cause unnecessary battery usage. On board batteries will be added eliminating external power
access, as button batteries are the only source of energy that will fit within the casing. The
temperature and humidity sensor is required to be set in the middle of the PCB. It should also be
thermally separated from the rest of the circuit for accurate temperature readings. This may
require two separate PCBs to separate the sensor from the rest of the components.

iOS Application
The two most important requirements for the prototype application to satisfy next semester are to
build a better user interface, and establish a connection with multiple Dromond platforms. After
temperature and humidity readings can be received from multiple devices, the user interface will
need to include more data processing and viewing options. Users would benefit from being able
to sort the data, plot it, and save it.
Firmware
The beta prototype must consider several factors from the alpha prototype. The security of
accessing the alpha prototype provides a way for anyone to connect to it. Furthermore, to use
more than one Dromond device at a time will require a method of adding digital IDs to the
Dromond platform that can be sent over Bluetooth to the application.
Summary of Alpha Prototype Session with Industry Mentor
The presentation of the alpha prototype resulted in useful feedback and a way to begin moving
forward to future development. By outlining the presentation represented by the following list,
the presentation followed a modular organization for the Dromond Platform.
1.
2.
3.
4.
5.
6.

Abstract of the Project

Design Approach
PCB
iOS
Bluetooth Module
Future

Breaking the outline into individual sections offers a description of the section along with the
feedback presented by the faculty and mentors. With slides to provide visual aid, team Dromond
presented the process and current status of the Dromond Platform.
Abstract and Design Approach
The abstract and design approach slides defined what the Dromond Platform is and how we
approached designing it. In regards to defining the Dromond Platform, key features/goals to meet
were listed along with resources used in the process. This would include technical specifications
for the Dromond to follow. No feedback was given in regards to the function of the Dromond
Platform and design approach.
PCB
The PCB slides were in regards to the circuit component of the Dromond Platform. The layout
and component description were made here. Feedback was given in regards to testing the range
of the Bluetooth module by decreasing the silicon on the PCB, decreasing it incrementally to test
the Bluetooth range in regards to the decreased size of the PCB in the beta prototype. The range
is a concern needing to balance the size of the PCB and range of the Bluetooth. It was discussed
after the presentation on how interchangeable the SHT25 sensor is with other temperature
sensors with in best cases no changes to firmware or hardware layout. This turned into more
support on how having the SHT25 on a daughter board (separate from the main board) could
benefit in having a beta board that has no need for any major hardware changes to try a different

sensor, Instead the daughter board could simple be connected and disconnected allowing the
Dromond beta to be used on develop for other possible projects.
iOS
At the alpha prototype presentation, Dr. Pedrow suggested that we explore a stocks application
for ideas on the user interface. Users would benefit from seeing which rooms have gone down or
up in temperature or humidity, as well as plots of these values to assist in trend finding. A
recommendation from Ben Walden included incorporating cloud based storage to the application
so that users can access their data online. All of the above considerations will be explored in the
development of the final application.
Bluetooth
Discussion on the Bluetooth module implementation led to one inquiry by Ben Walden on the
possibility of logging measurements over time through the Dromond platform and storing those
measurements in flash memory. For our alpha prototype development, this is a feature we
decided not to pursue. However, Ben pointed out this is a feature that could possibly be adopted
on a sister project by Decagon in the mold market and is a feature we will be looking into for the
beta prototype.
Jacob Preston brought up an intermittent connection issue that he experienced while using the
same Bluetooth module and inquired if our team had experienced the same issues. We informed
him that we have had this issue also and he has forwarded us a pre-release SDK package to test
on the device. The BGM111 is a fairly new device on the market and still has some bugs. Future
updates to the device will use this SDK in hope of it fixing the connection issues.
Ben also expressed interest in the creation of a release day wiki which would contain the various
PDFs that were used in the development of the Bluetooth firmware. This wiki be useful for the
maintenance of the Dromond firmware and also for any new BGScript development that
Decagon may do.
Future
The final slide presented the next step in the Dromond Platform in designing the beta prototype.
This includes revisions we will make on the alpha prototype for improving the beta prototype.
Feedback in regards to the next procedure is new division of labor. This is important as since the
board is done everyone should contribute slightly differently to exhibit the best form of work.
We will also need to consider making the Dromond Platform have a sister product in which it
will act as a daughter board to try other sensors out through the Bluetooth module. In regards to
firmware, we will have to follow a few new boundaries. One is to make sure we standardize our
code with Decagon so the overall project will be beneficial and easy to use for all of the
engineers. And version control through GitHub, providing a way to provide better tracking of the
development of the code and compare or adjust past code for different applications.
Conclusion
With the alpha prototype fabricated and presented to the clients, the next step in the product
development can be taken. With feedback, team Dromond can continue in the process of
applying the beta prototype through trouble shooting, testing, and brainstorming using

techniques already applied in finding new ideas. The importance of constantly maturing our
impact analysis techniques and following the iterative design algorithm, the best solution can be
chosen for the following iterations of the prototype.

Appendix

Figure A. 1.: Receipt of components required for Dromond device alpha prototype.