Critical Design Review
Jarret Allen Luis Cintron Michael Kubacki Robert Skinner
1 of 41
Department of Computer Science and Engineering
University of South Florida
Tampa, FL 33620 jjallen3@cse.usf.edu
lcintron@mail.usf.edu
mkubacki@mail.usf.edu
ras1@mail.usf.edu
Critical Design Review for Senior Project
March 23, 2012

• Final System Design Overview
• Detailed Design of System Components
• Risks Associated with System Components
• Brief Outline of Test Plan
• Development Information
• Project Schedule
2 of 41
Critical Design Review for Senior Project
March 23, 2012

Final System Overview
Adafruit’s Components
FTDI V2DIP2-48
Android 2.3.4+ Phone USB Mass Storage Device
3 of 41
Critical Design Review for Senior Project
March 23, 2012

Final System Overview
5v vdd input gnd
4 of 41
Critical Design Review for Senior Project
March 23, 2012

Final System Overview
USB Type-A Inputs
V2DIP2-48
(USB Host Module)
5v
5 of 41
5v
500ma gnd
Adafruit's
Minty Boost
( + & - terminals connected to vdd & gnd inputs on V2DIP2-48 )
5v
Android 2.3.4+ Phone
USB Mass Storage Device
Critical Design Review for Senior Project
March 23, 2012

Overview
Final System Overview
Android
Open Accessory
Protocol
FTDI
LFAT Driver
6 of 41
Critical Design Review for Senior Project
March 23, 2012

Final System Overview
7 of 41
Critical Design Review for Senior Project
March 23, 2012

Final System Overview
8 of 41
Critical Design Review for Senior Project
March 23, 2012

Final System Overview
9 of 41
Critical Design Review for Senior Project
March 23, 2012

Final System Overview
10 of 41
Critical Design Review for Senior Project
March 23, 2012

Final System Overview
11 of 41
Critical Design Review for Senior Project
March 23, 2012

Android
Device
Product
Application
Mass
Storage
Device
Memory
V2DIP2-48
(USB Host Controller)
USB
Port 0
USB
Port 1
Memory
Final System Overview
User
12 of 41
Critical Design Review for Senior Project
March 23, 2012

Final System Overview
1. The FAT API on the Vinculum-II device performs a linear scan of the file system and transfers this data (strings of filenames) to the Raytheon Senior
Project Application (RSPA) on an Android 2.3.4+ phone
2. Navigating to a new directory in the RSPA requires the file data for the new directory to be streamed from the Vinculum-II device to the RSPA
3. Once a file is selected, it must be transferred from the USB mass storage device through the Vinculum-II device to the RSPA to be emailed
13 of 41
Critical Design Review for Senior Project
March 23, 2012

14 of 41
Critical Design Review for Senior Project
March 23, 2012

Detailed System Component Design
USB Host Controller
FTDI Vinculum-II Operating System
Overview
•
Link between Android and Bulk-Only Mass Storage (BOMS) devices.
•
Provides power to both USB connected devices.

It is powered with a 5v 500ma battery input from MintyBoost power device
•
Performs message passing between V2DIP2-48 firmware and the Android application via the Android Open Accessory Protocol to transfer data such as file/directory names and file data.
Capabilities
•
Built-in drivers to implement Android Open Accessory Protocol and support USB hosting.
•
Support for FAT16, FAT32, and long file names using the FTDI LFAT API.
•
Supports a low-power sleep mode to conserve energy.
•
Enables significant control over USB data transfer (low-level manipulation)
15 of 41
Critical Design Review for Senior Project
March 23, 2012

Detailed System Component Design
USB Host Controller
•
Dimensions (l x w x h)
•
18mm x 69mm x 26mm
•
The pins will be removed to reduce volume
•
Power
•
5v 500ma provided by Minty Boost
•
Minty Boost is supplied power from 2 AA batteries
• Unit Cost
• $28.76
•
Allows development of custom firmware
•
Provides 2 Type-A USB ports
•
Easily programmed using external USB programmer/debugger module
16 of 41
Critical Design Review for Senior Project
March 23, 2012

Detailed System Component Design
USB Host Controller
Vinculum-II Driver Model
BOMS Driver
Provides an interface between a file system (FAT) and a USB disk (flash drive or hard drive).
USB Host
Driver
VOS Kernel
USB Host
Hardware
The USB host driver can control both USB ports. When a device is connected it is automatically enumerated by the USB Host
Driver.
The Vinculum-II OS. A pre-emptive priority-based multi-tasking
OS. Supports priority-based tasks, tasks switching (round-robin), task synchronization, and a device manager.
The V2DIP2-48 module that contains two Type-A USB ports.
17 of 41
Critical Design Review for Senior Project
March 23, 2012

Detailed System Component Design
USB Host Controller
Vinculum-II Firmware Model
18 of 41
LFAT
API
Android Open
Accessory Protocol
Raytheon Firmware Code
Device Manager
Device Drivers
VOS Kernel
USB Host Hardware
Critical Design Review for Senior Project
March 23, 2012

