Project Blox Final Report Submitted To: Prepared By · PDF file · 2015-10-27Project Blox Final Report Submitted To: Dr. Christine Julien Sponsoring Facufty Member Dr. Michael Becker

Project Blox Final Report

Submitted To:

Dr. Christine JulienSponsoring Facufty Member

Dr. Michael BeckerJongwook SohnTracy Wuster

Prepared By:

Dan ClearyAnkita KaulJesse TannahillZach Wasson

EE464 Senior Design ProjectElectrical and Computer Engineering Department

University ofTexas at Austin

Fall 2010

TABLE OF CONTENTSTABLES.ivFIGURES.vEXECUTIVE SUMMARY.

1,0 INTRODUCTION 12.0 DESIGN PROBLEM STATEMENT 22.1 Customer Needs 22.2 Requirements and Specifications 3

3.0 DESIGN PROBLEM SOLUTION 33.1 Core Subsystem 53.2 Communication Subsystem 63.3 User I/O Subsystem 83.4 Development Environment Subsystem 93.5 Deliverables 12

4.0 DESIGN IMPLEMENTATION 124.1 Core Subsystem Implementation 134.2 User I/O Subsystem Implementation 144.3 Communication Subsystem Implementation 164.4 Development Environment Subsystem 16

5.0 TEST AND EVALUATION 195.1 Component Testing 195.2 Subsystem Testing 225.3 System Testing 27

6.0 TiME AND COST CONSiDERATIONS 286.1 Schedule Review 296.2 Budgetar Concerns 30

7,0 SAFETY AND ETHICAL ASPECTS OF DESIGN 318.0 RECOMMENI)ATIONS 318.1 Blox Peripherals 318.2 Blox Core hardware 338.3 BloxSofParc..

ii

TABLE OF CONTENTS

9.0 CONCLUSIONS 35

REFERENCES 37

APPENDIX A - GANTT CHART A-i

APPENDIX B - BILL OF MATERIALS B-i

APPENDIX C - DEMO APPLICATIONS C-i

TABLES

Table 1 - Mass Production Estimate.30

FIGURES

Figure 1 : Sstern BlockDiagram 5

Figure 2 Core Subsystem Block Diagram 6

Figure 3 : Communication Subsystem Block Diagram 7

Figure 4 : User 1/0 Subsystem Block Diagram 8

Figure 5 Development Environment Subsystem Block Diagram 10

Figure C,- I Countdown Application C-2

Figure C- 2 MemoryMaze Application C-3

EXECUTIVE SUMMARY

This summary details the design process and implementation of Project Blox during Spring andFall 2010 at the University of Texas at Austin. We start by providing a detailed description of theproblem that Project Blox tackled: creating a distributed computing platform composed of Blox.small cube-shaped embedded systems, with a software development kit allowing deveopers tocreate innovative applications (Section 2). Project Blox mainly targeted the entertainmentindustry through engaging distributed games and the education industry through conceptmodeling.

Our proposed solution has been broken down into four subsystems—Core. Communication, UserI/O. and Development (Section 3). We created Blox with an enclosure using selective lasersintering (SLS), a custom PCB, many peripherals for user interaction (OLED display,accelerometer, touchpanels), and communication peripherals for Blox-to-Blox interaction(infrared, XBee). We detail the basic construction of a Blox and how this design satisfies theproject’s specifications and needs.

While the end-design proved successful, many challenges were overcome in its actualimplementation (Section 4). The largest changes included creating an additional custom PCB fora speaker amplifier and adjusting the IrDA sensors to reduce the signal cone to a manageablearea. Almost every software driver took much longer than planned, but we successfully createdover 10000 lines of platform code and 317 pages of supporting documentation [1]. Severallevels of testing were also performed during the implementation of Project Blox (Section 5). Weperformed component level tests on the sensors and electronics to find faulty parts, subsystem-level tests on completed interfaces to verify correct operation, and system-level tests to ensureoverall system behavior.

During the design-phase of Project Blox we came up with an initial estimate of the time (seeAppendix A) and cost (see Appendix B) which were modified to reflect reality during theimplementation phase. The project was completed by Open House and came in under budget at$2207 of our allocated $5000 funded by Dr. Christine Julien (Section 6).

We compiled a list of recommendations for future project efforts (Section 8). Spending moretime on the intial main PCB design would have saved us a lot of grief later on by allowingeverything to be intergrated on one board instead of creating separate “helper’ boards to fill ingaps. Also. the OLED display did not contribute as much as we had hoped to the outputcapabilities of a Blox, and a LCD option would be much cheaper and easier to acquire.

Projeci Blox was an overall success. placing first at the Fall 2010 Senior Design Open I-louse.Ail of our promised deliverables were successful designed. created. tested, and demonstrated tothe public. The Riox platform has proven itself yen stable in the weeks since its completion. Welook forward to developing interesting applications in the future!

1.0 INTRODUCTION

This report is a comprehensive summary of the design, execution, and evaluation of Project

Blox. The project aimed to create a distributed computing platform with a software development

kit (SDK) allowing developers to create innovative applications that primarily target the

entertainment and education industries. Distributed applications run on one or more cube-shaped

embedded systems called Blox. each roughly the size of a Rubik’s Cube and featuring a display.

wireless communication, and input sensors. The successful completion of our project resulted in

a new platform for prototyping distributed systems that is easily expandable. For purposes of FE

464. we created five prototype Blox and two demo applications to demonstrate the capabilities of

the platform. One application will be used as an educational tool to teach basic counting skills

while the other, an entertainment application, allows users to uncover pieces of a labyrinth

through the manipulation of Bloxen.

The Project Blox design team consists of Dan Cleary, Ankita Kaul. Jesse Tannahill and Zach

Wasson and was funded by Dr. Christine Julien. In the following pages we will further elaborate

on seven areas that outline the project process sequentially: problem background. design

solution. implementation. testing, scheduling and fiscal summary. and final comprehensive

evaluation. In the problem background section. we explore the customer needs for a distributed

application platform and outline the general design of our Blox solution. Afterwards, we break

down the project into four subsystems—Communication, Core, User I/O and Software

Development Environment—explaining the design solution and implementation of each. We

then evaluate the design by discussing our testing process, results and subsequent design

alterations. Next. we provide insight into the scheduling and fiscal evaluation of the project.

focusing primarily on the time constraints olthe class itself and the strategy for keeping under

our sponsor s piedeed budget. Finally, we conclude with an evaluation and recommendations for

our completed project. The design and implementation process we have outlined in this paper.

