Raytheon Senior Project Critical Design Review

1. Raytheon Senior Project Critical Design Review Jarret Allen Luis Cintron Michael Kubacki Robert Skinner 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

2. Agenda • Final System Design Overview • Detailed Design of System Components • Risks Associated with System Components • Brief Outline of Test Plan • Development Information • Project Schedule

3. Final System Overview System Components Power 2-Port USB Module Adafruit’sComponents FTDI V2DIP2-48 Case Android 2.3.4+ Phone USB Mass Storage Device

4. Final System Overview Physical Interfaces Compatibility Power 5v vdd input x gnd

5. Final System Overview Physical Interfaces Compatibility USB Type-A Inputs V2DIP2-48 (USB Host Module) 5v 5v 500ma 5v gnd Android 2.3.4+ Phone Adafruit's Minty Boost ( + & - terminals connected to vdd & gnd inputs on V2DIP2-48 ) USB Mass Storage Device

6. Final System Overview Software Libraries/Interfaces Overview Android Open Accessory Protocol FTDI LFAT Driver

7. Final System Overview Android Application Flowchart

8. Final System Overview Android Application Structure

9. Final System Overview Android Application Screenshots

10. Final System Overview Android Application Screenshots

11. Final System Overview Android Application Screenshots

12. Final System Overview System Communication Hardware Android Device User Product Application Mass Storage Device V2DIP2-48 (USB Host Controller) Memory Memory USB Port 1 USB Port 0

13. Final System Overview Very Brief System Communication Overview 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 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 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

14. Detailed Design of System Components

15. Detailed System Component Design V2DIP2-48 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)

16. Detailed System Component Design V2DIP2-48 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

17. Detailed System Component Design V2DIP2-48 USB Host Controller Vinculum-II Driver Model Provides an interface between a file system (FAT) and a USB disk (flash drive or hard drive). 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.

18. Detailed System Component Design V2DIP2-48 • VOS Kernel • Device Manager USB Host Controller Vinculum-II Firmware Model • Raytheon Firmware Code • Device Drivers • USB Host Hardware LFAT API Android Open Accessory Protocol

19. Detailed System Component Design V2DIP2-48 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

20. Detailed System Component Design Power (Adafruit’sMintyboost based) • MintyBoostschematic 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.

21. Detailed System Component Design Power Module Schematic

22. Detailed System Component Design Case • Manufactured with 3d printing technology • ON/OFF rocker switch and LED power indicator • LEDs to indicate File Copy Activity and Power

23. Detailed System Component Design Android Phone • 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 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

24. Risks Associated with System Components

25. System Component Risks Risk V2DIP2-48 • 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 Minty Boost • 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

26. System Component Risks Risk Android Device • 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. USB BOMS Device • 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

27. System Component Risks Risk Case • 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

28. Brief Outline of Test Plan 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.

29. Brief Outline of Test Plan General Best Case • 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.

30. Brief Outline of Test Plan General Worst Case • 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.

31. Brief Outline of Test Plan General Corner Cases • 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.

32. Brief Outline of Test Plan Traceability to Requirements Unit Testing 1. Volume requirement of at least 621cm3 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.

33. Brief Outline of Test Plan Traceability to Requirements 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.

34. Brief Outline of Test Plan Traceability to Requirements 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.

35. Brief Outline of Test Plan Requirements Summarized • 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 The requirements presented by Raytheon in Raytheon Project Specification REV20111231 have been organized as follows for simplicity:

36. Brief Outline of Test Plan Requirements Summarized • 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

37. Brief Outline of Test Plan Traceability to Requirements 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. Brief Outline of Test Plan Traceability to Requirements 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

39. Development Information

40. Development Information How to Find Development Progress 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.

41. Project Plan Project plan