Detailed System Component Design
USB Host Controller
Communication with Android Open Accessory Protocol
Data transfer in the firmware is fairly simple...
Data is matched between the firmware and Android application to ensure compatibility:
Strings match in the Android Java code
Data is written to the Android device using a write function with a handle to the device, a pointer to data to be written, and the number of bytes sent:
Only one line of code to send data
19 of 41
Critical Design Review for Senior Project
March 23, 2012

Detailed System Component Design
•
MintyBoost schematic and
Adafruit's PCB circuit
•
5V Output
•
500mA
•
2 x AA Batteries in series
•
Uses 5V DC converter
•
Originally a USB-based charger, repurposed to provide power to our device’s VDD and GND pins.
20 of 41
Critical Design Review for Senior Project
March 23, 2012

Detailed System Component Design
21 of 41
Critical Design Review for Senior Project
March 23, 2012

Detailed System Component Design
22 of 41
•
Manufactured with 3d printing technology
•
ON/OFF rocker switch and LED power indicator
•
LEDs to indicate File Copy Activity and Power
Critical Design Review for Senior Project
March 23, 2012

•
Android Open Accessory Protocol is backwards compatible to Android 2.3.4

Fully supported in Android 3.1+
•
The V2DIP2-48 is an "Android USB Accessory"
•
Powers the bus and enumerates devices
•
Android accessories must provide 500ma at 5v
•
Performed by MintyBoost power supply
Detailed System Component Design
Limitations:
•
Accessory mode support in Android 2.3.4 is ultimately dependent on the device's hardware
•
Although the majority of devices support Android Open Accessory Protocol
23 of 41
Critical Design Review for Senior Project
March 23, 2012

24 of 41
Critical Design Review for Senior Project
March 23, 2012

System Component Risks
• The chip may use too much power while looping continuously looking for connected devices
– This will be determined during testing and a larger power supply may be needed
• Even with code improvements, the device draws too much power to meet requirements
– MintyBoost can work with C and D batteries as well so moving to a larger battery would be our best option, including a case redesign
25 of 41
Critical Design Review for Senior Project
March 23, 2012

System Component Risks
• An Android 2.3.4 phone does not have the Open Accessory
Library installed
– Manufacturers can choose whether or not to include this library when the phone is manufactured and there is no method to install this library as a user.
• Device does not use FAT file format
– The V2DIP2-48 can only process FAT formatted BOMS devices. Most are
FAT16 or FAT32 devices.
– The LFAT library supports long filenames
26 of 41
Critical Design Review for Senior Project
March 23, 2012

System Component Risks
• 3D printing does not create a durable enough case to suit our needs
– Purchase a pre-made durable case and add holes for our input/output as necessary
• The case traps too much heat
– Redesign the case with better ventilation
27 of 41
Critical Design Review for Senior Project
March 23, 2012

28 of 41
More detailed testing procedures are located in Test Plan v1.01
www.cse.usf.edu/raysp
These section is designed to summarize the extensive testing procedures presented in the document.
Critical Design Review for Senior Project
March 23, 2012

Brief Outline of Test Plan
Analyzing an overview of system communication, the best case for various scenarios can easily be determined:
•
The best case for the USB mass storage device linear scan would be an empty mass storage device or, in the case of complete program operation, one file on the mass storage device.
•
The best case for data transfer both to the phone and across the network would be the minimum supported file size of the file system and the maximum speed data network connection supported by the Android 2.3.4+ device.
•
Directories with large list of files will take longer to navigate, as more data must be transferred to the user interface on the Android 2.3.4 device.
•
Thus, one root directory with no files would be the best case for overall system operation.
29 of 41
Critical Design Review for Senior Project
March 23, 2012

Brief Outline of Test Plan
Analyzing an overview of system communication, the worst case for various scenarios can easily be determined:
•
Because the FAT API performs a linear scan of the files in the current directory, the worst case would be the maximum number of files in a directory each of the minimum supported file size.
•
The worst case for file transfer to the phone and across the network would be a file of the maximum size supported by the file systems present (on the
Android device and the USB mass storage device).
•
The speed of the file emailed is dependent upon the data network speed.
30 of 41
Critical Design Review for Senior Project
March 23, 2012

Brief Outline of Test Plan
•
The Vinculum-II module should be tested to verify it is capable of operating in various conditions such as varying battery power levels, environment temperatures, durations of time, with various USB devices (not the expected Android phone or mass storage device), and combinations of these configurations.
•
The FAT API firmware should be tested with no files present, one file present, and many files present.
•
The RSPA should be run without the Vinculum-II module attached, with no data connection, and other limitations on successful program operation to ensure it gracefully exits and accurately reports the problem to the user.
31 of 41
Critical Design Review for Senior Project
March 23, 2012