together with our Blox Software Documentation [Ij, can be used as a starting point for further

platform or application development.

2.0 DESIGN PROBLEM STATEMENT

This section expounds on the problem that Project Blox seeks to solve and the requirements of asuccessful solution.

The Blox design expands on the design of MIT Media Lab’s Siftahies technology [21. Like

Si/rabies. Blox allows users to physically manipulate data and uses an accelerometer and 1Rsensors. The distinguishing factors of our project will be the physical shape (cubes in comparison

to tiles), the ability of each Biox to make independent decisions (Si/lab/es uses a centralmanagement application), arid the added peripherals (touch panels, speaker, and USB serial).

In an attempt to follow the progression of society via technology Project Blox strives to create“blocks of the future’ by taking traditional blocks and incorporating a technological twist. Thesystem is intended for two types of audiences: developers and end-users. For developers, the

project provides a platform to write and run their own distributed applications. For end-users, theproject gives them a fun educational and entertaining product that surpasses the capabilities of

traditional blocks.

2.1 Customer Needs

Project Blox will meet the needs of our intended audience, which are outlined below:

Platform for distributed applications: The system must be able to run distributed

applications (examples in Appendix C).

• Versatile functionality: Developers must be able to create a variety of applications using

the visual, aural, and tactile I/O interfaces supported by Blox.

• Intuitive interactions: The Blox interface should provide a common sense experience that

users should be able to navigate with minimum guidance and confusion.

• Ease of programming: Developers should be able to create applications using our SDK as

easily as a distributed application on a system of desktops.

• Low implementation costs: The end-users should find Blox as affordable as common

entertainment systems.

• Durability: Blox should be able to withstand environmental pressures of young children.such as shaking. banging. as well as surviving a five foot fall.Fun factor: The Blox experience should be enjoyable for both developers and end-users.

2.2 Requirements and Specifications

Our system’s requirements can be defined in two areas: the design of Blox hardware and thefeatures of the software development environment used to create applications.

Each Blox consists of a cube-shaped embedded system approximately the size of a Rubik’s Cube(3.2” x 3.2” x 3.2”) with a casing made from nylon plastic using selective laser sintering (SLS)technology, The casing will be safe for Young children to use. Our two hardware-centricsubsystems. Core and I/O. need to he mounted inside the casing to complete the hardwareportion of a Blox. To make decisions independently, a Blox contains a STM32F1O3\/Eprocessor. a main PCB, supporting hardware, and a 3.7V battery lasting at least six hours undernormal load. A Blox will be able to recharge and load new applications via a USB interface fromvarious platforms (Windows. Mac. Linux). To provide versatile functionality to developers, wedecided to include input’output interfaces that allow users to interact with a Biox through visual,aural. and tacti!e interfaces.

The main method for communicated information to the user visually was determined to hethrough an organic light emitting display (OLED) located on top of the cube, which is capable ofvideo playback while the Blox is under full load. A speaker on the bottom of the Blox shouldemit sound clear enough to understand recorded voices from at least five feet away. Users will beable to interact with a Blox by touching any of the four touch-panels on the sides of a Blox,which will he able to track finger movement across the panel. Rough shaking or tilting will bedetected by an accelerometer mounted inside a Blox. By carefully arranging a Blox’s I/Ointerfaces, we believe the user will he able to hold a Blox and intuitively manipulate each

interfac. Using these interfaces, developers will he able to create interactive distributed

applications

lntbrmation is communicated between Blox using the interfaces contained in theCommunications Subsystem. The Si)K will require that each Blox uniquely identify from other

Biox running the same application. This policy and an internal Xbee wireless sensor allows two

specific Blox to easily exchange data. Infrared channels will be included on each face of a Blox

to allow developers the ability to write applications that use information about the network

topology. Blox facing each other will be able to identify which Blox in the network is facing

them and use this inthrmation in running distributed application.

The Development Environment will provide tools and examples to help developers create a

working distributed application on top of a network of Blox. Even in desktop computer systems.

creating a concurrent application can be very difficult. The SDK contained in the Software

Development Subsystem will simplify the process of creating a distributed application on Blox

by providing abstractions to the concurrency and devices that developers face. Drivers will be

created for each interface listed above to hide the hardware implementation from developers and

make the interfaces more straightforward. Furthermore, for the communication interfaces

(infrared and XBee) we will facilitate the dynamic construction of the network and dispersion of

neiwork topology information. Two communication modes will exist for the infrared channel: a

raw mode. where the developer has access directly to the channel input/output: and. a message

passing mode. where the SDK will facilitate the discovery of cubes next to each other and the

transmission of messages between each Blox. Power management features will also be included

to allow developers to put a single Blox or the entire system into ‘sleep’ mode or have the LEDs

flash when the battery reaches a critical level,

3M DESIGN PROBLEM SOLUTiON

Our design strategy was created with the overall goal of Project Blox in mind—to create an

intuitive distributed computing platform and SDK—along with the requirements and

specifications discussed earlier in Section 2.0. As seen in Figure 1. the Blox system can be

described in the interaction of four main subsystems: Core. Communication. User I/O, and

Development Environment. Each Blox can exchange information with other Blox and Users, as

\\ Cii as receive programs from developers.

Biox Device

__

tFigure 1: System Block Diagram

Each Blox device will contain a “core” system where the application code physically resides

including the electronics necessary to allow a Blox to make independent decisions and run the

distributed application. The Core subsystem will be able to utilize the interfaces available in the

Communication subsystem to send and receive messages from other Blox, Messages sent and

recei ed in the Communication subsystem can contain both application data and network

topolog information. The Core subsystem can also query (or be interrupted by) interfaces in the

User P0 subsystem, which contains interfaces to send and receive information from an outside

user The running distnbuted application is able to run on top of the Core subsystem, and create

channels to the Communication and User I/O subsystems to get the information necessary for the

application to run.

To actually write the applications, developers will create programs using features of our

De elopment Environment subsystem, which includes a programming model and SDK. The

written programs will transferred into the Core subsystem using a transfer program a ailable in

the De elopment Environment subsystem.

3,1 Core Subsystem

Ihe ( orc uhsystem (see Figure 2) consists of the physical components of our system that allou

a Bk x o ploccs information and function as an independent embedded system,

Program Charge

Figure 2 : Core Subsystem Block Diagram

[The main processing power of a Blox, an ARM Cortex-M3 microcontroller, was integrated into

the (ore subsystem soldered onto the main PCB of the system. We considered other

microcontrollers such as the Freescale 9S 12, but we chose the ARM since it is the most powerful

processor that we hae experience with. The running application will reside and be executed on

this rnicrocontrolle?s embedded memory. The microcontroller is connected to interfaces in the

Communication and User I/O Subsystem through circuitry on the main PCB. A battery with a

power s\\itch provides power to both the 3.3V rail and the 5V rail. A mini USB interface located

on the bottom of the Blox both programs the microcontroller and charges the battery when

connected to a computer. The alternative we considered to the charging with USB was to make

the user phvsicall exchange hatteries however, we opted for the charging circuitry to avoid

potential durability or cabling issues that may have resulted from easy access to the electronic

Biox interior.

3.2 Communication Subsystem

The ( ommunication subsystem (see Figure 3) allows a set of Blox to communicate with each

other. There are two main interfaces for this communication: infrared for neighbor detection. and

XI3ee for a irelcss area network.

Data

InterfarDA Interface

tiD

Figure 3 Communication Subsystem Block Diagram

Infrared transceriers are placed four on a face. on the four side faces of a Blox. When two Bloxare placed adjacent, one or more of these transceivers will be able to exchange global identifiers(an ID in Figure 3) between the Blox. In this way, a Blox will be able to tell its relative locationto other Blox in the system. The infrared transceivers will connect with the core subsystemthrough an IrDA interface to send and receive information. Proximity sensors were alsoconsidered for neighbor detection, but they do not provide the directionality that infraredprovides. In addition. proximity sensors cannot send or receive information. Therefore we choseinfrared transceivers since they provide much more flexibility.

To create a wireless network over the entire distributed application, an XBee will be included

that will create a wireless area network. The XBee will be included inside of the Blox enclosure.and connect to the Core subsystem through an SCI interface. Blox will use this communication

channel to propagate data across the entire application, or to exchange large amounts of databetween pairs of Blox. The process of sending and receiving data is shown in Figure 3. The coresubsystem pros ides data for transmission and specifies which Blox to send the data to. The datais then sent over XBee to other Biox in the network. Data received from the network is passedhack to the core subsystem for processing. The alternatives to XBee were WiFi and Bluetooth.e opted for XBee due to our familiarity with it and its low power consumption.

XBee Interface

L

j

3.3 User 1/0 Subsystem

The User I/O subsystem (see Figure 4) contains the input interfaces that allow users to provide

feedback to a Blox and contains the output interfaces to allow applications to display intbrrnation

to users.

Touch

Movement

sPJ

___

Yw‘, I

4 TTLSDCard

Figure 4: User I/O Subsystem Block Diagram

3.3. 1 Input

In order to receive diverse information from the user, each Blox will include two input

mechanisms: an accelerometer and four touchpanels.

The accelerometer grants users the ability to communicate to each Blox through tilt motions and

vibrations. The accelerometer produces a voltage for each of the three axes of movement based

on the acceleration corresponding to each direction. These analog signals are passed through an

analog-to-digital converter to the Core subsystem to be processed in the running application.

Resisti e touchpanel technology will provide users the opportunity to control applications by

touching the side faces of the Blox. Pressing on a specific coordinate of a touchpancl will

generate an analog signal that a 4-wire controller wi H interpret. The touchpanel controller will

send the X and Y coordinates of the press oer an SPI interface to the Core subsystem. An

ilternatr e to the resistive toupanel that e considered were trackpads. We opted against this and

in I .n or Ur touchpanels because the touchpanels would allo fOr gesture detection and greater

pOiCntlai uabiiity for deelopers.

3.3.2 Output

Blox applications will use a speaker and an OLED display to provide audio and visual feedback

to the user. When audio feedback is required for an application, the Blox core subsystem will

send digital signals corresponding to a sound wave through a digitalto-analog converter and

then to the speaker. This speaker transforms this analog signal into sound waves which the user

hears.

To provide visual feedback to the user, applications will utilize an OLED display located on the

top face of the Blox. To display information on the screen. the Blox core will communicate

commands through an SPI interface to the OLED integrated circuit. The Blox core can command

the OLED to display text or graphics based on the instructions it receives, or it can display

images based on their location within a Secure Digital (SD) card. We had originally proposed

having displays on five out of the six sides of a single Biox; however, we decided against this

due to the flscal tradeoff.

3.4 Development Environment Subsystem

The I)evelopment Environment subsystem (see Figure 5) defines the process developers will use

to create distributed applications, and how the applications will make their way onto the Core

subsystem to run on the physical Blox device. A developer will create a code base following our

programming model and using the device drivers as needed to interface with the Communication

and user I/O subsystems. The feature modules of the SDK will contain common functions that

developers will be able to utilize to simply their programs significantly. A cross-platform

compiler will be provided to take the developer’s code base and the SDK and create a binary

version. A transfer program will allow developers to connect each Blox to a computer via the

mini USB interface in the Core subsystem. This transfer program will display the applications

currently loaded onto the connected Blox. and allow deletion of existing applicalion. and loading

of new application binaries.

Figure 5 Development Environment Subsystem Block Diagram

The sotlwarc development kit (SDK) includes three main components: device drivers tbr each

interface in the Communication and User i/O Subsystem, feature modules for commonly

performed tasks, and a programming model that developers should follow to create successful

applications.

3.4.1 Dei’ic Diivc’I:s

Our de\ ice drivers provide a hardware abstraction so developers can easily access the interfaces.

and also create modular code if we decide to change the underlying hardware at some point.

Information can be gathered from input interfaces by polling the interface or by assigning an

interrupt to the interface and creating an interrupt handling procedure. The device driver causes

an interrupt to occur when some action occurs and pass relevant data from that interface into the

interrupt where it can be serviced by the application processor.

3.4. Feature Modules

Distributed applications tend to require a lot of the same functionality, We attempt to encapsulate

some of this functionality in optional feature modules that can be included and used at v ill by

the de\ eloper.

Role \lana2crnent allons developers to create multiple roles vithin a distributed application and

what that role does when running. It also provides mechanisms for a role to be ‘instantiated” and

reterred to throughout the program via a global identifier. When an application begins the leader

E31o\ will assign a iole instantiation to one of the Bbs in the network before execution hegir.

Afier execution begins, a Blox will not be able to change roles and will remain the same for the

duration of the application’s execution.

Neighbor Detection controls of the infrared channels on the faces of the Blox and automatically

update when new Blox are passed adjacent to each other. At set intervals, the Blox will send out

“pings” to try and locate adjacent Blox. On discovery, both Blox will exchange their global

identifiers across the infrared channel. The Biox can then communicate data by using the XBee

network. Pings will continue to be sent out at set intervals to ensure that the adjacent Blox are

still adjacent. An array will be provided to the developer that will represent the four sides of the

Blox with the global identifiers of the Blox (if any) that are adjacent.

To facilitate low power applications, we will provide a module that will be able to shut down all

functions of the Blox until a specified event occurs. Developers will be able to trigger a wakeup

on any of the input interfaces and the module will shut down all of the Blox system except those

subsystems needed to manage the triggering event. An automatic sleep feature will also be

provided that will trigger on any of the input mechanisms (touchpanel, infrared, XBee.

accelerometer).

3.4.3 Programming Model

The programming model provides a set of guidelines to follow so that applications can

successfully run on top of a system of Blox. Developers do not have to follow this model, but it

is our vision of iow an application will look and the device drivers/provided feature modules are

tailored to this model.

A program will consist of a set of source code including an initialization file and source code for

each of the roles in the application. Each file will be written as a stand-alone program and

compile into separate binaries. The Role Management feature module is used in the initialization

script to create mstantiatlons of each i’ole. On instantiation, the Blox running the initialization

script will send both the role and global identifier to a role-less Blox. After instantiating all roles.

the leader Blox wili broadcast a begin signal and each Blox will execute the binary H conans for

its assigned role,

The source code for each role will initiaiize the needed feature modules and device drivers.Needed input interfaces will assign the device driver for that interface to an interrupt vector anddefine the interrupt handler for that vector. Output interfaces (exception of infrared) will sendmessages by busy-waiting or setting up a temporary interrupt until the message has been sent.When no interrupts are being serviced a main procedure will run to take care of the state of theapplication (e.g.. process received information).

3.5 Deliverables

The deliverables for Project Blox includes both software and hardware components along withextensive documentation. Project Blox’s primary objective is to develop a successful software

platform, so a majority of our project deliverables will consist of the code and the documentationassociated vith the Blox system. The extensive documentation meets the ease of programmingcustomer need by allowing future application developers the ability to expand on our originalSDK. We will also provide the code for the two demonstration applications (see Appendix C).

The hardware deliverables consists of a prototype B!ox as well as any schematics. data sheets.and component lists necessary to independently build a Blox. For purposes of EF 464 and our

demonstration applications we chose to build five identical Blox prototypes: however, theplatform was designed so more Blox can be added to the distributed system as the future user or

developer sees fit. While data sheets for the components we use will be included in the

documentation, we also intend on creating our own data sheets for the Blox system.

4.0 DESiGN IMPLEMENTATION

Durin our semester in EE 464 we succeeded in implementing the core functionality of Project

Blox as described earlier in Section 3.0. though we ran into many unexpected challenges that led

us to change some of our initial designs and process plan. As with the design phase. our proJect

implementation was highly collaborative with multiple team members working on each

subsystem while simultaneously each individual owning portions of the project implementation.ifl Figure 6 heIo\v. we outline the overall project process flow diagram.

p

Rij sw4P Deid -

Wne ewemods

Figure 6: Project Process Flow Diagram

Our subs stem level implementation process was originally expected to take from lateAiigust to

midOctoher, but e ended up continuing implementation through early November due to the

difficulties we encountered. The following subsections describe the implementation process for

each subsystem.

3.1 Core Subsystem Implementation

The implementation of the core subsystem followed closely with our original plan. The only

modifications necessary were minor and easily fixable. For the casing. all issues dealt with

components not fitting properly. For the PCB, a few components were forgotten.

As we were assembling the casing for the first B lox. we realized the opening for the OLED

displa’. was too small. We also found out how fragile the display was, as the original test OLED

nas missing nultiple lines of pixels After contacting the manufacturer. we found that the

e\posed ribbon cable will malfunction if any pressure is placed on it, resulting in lines of pixels

to O permanentl missing. In order To amend both of these issues, we enlarged the displa slot

so that the ribbon cable would not touch the case at all, and we recessed the display by 1/8” to

further protect it from users touching it.

We also came across a fitting issue during the final assembly process The speaker for one

particular bottom panel was very loose; typically the speakers snapped into place. This happened

due to us placing and removing the speaker too many times. In the end, we overcame this

ohtacle by gluing the speaker in place.

The PCI3 also had some minor issues, but fortunately, a second PCB was not necessary. First of

all. the PCB was missing a vital pull-up resistor that allows for interrupts on the touchpanels,

I uckily, we were able to solder a resistor directly to the chip as shown in Figure 7 below.

Figure 7 : Touch controllers with pull-up resistors

Secondly, the main PCB had the charging circuitry connected to the wrong net. The output was

connected to the wrong side of the power switch, rather than directly to the battery. Therefore the

battery could only be charged when the Blox was turned on. We attempted to cut the trace and

physically wire the output to the battery, but this caused the board to overheat (due to the

incision being too deep). We determined it was not worthwhile to ruin another board since the

issue was a minor annoyance; the Blox must be disconnected from USB before the power switch

can be toggled to power cycle the Blox.

42 Laser 1 0 Subsystem Implementation

I m. I. set 1/0 subsystem followed our original design x cry closely. However, we left the

nt if aces under-specified an some area and some componenk did not heha e as expected. Our

r aj i issues were a soft speaker, fragile display, and mounting considerations

After creating the speaker driver for the Development subsystem and testing the volume of the

speaker. we realized that driving the speaker directly from a microcontroller pm would not

produce a loud enough sound. We decided to create an additional custom PCB that used the

TS4990, an audio amplifier, with a gain of 4 to make the speaker loud enough to be heard from

five feet and meet our specification as shown in Figure 8 below.

By adding the speaker amplifier the speaker actually became too loud and we were forced to

control its volume in software.

1

There were no major problems with the touchpanel interface, the Palm Treo replacement

touchpanels we purchased had adhesive on the back that stuck nicely to the nyion material of the

case. The cable from the touchpanel was able to plug into the breakout board and finally into the

main PCB through a custom cable.

During testing with the OLED display, we noticed that lines of pixels were disappearing. On

further inspection, we discovered that there was an issue with the ribbon cable connecting the

OLED display to its supporting circuitry. If any pressure is applied on the ribbon cable. pixel

lines can disappear. To alleviate this issue. the slot for the display on the casing was enlarged so

no pressure could he placed on the ribbon cable from sitting in the case. Additionaly, the display

is now inset from the outside face by 2 more mm so it is less likely the display could be injured

by being placed face down or from people touching it.

Figure 8 : Speaker Amplifer Assembly

4.3 Communication Subsystem Implementation

While ultimately successful. we ran into a couple of difficulties with the implementation of the

communiation subsystem. After consulting with the datasheets. we were able to find simple

olutions to most of cur issues S -ri.

The infrared sensors proved to ilae too large of a signal cone for general use. This is a

combination of the windov design in the case and the IrDA sensor itself. We experimented with

placing different kinds ot materials in front of the IrDA sensor with varying success. The best

material would be a polarizing material that would direct the signal and reduce its power. We

could not easily affix this material to the existing windows, but using masking tape produced the

desired 30 degree signal cone with a range of about 10”.

Due to network congestion when multiple Blox broadcast at the same time, we had difficulty

communicating across the network. in order to resolve this problem. we explored different XBee

settings such as increasing the random delay slots. Increasing this number from one to three

resulted in a more reliable connection among a group of Bloxen. Additionally. we increased the

number of retransmissions so each Blox would have more attempts to get its message across the

channeL Once the main PCB was placed inside the enclosie. the XBee signal strength became

too weak to meet ou original specification often feet. After further inspection, we noticed the

added speaker amplifier was crammed next to the antenna on the XBee. We fixed this issue by

moving the speaker amplilier axay from the XBee . After testing this new configuration, we

found the range of the XBee to be acceptable.

4.4 Development Environment SubsystemI he lnaior components of Uhis subsystem: device drivers, feature modules, and demo

appIeati;is. all ending up takin much longer than originall\ estimated.We ended wih over

lin of code and a 3 17 page book of documentation [1].

i make ‘ ood platform. we decided that we needed to make some additional driers that

h’o:ct n i the iness deteik of the microcontroller we were using. In addition to the

device drivers, we created drivers for timed interrupts, externally triggered interrupts. F1FO data

structures, tilesystems, virtual USART, accessing or modifying system variables, and debugging

information. These drivers formed a solid foundation to build the device drivers hut took much

longer to develop than expected.

The device drivers themselves were very straightforward to implement once the low-level system

drivers were complete. Each device driver attempted to provide very simple access patterns for

each peripheral. For example. the accelerometer driver allows a user to poii for an integer value

that represents the amount of tilt in the X. Y. or Z axis. The XBee driver however, lets a user

register a function to he called when data is received. We found that for XBee and 1R, it was

very likely a user would want 10 be alerted the instant a frame came in, so we added the

capability to interrupt on receiving a frame.

Our original gesture detection, power management, and role management feature modules were

completed successfully. The gesture detection feature module works by interrupting on a user

touching one of the four touchpanel on a Blox. It then measures for a full second (or until the

user lifts their finger) and records the path the gesture takes. Once their finger has been lifted, the

module calculates the average movement and evaluates the gesture to one of nine gestures (tap,

moving along a cardinal direction or any of the 4 diagonals). Developers can read out the last

read gesture using a simple api call which returns the type of gesture and a timestamp to make

sure it isnt stale. The role management feature module ended up being one of the most

complicated pieces of software in the Blox platform. Once an application is started on one Blox,

a specific protocol (illustrated in Figure 9) finds other base programs in the area. and starts the

same application on those Blox with the needed roles to create a successful instance of that

distributed application.

17

Parent Child

User beginsapplication

Parent Query (No response)

BaseQucry

BaseACK

App. Start

Parent QueryParent ACK IZZiiL. (Runs application)

(Runs application)

Figure 9 : Role Management Protocol

The final feature module power management is not as feature-filled as originally enx isioned. Due

to time constraints, none of the sleeping capabilities of the microcontroller were used. Dris ers

can register a tuiletion with the power management feature module that will he called v hen

entering sleep mode and another to be called on exiting sleep mode. This will allow peripherals

to disable theinselve. hut there is no useful way to trigger exit from sleep mode.

Since the beginning, we have planned to create two demo applications, MemoryMaze and

CountDown (sec Appendix C). Dan Cleary completed MemoryMaze as described in the

Appendix for Open Flouse. It is functionally complete, but some bugs remain. Specifically, when

the character is moving from one Blox to another, it is possible for the character to leave one

Blox and get lost in space. Also, there are some buggy situations where the game crashes for

a reasons, Again due to time constraints. CountDown has been di asticall. modified.

Instead ot a model of paralleliin. the ness demo application siniply shows thiee numbers, the

romher of Blox ahus c, the number heloss . and the total number of Blox found. These iunnhers

aic alcuIateij using a recursive lookup Os er the infrared interface. The BIos at the top of the

hjn :aturns that it is the onI BIos above the 2nd BIos in the chain, the 2nd BIos returns 2

B ins, and on to build an accurate representation of the chain on all B los. E en though theappli ‘ (fl lacked Ihncr graphics, it lullilled itc puose x er \s cii \hen another Bin was

placed in a vertical chain of B lox. all others in the chain would immediately update with theinformation about the newly added Blox. In the future, this application could be expanded toinclude chains that extend in all directions rather than only up and down.

5.0 TEST AND EVALUATION

The success of our project was contingent on thorough testing throughout the project

implementation process. In the thilowing subsections, we discuss the testing and evaluation

process from the ground up. We began our testing process with our sensors and basic hardware

components. After we confirmed that all individual components functioned to our standards, we

integrated these components ith software to build subsystems. and ended with the overall

s stem-level testing.

5.1 Component Testing

At its most fundamental level, a Blox contains seven peripherals and three core hardware

components which need to function independently. Here we outline this first phase of our testing

process.

iLl Peripherals

The project peripherals are the key to building the User I/O Subsystem, designing the main PCB.

and writing the device drivers. Each peripheral operates different independently and we tested

each peripheral independently of the others to ensure that each Blox would function properly.

51. 1.1 OLED DLsplay

I he 01 FD displa had a quick test built into it in the form of an “auto-slideshow” program that

loaded directly onto the display’s chip. When a jumper vvas connected between Pin 6 and OND.the displax ould sho\ a slideshow of the images on the display’s SD card. By atching theseimages. se were able to see whether there ere any dead pixels present on the display andensure the small microcontroller on the display itself is functioning correctly. Dan Clearypertormed this tect on August 25’ and was able to catch an OLED with several lines of dead

it)

pixels. We discarded the faulty display and ensured we had five properly functioning displays

before continuing with the subsystem level testing.

5. 1. 1.2 Accelerometer

The MMA726OQ accelerometer outputs three voltages corresponding to the amount of tilt in X.

Y. and Z axes. The range of voltages specified by the datasheet indicated that they should be

between 0 and 3.3 V dependent on the g-forces the accelerometer experiences. To test the

accelerometer, we created a table of reference angles and voltages (e.g.. 900 = 0.85 V on that

axis). Each part was tested by measuring the voltages the accelerometer outputted at these

reference angles and verified similar resulting behavior. The testing took two days and was

completed by Dan Cleary on September 21. Of the six accelerometers ordered and tested, one

malfunctioning accelerometer was discovered and the remaining five accelerometers had voltage

readings ranging from 0.85V to 2.5V on each axis.

5.1.1.3 Touchpanels

To test the touchpanels, a 3.3V power source was connected to the touchpanel controller and the

X and Y pins for voltage changes due to tracing a finger on the touchpanel were measured.

Voltage measurement readings were taken at every 3cm and examined to ensure the voltage

varies linearly. This testing took two days and was completed by Ankita Kaul on September 5,

The next stage of testing involved writing some basic driver code and recreating the first test

over Serial Peripheral Interface (SPI). Ankita Kaul finished testing the touchpanels on September

30. The final phase of touchpanel testing involved interfacing the touchpanels with our main

PCB. which resulted in some problems. After initially suspecting faulty chips, we determined the

lack of a resistor on the main PCB that was needed to measure pressure through the PEN IRQ pin

on the touchpanel controller. We were able to solder miniscule resistors directly onto the main

PCB, which solved this problem.

5.1. I.-iSi,eaker

The speaker was initially tested for audio range by connecting it directly to a function generator.

The next phase of testing was using the microcontroller’s built in DAC to send the speaker

voltages that oscillate in a triangle wave at various frequencies. In order to ensure that it projects

a steady tone across the frequency spectrum. we tested frequencies from l-kHz to 20-kHz at 4-

kHz intervals. All speakers tested produced a steady sound audible from four feet away through

both of phases of testing. These tests took one day and were completed by Ankita Kaul on

October 1.

5. 1.1.5 LED Lights

The functionality of an LED is determined solely on their ability to turn on. A simple LED

circuit with a power source and resistor to limit current was constructed to test that the LED

could turn on. Current measurements on the power source were noted to ensure the LEDs were

are within the datasheets specifications. The testing took one day and was tested by Jesse

Tannahill on September 29.

5. 1. 1. 6 infrared Sensors

There were three critical pieces of information we need to test for each JR sensor which included

effective communication, range. and the signal cone size. A simple program that continually sent

packets between two IR sensors and monitored packet loss was utilized to determine all of this

information. Using this program, the range was tested by gradually pulled two sensors apart until

the packet loss exceeded 10%. The signal cone was measured by slowly angling the sensors

awa from each other until the packet loss exceeded 10%. The IR sensors needed to be able to

transmit at least six inches and have a signal cone that doesn’t reach Blox that aren’t facing the

transmitting Blox (30 degrees). The testing will be done by Dan Cleary on October 1. During

testing found one mis soldered cable and to accidentally bridged pins, however, once these

mistakes were corrected all 16 sensors could send from all four edges and receive on one edge.

h5.1iEXbee

Similar the JR sensois a simple program was constructed to establish a connection and send data

beiween tn-n Xhee sensors. The data sent and received will he verified by the tester to ensure the

data s not scrambled during transmission. The Xhee sensors should be able to transmit data with

no packet loss at least 10 feet and at a baud rate of 115200. This will take two days and will he

completed by Dan Clear on October 1,

5.1.2 Core Hardware

The Core I-lardware Subsystem contains components that make up the internals of a Blox

including a STM32 microcontroller. USH to Serial converter, battery, and charging circuit.

.5. 1.2. I S77v132 ,lficrocontroller

To make sure that the STM32 microcontroller works on a basic level and is capable of handling

other components. we loaded a program which simply blinks an LED on and off at a rate of I

blink sec. This confirmed that the STM32 was functioning. could store a program in flash, and

could output to an external peripheral. This testing took one day and was completed on October

5 by Zach Wasson.

5. 1.2.2 (1513 to Serial Converter

The USB to serial converter allows us to program the microcontroller from USB on a host

conwuter and receive serial at the microcontroller side. We constructed a simple test program

that sends several frames of data between the microcontroller and host computer. By analyzing

these frames and ensuring the data gets through the converter correctly going both directions. A

baud rate of 115200 was attained with minimal frame corruption. Testing was completed the

week of October 24 by Zach Wasson.

5. 1.2.3 Baneii and Charging Circuit

The power rail from the USB bus will be used to charge the battery. With LISB plugged into the

system, an ammeter will be connected to measure that lOOmA or 500mA are being drawn based

on a jumper. After waiting for the battery to charge, an LED in the battery charging circuit

should light up. After charging, we will verify the battery’s voltage is at 4.2V. This procedure

should take one davnd will be completed the week of Oct 24 by Zach Wasson.

5.2 Subsystem Testing

After testinu each component. we built up larger subsystems including user 10. Communication.

Core Hardware, and Software Development subsystems. Further testing was performed by

integrating the previously tested components into the subsystem level.

5.2.1 User I/O Subsysteni

The User In) Subsystem is comprised of the hardware and software components that allow auser to interface with a Blox. The user I/O hardware includes the OLED display, accelerometer.speaker. and touch panels. The softare of this subsystem consists of the drivers for thesevarious components. \Ve expanded upon the simple drivers used to test the user I/O hardware inorder to develop libraries of functions that are easier for developers to implement at a high levelof abstraction. The testing of these drivers using our demo applications will be completed ineight days on November 9 by Zach Wasson with assistance from Ankita Kaul and Dan Cleary.Our two demo applications were meant to test our libraries’ extensiveness and ease ofimplementation. We decided to only classify our libraries complete if we are able to create theseapplications easily with only the functions we created in these libraries. Each component of theI/O subsystem was thoroughly tested by integrating the components together and runningapplications. The touchpanels and OLED were tested by ensuring the user could scroll throughthe base program and select an application to run. The accelerometer and speaker were testedthrough the testing of the Memory Maze application. This secondary testing was a continualprocess through November 9.

5.2.2 Communication Subsystem

The Communication Subsystem is comprised of the components that a Biox uses tocommunicate with each other and includes the infrared receivers and the wireless Xbee. Like theUser I/O Subsystem, we created drivers with the appropriate level of fimctionality andabstraction required, adding more functions or more abstraction as needed. The testing of thesedevice drivers were completed alongside the User I/O subsystem by Zach Wasson, Ankita Kaul.and Dan Cleary.

[sine the JR sensors. Blox needs to be able to recognize’ each other when their faces are

aligned. The Neiehhor Detection feature module is a major software component that abstractsthis behavior and presents developers with an array of neighbor identitIers. A simple programthat uses \ciehhor Detection will be written. The subsystem should be able to populate the array

neighbor hiemi icrs \vhhin a second of Blox hein placed face-to-face. if we pull the Bloxapart thL ai ol id..q1fj should reilLct this changc in adjacenc\ topolog 1 he integration

between Neighbor Detection and IR sensor testing was completed on October 24 by ZachWasson. The communication system as a whole was tested by running Memory Maze using theRole Management feature module. Using this feature module requires complicated interactionbetween the parent Blox (the one that the user ran MemoryMaze on to begin with) and thechildren Blox in the area over XBee. After starting the application. MemoryMaze requires theuse ot all four faces of infrared sensors. The successful completion and implementation ofMemorvMaze. thus. was a check for the communicaton subsystem functionality.

5.2.3 core Hardware SubsystemThe core hardware subsystem is comprised of the Printed Circuit Board (PCB) as well as theSTM32 microcontroller. In order to test the functionality of this hardware thoroughly. we firstverified that every component worked individually when connected to microcontroller onto themain PCB. Then we tested all of the components simultaneously as a stress test. We expectedthis subsystem to be quite challenging to test. because it involves making sure every hardwarecomponent works together once integrated. If there had been a significant problem in our design.we would have needed to reorder the PCB which would cost valuable time. Since none of theother subsystems could be tested without the completion of Core Hardware system, it wasimperative that we finish this testing quickly and thoroughly. We took the following steps toensure the PCB was designed and manufactured correctly, the supporting hardware wasconnected correctly, and the hardware could function together as a whole:

1. Check the resistance between the power and ground lines on the PCB to make sure theyare not connected. The resistance between power and ground when checked with amuhimeter should be infinite.

2. Solder the power supply circuitry. which include the voltage regulators, battery, andnecessary capacitors. Then using a multimeter we will check the 5V regulator and the—-3.3V regulator for their respective voltages. The power LED should also light up at thispoint.

3. Incrementally solder the USB chip. test the LED, and microcontroller along with allnecessary components (resistors. capacitors, crystal oscillator. boot jumpers. etc.).

4. Nolder the battery charging circuit and check if the battery will charge via USB.

5. Incrementally solder the hardware components to the PCB. Then test each component’sconnection by loading and running the appropriate test program based on the specific

peripheral’s driver on the microcontroller. We should see the same results and

functionality that we saw in the component tests.

6. Load and run a test program that tests all of the components simultaneously. This will

ensure that the microcontroller can handle the maximum amount of multitasking possible,

as yell as confirm the battery’s ability to power all of the components.

The core hardware subsvsten. was tested by connecting the components in the user I/O and

comnunication subsystems and peribrming wholistic tests to make sure each interface worked as

expected. With the exception of the missing pull-up resistor on each touchpanel controller, no

mistakes in the main PCB were found.The issue of the missing pull-up resistor was quickly fixed

by soldering a replacement directly onto the main PCB touchpanel PENIRQ pins.

5.2.4 Software Development Subsystem

The Software Subsystem consists of the feature modules required to facilitate the running ofapplications on the Biox system. These feature modules provide the backbone necessary to createa stable environment for applications to run on. Role Management and Program Loading are

feature modules that play a vital role to having applications run correctly, while power

management is an extra enhancement that will improve the overall user experience. We would

consider the final demonstration a success if only the vital feature modules were implemented

correctly.The drivers for each peripheral were tested by creating an example application that

illustrated the way to use that peripheraPs driver and outputs meaningful data for that interface.

For example. the touchpanei example code outputted a value over USB when a user touched

each touchpanei.

5.2.4. 1 Role Management

At the beginning of any run of an application or base program, roles are assigned to each Bloxbased on application-specific parameters. For example. a Blox will be assigned the “leader” roleit it is picked up first while the main program is runnii’ . We created other similar scenarios thatiii k’St inciiviouai roies. and then test scenarios that required interaction between multiple roles.

it’ dil anplieation reouires more Blox than arc present in the system, the feature module should

kill the distributed application. Our software needed to be capable of handling these role

management scenarios on a case-by-case basis b addressing the specific issues logically or by

displaying an error notification. Role management was the most challenging feature module to

test because of its complexity and lack otdebugging options. Two Blox needed to communicate

over XBee, which is an unreliable interface. After modifying the number of re-tries and random

hackoff configuration options in the XBee. the Blox were able to perform the role management

hand-shaking protocol properly and remotely start an application on another Blox. When we

executed role management on a system of five Blox it worked most of the time, but there appears

to be some instability due to the unreliability of the XBee interface and collisions of the children

Blox during broadcast. The testing of role management capabilities were completed on October

1 9 by Jesse TannahiH,

5. 2. 4. 2 Program Loading

A transfer program vill operate from a host PC to transmit a program across USB to a base

program waiting for an input program on a Blox. The base program should be able to store a

program into flash memory and have it still exist after power cycling a Blox. The base program

will update its list of loaded programs, display program names on the OLED display, and allow a

user to execute any of them by tapping touchpanels. In order to test our transfer and base

programs, we will attempt to load a simple program like the test program for the Neighbor

Detection feature module onto the Blox. For each of the supported platforms (PC. Mac. Linux).

the application wilt be compiled. compared against binaries from the other platforms. and loaded

onto each Blox using the transfer-to-base-to-flash pathway. We will verify the correctness of the

transfer and base programs by confirming the correct list of programs loaded onto a Blox, the

ability to delete a program off a Blox, and the ability to load the simple application onto a Blox.

If xve are able to complete these tasks and verify the functionality of the test program by visually’

ohscrvnc the output on each OLED display in ten independent tests. we will consider the

transfer and base programs successful. Testing of the transfer and base programs will be

completed on ()ctobcr 26 b Jesse Tannahill.The transfer program and base program worked

ver well. After xve completed them, they’ were used to load and run every application we

created, After around 100 application loads and runs, we observed no issues with this interface.

26

5.2.4.3 Power MunuemeniWe created a feature library that the Blox can utilize in order to be as power efficient as possibleand initially planned to allow developers to put a Blox to sleep when peripherals are not beingused, After 5 minutes. an idle Blox should have turned off its display and should only wake upfrom sleep mode when the power button is pressed. The power managment feature module wascreated but is not as functional as originally intended. Currently, you can register functions withthe power management module that will be called whenever a user calls the sleep0 function. hutthe microcontroller itself does not go to sleep. Due to time constraints, we decided to have amore simple power management module and focus more on developing polished applications fordemonstration purposes.

5.3 System Testing

Finally, the complete system was tested to make sure it met our intial requirements andspecifications. Three holistic tests were performed that will allow us to demonstrate the platformcapable of running distributed applications using all system parts.

5.3.1 Physical Properties

The J3iox design was tested for two key physical properties to ensure its ability to withstandenvironmental stresses of durability and temperature. though they were not critical to our finaldemonstration. A Blox was intentionally dropped to test its ability to withstand a four-foot failonto carpet. We verified that it remained fully operational with minimal aesthetic damageafterward. A Blox also needed to he able to operate in an temperature of 0-100°F. We initiallyplanned to place a Blox in a freezer for a three-hour duration and another Blox in an oven for thesame duration; however, due to time restraints and need to utilize all Blox for coding anddebugging, we were not able to test this property prior to Open House.

5.3.2 Operational Properties

We decided to test our entire system by running both of our demo applications on a set of fullyconsiructed Blox. this holistic approach was expected to show that Project Blox couldsuccessfully execute distributed applications. We went through the process of loading a newapplication onto a l3lox. selectinu it out of the program list using the Blox base prouram. and

running the application to test for interaction and logical bugs. As previously mentioned, the

demos vvere also intended to test our driver libraries’ extensiveness and ease of implementation.

Appendices A and B show the operational steps of each demo application. This holistic test of

our the Blox using our demo applications was intended to be completed in eight days on

No ember 9 by Zach Wasson with assistance from Ankita Kaul and Dan Cleary. Due to delays

in creating the feature modules and subsequently the delays in creating the applications, system

le ci operational testing was conducted continuously and full testing completion pushed back

until the point of Open House.

5.3.3 Ucer Experience

Once v. e had the basic platldrm created, we asked a peer ECE student to try developing a

distributed computing aoplication to run on multiple Blox. Unfortunately, he was unable to finish

n time for the open house. though there was a preliminary demo on one of the Biox, While he

as working on the application, we were available to him to help him with any issues and

comprehend the needs of the developer more. Aside from some issues with animation due to the

inflexibility of the 01 EDs serial interface, he had no major problems. The demo shown at open

house only required a single Blox, but it had a fully animated pacman chomping across the

screen. In addition, a user could modify his direction by tapping on any of the four touchpanels.

6.0 TIME AND COST CONSIDERATIONS

Project Blox could not have succeeded without effective project management. Our design team

as selfmanaged and xork as divided approximately equally among the design team

members. Design team member Jesse Tannahill was the lead in assembling the Blox and the

Soft are I)evelopment Environment Subsystem: Zach Wasson led the Core Subsystem and

Communicaton Subsystem efforts: Dan Cleary led the User I’O Subs stern efforts with Ankita

kaul, \nkita was also responsible lbr procuring all materials from venders, interfacing between

thc team and the sponsor. and led the paper and presentation efforts. We scheduled our project

tasks oer the 15 weeks in the semester. and updated our Gantt chart regularly to indicate the

current status quo of the project implementation. \\ hue time and sheer project complexity were

the n alfl liniitn Uctors we all haa to deal with, we were still consciencous of staving under our

sponsors pledged budget. In the following two sections. we further elaborate on the schedulingand fiscal considerations of our project.

6.1 Schedule Review

The Project l3lox implementation plan had been carefully designed with both time and humanlimitations in mind. As seen in the Gantt chart in Appendix A. we had originally divided ourtasks into seven key steps to project completion in our Design and Implementation Plan.Important milestones had included testing all peripherals by 9/25, completing the model designby 9’19. designing the main PCB by 10/10, and assembling and testing Blox hardware andsoftware by 11/9. Our original schedule plan was overly optimistic as we did not factor in thesheer complexity and plethora of faults possible at each step of the design process. We ran intoissues keeping with our originally proposed schedule due to misfactored complexity in designingthe main PCB within our 2” x 2” size constraint. Our original scheduling plan had included twoiterations of main PCB manufacturing to give us a buffer for factors we had missed in the firstdesign. However, when our first PCB design iteration was already two weeks late, we decided toreduce our plan to a single iteration and spend more time carefully ensuring the accuracy of thedesign. To compensate for this delay, we were able to find a manufacturer in China that had athree-day manufacturing turn-around and still met our fiscal restraints. While we recievd thePCB faster than we would have with any other manufacturer, this delay also led to delays indriver de’velopment as debugging without the PCB was not possible. We re-evaluated our Ganttchart to reflect these changes and increased the aggregate amount of weekly time spent on designimplementation. With the extra effort. we were able to successfully complete the corefunctionality of the project by early November. However, the delay in getting the FeatureModules written and tested, we were not able to develop our demonstration applications to thefullest extent and as polished as we would have liked. Overall however, by Open House we hadsucceeded in building all five prototype Blox, a 371 page Blox Software Documentation manualand two working applications, albeit slightly altered from our original application idea [1].

6.2 Budgetary ConcernsWe \\ere fortunate to ha e a sponsor. Dr. Christine Julien, who was willing to fund the project upto $5.000 which was more than double our originally anticipated costs. The total cost for ProjectBlox came out to be $2070 which is much less than the amount pledged. We ordered extras ofmany parts as backups since shipping replacement parts could potentially cause us to fall behindschedule. For the PCB, we used GoldPhoeaix because of their special price on bulk orders: thiswas especially useful for the IR breakout board since we needed 80 boards. GoldPhoenix wasalso the cheapest option for the main and the speaker amplifier PCB. Using the special price, weended up with 12 extra main PCBs and 93 extra speaker amplifier PCBs, yet we paidsignificantly less than other PCB manufacturers ($200 vs $500).

If Project Blox were mass produced, the total cost would be reduced significantly. A largeportion of our funds went into faster shipping times, which would be unnecessary for a massproduced design. We would most likely use an LCD in the future as opposed to an OLED, whichwould also save significant costs since the OLED cost $65 each. Additionally. the accelerometercould be soldered directly to the PCB instead of purchasing it from Sparkfun. Table 1 belowshows an estimated cost for mass production.

Table I - Mass Production EstimateComponent Number/Blox CostlUnit lCost/BloxEnclosure t I $5.00 $5.00Core PCB I $5.00 $5.001R Assembk 16 $1.00 $16.00:PYi_

Touchpanels 4 $1.00 $4.00Speaker I $2.00 $200XI3ee 1 $14.00 $14.00

fouchpanel Controllers 4 $2.50 $10.00FTDiChip1 I $3.00 $100

Poer Regulators $4.00 $4.00ndigIc1C ‘2)0 S20fl

J- —-——

Total Cost: $5.00

7.0 SAFETY AND ETHICAL ASPECTS OF DESIGN

To fully meet the customer needs in Section 2.0, the Project Blox design team will state key

safety requirements for our system. While each Blox itself will be made of durable materials, it is

designed to operate in the conditions available inside a typical home. The temperature range of

the environment where a Blox is kept and used should remain in the range 0-100 °F so that the

I/O interfaces and internal electronics are not damaged. Blox are not designed to be tireproof or

waterproof since the case is water-permeable and will short the electronics inside. As far as user

safety is concerned, the Blox do not have enough electricity or heat to cause any harm from

proper use. There were no major ethical aspects to consider with the creation of our project.

8.0 RECOMMENDATIONS

The Project Blox design team has collected recommendations for future replications of our

project based on our design and implementation experience through EE 464. Our

recommendations primarily discuss the hardware design alternatives we would recommend to

better the replication of our project in the future.

8.1 Blox Peripherals

All of our peripherals performed satisfactorily during our demonstration and were necessary for

our final system. However the display and JR transceivers both could have been improved to

create a better experience for the Blox user.

S. I. I ()LEL) Disp/ai

While the OLED display we chose worked, the issues encountered during the project lead us to

recommend using a color LCD instead. From a hardware perspective, the OLED display was not

ideal because it took a noticeable amount of time to refresh and draw to the screen. The slow

refresh did not allow for smooth animations and caused screen flickering. Also, the manufacturer

i’ecuired serial command interface API was inflexible and problematic. Ideally. the developer

would have complete control of what is being drawn in each pixel by ‘a citing to a matrix which

contains each pixeis color inlbrmation. They should also be able to make quick changes to what

31

is displayed on the screen. However, this is not possible with the OLED display we chosebecause any change to the screen requires sending a serial command, which takes a significantamount of time to he processed and executed by the OLED display.

When making several changes to the screen at once, it is visibly noticable that each change isbeing drawn in succession as opposed to simultaneously. Another major issue with the serialinterface was the manufacturer’s inextensible command library. Commands that dealt withchanging the orientation of the screen, sending a matrix of color information, or aiding withcharacter animation would all have been immensely useful for Blox applications but wereunfortunately missing.

Finally, the OLED display was not acceptable from a fiscal standpoint. The OLED display wasthe most expensive component in a Blox. Also, we would have liked for the screen to take upmost of the top face of the Blox. but could not find a larger option. The large space between twoBlox OLED displays negatively impacted our Memory Maze application by diminishing theillusion of the ball moving directly from one screen to another.

Choosing an LCD would have alleviated the majority of the issues we experienced with theOLED display. Typical LCDs not only allow for increased speed and simultaneous drawing ofmultiple changes. but would also allow us to create our own driver library that could beexpanded to fit the common needs of Blox developers. Since LCDs are more available thanOLED displays, we would have had a greater range of dimensions and prices to choose from aswell.

8.1.2 JR Transceivers

The other peripherals that could have had improved performance were the IR transceivers. Forour Blox design. we would have liked the signal cone to be ver narrow (30 degrees) and therange to be very short (6 inches). This ensures the iRs on one face of a Blox are only able to sendsignals to the Blox directly adjacent to it within a short range. By insetting the IRs into their slotson the 13 lox we were able to narrow the signal cone of the transceivers. We believe we could

further improve their performance by creating windows around the transceivers and coveringthem with polarizing material to help direct and limit the power of the signals.

8.2 BIox Core Hardware

There arc a number of modifications to the Blox hardware that would make the manufacturingand development streamlined and more elegant.

8.2.1 PCB Design

Due to timing constraints on our project. we only had time to design and ship one iteration of themain PCB. This PCB design had no major flaws, but we believe that an optimized redesign usingmore layers would be beneficial in fixing small mistakes and improving the layout of theperipheral headers. For example. we should place the batterys header on top of the PCB sincethe battery is mounted above the PCB. Additionally, we should incorporate the speaker amplifiercircuit into the main PCB design.

8.2.2 1i/Jjcrocontroller

Our selected microcontroller, the STM32F I O3VE, lacked enough USART ports for all of ourserial communication needs. Therefore we were forced to create a Virtual USART (or VUSART)drix er that could handle incoming serial signals from the OLED display and XBee. TheVUSART driver functioned properly, but we suspect that it caused timing issues and slowersystem speeds. In future iterations of the Blox architecture, we would prefer to use amicrocontroller that included seven USART ports, removing the need for a VUSART driver.

N. 2.3 Qahies

As well as placing headers in more appropriate areas on the PCB as previously mentioned, thecables e created to connect the components could be improved to provide a more solidconnection from the PCB to the Blox components. We suggest using cables that incorporate aconnector locking sYstem to ensure the cable does not slip off of the header. At the very leastthere siould he enough friction to hold to cables in place. We recommend these improvements toprever t accidental disconnects ibm causing an application to malfunction or from damagingadjacent Blox components.

1

2.4 Casiiig

The unique method of creating the casing of the Blox using SLS provided a stable, exact, andunintimidating way of protecting and holding the components within the Blox. We ou1d usethis method again in future Blox designs. However some slight modifications are necessary toimprove the functionality and aesthetic appeal of the Blox design. We did not label anycomponents that crc not located on the PCBs, such as face numbers or functions of theswitches on the bottom face of the Blox. This led to confusion during the applicationdevelopment process. so it would be logical to label these parts in a professional manner in thefuture. Also. with the addition of an LCD taking place of the OLED display. an adjustmentwould need to be made in the case model to accommodate the larger size of the screen. Finally.hiding the metal screws, painting the Blox. and minor aesthetic improvements would contributeto a sleeker user experience.

8.3 Blox SoftwareThere are a variety of software additions and enhancements that we would suggest. First the RoleManagement Feature Module should be more robust so it always starts the correct number ofBlox for an application. Sometimes when trying to start an application with more than threeBlox, only a few would get the request to start. The cause of this bug should he investigated andfixed so a large quantity of Blox can start without any errors. Another feature that we would liketo see implemented is the ability to wirelessly transfer applications between Blox over XBee.This expansion would greatly simplify loading programs onto each Blox since one Blox wouldbe able to program all other Blox within the XBee’s range simultaneously. Also, as previouslymentioned we would recommend creating a driver for an LCD that uses a matrix system asopposed to using serial communication. The matrix system would allow developers direct accessand total conirol over what is displayed on the screen. as well as provide a signficant speedboost O cmli the coftware aspect of Project Blox would be improved by adding these extra!batures

9.0 CONCLUSIONS

Ibis report discussed the complete project development and implementation of Project Blox, adistributed computing platform intended for entertainment and education purposes, We started

with our problem analysis. considered and selected possible solutions, described our selectedsolution. reviewed our implementation process. explained our testing and evaluation process andfinal1 evaluated the project as a whole.

Our design problem challenged us to create a computing platform and SDK that would allowdevelopers to easily create distributed applications that would run on cube-shaped embedded

s stems. We started our analysis by listing the key needs of our customers, the most important ofwhich included a variety of peripherals and intuitive software and hardware design. Next. wederived ke requirements and specifications for Blox that would solve these needs. Afterdeveloping the specifications for our designs, we explained our component choices by analyzing

design alternatives. Finally, to conclude our problem analysis we described our design solution

by dividing our intended efforts into four subsystems: (‘ore, User I/O, Communication and

Software Development Environment.

In the next sections, we detailed the design implementation of each of these subsystems. We

noted the design changes that needed to be made to add functionality or correct initial design

errors, mainly break-out boards for the IR sensors and speaker. Next, we discussed our testing

and evaluation process which occurred concurrently to our subsystem development. Testing was

done from the ground up: each component was tested individually, then integrated into

subsystems for subsystem-level testing, and finally tested at the system level through our demo

applications. Finally, we looked back at the project from several perspectives. We first revieed

the fiscal and scheduling management of the project. With an overall cost of $2207 of our

allocated $5000 funded From D:. Christine Julien. managed to stay well under budget. With

the PQB design dela\ed two \\eeks and softxare taking significantly longer than originally

ch.i’1d, the eroup put in extra effort to make up for lost time. Lastly, we providedrornri;idations for future prolect expansion or replication. Our recommendations outlined

ComPonent alternatives that ould he aiioed tor better project functionalit such as replacing

the OLED displa3 with an LCD. We also explained future software improvements in some of the

feature modules such as bettering Role Management to allow for perfect pre-application start-up,

In the end, Project Blox met the requirements and expectations we had layed out in our design

and in EE 364. We finished our project with five fully built Blox, more than 10 thousand lines

of source code, two functioning demonstration applications, and an overall first place win at the

E( E Senior Design Open House. We plan on further expanding on our product even after the

end of EE 464, potentially filing a patent and with hopes of future product commercialization.

36

REFERENCES

[1] Dan Cleary. Ankita Kaul. Jesse Tannahill, Zach Wasson. B/ox Software Documentation.Austin. TX: Project Blox. 2010. pp. 1-371.

[2] MerriL D,. Kalanithi. K.. Maes. P.: “Sifatbles: Towards Sensor Networks User interfaces”,MIT Media Labs. February 2009. [Accessed February 12. 2010]. Available:http://web.media.rnit.eduIdrneITi1l/pubIications/dmerril1siftab1es.pdf.

[3] XBEE Pro Datasheet, Digi International 90000982_B, Rev 09/2003http://www.sparkfun.com/datasheets/Wi reless/Zigbee!XBee-900-Datasheet.pdf

[4] IrDA Data 1.2 Low Power Infrared Transceiver Datasheet, Hewlett Packard HSDL32O1http://www.digehip.com/datasheet/parts/datasheet/02I /HSDL-3201 .php

L

APPENDIX A GANTT CHART

Ai

1UUUUUUUU

D-

—U

EE

c.o

b.

9-

Q<

cna

o0000

zzzzz

EC

(3C

0‘1

—C

—C-

c0-

n—

—r

C’4C

00

—(;

CU

UW8S

Tasks

TaskLead

fl

CoreSubsystem

9:04

101027:10

53100%

3853

01

10ncserenannD

carts

esse

904.10

90610

2100%

12

012

UdateedeI

9:05.10

90910

4100%

44

013

ManufactureMcde

nita

91010

9-1710

7100%

67

014EesrP08

Zachesse

911610

10:0510

19100%

1419

05

MapjfacturePC2

Zach

1005

101012

107

100%

67

016

AssemblePOE

Zach

1011210

10:1410

2100%

32

017

TesIPCB

Zach

10112i10

102710

15100%

1215

02

UsertICSubsystem

80210

110111080

100%

4380

021

TestOLED

Dan

9102110

90510

3100%

23

022

TestAccelerometer

Dan

9408110

9:1110

3100%

33

023

TestSpeaker

Ankst

912210

92510

3100%

33

024

TestTouthpane:

Anleta

912710

1002

105

100%

55

025

nteOLEDdr’er

Dan

9403110110110

59100%

4259

02

ArtsAcceercmeterdr.er

Oar

921.10

102910

38100%

2938

027

AnteSpeakerdr:.er4nKa

1012-10

1026:10

14100%

1114

028

ArchTcuchpareJrr

raota

101210

1101

1020

100%

1520

03

CommunicstonSubsystem

8131,10

11.01:10

62100%

4562

031

Deagn

IRPOE

Zacti

831110

91110

11100%

911

032

Orderardassen’b:e

RCB

Zach

91110

91910

8100%

58

033

TestRsenscs

Oar Jesse

9:24.10

928-10

4100%

34

034TeX

Dan

100810

101210

4100%

34

035

r1eRdner

Jesse

1011710102210

5100%

55

036

VnteXBeedr

erDan

102010

110110

12100%

912

037

Testdrvers

DanJesse

1110110

1109

108

100%

78

0

111I...

rL

7I1

wC

w >—

>rn

coro

0E

Eco

0)

9E

cC)

‘,Oj)

J.0

C0

4Development Subsystem

41\rtemerdrer

42

Wnte

USARTdnoer

43

WrrteV

irtualUSARTdrrve

44

Wote

RoleManagement

45

Wnte

Neighbor Deteobon

46

WotePoefManagement

47

Wrie

DrLerTestApp

48\teEasePrearam

494teEasenroaram7

410JrteranserProgran

411Stressestbose1rarerogarn

SSubsystemIntegration

51

CreatecaCing

52AssernleBlox

53

TestBlox

54

Write

LemoAppA

55

Wnte

LemoAppB

56

Test.ontcations

6Writing

62

Testno

&E’auaton

Dan

63

OraiPrc’ressReport

64Jflrogres.seport

6...5

FinalOralReport

6,6

Fi:.nalWrittenReport

101610

110910

24102210

102510

310118110

102110

310119/10

1027110

810/21110

10126,10

510/21110

1026110

510/28110

1101

104

1016110

110410

19102510

103010

5102810

110910

12103010

110210

3110110

110910

892110

1109;10

4910,15110

110910

259121110

110910

4910115110

11104110

2011101110

1109/10

811101110

110910

811105/10

110910

490710

120210

8690710

91410

7Arkta2ar

91510

92510

1093010

100710

7Zaoresse102110

102810

7All

11/23110

113010

7All

11125110

120210

7

100%

1724

0100%

23

0100%

43

0100%

78

0100%

45

0100%

45

0100%

34

0100%

1419

0100%

55

0100%

912

0100%

23

0100%

78

0100%

3649

0100%

1825

0100%

3649

0100%

1520

0100%

78

0100%

78

0100%

34

0100%

6386

0100%

67

0100%

810

0100%

67

0100%

67

0100%

67

0100%

67

0

WBS

Tasks

TaskLead

Start

End

CC

CC

CC

CC

CC

CC

CC

ZU

00

0’c

ao

0a

<CO

Cl)

COCO0

000z

zzzz

CC

COC

NCO

IX)

—C

lfln

CII

COC

—C’

—.

CC

C—

CC‘IN

Zach

Jesse

Zxch

Jesse

Zach

Zach

Da.n

Jesse

Jesse

Zac

Jesse

Zach

Ankita

Dan

Zach

61Desor

&‘nementationPar

Anta

APPENDIX B -BILL OF MATERIALS

I

Sn

APPENDIX B - BILL OF MATERIALS

Quanttv nit si Supp1ic

IR Breakout PCB 80 $1.50 GoldPheonixPCB

IR Sensor 80 $3.40 DigikcvCase 5 $120 ME DepartmentCase Screws 40 $0.04 McMaster

Case Standoffs 40 $0.51 McMaster

Case Bolts 16 $0.01 McMaster

Touchpanel Sensor 20 $4.53 Global Direct Parts

Touchpanel Connector 20 $0.95 SparkfunUSB Connector 5 $11.22 Digikey

USB Bolts 10 $0.05 McMaster

Power Switch 5 $0.99 Digikey

Power Switch Bolts 10 $0.16 McMaster

Power Switch Nuts 10 $0.03 McMasterProg. Switch 5 S0.99 DigikevProg. Switch Bolts 10 $0.16 McMaster

Prog. Switch Nuts 10 $0.03 McMaster

Speaker 5 $3.80 Digikey

Main PCB 5 S40 GoldPheonixPCB

ARM Processor 5 $13.70 Digikey

Xbee 5 $19 Sparkfun

Accelerometer 5 $19.95 Sparkfun

2000rnAh Battery 5 $16.95 Sparkfun

Battery Velcro 5 $0.47 McMaster

Battery Plate 5 SO Team Made

OLED Display 5 $64.95 Sparkfun

OLED Display Bolts 20 $0.01 McMaster

OLED Display Nuts 20 $0.01 McMaster

LED 20 S0.52 MouserTotal S2,09&96

Documents

Project Blox Final Report Submitted To: Prepared By · PDF file · 2015-10-27Project Blox Final Report Submitted To: Dr. Christine Julien Sponsoring Facufty Member Dr. Michael Becker