Brief Outline of Test Plan
Unit Testing
1. Volume requirement of at least 621cm 3 will be tested by measuring the volume of the completed device.
2. Weight requirement of less than 300g will be done through testing by weighing the device. Requirement of the system being self-powered will be done by inspection by showing that the unit is on without any external wires.
3. The Android application’s ability to send emails can be demonstrated by emailing a file stored on the Android device.
4. The Android application’s ability to send MMS can be demonstrated by sending a file stored on the Android device.
5. The VF2F2’s ability to transfer files from the mass storage device to the
Android device can be demonstrated by successfully transferring a file.
32 of 41
Critical Design Review for Senior Project
March 23, 2012

Brief Outline of Test Plan
Integration Testing
6. Compatibility with Android 2.3.4+ will be demonstrated by showing that data transfer can be exchanged between the mass storage device and a version 2.3.4
Android phone.
System Testing
The system processing different media files of different types will be done through demonstration by transferring a diverse group of files.
7. The locating a file on the mass storage device in 5 seconds will be tested by timing of retrieval for several different files and recording elapsed time. Times will be averaged to determine average-case retrieval time.
8. The transfer of a 3Mb file from the mass storage device to the Android phone in 5 seconds will be tested by timing of retrieval for several different files and recording elapsed time. Times will be averaged to determine average-case retrieval time.
33 of 41
Critical Design Review for Senior Project
March 23, 2012

Brief Outline of Test Plan
9. The sending of a file on the Android phone in 5 seconds by email will be tested by timing of sending for several different files and recording elapsed time. Times will be averaged to determine the average-case retrieval time.
10. The sending of a file on the Android phone in 5 seconds by MMS will be tested by timing of sending for several different files and recording elapsed time.
Times will be averaged to determine average-case retrieval time.
11. The ability to transfer files at a distance greater than two meters can be demonstrated using a USB cable measured to greater than two meters to successfully transfer a file from the mass storage device to the Android phone.
System Integration Testing
12. System Integration with multiple mass-storage devices can be demonstrated by testing system functionality when any mass-storage device is being used.
13. System Integration with multiple Android phones can be demonstrated by testing system functionality with any 2.3.4+ Android phone.
34 of 41
Critical Design Review for Senior Project
March 23, 2012

Brief Outline of Test Plan
The requirements presented by Raytheon in Raytheon Project Specification REV20111231 have been organized as follows for simplicity:
1. Assumptions
GEN01 (GEN01a, GEN01b), GEN03, GEN05, SYS19
2. Requirements
The seven overall requirements for this project are (please note, a specific requirement may fall under two overall requirements):
Project Advancement Requirements
GEN02,GEN04 (GEN04a, GEN04b, GEN04c), TEST06
System Compatibility Requirements
SYS01, SYS02 (SYS02a, SYS02b, SYS02c, SYS02d), SYS03, SYS09 (SYS09a, SYS09b,
SYS09c), SYS11 (SYS11a, SYS11b, SYS11c, SYS11d)
System Performance Requirements
SYS04, SYS05, SYS06, SYS07, SYS08, SYS09 (SYS09a, SYS09b, SYS09c), SYS10,
SYS12, SYS13, SYS18
35 of 41
Critical Design Review for Senior Project
March 23, 2012

Brief Outline of Test Plan
System Physical Requirements
SYS13, SYS16, SYS17, SYS20
System User Interface Requirements
SYS14, SYS15
Testing Requirements
TEST01, TEST02, TEST03, TEST04, TEST05, TEST06, TEST07, TEST08, TEST10,
TEST11
Project Documentation Requirements
GEN06a (GEN06aa, GEN06ab, GEN06ac), GEN06b, TEST01, TEST07
36 of 41
Critical Design Review for Senior Project
March 23, 2012

Brief Outline of Test Plan
Simple Traceability Matrix
•
The traceability matrix has columns represented by the requirement numbering in the previous "umbrella" requirements
•
Some "umbrella" requirements have been removed that are not tested such as Project
Advancement Requirements
•
The rows specify the tests described previously
37 of 41
Critical Design Review for Senior Project
March 23, 2012

Brief Outline of Test Plan
Simple Traceability Matrix
•
The traceability matrix has columns represented by the requirement numbering in the previous "umbrella" requirements
•
Some "umbrella" requirements have been removed that are not tested such as Project
Advancement Requirements
•
The rows specify the tests described previously
38 of 41
Critical Design Review for Senior Project
March 23, 2012

39 of 41
Critical Design Review for Senior Project
March 23, 2012

Development Information
Progress is updated on our project Web site at www.cse.usf.edu/raysp
Bitbucket is used a Distributed Version
Control System as our code repository for
Android development

A feed from Bitbucket shows live updates to the Android code on the Web site.

A development log is updated on the Web site with firmware development updates.
 All documents are available on the project Web site.
40 of 41
Critical Design Review for Senior Project
March 23, 2012

Project Plan
41 of 41
Critical Design Review for Senior Project
March 23, 2012