Automated Bio-Medical Diagnostic Collection System

UCF Senior Design 2

28 April 2014

Group 12: Jesse Easterling

Jimmy Nguyen

Jonathan Adams

Zachary Levy

P a g e | i

Table of Contents Table of Contents .............................................................................................................................. i

1 Executive Summery ....................................................................................................................... 1

2 Project Description ........................................................................................................................ 2

2.1 Motivation .............................................................................................................................. 2

2.2 Objectives and Goals .............................................................................................................. 3

2.3 Project Requirements and Specifications .............................................................................. 5

2.3.1 System Enclosure ............................................................................................................ 5

2.3.1.1 Exterior ..................................................................................................................... 5

2.3.1.2 Interior ..................................................................................................................... 5

2.3.2 Test Tubes ....................................................................................................................... 5

2.3.3 Interactive Display .......................................................................................................... 5

2.3.4 Dispensing Unit ............................................................................................................... 7

2.3.4.1 Test Tube Dispenser “Boot” ..................................................................................... 7

2.3.4.2 Dispensing “Pacman” Roller .................................................................................... 7

2.3.4.3 Scanning Chute ........................................................................................................ 7

2.3.4.4 Dispensing Sensors .................................................................................................. 8

2.3.5 Dispensing Chute “Tongue” ............................................................................................ 8

2.3.6 Bag Dispenser .................................................................................................................. 8

2.3.6.1 Collection Chute “Collector” .................................................................................... 8

2.3.7 Sample Collection Unit “Holder” .................................................................................... 8

2.3.8 Environmental Control .................................................................................................... 9

2.3.9 CPU & Microcontroller .................................................................................................... 9

2.3.10 Power Supply ................................................................................................................ 9

3 Research Related to Project Definition ......................................................................................... 9

3.1 Existing Similar Projects and Products ................................................................................... 9

3.1.1 Medbox ........................................................................................................................... 9

3.1.2 Vending Machines ......................................................................................................... 10

P a g e | ii

3.1.3 ATM ............................................................................................................................... 10

3.2 Medical Standards and Requirements ................................................................................. 10

3.2.1 Test Tube Specifications ............................................................................................... 11

3.2.2 Specimen Collection Methods ...................................................................................... 11

3.2.3 Specimen Shipping Requirements ................................................................................ 11

3.3 Universal Labeling System ................................................................................................... 12

3.3.1 Code Format ................................................................................................................. 12

3.3.2 Numbering Scheme ....................................................................................................... 13

3.4 Relevant Hardware .............................................................................................................. 13

3.4.1 Barcode Scanner ........................................................................................................... 13

3.4.1 Touchscreen .................................................................................................................. 14

3.4.2 Motors Types and Control ............................................................................................ 14

3.4.2.1 Dispenser Wheel ................................................................................................... 15

3.4.2.2 Roller ..................................................................................................................... 16

3.4.3 Power Supply ................................................................................................................ 17

3.4.4 Microcontrollers ........................................................................................................... 18

3.4.5 CPU ................................................................................................................................ 19

3.5 Relevant Software ................................................................................................................ 19

3.5.1 Software Requirements ................................................................................................ 19

3.5.2 User Identification ........................................................................................................ 20

3.5.1 Database Information ................................................................................................... 22

3.5.2 Graphical User Interface Options ................................................................................. 22

3.5.3 Development Environment ........................................................................................... 23

3.5.4 Qt Creator ..................................................................................................................... 24

3.5.4.1 QGraphicsView ....................................................................................................... 25

3.5.5 Serial Communications ................................................................................................. 28

3.5.6 Licensing ........................................................................................................................ 29

3.5.7 Embedded Software ..................................................................................................... 30

3.6 Strategic Components .......................................................................................................... 30

3.6.1 System Enclosure .......................................................................................................... 30

3.6.2 Dispensing and Collecting ............................................................................................. 31

P a g e | iii

3.6.3 Bag Dispenser ................................................................................................................ 31

3.6.4 Environmental Control .................................................................................................. 33

3.6.4.1 Vapor Compression Refrigeration ......................................................................... 33

3.6.4.2 Thermoelectric ....................................................................................................... 35

3.6.4.3 Temperature Sensors ............................................................................................. 36

3.6.5 Dynamic Component Control ....................................................................................... 37

4 Project Hardware and Software Design Detail ........................................................................... 38

4.1 Hardware ............................................................................................................................. 38

4.1.1 System Enclosure .......................................................................................................... 38

4.1.2 Motor and Sensor Control ............................................................................................ 38

4.1.3 User Interface ............................................................................................................... 38

4.1.4 Dispenser ...................................................................................................................... 40

4.1.4.1 Order of Operations ............................................................................................... 40

4.1.4.2 Test Tube Dispenser “Boot” ................................................................................... 40

4.1.4.3 Dispensing Roller.................................................................................................... 42

4.1.4.4 Dispensing Chute ................................................................................................... 43

4.1.4.5 Dispenser Barcode Scanner ................................................................................... 43

4.1.4.6 Dispensing Motors ................................................................................................. 44

4.1.4.7 Dispenser Sensors .................................................................................................. 48

4.1.5 Bag Dispenser ................................................................................................................ 49

4.1.5.1 Lock ........................................................................................................................ 49

4.1.5.2 Bag Supply Sensor .................................................................................................. 51

4.1.6 Collector ........................................................................................................................ 51

4.1.6.1 Order of Operations ............................................................................................... 51

4.1.7 Holder ........................................................................................................................... 53

4.1.7.1 Temperature Control ............................................................................................. 53

4.1.7.2 Cooling Unit............................................................................................................ 55

4.1.8 Microcontroller ............................................................................................................. 56

P a g e | iv

4.1.8.1 Microcontroller and Circuit Board Design ............................................................. 56

4.1.8.2 Choosing a Microcontroller ................................................................................... 56

4.1.8.3 Microcontroller Circuit Design ............................................................................... 56

4.1.9 PCB Design .................................................................................................................... 61

4.1.10 CPU .............................................................................................................................. 64

4.1.11 Power Supply .............................................................................................................. 64

4.2 Software ............................................................................................................................... 66

4.2.1 Requirements ................................................................................................................ 66

4.2.2 Operating System Software .......................................................................................... 67

4.2.3 Application Software ..................................................................................................... 67

4.2.4 Management Software ................................................................................................. 70

4.2.5 Serial Communications ................................................................................................. 70

4.2.6 Database ....................................................................................................................... 72

4.2.7 Payment Processing ...................................................................................................... 74

4.2.8 Embedded Software ..................................................................................................... 75

4.2.9 Laboratory Portal .......................................................................................................... 76

5 Design Summary of Hardware and Software .............................................................................. 76

6 Prototype Construction ............................................................................................................... 85

6.1 Parts Acquisition .................................................................................................................. 85

6.1.1 System Enclosure .......................................................................................................... 85

6.1.2 Dispenser System Components .................................................................................... 86

6.1.3 Printed Circuit Board (PCB) ........................................................................................... 87

6.1.4 Collector ........................................................................................................................ 87

6.1.5 Bag Dispenser ................................................................................................................ 87

6.1.6 Holder ........................................................................................................................... 88

6.1.6.1 Temperature Control ............................................................................................. 88

6.1.6.2 Cooling Unit............................................................................................................ 89

6.2 Final Coding Structure .......................................................................................................... 89

6.2.1 Operating System Software Structure .......................................................................... 89

6.2.2 Embedded Software Structure ..................................................................................... 90

P a g e | v

6.2.3 Laboratory Portal .......................................................................................................... 90

7 Project Prototype Testing ........................................................................................................... 91

7.1 Hardware Testing Environment ........................................................................................... 91

7.2 Hardware Specific Testing .................................................................................................... 91

7.2.1 Dispenser ...................................................................................................................... 91

7.2.1.1 Test Tube Dispensing (Boot) .................................................................................. 92

7.2.1.2 Dispensing “Pacman” Roller .................................................................................. 92

7.2.1.3 Boot Capacity and Dispensing Sensor .................................................................... 92

7.2.1.4 Scanner Roller ........................................................................................................ 93

7.2.1.5 Barcode Scanner .................................................................................................... 93

7.2.1.6 Tilting Dispensing Chute ........................................................................................ 93

7.2.2 Collector ........................................................................................................................ 94

7.2.3 Bag Dispenser ................................................................................................................ 94

7.2.4 Bag Sensor ..................................................................................................................... 95

7.2.5 Door Lock ...................................................................................................................... 96

7.2.6 Holder Test Procedures ................................................................................................ 97

7.3 Software Testing Environment ............................................................................................ 99

7.4 Software Specific Testing ................................................................................................... 100

7.4.1 Application Software Testing ...................................................................................... 100

7.4.2 Barcode Reading Software Testing ............................................................................. 101

7.4.3 Magnetic Card Reading Software Testing ................................................................... 101

7.4.4 Embedded Software Testing ....................................................................................... 101

7.4.5 Laboratory Portal Software Testing ............................................................................ 102

7.4.6 Serial Communication Testing .................................................................................... 102

7.4.7 Database Software Testing ......................................................................................... 103

8 Project Operations .................................................................................................................... 103

8.1 Initial Setup ........................................................................................................................ 103

8.2 Purchasing a Test ............................................................................................................... 103

8.3 Returning a Sample ............................................................................................................ 108

9 Administrative Content ............................................................................................................. 109

P a g e | vi

9.1 Milestone Discussion ......................................................................................................... 109

9.2 Budget and Finances .......................................................................................................... 112

10 Appendix A .............................................................................................................................. 113

10.1 Works Cited ...................................................................................................................... 113

10.2 Table of Tables ................................................................................................................ 116

10.3 Table of Figures ................................................................................................................ 116

10.4 Permissions ...................................................................................................................... 118

P a g e | 1

1 Executive Summery

Currently, bio-medical diagnostic tests (blood, saliva, urine etc.) require visiting a doctor’s office, which generally results in time consumption and high medical rates; additionally, the test/s and corresponding results are generally desired to be kept private, which may lead to potential patients not taking the tests due to the feeling of their privacy being invaded even by their doctor. The main motivation for the DocBox was to provide a means of taking a bio-medical diagnostic test that is quick, cheap, and convenient while maintaining confidentiality.

Due to the complexity of biomedical testing, the DocBox itself does not perform any of the tests. Instead, the DocBox is be a system that collects the samples to be sent to a lab for testing. Such an intermediary system can be applied for a variety of biomedical tests. To meet the requirement of convenience, DocBox is a system that can be accessible in public places, similar to vending machines and ATMs. Since the system is planned to be in such a public environment, not all biomedical tests can be collected sanitarily (blood and urine samples, for instance). Taking such factors into consideration, DocBox was designed to collect samples for saliva testing. With saliva testing, the samples must adhere to specific medical regulations for storage between the depositing of the samples and the testing at the laboratory.

DocBox contains multiple subsystems that collectively store contact information for the patient in a database, dispense collection test tubes, collect test tubes with saliva, and store the samples in an appropriate environment while awaiting pickup. These subsystems require the implementation of embedded, control, communication, and power systems. One significant milestone of the overall system design was the interface between microcontrollers and motors in order to dispense discrete amount of test tubes. Additionally, since the target audience is the general public, the system interface has been design to be user friendly and easy to navigate.

Administratively, the research, design, and testing phases of the DocBox each had fixed milestones in order to reach the project deadline with a significantly tested system that reliably performed each specified function. Although the project had a rather dynamic initial budget due to the system enclosure and user interface, the projected budget was constantly taken into consideration, and resulted in an efficient yet effective system development.

The overall goals of the DocBox project were to develop effective administrative management and technical design, the result being an easy to use device to deliver to the public for easier access for biomedical testing. With such ease for testing, vitamin deficiencies, diseases, and conditions can be more easily detected and consequently taken care of, resulting in a healthier culture.

P a g e | 2

2 Project Description Throughout the course of the initial phases of the DocBox project, Group 12 had several ideas and potential courses to take the project; however, it was soon decided to distinguish what the main goals and motivations for the project were to the Group, as well as what specifications the final version of the project was to contain.

2.1 Motivation

Upon evaluating the project as a whole, the motivation for DocBox could be broken into three basic categories: Creative, Technical, and Administrative. Each of the three categories is comprised of components that each member of the design group expressed interest in or held as a motivating factor for the project as a whole. Without further digression, the following describe the three motivational factors of the DocBox project:

Creative Motivation: When initially beginning the senior design process, it is typical for groups to get a mental “block” from design ideas that are not only interesting to the group, but also technically satisfying with respect to feasibility. Hence, when presented with the concept of DocBox, Group 12 found it to be an excellent creative design proposal for the fact that the practical applications are numerous; therefore resulting with plenty of room for technical design. Another beauty to DocBox is that the initial design was not set in stone but left, and almost encouraged, plenty of room for creative adaptation. Having such flexibility in design left room for future improvements with respect to technology and testing types; in the western culture such adaptability is required, else the product fade from existence before successfully reaching a majority of the population. Hence, creatively, DocBox showed motivating promise to be original, adaptable, and successful.

Technical Motivation: DocBox presented multiple design problems that, technically, were significant challenges for the group, yet were within the ability of the group to perform. The project presented design of control systems for motors and displays, as well as device communication and circuit design. Overall, the technical requirements for the project presented significant hardware and software design in key areas of Electrical Engineering: Controls, communications, and circuitry. The components of DocBox that involve control include, but were not limited to, microcontrollers and FPGA’s, motors, and displays. In many engineering applications such as robotics, weapons, and communication systems microcontrollers and FPGA’s are utilized significantly. Since these control devices play such a significant role in the engineering in both software and hardware, it therefore proved to be a significant skill to become further acquainted with. Within DocBox, there was additionally a significant amount of motor control for position and quantity as well as the control of interactive displays. All three of these control

P a g e | 3

features were extremely desirable skills to become better acquainted with for the purpose of becoming better-rounded engineers. A final motivating factor on the technical side of this project was the challenge of printed circuit board (PCB) design. In any electronic device, a part of the circuit design is not only the schematic layout, but the actual board layout for the circuit. Group 12 had desire to learn more about correctly designing PCB’s to provide a more reliable, and efficient means to control a large portion of the electronics within DocBox, and therefore from the Electrical Engineering perspective, PCB design layout was beneficial knowledge to have. Administrative Motivation: Although generally overlooked, the administrative side of Engineering was extremely important for the wellbeing of the project, and (in the context of the engineering industry) the company. Administrative qualities that were prevalent within this project included time management, budgeting, task delegation, and very importantly, effective communication between group members and affiliates. Each of these characteristics are vital to the success of the DocBox project, and are excellent practices for every engineer to have in order to have a broader understanding of working with a group on projects of various sizes. In many design scenarios, a time frame deadline is set, and it is therefore critical for the time spent on different sections of the project is managed considerably. With respect to the DocBox design project, a milestone chart was compiled in order to keep the project on a consistently progressing status. Similarly, the list of the expenses of the project was important for the entirety of the project for the purpose of knowing the general cost of designing DocBox, for the purpose of manufacturability costs. Administratively, the management of the time and money of this product were extremely crucial to the success of the project, for without meeting the milestones the required tasks to complete the project would begin to overlap and threaten to cause the project to not achieve the initially set goals. Lastly, effective delegation of roles and tasks among the design group was also important; without considering the strengths and weaknesses of each member, the effective working of the group to meet the project milestones would be extremely difficult. Delegation of roles also fell under the category of effective communication throughout the group as well, which was the last, yet very important qualitative skill that this design group set out to develop. These four administrative characteristics served as the main motivating factors to the group, without them, the project would not have nearly come together as well as it did by the Spring of 2014.

2.2 Objectives and Goals

The overall goal of this project was to provide an affordable, anonymous, and autonomous service that would offer the user personal biomedical testing for various conditions and deficiencies. As a parallel objective, Group 12 wanted to

P a g e | 4

learn more about control systems, embedded processors and other technology that would supplement their education in Electrical Engineering.

In order to meet the needs of the consumer, the system feature set needed to first be defined. This would allow for a structured design that would maintain a certain scale as well as manage expectations. The system was broken down into the 5 following subsystems: Screen Interface, Dispenser, Collector, Holder, and Power Supply. The definitions of the role and educational goals associated with each subsystem are as follows:

The majority of user frustration when dealing with autonomous vendors is associated with the screen interface. For DocBox, it was desired that users have a natural, logical, as well as efficient encounter with the system when entering information and choosing a service. A simplified set of instructions was designed in addition to a streamlined screen flow to minimize time spent at the kiosk. Additionally, a touchscreen monitor was utilized in order to maintain the appearance (and reality) of a simple interface, this allowed simplified user input as well as provided Group 12 with experience in touch integration.

Once the user has entered their information and has paid the nominal fee, the dispenser within DocBox is to release a certain number of test tubes to an intermediate bay within the kiosk. At this point, there will be an internal barcode scanner that will link the code on each test tube to the current user’s account information. The dispenser subsystem will then release the test tube(s) to the user for pick up. A sanitary re-sealable plastic bag will be vended along with the empty test tubes. The dispenser design will be one of the biggest challenges of this project. We wish to gain experience with motor control systems as well as embedded processor design through this subsystem.

The user will return to the kiosk once they have collected their saliva sample(s) in the test tube(s). They will scan one test tube via the external barcode scanner which identifies the account of the user returning the sample. A door will then open allowing the user to drop off their sample provided it is sealed in a sanitary plastic bag. This part of the process was be handled by the collector subsystem and involved embedded software as well as sensor design.

At this point, the user would have completed their interaction with the system and would wait for the test results from this point. Their sample residing in a sanitary container within the system’s enclosure awaiting pickup by a shipping courier. Once the bin reaches capacity, an embedded sensor will alert the main CPU to halt further sales until the bin has been emptied. This subsystem was called the holder. This subsystem monitors the temperature of the bin area and control an air conditioning system that keeps the samples at a medically regulated temperature. Group 12 gained experience with component datasheets and specifications in selecting the best sensors for these discussed applications.

The final subsystem, which played a major role in operation, was the power supply. There were multiple components that had various power requirements which made

P a g e | 5

the design more complex. However, due to desire to put more focus on the motor and sensor control within DocBox, a standard pre-built power supply was selected, compared to designing a power supply from scratch.

It was crucial to track the progress of the system design and assembly of the subsystems while maintaining a high quality of work. In order to set the milestone

expectations, Group 12 created a progress chart shown in Table 1.

2.3 Project Requirements and Specifications

In a broad view, the DocBox project had a wide amount of feature possibilities such as the shape of the unit, potential vitamin and/or medication dispensing depending on test results, mobile application support, or even a system diagnostic device for quick maintenance checkup. Given such flexibility in initial design, Group 12 defined the top-level requirements and specifications of the system in order to establish the initial DocBox system, which is shown in Figure 1 (including the role delegations of each of the members of Group 12).

2.3.1 System Enclosure

2.3.1.1 Exterior The first generation DocBox enclosure was designed to meet the exterior dimensions of 20”x20”x55”. The box frame and plating additionally was designed to be durable and easily extendable to be tamper and weather proof. The upper third of the front face is also angled to remove third party visibility of the user interface. The exterior paneling has three sections cut out for the interactive display, card reader, test tube dispensing/collecting door, sealed bag dispenser, and barcode scanner. Additionally, the rear of the enclosure has a secure door that enables easy access for test tube stocking/pickup and device maintenance. The Exterior design diagrams are as shown in Figure 15.

2.3.1.2 Interior

The interior of the system contains sufficient shelving to support the dispensing unit with corresponding motors; additionally, the holding section of the interior is insulated to keep the storing conditions cool.

2.3.2 Test Tubes

Each test tube meets the dimensions specified by the testing laboratory (2.25” long with diameter of 0.5”) and has an individual barcode specific to that test tube. These barcodes wrap fully around the test tubes so as to increase scanning likelihood.

2.3.3 Interactive Display

For effective user interaction, a 15” touchscreen display was placed on the angled front face of the system enclosure. The display is of industrial quality so as to withstand public use with great reliability.

P a g e | 6

Table 1 – Doc Box Project Milestones From Fall 2013 to Spring 2014

P a g e | 7

2.3.4 Dispensing Unit

2.3.4.1 Test Tube Dispenser “Boot”

The “boot” consists of a gravity-fed container that holds a required 1000 (2.25” long and diameter of 0.5”) test tubes; the container was designed in such a way so as to deliver all test tubes to a single dispensing slot at the bottom of the boot with minimal theoretical likelihood of test tube jamming.

Figure 1 – DocBox Top Level System Block Diagram

2.3.4.2 Dispensing “Pacman” Roller

To discretely dispense test tubes from the boot, a roller with a collection slot (1/4 cutout from the cross sectional of the roller) is located directly below the dispensing slot of the boot. When the roller is rotated via DC motor, test tubes remain within the boot until the slot within the roller faces the dispensing slot, where a single test tube falls within and is consequently dropped onto the scanning chute.

2.3.4.3 Scanning Chute

The scanning chute is a short “teeter totter” ramp that pivots either clockwise (CW) or counter clockwise (CCW), depending on whether the barcode on the test tube is read or not. To ensure that the barcode is read, a motor driven roller at the end of the chute rotates the test tube while a barcode scanner scans from above the

P a g e | 8

chute. Upon verification of the barcode being read, the chute rotates CCW to send to the dispensing chute. Once the test tube has left the scanning chute, the chute returns to its initial position, awaiting the next test tube. Given that the barcode cannot be read, the chute rotates CW to send the test tube to a discard box, then return to the initial position and scan an additional test tube.

2.3.4.4 Dispensing Sensors

One sensor is placed within the dispenser in order to increase the reliability of the system. This sensor is located below the Pacman Roller, to verify that a test tube is actually dispensed to be identified by the barcode scanner.

2.3.5 Dispensing Chute “Tongue”

The Tongue is a stationary chute located directly below the scanning chute that delivers the test tube to the exterior of the system enclosure. Although for the first generation prototype of DocBox, the tongue is simply an open chute leading to the exterior of the enclosure, future generations could incorporate one-way doors (similar to a gumball machine) or even mechanically locking doors to prevent from tampering. For the case of the first generation DocBox, the tongue remains an open chute.

2.3.6 Bag Dispenser

Per the specifications within Section 3.2.3, the samples must be stored within a re-sealable watertight bag. The exterior front face of the box has a locked door that is opened by software in order to allow the user to access plastic bags for storage of test tubes. This door is locked in order to prevent from tampering in addition to keeping bag supplies up without erroneous dispensing. Additionally, the bag dispenser contains a limit switch in order to send a notification to the CPU that the bag level is low.

2.3.6.1 Collection Chute “Collector”

For the retrieval of test tube samples, a chute leading from the exterior of the box test tube holder provides the means to simply deliver the samples to the environmentally controlled holding area. The chute is designed in such a way so as to only allow test tubes within specific sized bags to be dispensed. At the Holder end of the chute, a sensor both verifies that the holder is not full as well as that the sample has been dispensed into the holder.

2.3.7 Sample Collection Unit “Holder”

The returned samples shall be collected within the Sample Collection Unit (“Holder”). The Holder shall fit within the interior dimensions of system enclosure, and be able to hold 500 samples within a re-sealable bag. This size is smaller than the full capacity of the holder in that each test may require more than one test tube, therefore resulting in multiple test tubes per sample.

P a g e | 9

2.3.8 Environmental Control

Per the sample storage specifications listed in Section 3.1, the temperature of the interior of the box must remain within the specified range. The temperature within the holder is therefore regulated by a compact air conditioning unit that monitors the temperature periodically via its own analog temperature control circuit designed by Group 12.

2.3.9 CPU & Microcontroller The DocBox uses a computer tower that runs the basic Windows 7 operating system. The CPU supports sufficient USB ports to connect to all peripheral components within the box. The main function of the CPU is to run the Graphical User Interface (GUI) and communicate with the microcontroller which controls the motors, sensors, and locks of DocBox.

2.3.10 Power Supply

Due to the wide variety of system components, the main power supply for DocBox shall be able to meet the requirements for all of the components that connect to the microcontroller and holder circuitry. The CPU shall be supplied from its internal supply. Surge protection via an internal power strip as well as noise decoupling within the purchased power supply are features of the internal power supply of DocBox. The entire DocBox assembly shall obtain its input power from a single cord that utilizes a general U.S. wall socket (120 V, 60 Hz).

3 Research Related to Project Definition

3.1 Existing Similar Projects and Products Since no known existing product serves the same exact function, the concept of the DocBox is truly unique and original. Though there were no existing designs to solely base the DocBox project off of,there are similar products that were worth researching. These are shown in the following sections.

3.1.1 Medbox

Most similar to our project concept was the Medbox MDS or “Medicine Storage Machine”. The Medbox is a vending machine-like system that dispenses prescription medication to authorized personnel. Like the desire for the final product of DocBox, the Medbox boasts security in terms of contents and patient identification. As such, Medbox utilizes biometric identification (fingerprint sample) in combination with registration card scanning to access its contents. This provides the system the ability to track and restrict usage as well as monitor activity. Patient information is also kept on site as the software is self-supportive and requires no internet access. Furthermore, the sensitive drugs are stored in a climate controlled environment and are dispensed in various doses within standard pharmaceutical vials. [1]

P a g e | 10

3.1.2 Vending Machines

Vending machines can be found virtually everywhere and offer a multitude of possible products that can be vended. From sodas and snacks to electronics and pizza’s, there seems to be a vending machine for anything that can be sold. DocBox is similar to a vending machine in that it automatically dispenses a test tube for sample containment in exchange for monetary payment. However, DocBox differs in that it also takes in objects (tubes) and stores them for daily pick up. In all typical vending machines, there must be a way to access the storage area. This is usually a secure door or panel that only a courier or technician can get into for restocking and/or maintenance. Consequently, DocBox has panels that allow access for maintenance and test tube pickup. If the product in a vending machine is to be stored at a low temperature, a cooling unit is often installed. Since the samples for DocBox are required to be stored in a temperature-controlled environment, a small cooling unit similar to those in vending machines is used. In many vending machines, products are dispensed using motor assemblies controlled by some type of embedded control board. The DocBox, like most vending machines contains a main embedded control board to interface the electro-mechanical components of DocBox with the CPU. It is additionally noted that refrigerated vending machines consume 5 more times more electricity than a typical home refrigerator – 7 to16 hWh/day/machine [2]. The compressor draws the most energy followed by lighting, since the compressor is the heart of the cooling system and is where energy is put into. Section 3.6.4.1 explains in detail the working of the compressor and the cooling system.

3.1.3 ATM

Automated Teller Machines (ATM) are known to be convenient and secure with intuitive displays and inputs and tamper-proof enclosures. With advancing technology and increasing computing demands, ATM’s have also been transitioning away from dedicated microcontrollers and integrated circuits to that of hardware architecture akin to personal computers. This was the desire for the DocBox, which can be further implemented in future generations of the system.

3.2 Medical Standards and Requirements

Due to the fact that this project involved the handling of biomedical specimens, it was therefore established that the project adhere to both the national and testing facility medical regulations. The regulations for the handling and storage of each of the samples is as specified by the Centers for Disease Control (CDC) diagnostic specimen packing document. [3]

P a g e | 11

3.2.1 Test Tube Specifications

The test tube size and dimensions were regulated to the size specified by the specimen testing facility, which is within the size of 500 millilitres [3]; additionally, per the CDC specimen packing document, the primary specimen containers (i.e. test tubes) “…must have positive closures, such as a screw-on cap. The primary receptacle may be glass, metal or plastic…” The test tubes that are used in DocBox have the dimensions of 2.25” long with diameter of 0.5”.

The test tubes also contain labels that specify the time, date, and name associated with the sample. Traditional methods for labeling the test tubes is by manually writing the information on a sticker label and affixing the label to the test tube; however, since one of the goals of the DocBox project was to make the collection process as simple as possible, individual barcode labeling of each test tube was sought out to provide a more simple means of providing user information.

3.2.2 Specimen Collection Methods

With respect to saliva collection, there are various methods in which the patient may deposit a specimen. The most popular methods according to Salimetrics, a saliva research support company, are drooling and swabbing. Swabbing, as described by the title, is simply swabbing a portion of saliva from key areas of the mouth; although this method may be easier, it does not tend to be as accurate, due to higher potential of swabbing plaque and other bacteria instead of the actual saliva. Hence, drooling is the more preferred option, at least for Salimetrics. Drooling is generally performed with the assistance of a straw-like attachment to the test tube since they are generally rather small; however, just the test tube itself can suffice for specimen depositing. Specimen collection by drool is also more beneficial due to the higher likelihood of depositing saliva that contains a more evenly balanced representation of the contents throughout the body. [4] From this basic overview, it was easily seen why the testing facilities utilize the drooling technique for saliva testing.

3.2.3 Specimen Shipping Requirements

It was important to understand the shipping requirements before the system was designed, so as to make the entire specimen collection process possible. According to the Code of Federal Regulations (CFR), an infectious substance is a “Material known or reasonably expected to contain a pathogen. A pathogen is a microorganism (including bacteria, viruses, rickettsiae, parasites, fungi) or other agent that can cause disease in humans or animals.” [5]. Any substance that meets this criteria falls into sub-category A or B. Category A is defined as “An infectious substance in a form capable of causing permanent disability or life-threatening or fatal disease in otherwise healthy humans or animals when exposure to it occurs.” Category B, on the other hand, is “An infectious substance that is not in a form generally capable of causing permanent disability or life-threatening or fatal disease…” In order to ship any specimen from these categories, a special identification number (UN3373 for category B, UN2814 for category A) must be

P a g e | 12

applied to the outer packaging and special packing is required. However, there are a few exceptions that allow shipment of saliva without the need for a specific HAZMAT ID. The CRF states that if a human sample is not for the diagnosis of an infectious disease but for routine tests such as cholesterol, pregnancy, blood glucose, cancer biopsies etc., the sample is considered a non-infectious substance. The protocol for shipping non-infectious clinical samples is defined by the individual courier, in this case the projected courier for DocBox is UPS. Since the samples to be shipped will travel by air, UPS mandates that the packaging of all non-infectious samples adhere to International Air Transport Association (IATA) protocol PI 650. This requires three levels of sealant: a primary leak-proof receptacle(s), a secondary leak-proof package and a rigid outer packaging [5]. The test tubes represent the primary container and will be held in a secondary container that is watertight (in other words, a re-sealable bag). This method is identical to shipment protocol of Category B: infectious substances. For the purposes of this system, the tests conducted are classified as Category B substances in order to allow routine and low risk pathogen testing. Since the DocBox is meant to be the “middle man” between the patient and the testing facility, it only needs to provide the basic handling requirements of providing the test tube, re-sealable bag, and a suitable storage temperature. Since the DocBox remains stationary, the rigid box requirement will be met for simple collection purposes, but is not required. Once the delivery service picks up the specimens from DocBox, the service will store the samples in their own boxes and moderate the environmental conditions.

3.3 Universal Labeling System

In order to keep track of each customer's saliva samples from box to lab, a method of indexing was used. A unique ID is assigned to each test tube and associated with the user’s test choice and contact information. One way to assign a number to a test tube is by the use of a label printer. However, peel and stick labeling requires more action on the user’s end, increases error probability, and requires more maintenance. Therefore, stocking the system with pre-labeled test tubes and automatically scanning the numbers was the simplest solution for the user. Therefore, a code was chosen to be used that can be quickly and accurately translated to the digital world.

3.3.1 Code Format

Since an internal scan identifies each outgoing vial, it was important to determine the most efficient, accurate, and logistically feasible code format. The first option was to use a 1-dimensional bar code known as a Universal Product Code or UPC. There are several standards within the UPC line including but not limited to UPC-A, UPC-E, and UPC-128 [6].

There are also 2-dimensional codes which can hold mountains of information over 1-dimensional barcodes. A few common formats are known as QR-Code,

P a g e | 13

Maxicode, and Data Matrix [6]. These formats are great for storing sufficient data but require a flat surface for scanning. Since the sample vials are small cylindrical tubes, a 1-dimensional barcode was therefore the best choice.

From the UPC standard formats available, the UPC-128 code supports the largest number of unique ID numbers. Also, UPC-128 supports all ASCII characters as well as numbers. This made the numbering scheme orderly and logical, and was a part of the original design for the numbering scheme to be used. This is further discussed in the design testing section of this document.

3.3.2 Numbering Scheme

The ID number system needed to be able to accommodate the future expansion of DocBox kiosks. Also, there needed to be a customer ID large enough for each kiosk so that no two customers could get switched. For this system, the UPC-128 is implemented to encode format “DB#0001_00000001” in hexadecimal. The first four numbers after the # symbol represent the kiosk number and the last eight digits represent the customer ID. Starting with all zeros, there are over 4.2 Billion possible ID numbers for each kiosk and over 65,500 possible kiosks as seen in the expressions below. During manufacturing, the test tubes will have the barcodes printed on the side in an incremental fashion and each test tube will belong to a specific kiosk. These test tubes can be labeled and sent from the manufacturer to an authorized DocBox personnel in numerical increments of 1000. For obvious reasons, careful inventory must be taken with each refill so keep track of the number system.

164 = 65,536 𝑢𝑛𝑖𝑞𝑢𝑒 𝑘𝑖𝑜𝑠𝑘𝑠 168 ≈ 4.29 𝐵𝑖𝑙𝑙𝑖𝑜𝑛 𝐼𝐷 𝑛𝑢𝑚𝑏𝑒𝑟𝑠 𝑝𝑒𝑟 𝑘𝑖𝑜𝑠𝑘

3.4 Relevant Hardware

3.4.1 Barcode Scanner

There was one location in the system where a scanner was needed to translate the coded index on each test tube. When a test tube is first dispensed it is stopped beneath the barcode scanner until the scanner makes a valid read on the barcode on the side. Once the test tubes are returned and sent to the testing facility, a barcode scanner is needed at the laboratory facility for the technician to retrieve the contact information provided by the user from the web database. There are primarily 2 types of barcode scanning methods: CCD optical and laser scanning. CCD (Charge Coupled Device) scanners convert optical, ambient light reflected from the barcode into a voltage pattern across the sensor [7]. This type of recognition requires a significant amount of available ambient light. This type of scanner could work in a laboratory environment but since our internal scanner is going to be in a dark area, another option needed to be explored. A laser based scanner focuses a laser beam onto the barcode and detects the returned light via photodiodes [8]. Since the transmitted laser light is modulated, the internal digital signal processor is able to block unwanted light signals and only process the

P a g e | 14

desired information. This type of barcode scanner was chosen to be used for the internal scanning solution.

3.4.1 Touchscreen

There were multiple options when considering using a touchscreen. The technology varies widely so the application was considered when selecting the appropriate type of touchscreen technology. DocBox requires a responsive, accurate, and durable touchscreen. Current technologies include capacitive, surface acoustic wave (SAW), infrared, and resistive touchscreens. Each option carries its own attributes that make it suitable for different applications.

Capacitive touchscreens offer very fast response time, which makes them suitable for applications involving features like drag and drop. Thick glass can protect these screens from dirt, dust, condensation, liquid spills, and cleaning solutions. This protective layer also makes these screens resistant to scratches and abrasion. Cost for these screens can be high and integration is not always the easiest.

Surface acoustic wave touchscreens are moderately priced and are moderately complex to integrate. SAW touchscreens are useful for applications that require excellent touch performance without compromising aesthetics. The downside of SAW technology is the adverse effects from moisture, surface contaminants, and changes in temperature. This technology is great for controlled environment applications.

Infrared technology has the benefits of withstanding severe environments, adjusting to changing light conditions, vandal and abrasion resistant, and is sealable against contaminants. Infrared costs about the same amount as SAW and provides simple integration. Infrared does not rely on pressure so there is no activation or sensitivity pressure. These features make infrared touchscreens useful for indoor/outdoor kiosks, ATMs, and process control systems.

The last option was resistive technology. Resistive touchscreens are known for their durability and long product life. They are resistive to contamination and maintain accuracy in high-use environments. Resistive touchscreens also tend to be more affordable than the other choices. One downside is a higher transmissivity distortion due to the coatings on the surface. Resistive touchscreens are used in POS, industrial, medical, and even the RedBox® systems. This proven performance made resistive a great choice for the DocBox system.

3.4.2 Motors Types and Control

Since the systems functionality depended on the incorporation of multiple moving parts, careful consideration was taken when choosing the appropriate motors. There are three places in the system where a specific motor operates and these are found exclusively in the dispenser subsystem. In choosing a motor for each part of this subsystem, the mechanical requirements such as torque, rotational speed and direction as well as electrical control needs was evaluated. Once the requirements were generally defined for each location, a specific type of motor was

P a g e | 15

assigned. The various types of motors available had various advantages and drawbacks with respect to each application. At the time of research, there were three types of motors that were considered for this subsystem: Brushed DC, Brushless DC, and Stepper motors. A brushed DC motor can operate without an electronic driver and runs freely when power is applied. This is beneficial because it can be switched on and off with a single pin of data. The direction of its rotation depends on the current flow direction. The speed of its rotor has a linear dependency to its armature voltage, which makes speed control simple. A drawback to a brushed DC motor is the fact that the electrical contact of the rotor (commutator) rotates in contact with the fixed brushes. This can causes sparking and electrical noise. [9] Motors such as the brushless DC and stepper motors utilize electrical commutation rather than brush contact. This allows for virtually noiseless operation. These motors consist of an array of stator windings and permanent magnets which allow for discrete rotation increments. Unlike brushed DC motors, brushless motor control requires more than a single control line. In order to turn the rotor, a precisely timed sequence of pulses is required to energize the windings. These motors require a controller capable of pulse width modulation output. [10]

3.4.2.1 Dispenser Wheel

In the order of operations, the dispenser wheel is the first moving component that required a motor. The dispenser wheel is a solid cylinder with a notch that allows one test tube from the gravity feeder (a.k.a. the “Boot”) to drop down upon each rotational pass. Since the dispenser wheel only needs to rotate in one direction at a constant speed, the control requirements are significantly reduced. Figure 2 and Figure 3 show two control logic diagrams which were considered to be implemented when a “dispenser wheel” command is given. For the diagram in Figure 2, the current position of the motor is compared with a reference value, which is determined from initial calibration. Once the rotation is complete, the motor is turned off and the roller sequence is initiated. This method of control is advantageous because the position of the wheel is known at all times. For the diagram in Figure 3, there is no direct motor feedback. Instead, there is a sensor beneath the dispenser wheel that detects when a test tube has dropped. When triggered, the sensor alerts the main controller to stop the motor rotation and initiate the roller sequence. This control technique is beneficial in that the vending of a test tube is virtually guaranteed before the roller sequence begins. Based on the two control methods shown in the figures as well as in the mechanical requirements, a specific motor type was chosen to drive the dispenser wheel.The mechanical requirements for this motor can be inferred from the specifications in Section 2.3.4. The primarily restriction for this application is torque. Figure 4 shows that for a clockwise rotation of the dispenser wheel, there is an opposing torque that is dependent on the weight of the test tubes, the coefficient of kinetic friction, and the radius of the wheel. Therefore, the motor needed to be able to supply a

torque larger than τ by a minimum factor X. This factor was determined based on

the individual motor performance of torque vs speed, voltage, current etc.

P a g e | 16

Figure 2 – Dispenser Wheel Logic Methods: Discrete Rotation

Figure 3 – Dispenser Wheel Logic Methods: Sensor Feedback

Figure 4 – Dispenser Wheel Dynamics

3.4.2.2 Roller

After a test tube is released from the holder, it rolls to a wheel that will rotate the tube so that the barcode can be scanned. This motor is controlled in the same

P a g e | 17

fashion as the dispenser wheel except that the feedback comes though the CPU by way of serial interface. The CPU alerts the embedded control system when a valid scan has been made.

3.4.3 Power Supply

As previously specified, the DocBox will receive its power from the standard North American 120 volt (rms), 60hz AC main electricity. The National Electrical Manufacturers Association, or “NEMA”, have standardized AC power plugs for mains electricity so, as such, a NEMA L5 connector is used to supply the main electricity to the DocBox. NEMA L5 connectors are common among many devices and feature 2 parallel contact blades with a ground blade. At a rated 15A at 125V, this connector is more than sufficient enough to supply the needed power. The connection to main is made through a common NEMA 5 outlet – which goes through a ground fault circuit interrupter receptacle (GFCI). According to the Occupational Safety and Health Administration (OSHA), “The ground-fault circuit interrupter, or GFCI, is a fast-acting circuit breaker designed to shut off electric power in the event of a ground-fault within as little as 1/40 of a second.” This device is used to protect persons from potentially fatal electric shock by comparing current coming out of the receptacle to current coming in. If the current differs by about 5 milliamps, the GFCI will break the circuit quickly preventing any harmful shock due to the ground fault. Also available are GFCI on cables which protects the cord and devices connected to them. [11] Since this project contains multiple sensitive components, great care was taken when designing a system to deliver power to such devices. The DC power supply used for DocBox converts the AC power signal to multiple regulated DC voltages, namely ±12, 5, and 3.3V. Figure 5 is a rudimentary diagram of the power supply system. To protect from overcurrent that may cause damage to the power supply or other components, an inline fuse is utilized on each of the supply rails within DocBox. Expected to draw the most power are the display, holder, and CPU; therefore the power supply is rated to those components, which are further specified in later sections of this document. That being said, the power supply was one of the last components to be specified in the first generation design. Aside from power output and overload protection, other factors in choosing a power supply for the DocBox include size and operating temperature. However, looking at existing power supplies for purchase in the 24VDC range, these factors should not be a problem. Proper testing of enclosure temperature and heat dissipation of the power supply’s heat sink will still be employed especially if the DocBox will be used outdoors. As mentioned before, the DC power supply converts AC voltage into usable DC voltage. However, during the research phase of the project, unregulated supplies were considered, the output voltage of the supply would vary depending on fluctuations of AC supply voltage and load on the output.

P a g e | 18

Figure 5 - Power Supply Diagram

Since multiple loads are tied in parallel to a power bus, it was desirable for our application to have the voltage resistant to change through a linear regulator - this is called a linear regulated power supply. Another type of power supply considered uses a switching regulator called a switched-mode power supply. These supplies are more complex than linear regulators but yield better efficiency and smaller size. In fact, many home electronics use switched-mode power supplies such as cell phone chargers and personal computers. However, despite their advantages, the supplies may produce more noise due to the switching.

3.4.4 Microcontrollers

The use of an embedded processor in conjunction with a full CPU has several advantages. For example, the main system program was simplified by outsourcing trivial, yet necessary tasks to a microcontroller through a communication line. Also, the systems power efficiency was increased because of the low power nature of embedded processors. Many processors implement a “sleep mode” when not in service until a communication interrupt occurs. There were several factors that were considered in choosing an embedded microcontroller such as processing power, I/O capabilities, number of I/O, and communication. These specifications were determined by outlining the tasks that the processor needed to perform and the hardware that will be interfaced. Due to the educational background of the members of Group 12, the Texas Instruments MSP430 microprocessor was the first option for consideration, and consequently was the microprocessor of choice for project. The MSP430 comes in multiple compact package sizes and was therefore scalable to the design of the project.

P a g e | 19

Additionally, the background knowledge and vast community support of the MSP430 was a deciding factor for the processor. However, the TI microprocessor was not chosen simply for background, but also due to it’s qualifications for the project, which are further discussed within the Microprocessor design section of this document.

3.4.5 CPU

The central processing unit contains all the software and data necessary to run the DocBox system. There are different options available when considering the purchase of a CPU. The choices are narrowed by the conditions defined in the project definition section.

A mini PC was explored as a choice due to its small physical size and dimensions. Mini PCs generally do not have the most impressive specifications but still function as a regular desktop PC. This is an attractive option because the CPU would not take up much space inside the box and be very cost effective. However, utilizing lower grade hardware may not be the best option to provide a friendly and usable customer interface. Yet it was additionally taken into consideration that the user interface did not need significantly high performance hardware.

Another option was a touch panel PC like those used in industrial human interface applications. These would provide a display and CPU packaged together that mounts into the system saving valuable space. This product area provides resistance to harsh environments such as a factory or railway control center. The necessary I/O ports are plentiful on these devices as they are designed to integrate with many systems. The downside of this product is the cost. Touch panel PCs may offer more than what is needed in a kiosk design.

A regular desktop PC that would fit in the allotted space was a good option. A desktop PC provides the appropriate I/O ports, storage, memory, and functionality to meet the needs of the project. This would also provide a level of expandability that the previous two options did not. A desktop allows easy access to update software as well as hardware. Development of the DocBox software took place on a desktop PC, so testing and implementing also took place all on one unit.

3.5 Relevant Software

3.5.1 Software Requirements

Identifying the requirements of a new software product is vital for success in the marketplace. Before the DocBox software can be fully development there must be a complete understanding of all the requirements the system must adhere to. Concerns such as who will be using the software, how will it be developed, what technologies are necessary, and how will it be maintained are among a few of the topics addressed in the following sections. Before looking into the development of the software the reason the project is commissioned must be addressed.

P a g e | 20

The stakeholders, or sponsors, own the original idea so it makes sense to understand what they are looking for in a final design before beginning production. Meeting with the sponsors has been crucial in identifying the requirements for the DocBox software. The requirements began as very abstract guidelines that assisted in developing an original proposal for our team to acquire the project. It has been identified that the stakeholders require an easy to use system that is visually stimulating and attractive. The software must maintain a high level of security to protect the customer’s information. The system must also be robust and adaptable to allow modification as medical diagnostic technology changes.

Graphic design is a very important role in the success of any product; this is no different for the DocBox. The screen has an eye catching animation that plays in a loop as potential customers pass by. This may be in a drug store, gym, or school campus. Wherever the DocBox is located it will need to grab the attention of a wide variety of people from all different demographics. Research into what type of visual aids and colors are best suited for this will be discussed in a later section. Once a customer approaches the kiosk the looping visual aid will smoothly transition to a friendly environment the customer can interact with. As the user interacts with the system the interface will clearly display choices that can be selected. Visual aids are used to help the user identify what they are looking for.

Avoiding a security threat is crucial in the success of the DocBox because the target audience is the general public. Any security problems will surely lead to negative marketing for the product. Security will be treated with the utmost priority in the design.

3.5.2 User Identification

Identifying the users of any public access system is required to generate the most effective interface. The quality of the user interface will influence how easy a user can gather information and conduct transactions. Catering to the wide variety of users the DocBox may attract is a challenge on many different levels. A friendly and useful user interface has many benefits including but not limited to increased frequency of use, less training or instruction, lower error rates, and increased turnaround time per customer.

Some of the undesirable effects mentioned by users of public access systems are confusion among new users, system does not provide information needed by the user or produce information in an undesirable form, users are forced to perform certain tasks, and system may provide extra information that is not required [12]. To avoid these downfalls we will study usability in detail. Usability of a product is the ease of which a user can achieve the goals the product was set out to accomplish in a particular environment. Accomplishment should also include the process being finished efficiently and comfortably.

The components of usability have been described by Rowley and Slack as learnability, throughput, flexibility, and attitude [12]. The first can be described as

P a g e | 21

ease of learning, or the time and effort required to reach a specified level of user performance. Throughput, or ease of use, is the ability to accomplish tasks within a reasonable amount of time compared to the amount of errors made. Flexibility is the extent at which the system can accommodate changes to the tasks and environment originally specified. Attitude is the way users perceive the learnability, throughput, and flexibility of the system. Attitude is extremely important when it comes to public perception of a product or system; therefore, we wish to instill a positive attitude around the DocBox. The following list summarizes the important concepts of usability.

Learnability

Throughput

Flexibility

Attitude

There are many types of users from all types of backgrounds with varying experience and knowledge. Users are generally very adaptable and will learn to use a poorly designed system if it is necessary for their needs. This must be avoided for the DocBox because we are offering an optional service. This service is not necessarily essential to the survival or well-being of most users. When the system is not intuitive to use people are discouraged from coming back. Users will likely share their experience with their family and friends resulting in a negative attitude about DocBox as mentioned above.

A simple graphic can be used to display the variety of users we wish to accommodate. There are three categories which are experience, frequency, and age. A user will fall into a different spot on the scale in each category. Figure 6 demonstrates the flexibility that must be accomplished for the DocBox.

Figure 6 - Range of Users

The last group of users that has not been mentioned yet are those with special needs. DocBox’s goal is to accommodate all users, so this includes people who are hearing or visually impaired. Audio output can be provided to assist those who cannot see the touch screen. Audio commands paired with a touch keypad can allow a visually impaired user to navigate the system effectively.

P a g e | 22

Overall, we see the need for a robust, intuitive, and usable system that all types of users can use. Everyone from first time users to regular customers, children to adults, and beginners to technology experts will have the ability to learn and enjoy the DocBox interface. The goal of DocBox is to keep it simple while providing an informative and detailed interface that provides as much or as little information the user requires before embarking on their first transaction.

3.5.1 Database Information

The DocBox will require a database to manage the client’s information. A second database will be used to store all the available testing information that will allow users to quickly search for available tests. The core information that will be kept in the client database will be an identification number, tests received, and contact information. The goal of the database is to allow the laboratory access to the clients contact information. This information will be used to send out customer results from the laboratory.

The resource available that is most commonly used for database management is MySQL (“My S-Q-L”). MySQL is a widely used open-source relational database management system. MySQL does not ship with tools to manage the data contained within the databases. The resource available to create and modify databases is the command line utility. However, Oracle actively develops a front-end tool known as MySQL Workbench. This tool gives the ability to build database structures, backup data, and work with records. This tool is freely available for use by anyone. There is also a proprietary standard edition that is available which extends and improves the features given in the free edition.

The DocBox tests vary in complexity and size. Test range from a few results to hundreds of results. By storing which items can be tested by which test in a database they can easily be displayed to the user. User will also be able to search for items they may wish to test. Searching the database will provide results for which test is needed to meet the customers need. This way we can provide the most accurate information to aid the customer in purchasing the right tests.

3.5.2 Graphical User Interface Options

The motivation for this section is to explore the different options available for creating an appealing, eye-catching, and high-end user interface for the DocBox. The framework used to develop the DocBox software needs to be quick and responsive, have natural animations, provide visual cues rather than long textual descriptions, and be visually stimulating to look at. Below is a description of the toolkits explored before deciding which will be most useful for the development of the DocBox software.

According to GTK.org, GTK+ (Graphics Toolkit), or the GIMP Toolkit, is a multiplatform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites [13]. GTK+ offers the benefits of having been

P a g e | 23

developed for over a decade, which means it delivers a high level of stability. GTK+ collection of windows, dialogs, and widgets boast a native feel that adapts to different platforms including Linux, Windows 32 and 64-bit, and Mac OS X. The project is protected by a Lesser General Public License (LPGL) so it can be used by anyone, even for proprietary software. While GTK+ is designed to be lightweight and efficient it does have its drawbacks. Basic free-drawing and image manipulation is available; however, the framework is pixel-level based so building a semi-complex application requires significant effort by the programmer. This also means animations and transition have to be implemented from scratch which is not suitable for the short development time available for the DocBox. The second deciding factor was that GTK does not support 3D in any way.

The Open Graphics Library (OpenGL) was also explored as an available option. OpenGL is the most widely adopted 2D and 3D graphics application programming interface (API) in the industry. It is already used in a wide variety of computer applications. OpenGL also is protected by a LPGL license which makes it a viable option. The downside of trying to create a graphical user interface (GUI) with OpenGL is that every frame or button should be a set of triangles projected in 2D on a plane. Input is complicated because a buffer analysis or vector selection would be necessary. It was determined that OpenGL would not be useful for the basis of creating the interface but can be implemented alongside other graphics libraries to create sleek and attractive scenes.

Another UI framework that has been explored and ultimately decided on is known as Qt (“cute” or “cue-tee”). According to the Qt-project, Qt is a cross-platform application and UI framework for developers using C++ or QML [14]. Qt is developed as and open source project but can also be used under commercial terms. The licensing details are discussed in the section titled ‘licensing’. Qt offers a vast collection of windows, dialogs, and widgets that are useful and eye-catching. Qt sets itself apart from the other available options in a few different ways. First, the IDE that comes with Qt, known as Qt Creator, is tailored to the needs of Qt developers. It focuses on providing features that help new users get up and running fast, this is something we are looking for because of the short development time allotted for the DocBox. The second deciding factor is a feature called ‘signals and slots’ that Qt implements. A signal is emitted when a particular event occurs- a button press, timeout, or basically any event you can think of. A slot is a function that is called when a particular signal is emitted. The power in this method is derived from the ability to interconnect multiple signaling objects together with multiple slot objects. A signal can trigger multiple slots, from multiple objects. demonstrates the ability to connect multiple objects.

3.5.3 Development Environment

Software can be developed by carrying out each process manually. The process involves writing code in a text editor, then using a compiler such as GCC or make to compile and build the executable. There are many details involved in compiling a program manually that must be considered.

P a g e | 24

Figure 7 - Signals and Slots

A very experienced and quality software programmer can face frustrating issues when going this route. There is another option available to computer programmers to develop their software, an integrated development environment (IDE).

An IDE is a software application itself that facilitates the programmer. Usually any given IDE consists of a source code editor, build automation tools, and a debugger, at the minimum. There are numerous amounts of other tools available in different IDEs. Some IDEs contain a compiler while others use an external compiler such as GCC or Mingw32. An interpreter, which directly executes or performs scripts without compiling into machine language, is also included in most IDEs.

The idea behind an IDE is to maximize the programmer’s productivity by providing an integrated set of tools that work well together while maintaining a similar look and feel. Bringing all the tools necessary together is the central goal of any given IDE. One of the most useful functions of an IDE is to parse the code as the programmer is writing it to give immediate feedback about syntax errors. This allows a programmer to increase efficiency as well as learn new languages much quicker. The debugger is very useful because it allows the programmer to view memory, variables, and other useful information to determine where a programmer is malfunctioning.

3.5.4 Qt Creator

Here we will discuss the advantages and usefulness of Qt Creator. First of all, Qt Creator is the integrated development environment (IDE) that allows a developer to create an application utilizing the Qt libraries. Qt Creator is cross-platform IDE that is tailored to Qt developers. It allows users to get up and running in a minimal amount of time, but also provides a feature rich environment for experienced developers. This is advantageous for the DocBox software because an initial

Object 1

Signal 1

Signal 2

Object 2

Signal 1

Slot 1

Slot 2

Object 3

Signal 1

Slot 1

Object 4

Slot 1

Slot 2

Slot 3

P a g e | 25

application can be developed, then more advanced features added along the way of development.

Qt Creator has an advanced code editor that supports C++ and QML. QML is short for Qt Meta Language which is a JavaScript based declarative language for designing a user interface. QML is similar to XML in its goal of simplicity and human readability. Although QML is very useful, the DocBox will be developed in the C++ language. Qt Creator has rapid code navigation tools, advanced code completion, context sensitive help, and parenthesis matching. All of these tools allow for rapid development.

A visual debugger is another tool Qt Creator offers that aids in finding errors. The debugger can handle interrupt program execution, has the ability to step through code line-by-line or instruction-by-instruction, set breakpoints, examine stack contents, and view local and global variables.

Qt Creator also offers an integrated GUI layout and forms builder for C++ projects. This feature allows developers to rapidly design and build widgets and dialogs using on-screen forms. These forms are fully-functional and can be previewed immediately to ensure that they will look and feel exactly as designed. Having the ability to immediately preview forms gives the developer the opportunity to generate the application very quickly.

3.5.4.1 QGraphicsView

The most important class that will be implemented for the development of the DocBox user interface (UI) is called a QGraphicsView class. The QGraphicsView is a QWidget. The power in using this class for the application is the QGraphicsView can be used as the entire main window. This allows for an entirely customized look and feel containing completely customized items. Developing using a traditional form will give the feel of a desktop application which is undesirable. Many mobile applications are developed using the QGraphicsView as a main window giving the wide variety and smooth feel we are all accustomed to. The DocBox UI needs to provide a rich and easy to use environment that more and more people are becoming used to. Users are familiar with using the many mobile applications on their smart phones every day. We will take advantage of this ‘free’ training that users already have to implement the design, providing the highest level of usability. The following QGraphicsView information can be found at the Qt project website [15].

To implement a QGraphicsView we must first create a QGraphicsScene. Qt uses a powerful method that is referred to as the “model-view” method. The QGraphicsView is the “view”, while the QGraphicsScene is the “model” for the graphics view. More clearly, the view shows the scene while the scene contains all the items that are viewed on-screen. The scene contains all the items. These items are created as a QGraphicsItem. Figure 8 helps explain this framework.

P a g e | 26

Figure 8 – QgraphicsView

The graphics view is extremely robust in that it can implement many features. The graphics view handles transformations of the scene like zooming, rotation, and translation. The view is the parent class, handling a high level of detail over every item in the scene. For example, the view handles all events that take place in the scene. When an event occurs, like a key press, mouse press, or mouse movement, the view accepts this event and then propagates these events to the individual items involved. This happens by translating any input event into a QGraphicsSceneEvent, which is all handled by the view. Another feature the view provides is unsurpassed support for OpenGL. OpenGL provides the possibility for eye-catching 2D and 3D graphics to be displayed on screen. The last major feature the view provides to the ability to automatically map coordinates between the view and the scene, or vice-versa. This will be discussed further in the next paragraph.

The model-view method is useful here because it allows all the individual components of the application to have its own set of local coordinates. The view has integer coordinates that start at (0, 0) in the top left of the view, and then extending along the positive x-axis (to the right) and the positive y-axis (downward). The scene then has its own set of coordinates inside the view which are not relative to the view; they are local to the scene. Each individual item inside the scene also has its own set of local coordinates. Therefore, if a rotation or any other transformation is applied to an item it takes place about its own coordinates. Another way of visualizing the usefulness of this method is realizing that the center of a (100 x 100) box is always going to be at (50, 50), no matter what transformation has taken place. Figure 9 shows each component containing its own coordinate system.

P a g e | 27

Figure 9 - GraphicsView Coordinates

Just as the QGraphicsView handles and executes important methods of the model, so does the QGraphicsScene. The scene provides a canvas for managing a large number of items, in the tens of thousands. It is a container for graphic items. An item can be a box, circle, line, text, or custom item. The scene has no visual appearance of its own, it only manages the items. The scene can then be visualized by adding it to a graphics view as discussed earlier. There are two options when adding item to a scene. First, the convenient built-in functions can be used such as addRect(), addPolygon, and so on. The second option is to create a custom item and then add this item to the scene by using addItem(). To add a custom item the following two lines of code are necessary:

QGraphicsItem *item;

scene->addItem(item);

Adding a custom item to the scene is as easy as that. Of course, the item has to be defined elsewhere beforehand as well as the scene. The following section will discuss items in more detail. Some of the other interesting methods involved with the scene are as follows: items(), which returns a list of items intersecting a particular point or region in the scene, selectedItems(), returns a list of all selected items, and sceneRect(), returns the bounding rectangle for the entire scene.

The last piece of the Graphics View framework is the QGraphicsItem. QGraphicsItem is the base class for all graphics used in the scene. QGraphicsItem provides a light-weight foundation for creating custom items. Properties such as geometry, collision detection, painting implementation, and item interaction are all easily defined. Items contain methods to move, show/hide, enable/disable, set focus, select, along with many others. Two important methods must be implemented with any custom item. These are void paint(), which paints the item in local coordinates, and QRectF boundingRect(), which returns the outer

P a g e | 28

bounding shape of an item. An important property of items is the z-value. The z-axis value is used to determine the depth the item is placed on the scene, an item with a z value of 1 will be at the top of the scene. Items can also be grouped using QGraphicsItemGroup. This is an invisible item that provides a grouping for other items. If the parent object is removed all the child objects in the group are also removed.

When working with items we usually want to have the ability to alter or transform the items. Some of the more common transformations are rotate, scale, shear, and translate. Qt provides pre-defined functions for these common translations, this save time and effort by avoiding having to define a transformation matrix and implementing it yourself. Transformations are done about the z-axis by default, but can be done about a non z-axis to get an interesting perspective transform. To create a transformation a transformation object is first created, then properties are applied to the object, and then the transform object is applied to an item. Following is an example of a simple transformation that scales and rotates an item.

t = Qtransform();

t.scale(1.5, 1.5);

t.rotate(45, Qt::ZAxis);

item->setTransform(t);

The above code snippet creates a transformation object, t. Then applies a 150% scale in both the x-axis and y-axis. Also, a 45 degree rotation property is added about the z-axis. Finally, the transformation is applied to the item titled ‘item’. Transformations have properties that can be used to add more customization.

Anchors can be used to allow a transformation to take place about a particular point like the cursor location. Another feature arises when you may not want a certain item to transform. For example, if the scene is zooming in you may not wish for the toolbar in the application to remain the same. Flags can be set using item->setFlag(QGraphicsItem::ItemIgnoreTransformations) to prevent the transformation from being applied to this item.

3.5.5 Serial Communications The DocBox must integrate a powerful user interface with multiple hardware components to accomplish the functions it is designed to do. The communication between the main central processing unit (CPU) and the microcontroller is critical. The microcontroller will control the processes such as vending and receiving. User input will control when particular hardware components are activated. There must be a reliable line of communication to ensure all the devices operate when they are supposed to.

A serial protocol will be used to accomplish this task. The microcontroller is used to process the received control signals. The module on the microcontroller used (MSP430) is called a Universal Serial Communication Interface (USCI). This module can be used to implement multiple serial communication modes with the

P a g e | 29

same hardware. For the DocBox we will be using the Universal Asynchronous Receive Transmit (UART) mode. The specific USCI module that will implement UART on the MSP430 is the USCI_A module. Texas Instruments provides details about this mode in the MSP430 user guide [16]:

7- or 8-bit data with odd, even, or non-parity

Independent transmit and receive shift registers

Separate transmit and receive buffer registers

LSB-first or MSB-first data transmit and receive

Built-in idle line protocols

Receiver start-edge detection for auto-wake up from LPMx modes

Programmable baud rate

Status flags for error detection and suppression

Status flags for address detection

Independent interrupt capability for receive and transmit

This system will be utilized to receive and transmit serial data over a serial cable. The above feature set makes this module ideal for the DocBox implementation. It may seem as though the CPU only needs to transmit data while the microcontroller receives. However, it will be necessary to receive and transmit data from both ends. The reason for this is to check for errors. The CPU will need to know when an action has taken place or not. Figure 10 shows a typical serial data protocol.

Figure 10 – Serial Data Protocol

3.5.6 Licensing

The DocBox user interface and supporting software requires a rich development environment for realizing the necessary functionality. To accomplish this goal the software is developed using a cross-platform application and UI framework known as Qt, pronounced “cute” or “cue-tee” depending on the language being spoken. From here on we will refer to the framework as just ‘Qt’. Qt has been developed by Nokia’s Qt Development Framework division which acquired it from a Norwegian company known as Trolltech, who was the original developers of Qt. Since the acquisition Nokia has sold Qt’s commercial licensing and professional services to Digia.

To accommodate a wide range of users Qt is available under three different types of licenses. The first being a commercial license that is suitable for proprietary and commercial software. This option allows the developer to keep all source code

P a g e | 30

from third parties to maintain their trade secrets. This license would also need to be exercised if a company cannot adhere to a general public license (GPL).

The second option for Qt developers is under the GNU lesser general public license (LGPL) version 2.1. This option is exercised as long as the creator can comply with the conditions set out in the GNU LGPL version 2.1 license. This option is matter of strategy when it comes to protecting your libraries. Mainly, the LGPL does not protect your libraries from being used in proprietary programs while the following option does. Only allowing the source to be used in free programs prevents companies with a large amount of capital and development resources from competing against you with your own work.

The last licensing option is the GNU general public license (GPL) version 3.0. Most software packages are released under a general public license. This allows free software developers more strength against proprietary developers because there are many more free developers. By sharing the source the free software developers help each other outdo the proprietary counterparts.

Development of the DocBox software will be protected under a GPL license. This allows integration of currently available libraries as well as an opportunity to share developments with the community. For the development of a working model this license is sufficient because there is no need to protect the source that is developed. The program will not be distributed for a fee and shared on any other device other than the developing environment computer. Eventually, if the owners of DocBox decide to take their idea to the marketplace they will need to consider different licensing and developing options to protect them from competition.

3.5.7 Embedded Software The DocBox embedded software is the internal control of the system. Embedded software is the code loaded into the microcontroller memory. The software needs to receive control commands from the CPU, then execute the commanded process. An interrupt driven architecture is useful to accomplish this. The microcontroller waits in an idle state until interrupted by the CPU. The microcontroller then checks what should be done, executes the process, checks for more commands, and then returns to idle mode.

3.6 Strategic Components Although the general requirements have been specified earlier, there are a few components that are worthy of further discussion with respect to research. Such components required either significant design or modification due to the nature of the component.

3.6.1 System Enclosure

As discussed in Section 2.3.1, the system enclosure needed to be durable and secure from any tampering with the device. Although similar devices such as ATM’s and dispensing machines meet the initial security and dimension requirements, the factor of system components placement on the interior and

P a g e | 31

exterior of the box are extremely prevalent. The touchscreen display, for example, is larger than most ATM displays; therefore, if an ATM was to be utilized, a larger cutout from the box would have had to be made, which was not beneficial considering the high strength material used for the enclosure. An additional factor of the potential design was patent infringement with using an existing box design; therefore, Group 12 decided to present a new box design for DocBox. Consequently, with the Group 12’s focus on DocBox being with the design of electrical systems, the first generation prototype system enclosure did not meet the requirements of industrial robustness. This, however, could easily be changed if the task is given to a professional enclosure design company, or even a mechanical senior design group.

For the reasons mentioned, the project group decided to utilize a custom box design. The design played a strategic component within the entire product for the obvious fact that it is what holds all of the system components. The placement of components both on the interior and the exterior of the box played a very strategic role with respect to material cost, visual appeal, and ease of maintenance. These factors, and others, were all taken into consideration when designing the system enclosure, so as to utilize maximum efficiency and quality in the final product of the first generation prototype.

3.6.2 Dispensing and Collecting

Since dispensing and collecting of test tubes is the main function of DocBox, the design of the dispensing and collecting components was a vital part of the system. Although there already exists test tube dispensing devices, most either required too much space, were too expensive, or both. Therefore, Group 12 decided to design the dispensing unit, so as to effectively fit the unit within the compact space of the box. The strategy behind the design needed to involve the size and method of storing hundreds of test tubes as well as the ability to dispense discrete numbers of test tubes. Additionally, the dispenser needed to effectively scan each test tube, and deliver each to the user. The collection of test tubes was a much simpler design, with the main features being the ability for only the test tubes in plastic bags to be received and a sensor to detect such.

3.6.3 Bag Dispenser

In keeping with the specimen shipping requirements previously described in section 3.2.3, the DocBox dispenses a watertight, re-sealable plastic bag in which the sample vial(s) are to be placed. It is important for the bag to be dispensed along with the test tubes, as samples that are not in compliance will not be tested. The dispensing mechanism must be accurate as to reliably dispense the correct number of bags per number of samples – too little would result in untestable samples and too many would create a mess of unused plastic bags in addition to increase costs of replacing the wasted bags. In order to minimize these errors, a limit switch is utilized to monitor the number of dispensed bags and adjust accordingly by communicating to the CPU.

P a g e | 32

In researching methods of dispensing, the most attractive to the DocBox application were friction feed mechanisms. Friction feed machines use rollers that are driven by rotating cylinders to dispense from a stack of flat objects one at a time. This is used in numerous applications but probably most commonly recognized in home inkjet printers to move paper from a stack through the printer. Just about anything can be friction fed as long as they’re flat. The re-sealable bags will be the size of a business card and just as flat with nothing in it so it shall be able to pass through a feeder. The feeder’s motor control that drives the rollers could be controlled by the microcontroller which would be programmed to feed a certain amount of bags based on the number of tests ordered into a collection point where the user will be able to receive them. Although heavily mechanical, it could be easier to design and build a friction feeder than to find one for purchase as market friction feeders are generally specialized and expensive. Another method in dispensing a bag to the user is by keeping the bags in a locked compartment which would only be accessible when granted by the CPU (after a vial has been dispensed for instance). This option would be much easier and reliable as there are less moving parts but trusts the user to not steal or tamper with the bags. The bag compartment would have an access door that is normally sealed by a deadbolt lock that will be able to extend and retract given an electric signal. A linear solenoid converts electrical current into mechanical actuation and may be able to extend and retract a bolt. Solenoids consists of a ferromagnetic plunger within a current carrying coil that, once energized, creates a magnetic field that induces a pushing or pulling force on the plunger. Once de-energized, a spring attached to one end of the plunger pushes or pulls the plunger to their resting point depending on what type of linear solenoid is used. Pull type linear solenoids (Figure 11) are normally extended and retracts once energized (push type solenoids operate conversely).

Figure 11 - Cross Section of Pull-Type Solenoid

P a g e | 33

A disadvantage of traditional solenoids is that to actuate requires constant applied energy. This results in generation of heat which can damage the device. A latching solenoid holds the actuated plunger in place using no power providing a solution to the heating problem. This makes these solenoids ideal for prolonged actuation, which were desirable. In the scenario where the user takes a long time retrieving a bag or the door is obstructed from closing to lock, a latching solenoid would ensure the solenoid would not burn out. There are two types of latching solenoids; permanent magnet and residual magnet latching solenoids. Permanent magnet solenoids utilize a permanent magnet to hold the plunger in the actuated position once the solenoid is powered down. To release, or unlatch, a current pulse of opposite direction to the actuating current pulse is applied which causes the plunger to separate from the permanent magnet. A spring is still used to set the plunger to its resting, or unactuated, position. Residual magnet latching solenoids work in a similar fashion but do not use permanent magnets. The difference between the two is that while a permanent magnet latch can be latched manually, a residual magnet latch requires a current pulse to latch.

3.6.4 Environmental Control

As mentioned before, the samples to be tested are stored in a temperature controlled environment. Section 3.2 explains the medical standards and requirements for the sample storage environment. This section covers methods of achieving these requirements that are used in the project. Environmental control extending outside of the holder and into vital components, such as the CPU, is also discussed here.

3.6.4.1 Vapor Compression Refrigeration

Vapor-compression refrigeration was a natural choice in keeping the samples at the required temperature. This method is widespread and is commonly used in home refrigeration and air conditioners due to its relatively high efficiency and low costs. This method uses a refrigerant liquid to absorb heat from a cool area and expel it elsewhere through the laws of thermodynamics. However this method requires multiple parts including a compressor and evaporator, which can be space consuming. Refer to Figure 12 [17] for diagram of the vapor-compression cycle. The heart of the system is the compressor and is where work was put into. The refrigerant is pumped into the evaporator where heat is absorbed (cool area) and is taken into the condenser (hot area) where the heat is expelled. A type of vapor-compression refrigeration is the inverter control refrigeration. Typical refrigeration methods employ a fixed frequency compressor to cool an area. The temperature is controlled by running the compressor when temperature is too high and turns the compressor off when temperature is in between a suitable range. However, since the frequency is fixed, the compressor runs at full speed when powered on.

P a g e | 34

Figure 12 – The Vapor Compression Cycle

By using a variable frequency compressor and an appropriately designed controller, a given temperature can be reached by running the compressor at a high speed and maintained by running at a low constant speed. This constant low speed as opposed to the intermittent operation of the fixed frequency compressor is more efficient as it reduces energy consumption and audible noise while maintaining a more accurate temperature. Numerical simulation shows that this kind of operation can lead to energy savings of up to 30% [18]. Table 2 [19] is a table comparing energy consumption of a fixed frequency compression refrigerator/freezer and a variable frequency one.

Table 2 – Comparison of Energy Consumption of Fixed & Variable Compression Refrigerators/ Freezers [19]

Most compressors utilize AC motors. In order to vary the speed of an AC motor, the frequency of the input must be varied. To do this, a variable frequency drive (VFD) is used. These devices take in a three phase voltage input where it is rectified and converted to DC. The DC signal is then inverted back to AC and outputted as a pulse width modulated (PWM) signal with a frequency defined by

the operator via a controller.[20] Figure 13 is a schematic of a VFD. To vary the

PWM signal, the timing of closing the switches (transistors) is controlled.

P a g e | 35

Figure 13 – VFD Schematic

3.6.4.2 Thermoelectric

Thermoelectric cooling makes use of the Peltier Effect and was another option in controlling the holder environment. Advantages of this over vapor-compression are that it has no moving refrigerant, space saving, and is voltage or current controlled

(thus a higher degree of temperature accuracy). Table 3 [21] shows alternatives

to vapor compression technology. It was seen that the efficiency of vapor compression is far greater than thermoelectric. Though not as efficient, the advantages of thermoelectric outweighed the disadvantages in the DocBox application.

Table 3 – Alternatives to Vapor Compression Technology [21]

In regards to cooling the CPU, a system of thermo-controlled fans was sufficient enough. Similarly, personal computers commonly use a combination of fans and heat sinks to cool their CPU’s. However, fans do not provide cool air but simply circulates cooler air from the outside environment into the enclosure in order to cool components. Often heat that is dissipated from the CPU’s heat sink is then circulated out of the enclosure by another fan. A Peltier module (thermoelectric)

P a g e | 36

was an alternative way to cool the CPU especially if the outside air temperature is above the CPU operating temperature.

3.6.4.3 Temperature Sensors

In any case, temperature monitoring was imperative in this project. Therefore, temperature sensors in combination with respective cooling methods was implemented in multiple systems in order to maintain required temperatures. There are two main types of temperature sensors to choose from – contact and noncontact. As the name implies, contact temperature sensors physically touch the object they are to measure and non-contact temperature sensors measure thermal radiation of heat sources from a distance. Types of contact temperature sensors include thermocouples, thermistors and resistance temperature detectors. Thermocouples make use of the Beck effect to measure differences in temperature dependent voltages which it then converts into a temperature reading (as high as 2750C and low as -250C) [22]. These are popular due to being inexpensive, durable, rapid response time, and they do not require a battery. However, substantial conditioning is necessary to convert the thermocouple voltage into a usable temperature reading. Since the voltage generated by the thermocouple is small and nonlinear, it is difficult to transform the signal into an accurate temperature reading [23]. Thermistors are also inexpensive, durable and are made of semi conductive material whose resistivity is sensitive to temperature. Depending on the type of thermistor (+k or –k), resistance of these materials increase or decrease with increasing temperature. This change is predictable and is how thermistors are able to measure temperature. Often, thermistors are also used as current limiters and overcurrent protectors. However compared to thermocouples and resistance temperature detectors, thermistors have the narrowest measuring range, lowest stability and linearity, and are highly sensitive. On the upside, they are the least expensive and provide a robust signal [24]. Resistance temperature detectors or RTDs are sensors with a resistor whose value changes nearly linearly with temperature change (-200C to 850C). These are known to be more accurate than thermocouples and are stable but have a

smaller temperature range [22]. Figure 14 shows the resistance versus

temperature relationship of a 100 ohm RTD. As shown, the relationship appears very linear but in actuality is slightly curved. However, in the small temperature range that the DocBox operates in, one can assume a linear relationship.

P a g e | 37

Figure 14 – RTD Resistance Vs Temperature [25]

Infrared sensors are the main non-contact sensor used in DocBox. These sensors pick up infrared radiation signals generated from heat and convert them into electric signals which are then computed as a temperature. Typically, infrared sensors are used when the temperature of the object to be measured are too far or dangerous for contact sensor usage. With a large range of measure (-70C to 1000C) [25] and more complex technology, infrared is expectedly more expensive. In choosing a temperature sensor for the DocBox application, reliability and accuracy were key factors. A resistance temperature detector may have been a good choice due its wide range and accuracy. However an infrared sensor would be able to monitor a wide area of the chamber and may be a better choice. Testing of the resistance temperature detector in the chamber would be conducted to conclude if whether this sensor would be sufficient. For cooling of the CPU a thermocouple or thermistor hooked up to a voltage or current switch controlling a fan to air cool the device could suffice. Also available for purchase are CPU cooling units that are used in personal computers.

3.6.5 Dynamic Component Control

With respect to the dynamic hardware, several control methods were taken to efficiently run the entire system. The two main considerations for the hardware control were Microcontrollers and Field Programmable Gate Arrays (FPGA’s). An entire computer system was not considered due to the desire to keep the system in the fastest possible working conditions, in other words: to leave the majority of the dynamic component processing to external devices (microcontrollers and FPGA’s). The main strategy in component control was in choosing which type of

P a g e | 38

device to use, preceded by the model that would provide the fastest control while maintaining accuracy. Since FPGAs are used for the purpose of faster responses based off of logical circuitry, the initial strategy was to use an FPGA for the control of the dispensing and collecting unit; whereas a microcontroller would be used for the control of the air conditioning unit. These factors, and many others, were taken into consideration for the controller design, which method was decided on and is further discussed in Section 4.1.2.

4 Project Hardware and Software Design Detail

The DocBox system as a whole requires much design with respect to both hardware and software. Throughout this section, the design of the several components that cause the system to function as a whole is written in detail.

4.1 Hardware

4.1.1 System Enclosure

The DocBox system enclosure shall be robust, able to withhold industrial use, a visually appealing. As mentioned in Section 2.3.1, the exterior of the box shall meet the dimensions of 20”x20”x54”, with an angled top face for the user interface to fit within the 14”x11¼” cutout. Two additional cutouts of the top frame shall be used for the dispensing and collecting chutes. These dimensions are depicted in Figure 15. The front faces of the enclosure shall be able to open for maintenance purposes; this shall be done by two hinged faces on the bottom of the interface panel, and on the left edge of the dispensing/collecting face of the enclosure.

4.1.2 Motor and Sensor Control

Since the DocBox system contains multiple motors to control, Group 12 decided to utilize a microcontroller to process the main control signals for each of the motors, as well as the respective feedback sensors.

4.1.3 User Interface

The following display unit is used for the DocBox user interface. This is a product from Elo Touch Systems that provides display and touch response functionality in one encapsulated unit. The Elo Touch Systems 1541L has a convenient, space-saving design that makes it perfect for a kiosk application.

The 1541L features an injection molded bezel with a virtually invisible water-

resistant seal, making it a great choice to withstand the rigors of public use. The

display panel is LCD type that is high quality and LED backlit providing a high

resolution with less power consumption. The touchscreen technology is

AccuTouch 5-wire Resistive. The display has a wide viewing angle of 170° x 130°.

Table 4 provides a detailed specification for the 1541L touch system. [26]

P a g e | 39

Figure 15 – DocBox System Enclosure

Table 4 - 1541L Touch System Specifications

P a g e | 40

4.1.4 Dispenser

In the overall view, the dispensing unit plays a pivotal role for the entire system. The following are the specifications toward the hardware design of the dispensing unit.

4.1.4.1 Order of Operations

To further understand the design of the dispensing unit, the top level order of

operations of the unit is specified below and further depicted in Figure 16

1. Dispensing roller rotates to dispense single test tube onto dispensing chute.

2. Roller rotates test tube to expose barcode that is read by the barcode

scanner.

3. (a) Barcode scanner returns a positive scan of test tube: Rotate dispensing chute counter clockwise to drop test tube onto the tongue which will deliver the test tube to the user. (b) Barcode scanner cannot obtain positive scan of test tube after 5 seconds: Rotate dispensing chute clockwise to drop test tube into discard box.

4.1.4.2 Test Tube Dispenser “Boot”

The overall purpose for the boot is to efficiently store a goal of five hundred test tubes that can be discretely dispensed without jamming. The design approach taken by Group 12 is for the boot enclosure to have two (2) openings: the loading door at the top of the boot, and the dispensing slot at the bottom. The loading door at the top of the boot is to be used to load more test tubes into the boot; this door will go across the entire length and width of the top of the boot, so as to provide easy access for loading. The dispensing slot shall be located in the bottom corner of the boot, and shall be slightly larger than the dimensions of the test tubes so as to only allow one test tube to fit through the slot at a time without jamming. To enable the gravity feeding of the test tubes, the bottom floor of the boot shall be sloped toward the dispensing slot at a 9.46o angle.

The dimensions of the boot shall be arranged in such a way so as to allow a uniform test tube orientation, to prevent jamming and to allow for efficient space management. Since the test tube dimensions as mentioned in Section 2.3.2, the width of the boot shall therefore adhere to the length dimensions of 2.25” of the test tubes. So as to meet the required maximum of five hundred test tubes, the length of the boot shall adhere to the length of the DocBox enclosure (20”). Given the length parameter of the boot, as well as the diameter of the test tubes, the height dimensions of the boot can be found in order to meet the required test tube amount.

P a g e | 41

Figure 16 – Dispenser Operation Diagram

Since the width of the boot shall simply accommodate the length of one test tube, the problem of finding the total number of test tubes can be reduced to the cross section of the boot, looking only at the length and height. The calculation shall be looking at a cross section that does not include the angled bottom of the boot. Figure 17 shows the cross sectional view of the boot that is analyzed to obtain the required height of the boot to allow a 1000 test tube capacity. With the following definitions of each of the parameters, in inches, in Figure 17, the cross sectional area of the boot is found:

L = 18” H’ = 3” d = 0.5”

𝐴 = 𝐿(𝐻 − 𝐻′) + 𝑑(𝐻′) +1

2(𝐿 − 𝑑)𝐻′ ( 1 )

A = 18H – 26.25

Since the total cross sectional area of the boot needs to contain the required 1000

cross sectional test tube areas, the boot height can be found as follows:

“Boot”

Barcode Roller

DOC BOX

Outer Wall

2

3a

Dispensing

Chute 3b

Discard

Box

P a g e | 42

Figure 17 – Boot Dimensions

𝐴

𝜋 (1

2𝑑)

2 = 1000 ( 2 )

H = 12.37 12.5”

Since the test tube length is 2.25”, the width of the boot shall therefore be set at 2.3”. The final design dimensions of the boot shall therefore be 18” x 2.3” x 12.5”

on its highest side, and 18” x 2.3” x 9.5” on its shortest side. Table 5 lists the final

dimensions of the boot (dimensions in inches):

Table 5 – Boot Dimensions

The boot shall be made from sheet metal so as to maintain durability, and be held within the interior brackets of the DocBox enclosure so as to be removable for refilling while consistently lining up with the dispensing roller.

4.1.4.3 Dispensing Roller

Located directly beneath the exit slot of the boot, the dispensing roller shall provide

the means for discretely dispensing test tubes. As depicted in Figure 16, the cross

sectional depiction of the dispensing roller shall depict ¾ of a pie chart. The 90o cutout from the roller shall be the correct size for a single test tube to fall in to when the cutout is facing vertically upward; hence allow a single test tube to be dispensed by the time the roller spins 180o. Therefore, in order to provide enough space to collect a single test tube, the radius of the roller must at least be a minimum of 1.25 times the diameter of the test tube. Additionally, so as to prevent the potential sliding/popping out of the test tube before leaving the boot, the Dispensing Roller shall be either made from or contain a material that provides a

H

L

H’ …

d

P a g e | 43

tacky surface. The roller shall be moved by means of the motor described in Section 4.1.4.6.

4.1.4.4 Dispensing Chute

Within this section, the Dispensing Chute shall additionally be referred to as the “Chute.”

The dispensing chute shall be located directly below the dispensing roller and shall act as a means for the dispensed test tubes to roll to the internal barcode scanner. The Chute shall be pivoted by a low torque motor on the initial landing end, and shall have a resting angle of 1.8 degrees below horizontal, which shall provide a ¼ inch vertical drop. The length of the dispensing chute shall be eight (8) inches, and shall end at Barcode Roller. Additionally, directly below the dispensing roller, the Chute shall have a contact switch that shall act as a means to verify that a test

tube has been dispensed. These dimensions are shown in Table 6.

Table 6 – Dispensing Chute Specifications

The Barcode Roller is the second section of the dispensing chute, which shall rotate towards the dispensing chute when the test tube dispense verification switch is triggered. The barcode roller shall continue to roll until the barcode scanner retrieves the barcode from the test tube. The barcode roller shall have a 0.25 inch radius, and shall have a containing barrier directly above in order to prevent test tubes to pop over the roller.

Upon rolling the test tube, two possible outcomes may happen: the barcode is read, or the barcode is not read (due to manufacturing discrepancy). Therefore, the dispensing chute shall have a bidirectional pivoting function in which the test tube shall either be dispensed or discarded. Upon receiving the barcode verification signal, the dispensing chute motor shall pivot the chute down (counter clockwise) 4 degrees (0.56” vertical drop) so as to allow the test tube to be delivered to the tongue for customer retrieval. After completing the pivot, the dispensing chute shall pause for 0.5 seconds before returning to its initial position. Upon receiving the test tube faulty signal, the dispensing chute motor shall pivot the chute up (clockwise) 4 degrees so as to all the test tube to be discarded in a

bin. The layout for the dispensing chute can be seen in Figure 16, and the control

circuitry and software for the chute and roller motors can be seen in Section 4.1.2.

4.1.4.5 Dispenser Barcode Scanner

To provide a fast, yet accurate reading of the barcodes on the test tubes, the barcode scanner is capable of reading barcodes within the range of 0.25” to 2.25”.

P a g e | 44

4.1.4.6 Dispensing Motors

The motors used for the dispensing chute, dispensing wheel, and dispensing roller shall all be controlled by their own motors. All three components shall be driven by a Sayama 12SM-AT3 12 volt, 58 max RPM, DC brushed motor, as mentioned in Section 6.1. Due to the large voltage with respect to the microcontroller, each motor shall be driven by a motor control circuit that shall provide the means to supply the required voltage to rotate each motor in the required orientation and RPM. For both the dispensing and barcode scanning rollers, the driver circuits shall be variable so as to adjust the RPM of the roller shows the feedback voltage regulation circuit that shall supply to required voltage to the motors when turned

on by the microcontroller switching circuit shown in Figure 20.

Because simple brushless DC motors are being used, the speed can be altered with an adjustable linear regulator (LDO). This is because of the linearity of its field strength with respect to the armature voltage. The desired range for each of the dispenser motor shall be no less than 20 RPM and no greater than 40 RPM. Since the motors are rated for 58 RPM at 12v with a drop out at 1.5v, a plot can be made

to estimate the speed vs. voltage which is shown in Figure 18. The linear equation

is estimated as shown in equation 1. From the graph below, it is clear that the adjustable regulator should be designed to pass 9V (40RPM) down to 5v (20 RPM). A negative feedback configuration operation amplifier will be used with a zener diode voltage reference to regulate a 12v power supply. The configuration

for the regulator is shown in Figure 19.

𝑅𝑃𝑀(𝑉) =58

12 − 1.5(𝑉 − 1.5) ≈ 5.524𝑉 − 8.286 ( 3 )

Figure 18 – Dispenser Motor Voltage Vs. Speed

P a g e | 45

Figure 19 – Adjustable LDO Voltage Regulator

As shown above, the op amp determines the current into the base of the Darlington pair. If the output voltage seen through the resistor divider network of R5 and Rv rises above the reference voltage, the amplified error restricts the current flow to the output load until equilibrium is reached. In order to set the voltage reference value, the zener diode must be reverse biased to the breakdown point with a sufficient current for stability. According to the Fairchild datasheet, the 1N4733A holds a steady 5.1v reverse bias when Iz = 49mA [27]. In order to provide this current, a 141Ω resistor Rz is placed between the 12v power supply and the cathode. Since the typical input bias current to the non-inverting terminal of the op

amp is in the order of pA, the current through the zener diode is given as: 𝑰𝒛 ≈𝟏𝟐−𝟓.𝟏

𝟏𝟒𝟏≈ 𝟒𝟗 𝒎𝑨. The output voltage is directly determined by the voltage divider

circuit composed of Rv and R5. Rv is a 10kΩ potentiometer which can be changed to adjust the output voltage. The output voltage expression is given in equation.

𝑉𝑟𝑒𝑓 = 𝑉𝑜

𝑅5

(𝑅5 + 𝑅𝑣) → 𝑉𝑜 = 𝑉𝑟𝑒𝑓 (

𝑅5 + 𝑅𝑣

𝑅5) ( 4 )

For the upper limit of 9V on the output, Rv is set to its maximum level of 10kΩ and equation (2) yields equation (3).

𝑽𝒐(𝒎𝒂𝒙) = 9 = 5.1 (𝑹𝟓 + 10𝐾Ω

𝑹𝟓) → 𝑅5 ≈ 13𝐾Ω ( 5 )

P a g e | 46

If the potentiometer is turned all the way down to zero, the output is driven to the reference voltage. This effect is shown in equation (4).

𝑽𝒐(𝒎𝒊𝒏) = 5.1 (𝑹𝟓 + 0Ω

𝑹𝟓) → 𝑽𝒐(𝒎𝒊𝒏) = 5.1 𝑉 ( 6 )

With the adjustable power supply designed, a control stage need to be built to interface with the microcontroller board. This design is shown in Figure 20. When the system signals for a motor rotation, the output stage of the microcontroller sends a signal sufficient to activate an opto-coupler. This allows current to flow from the regulator to R2 which biases the base of Q3. This is a Toshiba N-Channel MOSFET model number SSM6N36FE which can allow 100mA of current from drain to source with Vgs at 1.8V. [28] With the MOSFET on, the current can flow through the 600Ω motor coil to ground. The motor will rotate continuously and at a constant speed until the control signal goes low. When the motor is switched off, the electric field produced by the coil windings creates a reverse voltage as it collapses. The snubbing diode D1 acts to shunt any back EMF from causing harm to the components. The complete list of components used

in this circuit are shown in Table 7.

Figure 20 – Dispenser Motor Driver Switching Circuit

Table 7 – Component Specifications for Motor Driver Switch Circuit

Unlike the two motors used for the dispensing and scanning rollers, the dispensing chute shall be able to tilt both clockwise and counter clockwise; hence a the circuit

shown in Figure 21(with component values specified in Table 9), which utilizes the

SN754410 Motor Driver that will allow the state of the tilter motor to be changed

P a g e | 47

by the two logic pins (pin 2 and 7). The enable input for the SN754410 is located on pin 1, and, for component efficiency/durability, shall not be permanently enabled, but enabled by the microcontroller. Therefore, a total of three I/O pins to

connect to the microcontroller shall be required. Table 8 shows the truth table for

the logic pins, and the corresponding motor state, given that the enable input is high. For this circuit, the logic high signal from the microcontroller (3.3V) translates to an internal logic high of 5V.

Table 8 – SN754410 Logic Input Truth Table (High = 5 v ; Low = 0v)

Figure 21 – Tilt Motor Driver Circuit

Table 9 – Component Specifications for Tilt Motor Circuit

P a g e | 48

4.1.4.7 Dispenser Sensors Within the dispenser, there is one specific style of sensor used for two different applications. The sensor is an optical sensor that utilizes a Vertical Cavity Surface Emitting Laser (VCSEL) to turn on a phototransistor; changes in the state of the transistor current shall be sensed by the microcontroller. The components used for the photo detection are the OPV332 VCSEL which typically emits a laser light of wavelength 860nm and the OFT-5301 Phototransistor, which has a spectral sensitivity of 80% for the range of wavelengths from 700nm to 1000nm. These two

elements are both used within the photo sensor circuit shown in Figure 22, with

each element described in Table 10.

Figure 22 – Photo Detection Circuit

Table 10 – Component Specification for Detection Circuit

The resistor values chosen are based off of the current-voltage specifications for the OPV332 and OFT-5301. The OPV332 has a typical forward current of 7mA and maximum forward voltage of 2.2V; similarly, the OFT-5301 holds a collector-emitter saturation voltage of 0.3V at a current of 2mA. It is noted that the 18 ohm resistor (R1) is rated for a half watt due to the dissipated power from the required

current draw from the IR LED. The detection circuit in Figure 22 is used for test

tube dispense verification, in which the laser light shall always be in contact with the OFT-5301, the beam shall be below the dispensing wheel. When a test tube is dispensed, the light beam shall be broken, which shall then be interpreted by the microcontroller as a successful dispensing of a test tube. These configurations can be seen in the dispenser diagram in Figure 16.

P a g e | 49

4.1.5 Bag Dispenser

The bag dispenser subsystem consists of multiple circuits that will be explained in this section. While highly mechanically functional in design, these aspects, though important, will only be touched on since the focus of this project is on the electrical components of the system.

4.1.5.1 Lock

The plastic bags are stored in a compartment secured by a locked door. The lock is made of a steel bolt that sits within a catch when the hatch is closed and is able to actuate out of the catch via a linear pull type solenoid allowing the hatch door to

open freely (refer to Figure 43 for an illustration). This solenoid when not powered

is normally extended and is electrically controlled by the microcontroller – a logical “1” (high) will be assigned to the actuating, or unlocking, operation and a logical “0” (low) will be associated to the extended armature, or locked, position. After a test tube has been dispensed and the saliva sample is ready to be returned, the user will be prompted by the interface to input the command to unlock the dispenser hatch in order to retrieve a bag. The microcontroller will be programmed to send a 1- signal to the solenoid that will unlock the hatch for 20-30 seconds – long enough for one to procure a bag from the compartment (testing will be conducted to gauge an appropriate time limit which is subjective). Figure 23 illustrates the circuit that will drive the solenoid. The 0-3.3 volt source is the signal from the microcontroller. When driven high to 3.3 volts, the NPN bipolar transistor is “switched” on and allows current to flow through the collector terminal which powers the solenoid (represented by R3). The voltage supplied to the solenoid is based on the collector voltage (V1) and is very close to its value. An LED is placed in parallel with the solenoid and will indicate when the door is unlocked (on). Since the solenoid is essentially an inductor, the diode D1 in series with the LED aids in the function as a flywheel diode in order to dissipate power and protect the transistor from residual energy stored in the solenoid which can be damaging. After the hatch has been unlocked for the allotted time, the user will be prompted with the option to continue the service process or request more time to obtain a bag. If more time is requested, the solenoid will actuate and the hatch will be unlocked for an additional 15-20 seconds. This process will repeat until the continue option is selected.

The flow diagram shown in Figure 24 illustrates this process. The duration of

solenoid actuation is important to note since overheating is a concern. An important factor in choosing a linear solenoid is the maximum duty cycle it is rated for given the maximum ON time before the solenoid is susceptible to damage from heat generated in the coils. Running a solenoid at higher duty cycles results in lower operating power thus a lower actuating force. In contrast, running a solenoid in a short time interval, or low duty cycle, one can operate the solenoid at a high power which in turn results in a higher actuating force. For the locking mechanism, a high pull force is not necessary as the load of the armature will essentially just

P a g e | 50

be the weight of the armature (or lock bolt) itself. Therefore it is possible to operate the linear solenoid at low power for long periods of time which is desirable.

Figure 23 - Locking Circuit

Figure 24 - Bag Dispense Flow Diagram

P a g e | 51

Although the solenoid will only be powered for about 20 seconds, heat generation should be avoided to prolong component reliability and life. With that said, the lock circuit will be designed to be low power – sacrificing high pull force for low heat generation. To calculate for low power consumption in the solenoid, the current draw of the solenoid will be determined from the specification sheets. A look at the pull type linear solenoid C5-273-B-1 from Ledex shows that at 100% duty cycle at maximum holding force, the solenoid draws about 3 Watts at ambient temperature (20 C) with a nominal voltage of 3V and resistance value 2.88. By ohms law, the current to the solenoid is about 1 Amperes which in the designed circuit in Figure 23 is high. The circuit will deliver about 3V to the solenoid but the current is in the milliamp range so the power will be less than 3W. Testing of the solenoid will be conducted to determine if the power delivered is sufficient enough to actuate the bolt. If not, the circuit design must be tweaked to increase the current delivered to the load. A Darlington transistor may be used to amplify the current.

4.1.5.2 Bag Supply Sensor

The bag supply will be monitored by a system that measures the position of a mechanical actuation (spring loaded plate). For a visual of this system, refer to Figure 45. As bags are taken out of the dispenser, the spring loaded plate slowly advances - pushing the stack of bags towards the opening of the compartment. An extending rib attached to the spring plate will travel along the underside of the dispenser and physically trip a strategically placed momentary - normally open switch. Once this switch is tripped, 3.3V appears on a microcontroller input pin signifying that there are no more bags within the system. Pushing the dispenser plate back with allow the switch to reopen. At this time, the microcontroller input pin reads ground. Since inputs are inverted, a high signal read by the microcontroller side means there are sufficient amount of bags in the dispenser and vice versa.

4.1.6 Collector Once a user has deposited their saliva sample into a provided test tube, the next step is to return it to DocBox where it will await authorized transportation to the testing facility. The subsystem which handles this return process is called the Collector.

4.1.6.1 Order of Operations

In order to visualize the role of the collector, a high level order of operations is

listed below and further depicted in Figure 25.

1. The system performs a status check.

a. If there are no bags, the microcontroller flags the CPU.

b. If there is a blockage detected, the CPU is flagged. The

microcontroller then returns to idle.

P a g e | 52

c. If neither, the microcontroller returns to idle.

2. Bag Dispenser door un-locks and screen prompts the user if a bag

is required, otherwise press “Continue.” Then lock door.

3. Unlock Collector door and prompt user to deposit bag with test tubes.

4. The internal return sensor scans the bottom of the chute and the microcontroller waits for a break in the optical beam.

5. a. If the system detects a return (break in beam), the user is notified

that they have made a successful return via the main system display and the locks are closed. The system is then returned to idle. b. If the system does not detect a return before the allotted time, the doors are locked and the system returns to idle.

Figure 25- State Diagram of Collector Operations

At the beginning of the collect sequence, two outputs are set in order to unlock the bag door and collector door. These outputs energize two solenoid actuators (Section 4.1.5.1) In order to detect when a test tube sample has been returned or if the bin is full, the MSP430 reads an input line from an optical sensor during the status check and return state. If there is any disruption of the beam over the holding bin, the MSP430 sets a flag and alerts the main CPU. Figure 26 shows how the MSP430 detects an optical disturbance.

P a g e | 53

Figure 26 - Optical Capacity / Return Sensor

4.1.7 Holder

The holder will be the area in which the saliva samples are kept to await transport to the testing lab. It will be an insulated, air and light tight chamber with temperature control to preserve biological sample integrity. This subsystem consists of two main components – the cooling unit and temperature control. This section will explain design details on these components and their operations.

4.1.7.1 Temperature Control

To regulate the temperature inside the holder, a circuit will control the power to the cooling unit. This circuit is discrete and uses no input from a microcontroller. This control circuit takes in a feedback signal from a temperature sensor and decides

whether to close or open the switch to the cooling unit’s power. Figure 27 is the

designed circuit for the temperature controller. The following will go into detail the functions of each component. In deciding what component to use for a temperature sensor, the LM35 was chosen for its linear output proportional to temperature (10mV/˚C). This makes calculations very easy. The sensor output is fed into the positive input of the LM293 precision comparator which is set up in a non-inverting comparator with external hysteresis configuration. On the negative input pin, a voltage referenced from a divider circuit is seen. This voltage will be calculated to correspond to the temperature that it is desired to have the hysteresis thresholds centered about. The non-inverting configuration of the comparator makes it such that when the output of the LM35 is above the high threshold (calculated by (7)) the comparator output is also high, and low when sensor output is below the low threshold (8). This can be thought of as positive logic. The comparators output drives an N-channel enhancement mode MOSFET which is used in conjunction

P a g e | 54

with another MOSFET which in turn forms an “AND” gate that controls the power to the cooling unit.

The timer is a TLC555 chip from Texas Instruments© which provides a delay of about 3 – 5 minutes once the cooling unit turns off before it can once again be powered. This is in order to prevent damage to unit’s compressor as it needs time to decompress at shut off. It is this device that controls the other input of the MOSFET transistor “AND” gate. The 555 is in a monostable or one shot circuit configuration. To start the timer, the 555’s trigger pin looks for a high to low pulse so this will be tied to the comparator’s output. Once the comparator output goes low from a high state, this signals a shutoff of the cooling unit thus triggering the 555 delay. This delay can be calculated with (9). While in the delay state, the 555’s output is high. Therefore, the 555 output is simply inverted with a transistor. After the delay, the transistor under the control relay is able to be driven back to saturation. In essence, control relay to the cooling unit can only be thrown if comparator output is high (temperature above the high threshold) and 555 is not in the timing delay state (cooling unit has been off for 3 – 5 minutes).

Figure 27 - Temperature Control Circuit

(7)

(8)

(9)

P a g e | 55

The cooling unit will be off otherwise. The flow diagram of this system can be seen

in Figure 28.

Figure 28 - Temperature Control Flow Diagram

4.1.7.2 Cooling Unit

The cooling unit will be that to a small home refrigerator. It will consist of a compressor to pump refrigerant liquid through series of tubes that allow the refrigerant to absorb heat in one place and expel it in another. The temperature controller will signal this cooling unit to either turn on when temperature is outside the desired range or turn off when the temperature is in the target range. The objective for the cooling unit is to have enough cooling capacity to able to cool the holder to the target temperature in a reasonable amount of time and be rugged enough to withstand intermittent switching. Another important factor to note is the current draw of the cooling unit – more specifically the compressor motor. To size for the compressor, the area it has to cool is observed. The cooling area will be about 12in x 12in x 12in or about 1700 cubic inches of space the cooling unit has to cool. This is the size of a small miniature refrigerator so a similar compressor of a mini-fridge will be used. A goal for this compressor is to be reliable and not have to be serviced often. There are a couple types of compressors

P a g e | 56

available on the market but the most attractive option for the DocBox application is the hermetic type compressor which is commonly found in home refrigerators. A hermetic compressor houses the compressing mechanisms and the driving motor in the same unit. This prevents leakage of oils and refrigerant but sacrifices the ability to be opened and serviced. The compressor will be AC powered by the mains at 115V-120V. Based on the spec sheet of the compressor chosen, circuitry will be designed to ensure the compressor is receiving proper power. Also, a GFCI on the cable to the mains power will be considered to protect against potentially dangerous ground faults as this device draws the most power. It is desired to specify a compressor that will have enough cooling capacity to cool the holding area from room temperature of about 70°F to the target temperature of about 38°F in less than 5 minutes running at full capacity. The compressor may also feature thermal protection in which if the compressor is running too long and reaches a threshold temperature, the compressor motor will shut off until the compressor is at operational temperature again. If not included, a thermal circuit breaker will be used in order to protect the motor. This is in case of the event in which the temperature sensor fails or the access door of the holder is accidently left open which would cause the compressor to run continuously. Though the temperature control will have circuitry to prevent the motor to run if the temperature sensor reads zero, any way to protect the compressor will be employed as it is an expensive component to replace.

4.1.8 Microcontroller

4.1.8.1 Microcontroller and Circuit Board Design

The microcontroller selected interfaces to the test tube dispenser, collector, and bag dispenser subsystems as well as the main CPU. In this section, a microcontroller is chosen based on the system hardware specifications and the embedded circuit boards are designed.

4.1.8.2 Choosing a Microcontroller

With the hardware details described, a microcontroller is chosen that will accommodate the necessary I/O, analog to digital conversions, and serial protocol.

Table 11 shows the peripheral hardware that connect to the microcontroller and

the requirements for each interface. Based on the requirements shown below, the Texas Instruments mixed-signal microcontroller MSP430G2553 28-pin package has been selected. This allows an addition 9 I/O should the design need modification.

4.1.8.3 Microcontroller Circuit Design

The MSP430 connects to the components that drive the I/O and serial interface as well as the power supply and noise filters.

P a g e | 57

Table 11 - Microcontroller Requirements

However, before all of the components are connected, the power needs are analyzed. Each part has a finite range of operation parameters such as input/output current, input/output voltage, transient load ratings, frequency response, voltage surge performance etc. Considering these restraints will allow the appropriate power components to be selected. The microcontroller requires the most precision with regard to electrical interfacing therefore its specifications are examined first. Table 12 outlines the critical electrical parameters of the MSP430. From the data shown below, an initial power diagram is created as shown in Figure 29.

P a g e | 58

Table 12 - MSP430G2553 Electrical Characteristics [29]

Figure 29 - MSP430 Power Diagram

P a g e | 59

With the MSP430 properly powered, the peripheral devices can be connected. There are 8 pins on the chip that are designated for driving an output. Because the MSP430 is current limited to 6mA per pin and interfaces with higher voltage components, a level translator was designed to drive the higher power outputs. Figure 30 on the next page shows the 3.3v to 5v general purpose level translator schematic. The circuit uses NPN transistor switching to drive a positive logic scheme with a very small input signal. When the base of Q1 is driven high to the point of saturation, the base voltage of Q2 drops below the turn on voltage and drives Q2 into cut-off mode. This causes the output of V02 to go to Vcc. If Q1 is driven low, the base of Q2 is saturated and causes V02 to drive low. The base resistor value Rb1 allows only a few µA of current draw from the MSP430.

Figure 30 – General Purpose Output Buffer / Level Shifter

For the pins that control the 12V motors, a special form of this circuit is implemented as shown in Figure 31. This device allows for separation of the ground planes between the clean logic power and the noisy brushed motor power. This decoupling method is preventative against unpredictable embedded software malfunction. This opto-coupler is defined in the Dispenser Motor section. When Q1 is driven on, Q2 is off. This causes a voltage division across the LED side of the opto-coupler. The resistance and forward voltage drop have been considered to ensure 20mA of current flow through the LED. In order to receive analog inputs, the 5v signal voltages are translated to 3.3v in order to protect the MSP430. In Figure 32, a basic NPN transistor is used as an inverting buffer. This is a good feature as it allows the input pin of the MSP430 to be normally high. An input signal of 5V turns Q1 on driving the input to the microcontroller low.

P a g e | 60

Figure 31 – Microcontroller Opto-Isolation Interface

Figure 32 – Microcontroller 5v to 3v Input Buffer

P a g e | 61

4.1.9 PCB Design

As discussed earlier in Section 4.1, there is specific circuitry required for the microcontroller, switches, and motors; although the development environment for such circuits utilized breadboards and other means of being able to tweak circuitry, the final design for the control of the motors, locks, and sensors utilized a custom Printed Circuit Board (PCB). The purpose of the PCB was mainly for greater reliability, in that each of the leads are isolated from each other, and each of the circuit components are firmly soldered to board for a longer lasting quality.

The design of the PCB was compiled using Computer-Aided Design (CAD) software. The formulating of PCB’s presented multiple design challenges such as: trace width, trace spacing, layers, component packages, and component placement. These few considerations are by far not all that presented a challenge in the design, yet these are the main design challenges that are discussed in more detail below:

Trace Width: The main consideration with trace width is to be able to effectively provide the correct amount of copper to supply a given amount of current. Since the maximum current required for the components on the circuit is for the solenoids and motor drivers, these current were therefore a limiting factor. Since the motors specified in the hardware design section of this paper require greater than 130mA but less than 170mA, the design for the board utilized traces greater than 10 mils but less than 16 mils. With such trace thickness, the traces of the dispenser PCB sufficiently support the required current draw of the motors, sensors, and controllers without causing any melting or burning. With respect to the solenoid current draw, although only one solenoid is on at a time, the trace width for the locking circuits is rated to support the current draw as if both were on, which is a current of 2A.

Trace Spacing: With respect to the trace spacing, considerations of electromagnetic interference/coupling were taken into account to minimize the likelihood of unwanted electrical interference from other traces or components on the board. For the given current requirements, the software used allots space on either size of the trace that is of equal thickness of the trace as “neutral zone.” This additionally serves as a means to verify that there are no connections between the traces.

Layers: An especially useful feature of PCB’s is the ability to have multiple isolated layers on the board that can have interaction due to vias (holes to a specific layer), the PCB designed for DocBox is a two layer PCB. As is customary in most PCB designs, the Dispenser PCB contains power plains/traces which is surrounded by a grounding plane. The benefits to having ground between all traces is to decrease any potential noise discrepancy between any points on the PCB; additionally, the plane allows multiple components to easily access ground without having to run additional traces.

P a g e | 62

Component Packages: As should be suspected, many components come in different variants, which includes packaging. The main features of packaging that were considered with PCB design are the lead connection types, and the package size. The main versions of lead connection are either pin or surface mount. For the majority of the components used in the PCB design, surface mounting was used; this is to encourage less vias in the PCB, as well has reduce the size of the board itself since surface mounted packages generally are smaller than through-hole packages. It is noted that for the design-testing phase of the project, pin variants of the surface mounted components were utilized so as to provide a simpler way to connect to a development breadboard, yet when the PCB was populated, the surface mount variants of some packages were used.

Component Placement: Last, but certainly not least, is the component placement. The location of each of the components had an effect on the PCB design for the reasons of electromagnetic interference, current draw, and board size. Determining the placement of each component was done with respect to the centrality of the component (it is used often by many other components) as well as the physical size. For the dispenser PCB, centralized components include the MSP430 microcontroller, TL084 Quad-Operational Amplifier IC, and the MCT6S Dual-Optocoupler IC. These components are “centralized” due to the fact of their multiple pins that are utilized by various sections throughout the PCB. In addition to the centralization, components were placed in such a way so as to provide the shortest trace path with minimal changes in direction, so as to discourage noise and power dissipation effects.

Taking into consideration the five challenges previously discussed, the circuits within Section 4.1.4 were then utilized to compose the Dispenser Motor Control and Sensor I/O PCB shown in Figure 33. Within the design, the board is split into the main sections of: Rs-232 Serial Communication, sensor I/O buffers, motor control, motor voltage regulation, and solenoid lock control.

With each of these factors considered in the design of the Printed Circuit Board for

the dispenser unit of the DocBox, the final PCB design shown in Figure 33 was

utilized successfully to perform the tasks of controlling the three motors for dispensing (Dispensing “Pacman” Roller, Scanning Roller, and the Tiling Dispensing Chute). It is noted that the PCB was designed and printed early into the second semester of the project, which allowed the members of Group 12 to realize design flaws (insufficient microcontroller pins broken out, and traces that were not connected), make the revisions, and order a second PCB with sufficient time to test the entire system.

P a g e | 63

Figure 33 – Dispenser Printed Circuit Board Layout (Top: Red, Bottom: Blue – dimensions in mm)

P a g e | 64

4.1.10 CPU

A regular desktop PC is a perfect choice to meet the needs of the DocBox. The PC chosen contains all the necessary hardware to integrate the subsystems together. Many desktop PCs contain the necessary hardware so cost was the driving factor in the choice. A refurbished Gateway AMD dual-core Processor PC is chosen for the job. Table 13 describes the specifications for the unit.

Table 13 - PC Specifications

Many desktop PCs do not contain serial ports anymore. A simple serial port card can be inserted into the PCI expansion slot to provide serial ports to the computer. Serial ports are necessary for exchanging data between the PC and microcontroller. A Rosewill dual serial port PCI card is used to provide this functionality. Refer to materials list (part# RC-301) to view specifications.

4.1.11 Power Supply

The power supply is the last but certainly not least of the components necessary for the DocBox. Before choosing power supplies, the voltage and current draw approximations of each system were taken into. Then, the power supplies were chosen with the appropriate output voltage and current based on the system they power.

A power supply outputting insufficient voltage or current can cause any system to behave unpredictably and ultimately fail. Therefore it was imperative that loading of the power supplies were carefully calculated - adding components or systems in parallel to a power supply might give desired voltage potential for the circuit, but may also overload the supply causing it to overheat and possibly become damaged. The voltage rail current approximations are recorded in Table 14. With these factors in mind, the DocBox is using AC-DC enclosed switching power supplies. These power supplies are chosen for being low profile and energy efficient. Many supplies also come with hiccup protection from overloading and overvoltage. Hiccup protection resets the power supply once the fault has been cleared which in a case of a power surge allows the DocBox to remain on without service.

P a g e | 65

Another factor in picking a power supply is deciding the amount of outputs. A minimum number of power supplies with multiple outputs is desirable over implementing multiple single output models. This saves space and eliminates the likelihood of malfunctions – fewer components means simpler troubleshooting. Again, though multiple outputs are attractive, overloading is an issue.

Table 14 - Current Draw Approximations

Looking into current power supply models, many offer the voltage required by the DocBox components with relatively high amperage (~3A - 8A) and at a reasonably low cost. It was prudent choosing a power supply in the prototyping phase rather than in the design phase. This allowed exact values to be calculated and base decisions thereafter. Ultimately, it was decided to utilize a basic computer power supply that had multiple outputs shown in Figure 34.

Figure 34 – ATX DC Power Supply

P a g e | 66

This power supply is able to supply 12V, -12V, 5V and 3.3V with a max of 25 Amps at the 12V and 5V supply. This power supply proved to be more than sufficient for all the Docbox components.

4.2 Software

4.2.1 Requirements

The DocBox system consists of three core software sections: operating system software (OSS), embedded software, and laboratory data retrieval (LDR) application. Together these units make up the entire DocBox software system. Each of the three units connects together using different communication protocols. The OSS is connected to the embedded software via a universal asynchronous receive transmit bus. This allows back and forth serial communication between the two units. Both of these units are contained within the field kiosk. The UI also contains a background process that manages and updates a database instance.

Therefore, the OSS has read and write access to the database. The OSS and embedded software are contained in each DocBox unit that is placed in the field.These two units communicate locally, whereas the OSS also makes a remote connection to the server hosting the database. The LDR application located at a remote location has read access to the database. This ensures the testing center cannot change or modify user data eliminating a security threat due to non-DocBox employees and technicians. Figure 35 explains the importance and implementation of each application.

Figure 35- Software System Overview

P a g e | 67

4.2.2 Operating System Software

The main CPU, just like a desktop pc, must have an operating system which is the basic set of tools that allows the computer to identify its hardware and run its applications. The DocBox utilizes a Microsoft Windows operating system to build upon. Added to the operating system is management software to handle task such as remote connectivity, serial communication, tamper-proofing, and application software. These components make up the main CPU stack. Figure 36 illustrates the DocBox software stack.

Figure 36 - System Software Stack

4.2.3 Application Software

To understand the design of the DocBox application a state flow diagram was constructed. The diagram is useful to visualize all the possible states the user may encounter when interacting with the application. The diagram shows a clear path for the user to navigate through the system. There are three root menu options: Return, New Test, and How It Works. Each of these options guides the user through a series of states that allows them to complete the corresponding task.

The New Test functionality is the logical starting point so this is examined first. The first form that is displayed to the user contains the most popular panel test highlighted for ease of access. An option to display all tests can be chosen from here. Selecting a test displays the detailed information along with an option for adding the selected test to the cart or returning to the all tests form. Upon selection, the user is prompted to check out or add more tests. If checkout is chosen, a shopping cart is displayed to allow reviewing of the impending transaction. Here the user ensures the appropriate selections have been made before entering the payment process. Upon finishing and verifying payment the appropriate amount of

P a g e | 68

sample containers are dispensed to the user. The user will also input a valid email address to identify their account upon return.

When the Return option is selected the return process is initiated. First the user is prompted to input the same email address that was used when the order was made. The system verifies the email entered and displays a review of the clients purchase. Here they are asked if a new sample bag is required before the samples are returned to the machine. The return slot is unlocked and opened to receive the samples from the user. If the system verifies a sample has been returned the task is complete and the user is notified they will receive their results in 24-48 hours.

The third option is the information center. Most people will not have encountered a DocBox before. The How it Works section informs the user about the details of the system. Here they can learn and become more informed of what types of resources are available to them. Figure 37 outlines the application flow.

The application flow describes the way the software flows from a user’s standpoint; however, the code operates in a relatively different manner. A Qt application has an event loop structure. The goal of this structure is to be able to respond to changes in the state of data models. In event-driven programs, the GUI view needs to respond to the changes in the data model to display the most up to date information, or view. Objects within the application are frequently sending messages to one another, which makes tracing through the program nearly impossible by hand. The model may change, and then it may have to pass the new data to multiple views for display.

The DocBox application creates objects, connects them, and then tells the program to execute. Once the event loop is running the objects can send information to each other in a variety of different ways. The key to the DocBox implementation is the ability for a custom widget, such as a customized button widget, to send QEvents to other QObjects in response to user input (touch screen press). The widgets can also respond to events such as repainting or resizing.

It is important to understand that the event loop does not handle events, they are delivered directly to the object involved. There are three categories of events: spontaneous events, posted events, and sent events. Spontaneous events are generated by the window system. They are placed in a system queue and processed one after another. Posted events are generated by Qt or the application. These events are queued by Qt and processed by the event loop for distribution. Sent events are also generated by Qt or the application, but are sent directly to the target object. The advantage of sending events rather than posting is immediate handling of the event by the effected objects. Although, Qt does not have time to compress the event.

While the event loop is running, as long as the application is open, objects can transmit information to one another through the use of signals and slots. An example is the ability to read/write data through the use of a single serial communication object from multiple different windows.

P a g e | 69

Figure 37 – Application Flow

The read/write methods are initialized as slots. Another object emits a signal triggering the slot. The signal can come from one or many different objects. The signal must be connected to the slot before the action will take place. This is done as so:

connect(Object1, signal1, Object2, slot1)

P a g e | 70

The above single line code snippet is enough to provide the powerful functionality of signals and slots. The DocBox application takes advantage of this feature extensively.

4.2.4 Management Software

The DocBox application is the software the user interacts with and sees when operating the kiosk. Other applications are necessary to provide the functionality necessary and preventing certain functionalities from being accessible. This is where the management software comes into place.

To protect the system from electronic attacks that may be possible if a user were to exit the DocBox application and gain control of the operating system the application is only operated in full screen mode disabling access to the pc. This configuration denies access to the task bar, toolbars, shortcuts, and windows.

The DocBox features a system maintenance utility that allows access to all the functionalities of the system without making a purchase or going through the selection and purchase process. This applications was very useful for testing, verifying, and debugging the system.

Remote maintenance access is a feature that is desirable but was not planned for the original DocBox. Having this feature allows remote restarts and updates to save time and money by not deploying a technician. This accessibility is part of the management software and will be part of future versions.

4.2.5 Serial Communications

T The DocBox relies on a serial communication scheme to issue and control commands from the central processing unit. When a signal is emitted the microcontroller unit receives this signal and processes the command. Upon processing, the unit executes the requested actions while the CPU waits for completion. The micro-control unit sends a signal back to the CPU to signal completion. When a task was not completed the respective error code is sent instead.

The CPU side of the communication line is handled by the operating system software and the DocBox application. This is where commands are initiated by the user interface. The central DocBox software contains a class for opening, setting, writing/reading, and closing the serial communication link. Figure 38 outlines the serial communication class.

The internal microcontroller handles the other end of the communication link. Data is transmitted from the CPU then processed in the microcontroller. The microcontroller contains a universal asynchronous receive transmit (UART) module that is used for the communication. To configure the microcontroller module (USCI_A) for UART mode the microcontroller is initialized with the following settings. First the control registers are initialized and used to place the UART in a software reset.

P a g e | 71

Figure 38 - Serial Communication Class

Then the baud rate and modulation control are set. The status register is set to disable echoing. Finally, control register 1 (UCA0CTL1-Bit0) is changed to take the UART out of software reset. This begins operation. Table 15 shows the register configuration.

Table 15 - UART Control Registers

When the microcontroller is ready to send data, the command is stored in UCA0TXBUF register. The UART automatically sends the data once placed here. When a command is sent over the serial interface from the CPU, the

P a g e | 72

microcontroller receives the data in a buffer register called UCA0RXBUF. The data is now stored in the microcontroller ready for processing. Processing software located in the microcontroller’s memory uses the 8 data bits it receives to determine which action takes place. A custom protocol is implemented to encode the commands into 8 data bits. Table 16 describes the command structure and whether the code is generated from the central processing unit or the microcontroller unit.

Table 16 - Execution Command Scheme

A special command is reserved for the system status. The CPU can request the system status at any time to receive a special bit stream that contains information about the status of the system. Each bit of the 8 data bits is a flag corresponding to a different system property. Table 17 outlines the system status bit pattern.

4.2.6 Database

Client data is retrieved from both the DocBox application and the laboratory portal.

P a g e | 73

Table 17 - System Status

The DocBox application has read and write access to the database while the lab portal is only given read access. To allow access from multiple locations the data is made available on a server. The web hosting service providing database services for the Doc Box is Amazon Web Services (AWS). AWS offers a relational database service (RDS) that manages a database instance on their server. Amazon RDS makes it easy setup, operate, and scale a relational database in the cloud. Amazon RDS also provides easy access to MySQL to facilitate compatibility with existing code, applications, and tools. This ensures easy connections to the data stored in the cloud from the DocBox units and the LDR application.

To retrieve data from the cloud a connection is made from the DocBox application. The following class diagram outlines the methods necessary to establish this connection. Different access identifiers are used when accessing from the DocBox application or from the lab portal to prevent unauthorized access as discussed above. Figure 39 indicates the methods used to query the data through the establish connection.

Figure 39 - Database Classes

P a g e | 74

The following code explains how a connection is made to the database, and then a query is requested and processed. First, the connection is made by creating a QSqlDatabase object, then setting the connection parameters. Previously, the username and password are given access from the web host service. Once the connection parameters are established, the connection is opened.

QSqlDatabase db = QSqlDatabase::addDatabase(“MySql”);

db.setHostName(“…endpoint address…”);

db.setDataBaseName(“test”);

db.setUserName(“user”);

db.setPassword(“password”);

bool ok = db.open();

Once the database has been opened a query can be made and processed using the following example. The QSqlQuery class passes a SQL query statement through the connection. The query will return a record which can be parsed using value(). The example retrieves all customers from a particular date and moves through each value returned in the record using next().

QSqlQuery query(“SELECT customers FROM date”);

while(query.next())

QString customer = query.value(0).toString();

doSomething(customer)

4.2.7 Payment Processing

The Doc Box requires credit card processing before dispensing the purchased sample tubes. A gateway account would be set up with a company like Flagship Merchant Services or Authorize.net. The chosen gateway account is PCI DSS Compliant to ensure the gateway meets the payment card industry data security standard. The connection used to process payment has a secure socket layer (SSL) to protect transactions. A merchant account is setup through the gateway service.

The process involved starts when the customer pays. Authorization is checked by sending the transactional data through the gateway service to the merchant bank’s processor, who, in turn, routes the transaction to the cardholder’s bank. The cardholder’s bank either approves or denies the transaction and passes the information back to the credit card processor, who, in turn, passes the information to the cardholder and the merchant. From here the purchased goods are delivered upon approval. The customer’s bank will send the required funds to the credit card processing network, who forwards the funds to the merchant’s bank.

The first generation DocBox prototype uses a magnetic authorization card to simulate credit card payment. Utilizing a magnetic card reader allows the prototype to simulate the action of paying by credit card. The data on the card is read and

P a g e | 75

processed in the UI for verification. This action is a valid method because the unit is used for display and promotional purposes.

4.2.8 Embedded Software

The embedded microcontroller is programmed to execute the functions of the DocBox system. The microcontroller controls the various motors and sensors that are used to perform the actions of dispensing and vending of test tubes, as well as collection. Figure 40 outlines the details of the embedded software.

Figure 40 - Embedded Software Details

The structure of the software begins with an initialization procedure. Here the input/output ports, peripheral modules, and variables are configured. During initialization the watchdog timer is configured along with the load capacitance for the external low-frequency crystal. After initialization the microcontroller enters low power mode and waits for an interrupt.

The software architecture is interrupt driven. A receive interrupt is generated from the universal asynchronous receive transmit module when data is ready to be

P a g e | 76

received into the buffer. Once this data is read the interrupt flag is cleared. This provides the ability for the microcontroller to wake up when a command is sent form the CPU. Inside the interrupt service routine (ISR) the command is read and the appropriate flag is set. The code returns to the main loop and checks which flag has been set. The appropriate block of code is then executed. Before the code is executed the flag is cleared to avoid an infinite loop of checking and executing. When the operation is done executing the flags are checked again, if no flags are set the system returns to idle mode. The microcontroller is now ready to receive the next command.

4.2.9 Laboratory Portal

The last part of the DocBox software system is an application issued to the sample testing laboratory. The laboratory portal is a tool that provides fast, simple, and secure access to client information. The current method used in a laboratory is to input client information manually when the samples are received. The DocBox streamlines this process by allowing the testing center to automatically obtain the clients information through scanning the sample tubes with a barcode scanner.

As long as the laboratory is logged into the application as a verified user the application queries the client database using the barcode scanned. The client information is then automatically retrieved from the database. This application was written in C++ using Qt Creator for development.

5 Design Summary of Hardware and Software

The DocBox, like many dispensing devices, is a very diverse system that requires design in not only electrical systems, but also software and mechanical systems. Despite the diversity in design, Group 12 focused more on the electrical and software design of the system, so as to meet the desired goals of more understanding of embedded systems, circuit design, and motor control systems. The top-level hardware design of the DocBox was broken into four main sections: The system enclosure, dispenser, collector, and holder. With respect to the software, the top-level design can be broken into four main sections: application software, embedded software, lab portal, and database. Each of these hardware and software top-level systems is further broken down into smaller subsystems that fully perform the task of each system. The top-level block diagram of the

DocBox is as show in Figure 1. It can additionally be seen within the block diagram

that each subsystem has a specifically delegated component for each of the four

group members of Group 12. In addition to the system block diagram, Figure 41

and Figure 42 shall assist in showing the physical placement of each of the

subsystems within the DocBox enclosure.

P a g e | 77

Figure 41 – Side View of Subsystem Placement

With the placement of the internal components of the system being established, the order of the operations shall be specified. The first interaction that the user has with the DocBox is with the touchscreen display.

Upon receiving the dispense signal from the CPU, the MSP430 microcontroller begins the dispensing sequence which shall consist of the following sequence: Dispense test tube, scan test tube barcode for indexing, deliver test tube to customer view the Delivery Chute (or “Tongue”). In order to be able to deliver a large quantity of tests tubes, the test tube holder “boot” is required to hold a minimum of 1000 test tubes so as to reduce the likelihood of a test tube shortage. Additionally, the dimensions of the boot is in such a configuration that it is capable of compactly storing the required 1000 test tubes while minimizing all likelihood of jamming while feeding to the single exit slot at the bottom corner of the boot.

P a g e | 78

Figure 42 – Top View of Subsystem Placement

The test tube dispensing wheel is located directly below the dispensing slot of the boot, and is driven by a DC motor that is controlled by the MSP430 microcontroller. The design goal for all of the dispenser motor applications was to use the microcontroller to simply enable and disable the DC motors without use of pulse width modulation. In order for the low voltage microcontroller to drive the voltage that is four times greater than that for the controller, a driver circuit that is enabled by the controller supplies the power to the motor. Group 12 decided to utilize an optocoupler that simply enables a transistor by a light in order to switch the regulated voltage to the motors. At the exiting end of the dispensing wheel, an optical detection circuit is used so as to determine when a test tube is dispensed.

After dispensing, the test tubes roll down the dispensing chute to the scanner roller that is also enabled by a dc motor identical to that used for the dispensing roller. The fate of the test tube, whether discarded or vended to the costumer, is dependent on the success of the barcode reader reading the test tubes. Due to the fact that the dispensing motor is bi-directional, the motor is run by a driver IC which controls the polarity change of the motor so as to change direction of the tilting chute. The motor driver IC chosen is the SN754410, which allows for simple motor driving control given a minimum of three input lines: Enable, motor direction 1, and motor direction 2.

For the development of DocBox, the students first assembled all of the circuits on breadboards so as to easily troubleshoot the designs. However, after development, a more reliable and concise board was designed for the control of all motors, locks, and peripheral sensors, this board design was outsourced to be

P a g e | 79

printed by a professional manufacture. The design of the PCB was completed using Eagle CAD software. Considerations such as the layers, trace width, trace positioning, component packages and mounts are just a few parameters that were met while designing the PCB and its revisions.

With respect to the layers of the PCB, there a few considerations were taken into detail, such as the number of components and the placement of such on the actual board, as well as the current consumption of the components of the board. The traces layers were each coated with different soldermask so as to provide a greater means of insulation of the layers traces from outside particles or solder to cause short circuits. Once the maximum current draw of the circuitry of the board was determined, the trace widths were selected accordingly.

With the test tube dispensing system design already described, the bag dispenser will follow next.

After much consideration it was decided that in order to reduce complexity and chance of system error of the project, a friction feeder solution to dispense a bag would not be used in this iteration of the DocBox. Instead, a locking door mechanism was employed in which a compartment containing the plastic bags is only accessible to the user once the CPU confirms the user is valid. The user is then asked to manually retrieve a plastic bag from the compartment to put the saliva sample vial into and return the package into the return slot. The access door is secure but easy to open and lock/unlock. It is bottom hinged and spring loaded to be normally closed when no force to open it is applied to it. The door has a triangular catch mechanism resembling that inside a bedroom door so that the hatch can close while the lock is engaged. This ensures that the hatch is always closed when not in use to prevent theft and tampering. The plunger, or “armature,” of the solenoid actuates in and out of a hole in a solid lip attached to the body of the DocBox. The hatch door catches on this armature when the lock is engaged (or when no power is delivered to the solenoid) – effectively locking the hatch door. When the door is closed and the lock engaged, the catch does not allow outward movement of the door due to a lip attached to the door from being

pushed inwards. The hatch door lock detail is illustrated in Figure 43.

The hatch is normally locked via a pull type solenoid when not in use. When the hatch is to be unlocked, the microcontroller sends a signal to the solenoid to actuate, which pulls the armature to a point above the catch of the door allowing it to be opened by the user. An LED placed below the hatch and notification on the display will indicate that the lock has been disengaged and a bag can be collected. The microcontroller is programmed to keep the solenoid actuated for a specific time out in the software, so the user may have a chance of opening the door. After that amount of time has expired, the lock is re-engage and the display prompts the user if they need more time. The user will either input “yes” or “no” where if “yes” is selected, the door remains unlocked for the set amount of time and if “no” is selected, the door locks and the process of service is continued.

P a g e | 80

Figure 43 - Lock Detail

By intermittingly locking the door this way, the solenoid has time to cool since solenoids are prone to generating heat when energized, which can be damaging. In choosing a linear solenoid, it was desired to have it be of low power since a high holding force is not needed in this application - the load on the armature is only the weight of the steel bolt and the negligible elastic band used to prevent the armature from falling out of the solenoid. The stroke, or how far the armature travels into the body of the solenoid, is set to be long enough to clear the door catch, yet short enough to firmly latch the door. Furthermore, since the lock is actuated for short periods of time, an intermittent duty solenoid suffices and also provides a smaller body than continuous duty solenoids, thus saving space. The bag dispenser resembles a napkin dispenser that one would find in a restaurant. Bags are stacked side by side with a spring loaded plate, pushing the stack towards the hatch entry. A stop plate is utilized to prevent the bags from spewing out of the dispenser. Here it was desired to have a system to sense when the supply of bags are about to be depleted. The spring plate runs on a track and has a rib extending from underneath. This rib moves with the spring plate along the track and trips a momentary limit switch at an appropriate point (about 85% of track length) indicating the bag supply is low. The limit switch has a lever-roller actuator which allows the spring plate to continue to traverse the track when activated. Once the spring plate touches the stop plate, the limit switch will be tripped and therefore indicate that no bags are left in the dispenser and therefore be read from the CPU. If no bags are available, service will cease thereafter as the bags are needed for acceptable testing. Figure 44 shows the conceptual illustration of the sensor.

P a g e | 81

Figure 44 - Detail of Sensor

Since the bags are very thin, the bag dispenser is expected to store anywhere between 700-1000 bags at full capacity. The reason simple limit switches were used as a position sensor to monitor bag supply is that due to the great amount of bags in the dispenser, it was expected for the supply to last a fairly long time thus movement of the spring plate will be very slow. Therefore, it is not necessary for sophisticated sensors such as optical sensors or linear motion potentiometers to track position. By using the design described in this section, power draw is lower and operation is more reliable than optical sensors and linear positioning sensors due to its simplicity. The reason a linear solenoid is used as opposed to a motor or linear actuator is similar. The simple application does not need a more complex device to be realized. To disengage the lock, a full on or off operation is needed opposed to a carefully controlled input. The result is a reliable and low power circuit which is desirable. A rotary solenoid, though more space efficient, was not chosen due to worry of the armature not engaging the locking pocket – there was a possibility of the armature getting wedged on the catch when the door is closing as the armature re-engages the lock, this is shown in Figure 45. The holder unit, which is the area where the saliva samples are collected once they are returned to the DocBox, is the next subsystem. Here the samples are kept under temperature controlled conditions in order to preserve the biological data until they are to be picked up for testing. The unit consists of a refrigeration system for cooling and a circuit to monitor and control temperature. Since this area is to remain at a cool temperature, the walls are insulated while being readily accessible in order for couriers to collect the samples daily. In researching methods to control temperature in a refrigerated environment, an attractive option was the inverter controlled compressor motor.

P a g e | 82

Figure 45 - Concept Illustration of System

By controlling the speed of the compressor motor it was possible to maintain a more accurate and constant temperature with a higher efficiency than traditional refrigeration systems. However, in order to do this, either a special motor built with such speed control built in or a variable frequency drive must be used (other methods are possible, but these are the most feasible for the DocBox application). These special compressors are very expensive and not widely available while VFD’s are also expensive and designing one from scratch would be complex and time consuming. Therefore, in the fabrication of the DocBox prototype, we forego the variable speed compressors for a traditional method of refrigeration. Information on variable speed compressors is left in this document for possible future iterations of the DocBox. A circuit is designed to control the switching of the refrigerator compressor. A temperature sensor is placed within the cooling area and is used as the feedback signal to the control circuit. The feedback signal is then compared to a set voltage (reference signal) that correlates to the target temperature and the resultant output controls the switching of the compressor power. If the feedback signal is higher than the reference signal, the area is assumed to be warmer than the target temperature and the compressor is switched on to start cooling. Conversely, when the target temperature is reached, the compressor switches off until the temperature drifts away from the target and the compressor switches on again. This is traditionally how general refrigerators work.

P a g e | 83

However, problems with this design arise if the control system is too tightly calibrated, which results in the compressor motor repeatedly switching on and off in a short amount of time due to system temperature fluctuating above and below the target temperature. To combat this, pulse frequency was decreased and hysteresis was designed into the circuit. Reducing pulse frequency meant that the circuit will checks the temperature less frequently as temperature is expected not to change dramatically. Also, designing hysteresis into the circuit allowed a range of acceptable target temperatures for the system to operate in. Figure 46 illustrates a block diagram of the temperature control system.

Figure 46 - Block Diagram of Temperature Control

The goal of the refrigeration system was to be completely independent of the other subsystems. In other words, the microcontroller that is controlling the other subsystems has no connection to the temperature control circuit since it is composed entirely of discrete parts. This saves precious pin space on the microcontroller that can be used for another subsystem. Also, if the microcontroller were to fail for any reason, the samples would still be preserved. With no processor the circuit is robust enough to be reliable and accurate. The cooling is performed through a traditional vapor-compression refrigeration unit. The compressor’s motor is an AC induction motor that compresses refrigerant into a high pressure high temperature gas. The gas is turned into liquid through a series of coils called the condenser where the hot air is expelled. This condenser is placed outside the cooling area, and attached to the inside walls of the system enclosure, so as to dissipate heat. The high pressure low temperature liquid is then turned into a mixture of liquid and vapor through an expansion valve and is run through another set of coils called the evaporator where a low power DC fan circulates air over. Heat in the air is absorbed by the refrigerant in the evaporator leaving the air cool and the cycle is repeated. This evaporator is exposed to the inside of the sample containment area. Refer to diagram in Figure 12 for an illustration of the vapor compression cycle.

P a g e | 84

The software system is summarized by reflecting on the initial goals and constraints the stakeholders require. The software accomplishes the requirements laid out previously in a secure, reliable, and compatible way. The components of the software are restated here for convenience. Refer to Figure 35 for a graphical view. The software stack is built upon the operating system. The operating system provides a foundation for other applications as well as a custom screensaver. The management software is loaded and initialized by the operating system to configure the PC with a kiosk look and feel, as well as provide a layer of security. The management software loads the DocBox application and ensures it is the only application capable of operating on the machine. The DocBox application runs continuously providing the public with access to private and affordable saliva testing.

The laboratory portal provides the testing laboratory with access to the web host where the database containing customer contact information is stored. The portal fetches the customer contact information after the user scans a barcode. The application must be logged into with a registered DocBox account to keep customers information secure. Once retrieved, the client contact information is easily copied into the laboratory’s existing management software. This completes the software cycle for the DocBox system.

Embedded software is loaded into the microcontroller’s memory in order to process all of the requests made by the CPU. The MSP430G2553 28-pin package microcontroller is used. The block diagram in Figure 47 outlines the highest level of peripheral control that the MSP430 services.

The architecture of the embedded software is interrupt driven. An interrupt is registered when the universal asynchronous receive transmit module data has left one of its buffers. The microcontroller checks the command, exits the interrupt service routine, then executes the appropriate function. Some of the peripherals in Figure 47 are used for output type execution, while others are used as input for providing feedback to the CPU.

The entire system comes together at the point of user interaction, the touch system. The touch and display system is integrated into the box in a secure manor that provides an astounding visual element for the user to view and interact with the DocBox. The display connects to the CPU through a standard DVI connection. The touch response is received through a standard usb connection.

Starting from the inside of the DocBox, the dispensing system was summarized, then the holding system, as well as the bag dispenser, then the embedded and operating system software, and finally the touch system. These subsystems come together to create the entire DocBox system.

P a g e | 85

Figure 47 - MSP430 Peripheral Control

6 Prototype Construction

6.1 Parts Acquisition

In the prototyping processes of the DocBox system, all of the components were considered and picked out to meet the requirements of the system, to the best of the knowledge of the members of Group 12.

6.1.1 System Enclosure

The enclosure to the system is different in small features such as height and exterior and interior component placement, especially for the purpose of avoiding legal conflict with existing designs. Due to the nature of Group 12’s goal to focus on the electrical design of the system, the box enclosure construction was left for an outsourced manufacturer which is shown in Figure 15 and further specified in Section 4.1.1.

P a g e | 86

6.1.2 Dispenser System Components

As described in Section 4.1.4, the dispenser unit within the DocBox system is comprised of a unique system of operations that required the unit to essentially be built “from scratch.” The purely mechanical components of the system were mainly acquired from other devices with similar components; for example, the scanner roller was taken from a printer. Additionally, components such as the test tube holder “Boot”, locking doors and other mounting hardware were made by the mechanically savvy members of Group 12. Given that this prototype of DocBox is desired to be put in public service, the box is to be professionally manufactured by a qualified vendor. With respect to the electromechanical and pure electrical devices, such as motors, wires, laser diodes and phototransistors, these devices were obtained from a variety of different electronic stores, both online and physically. For the DocBox project, the main resource for electrical devices was online electrical equipment distributors. Group 12 maintained to keep the overall cost of the project to a minimum without compromising the quality of each component for highest reliability. For example, the DC motor that was used for the rollers and tilt chute is the Sayama Brushless DC Motor obtained from All Electronics online electronics distributor. The component has a low cost in comparison with other distributors, yet is made from above average material thus finding a happy medium. The parts required for the dispenser system can be seen in their respective circuits in Section 4.1.4, the complete listing of the components can be seen in Table 18.

Table 18 – Dispenser Parts Listing

P a g e | 87

6.1.3 Printed Circuit Board (PCB)

The printed circuit board/s of the DocBox system were crucial to the success of the system, therefore Group 12 elected to utilize one of the many Printed Circuit Board manufacturing companies to produce the designed PCB for the Dispenser and Collector. Group 12 decided to use advanced circuits as the manufacturer for the PCB. The total cost for the PCB amounted to $55.00 each including shipping. This was a special rate for students and limited our board complexity to two layers.

6.1.4 Collector

Since the collector utilizes the movement sensors and the solenoid doors, the electrical components of the collector were obtained from the same sources as both the test tube and bag dispensers. Concerning the actual chute, the material used was recycled from an old mini-fridge.

6.1.5 Bag Dispenser

The bag dispenser subsystems key components consist of the locking mechanism and the position sensor. In this section, reasons why key parts were chosen and important aspects to note of these parts will be explained in detail. The locking mechanism for the bag dispensing hatch is operated by a simple actuation of a steel bolt via a linear solenoid. This solenoid is to be a pull type in which the armature (steel bolt) will be pulled into the solenoid’s body when supplied current. Section 4.1.5 goes into detail on how the solenoid works and its function in the DocBox. The C5-273-B-1 from Ledex is an open C frame pull type solenoid chosen for this application. The open C frame allows the solenoid to be easily air cooled and installed. According to the datasheet the solenoid is able to be run continuously at 3W is so desired. However, if desired to run at a higher power and therefore stronger holding force, at 6W the maximum on time is about 2.5 minutes – more than enough time for the user to retrieve a bag. The flexibility of this solenoid is attractive for this application and is why this part was chosen. The positioning sensor indicating that the bag dispenser is depleted of its supply is a limit switch that is activated when the spring plate of the dispenser is above it. It will be strategically place at the end of the dispenser track so that the spring plate will trip the sensor when the end is reached. For this sensor, the D2SW-01L2MS mini SPDT roller switch was chosen. This switch is momentary activated when the armature is actuated and deactivated when the armature is at rest. At rest, the switch is normally open and the armature allows the spring plate rib to glide along it via a roller. Once the thickest part of the rib reaches the roller arm, the switch activates the sensor circuit. The roller arm allows the spring plate to easily move along its track. The momentary activation allows the sensor to reset when the dispenser supply is replenished with more bags.

P a g e | 88

6.1.6 Holder

The holder has two main components – the cooling unit and the temperature control. This section is an overview of key parts in this subsystem.

6.1.6.1 Temperature Control

The temperature control circuit is described in section 4.1.7.1. The circuit revolves around the temperature sensor which sends a feedback signal proportional to the temperature in the cooling area. It was important for this sensor to be accurate and its output linear for this circuit to operate correctly. Chosen for the sensor is the LM35 temperature sensor from Texas Instruments© which is a “centigrade precision temperature sensor.” According to the product datasheet, these sensors output a voltage that is linearly proportional to the Centigrade temperature with an accuracy of +/- 0.5°C. Typical accuracy is rated even lower at about +/- 0.2°C to 0.3°C. Temperature range is rated for -55°C to 150° which is well within our expected range of 0°C to 26.7°C. All this considering, this sensor is a natural choice for our application. Compared to other sensors reviewed, this sensor was found to be the most accurate and reliable. The 555 timer is a popular timer IC device known for its accuracy, stability, and the ability to be customizable. This part was chosen to produce a time delay to prevent the compressor motor from rapidly switching on and off over a short period of time which can reduce the compressors life cycle. The 555 is able to produce timings with adjustable duty cycles from microseconds to hours based on the values of two resistors and a capacitor. The 555 timer was chosen for its precision and ease of use. Implemented is the TLC555 IC which is the CMOS version of the common LM555. The difference between these two chips are negligible for this particular application and could be considered interchangeable if need be. However, the TLC555 from Texas Instruments are available as free samples which is the main reason behind choosing this part. In choosing a comparator, the LM293 single precision rail to rail comparator from TI© was chosen. This comparator sports a relatively low input offset voltage which is desirable for accurate and predictable switching thresholds since the input will be small (on the order of tens of millivolts and up). Since this comparator like many others are prone to oscillating due to noise, external hysteresis is added to this IC by inserting positive feedback via a couple of resistors. This can be seen in Figure 27. The amount of hysteresis can be calculated using equations (7), (8), and (9) in Section 4.1.7.1. Hysteresis of a few millivolts should be sufficient for noise but more is desired for another purpose. A hysteresis of 20mV will provide protection from oscillations due to noise in addition to a ±1ºC (10mV) switching thresholds of the cooling unit. This will prevent the cooling compressor from constantly switching and thus increasing compressor efficiency and lifecycle while keeping the temperature in the holder within the desired limits. Capacitive coupling of the comparator output to its inputs will also result in unwanted oscillations so the entire

P a g e | 89

circuit is mounted onto a printed circuit board with bypass capacitors on the power inputs to reduce noise

6.1.6.2 Cooling Unit

In searching for a compact cooling system unit, little results arose. Vending machine cooling units are available but may be too specialized to be used in a Senior Design application as most are very expensive and come with built in temperature controls. Another option was to purchase a refrigerator condensing unit and an appropriate evaporator or repurpose a used miniature refrigerator to fit into the DocBox. At the moment, the less expensive among these options was chosen for prototyping purposes - a used refrigerator. A miniature refrigerator is easily obtainable and virtually any kind would have sufficed. A spare mini fridge belonging to a member was utilized as the cooling unit and was available free of cost. When stripping apart the refrigerator, it was noted that the cooling area was very well insulated with a special foam. This foam was heat resistant and surrounded the heatsink coils of the refrigerator. Since this type of foam is specialized, it was not able to be obtained to be put into the DocBox. Common insulating project foam was used for the holder instead. Unfortunately, this foam is flammable and was recommended not to be placed near heat – therefore the foam walls of the holder was placed in such a way that it would not touch the heat coils. These aforementioned coils are affixed to the aluminum walls of the DocBox enclosure with conducive tape in order to disperse the heat generated by the cooling unit.

6.2 Final Coding Structure

Each section of the DocBox software has been defined in the previous section. An organizational structure brings all these components together. The final coding structure provides an overview of how each component comes together to create the DocBox system. To start, everything was built upon the operating system.

6.2.1 Operating System Software Structure

The operating system provides the basic functionality to run the application software, provides the necessary external component drivers, and runs the management software. The operating system is altered to never sleep or automatically shut down. The boot animations for the operating system are also altered to provide a custom look and feel in case the general public is viewing when a reboot takes place. The Windows operating system is set up to auto-start the necessary applications the DocBox requires. This includes local database software and the DocBox application.

The DocBox application is a proprietarily developed software package so the source is not included inside this document. What is discussed is the general layout of the software. The components have already been discussed in the previous section. Here the details of the components are shown and how they

P a g e | 90

integrated together. The application begins with a main window class that displays the beginning screen to the users. Each page the users encounter thereafter is a dialog window. The main window remains in place while the dialog is opened above it. Each dialog is in charge of destroying the previous displayed dialog if necessary. Some dialogs remain in tacked because the user has the option of returning to the previous dialog; in this case the dialog destroys itself. This explains how navigation takes place from page to page in the application. The main window and each dialog are responsible for displaying their respective widgets and paint features.

In the background, the logic for opening the serial port connection with the microcontroller takes place. The serial port class contains methods for reading and writing data. These features must be accessible from more than one form (and related class) throughout the application. To do this, Qt’s signals and slots method is used as discussed in the research section previously. This allows the necessary classes to contain signals that can be connected to slots in the serial port class. The slots can be regarded as functions that read or write. The powerful features here is that many signals can be connected to each slot providing the functionality the application desires. Other features such as payment, database accessing, and barcode reading are accomplished in a similar manner. Each feature is contained in its own class to separate functionalities and provide an easier debugging environment.

The most important part of this structure is the concept of separating business logic and user interface. The code that provides the functionality to the DocBox is kept separate from the code that provides the user interface. Keeping these concepts separate makes it easier for designers to upgrade the user interface in future versions while maintaining the functionality of the original version.

6.2.2 Embedded Software Structure

The structure of the embedded software is described in the design detail Section 4.2.8. To execute this structure the code was developed with a simple interrupt driven architecture to ensure communication with the overall system. This approach ensures the core architecture of the embedded software integrates with the entire DocBox system before adding all the appropriate features.

6.2.3 Laboratory Portal

The laboratory portal application is much simpler in design than the DocBox application. In fact, the laboratory portal uses the blocks already created for the DocBox application. The major changes take place in the user interface design. This is easily accomplished because of the way the software is structured as discussed above. The laboratory portal application is also based off a main window. The main window is a simple interface that allows the user to read in a barcode number and view the associated information. This all takes place in the main window. A feature to add the contact information to the clipboard for easy

P a g e | 91

copying and pasting into the local laboratory software is available. The logic for barcode scanning and database access is derived from the DocBox application.

7 Project Prototype Testing

Upon assembling each subsystem design, each section went through a series of tests to detect any design flaws that could result in compensatory redesign of the system/component. The testing of the subsystems is broken into hardware and software testing, and further broken down into the respective subsystems within those classifications. The environment of each test is recorded in order to set a standard point of reference to expect the same results; this testing environment closely resembles the ideal environment that the DocBox system will operate in.

7.1 Hardware Testing Environment

Due to the required environmental specifications for the sample storage within the DocBox itself, there are two different environments for the hardware components to function within: the cooled environment of the Collector/Holder in the lower section of the enclosure, and the ambient environment of the Dispenser/CPU portion of the enclosure (Refer to Section 4.1.1 for enclosure diagram). The majority of the hardware (Dispenser, solenoids, CPU, microcontroller, etc.) is all within the non-cooled section of the enclosure. As is the case with all electrical systems, each component dissipates heat. The main contributors of heat are the CPU and touchscreen, which run continuously. Based off of the operating ambient temperature ratings for the upper enclosure components, the maximum temperature is not to exceed 80oC; similarly, all of the components for the cooled lower section of the enclosure all can operate at a low of 0oC, which shall not be attained within the DocBox.

Therefore, with these factors taken into consideration, the testing environment for all upper enclosure components is an ambient temperature above room temperature (25-40oC).

7.2 Hardware Specific Testing

7.2.1 Dispenser

With respect to the Dispenser hardware components, specific subsystems of the Dispenser is tested for functionality and reliability. The functionality testing of each subsystem is to verify that first, the system works, and second, that it works within the desired parameters. Many of the components have a large parameter range (max load current, heat dissipation, line impedance, etc.) that may allow for erroneous design parameters to allow the system to function for a period of time, until the incorrect parameter causes a system fault. Which leads to reliability, which more specifically means the correct system functionality over an extended period

P a g e | 92

of time. Per the temperature specifications discussed in Section 7.1, the dispenser hardware specific tests are in accordance with Table 19.

Each component is tested on five (5) separate events that are required to pass as functional for a minimum of three out of the five events without call for redesign; similarly, each component are to pass three out of the five events to be classified as functionally reliable.

7.2.1.1 Test Tube Dispensing (Boot)

Referring to Figure 16, it can be seen that the test tubes inside the boot are gravity

fed to the dispensing “Pacman” roller. Due to the nature of all items funneling within a container to the opening, there is a potential for the test tubes to jam at the dispensing slot of the boot. Although the Boot has been designed in such a way so as to prohibit jamming, the possibility still remained.

For the Boot to pass as functional, the system is not to jam for a minimum of ten (10) consecutive successful dispenses of test tubes at a Pacman RPM of 30. For the Boot to pass as reliable, the system is not to jam for a minimum of thirty (30) consecutive successful dispenses of test tubes at the same Pacman RPM.

These test cases are summarized and shown in Table 19.

7.2.1.2 Dispensing “Pacman” Roller

The Pacman Roller, which rotates at a specified rate of 30 RPM, is rotated based on the enable signal from the microcontroller and halted when the Dispense Sensor detects a dispensed test tube. So to avoid erroneous dispensing of test tubes, the Pacman Roller is required to come to a full stop within 0.25 seconds (0.125 rotations) of the microcontroller enable signal going low.

For the Pacman to pass as functional, the roller must not dispense any test tubes after the Dispense Sensor returns a positive dispense and before the next dispense signal is sent from the microcontroller. For the Pacman to pass as reliable, the Roller must meet the requirements for functionality and return to within 0.25 revolutions of its original starting position that are signified by a timing mark on the Boot and Pacman.

These test cases were performed on five separate events, shown on Table 19.

7.2.1.3 Boot Capacity and Dispensing Sensor

For the test tube dispensing optical detector to pass as functional, the infrared diode beam must remain in constant contact with the phototransistor unless momentarily broken by a dispensed test tube; upon being broken and reconnected, the microcontroller I/O pin detects at least one (1) optical trigger. The dispensing optical detection sensor passes as reliable if the sensor meets the requirements for functionality, with the difference being that the microcontroller I/O pin registers

P a g e | 93

only one (1) optical trigger for each test tube dispensed. This process is tested for five (5) consecutively dispensed test tubes.

These test cases are performed on five separate events, and are shown within

Table 19.

7.2.1.4 Scanner Roller

To provide the dispensed test tube the ability to rotate and allow the identifying barcode to be read by the barcode scanner, the scanner roller must continue to rotate until either the test tube is dispensed to the user, or discarded. For the Scanner Roller to pass as functional, the roller must rotate for five (5) consecutive successfully read barcoded test tubes on the first time. For the Roller to pass a Reliable, the roller must successfully rotate and stop for five (5) consecutive successfully read barcoded test tubes after one (1) timeout reset.

These test cases are performed on five separate events, and can be seen in Table 19.

7.2.1.5 Barcode Scanner

The barcode scanner is utilized to read the barcodes of each dispensed test tube before leaving the system enclosure. For the scanner to pass as functional the untainted barcodes of ten (10) consecutive test tubes must be read; for the scanner to pass as reliable, the barcodes of twenty (20) consecutive test tubes must be read.

These test cases are performed on five separate events, and are shown in Table 19.

7.2.1.6 Tilting Dispensing Chute

Similar to the Pacman Roller, an identical DC motor that rotates at a rate of 30 RPM drives the Dispensing Chute. The tilting motor holds the ability to rotate bi-directionally, which shall add in another factor of the reliability of the motor positioning. The Tilting motor is controlled through the use of an encoder wheel and optical circuit identical to the one used for the Dispensing Sensor. The test procedure for the optical encoder is identical to the procedure for the Dispensing Sensor.

For the Tilting Dispensing Chute to pass as functional, the chute must tilt towards the Tongue when the barcode scanner registers a positive barcode scan, wait two (2) seconds, and return to the idle position a minimum of 5 consecutive trials. If the barcode scanner does not register a positive barcode three consecutive times, the chute must rotate towards the discard bin, wait two (2) seconds, and return to the idle position a minimum of 5 consecutive trials. For the Chute to pass as reliable the chute must meet the same requirements for functionality, just with a minimum number of 10 trials.

P a g e | 94

These test cases are performed on five separate events, are shown in Table 19.

Table 19 – Dispenser Hardware Specific Testing (Each Set of Trials Repeated 5 times)

7.2.2 Collector

The testing of the collector consists of 10 consecutive trials of dispensing test tubes which entails the solenoid unlocking the front door and the return sensor successfully registering each sample deposit.

7.2.3 Bag Dispenser

The bag dispenser subsystem consists of two main parts - the bag supply’s door lock and the bag sensor. The door lock receives its command signal from the microprocessor but can be simulated with a 3.3V power supply. Door Lock testing is described in section 7.2.5.

P a g e | 95

7.2.4 Bag Sensor

Since the sensor is in actuality a switch, testing the functionality of the sensor was easily done with the multi-meters continuity feature. In preliminary testing before being integrated into the main system, the sensor was tested by hooking it up to a MSP430 input pin on a development board. The MSP430 was then programmed to light an LED once the sensor was tripped. In full system integrated testing, the sensor was tripped when nothing was in the bag dispenser (save a few bags due to them being very thin). When operating the GUI at this point, an “out of order” screen indicated the sensor circuit functioned as desired. 1. Begin with spring plate at a position before the limit sensor. Connect supply

voltage to the circuit and connect the input to the programmed microcontroller or 5V test supply. Connect the output of the circuit to a multimeter to measure voltage Vout.

2. Power on the supply voltage Vcc. Send a pulse to the input from the microcontroller or simulate a pulse by switching on the test source and measure Vout. Power off the test source if used.

3. Slowly advance the spring plate to the end of the track simulating the depletion of the bag supply. This should trip the sensor. Check armature of sensor to ensure it is actuated. Repeat step 2 at this point. Vout should be close to V.

4. Retract the spring plate slowly simulating the replenishing of bags to supply. This should release the sensor. Check armature of sensor to ensure is not actuated. Repeat step 2 once more. Vout should be very low.

Table 20 - Bag Sensor Troubleshooting Guide

As with the locking system, the 5V test source is used only to simulate the input from the microcontroller. A full test incorporating a programmed microcontroller must be conducted before fully implementing it into the system. Successful multiple

P a g e | 96

trials of the test will ensure repeatability which is desirable. Vout is the feedback signal going to the microcontroller for processing. When testing the DocBox system, start with Table 20. If the results of this subsystem are not as expected, the programming of the microcontroller should be checked for issues handling the feedback signal.

7.2.5 Door Lock

The following are the procedures used in preliminary testing. Solenoids and

relays were tested individually to ensure correct operation.

Table 21 - Door Lock Troubleshooting Guide

1. Apply a 12 V signal to the solenoid and check if the armature actuates into the

solenoid body. Test the hold of the armature by slightly tugging on it (the hold should be quite strong).

2. Once proper solenoid action is confirmed, disconnect the power and ensure see the armature returns to the extended position.

3. Connect the solenoid to the door lock switching circuit and connect Vcc to a solenoid terminal and to the switching circuit. The input of the circuit is

P a g e | 97

connected to the msp430 output pin or a 5V test supply source. Double check the circuit and power on Vcc.

4. Apply an input to the circuit through the microcontroller or test supply for 20 seconds. If input is through microcontroller, record time duration of actuation.

5. Observe the solenoid and confirm the bolt actuates. The bolt should stay engaged for as long as the input signal is high. Check the pulling force again by tugging on the solenoid armature. Switch off the input and allow the bolt to return to locked position.

6. Repeat steps 4 and 5 at least 3 - 12 times in succession allowing little time for solenoid to cool in between cycles. Note the heat generated from the solenoid and repeatability of the solenoid – does the solenoid show signs of wear or loss of actuation action?

Note that using a 5V supply is for preliminary circuit testing only. The locking circuit receives its input signal from the microcontroller. The test supply is simply used to simulate the microcontroller signal to the input. Therefore, before installing into the DocBox, this system must be tested using the programmed microcontroller. In full integrated system testing, the door locks were actuated only at certain moments in the dispensing and returning procedures. When the GUI prompts to collect a bag or return a sample, LEDs and a sound from the solenoid indicates the door lock unlocks. Once the LEDs turn off, the doors should be locked.

7.2.6 Holder Test Procedures

The holder’s temperature control must be tuned to best maintain a constant temperature in the cooling area. Since we do not know how fast the cooling unit can reduce temperature for the space given, this will have to be tested. This section will describe the steps taken to test the cooling unit’s cooling ability and the tuning of the temperature control. Additionally, Table 22 provides a troubleshooting guide

for the testing of the system. The temperature control circuit in Figure 27 will also

be referenced. 1. With the temperature controller disconnected to the cooling unit, power on the

cooling unit to begin cooling the holder area starting to ambient temperature. Observe and record this starting temperature and the temperature change over time every minute thereafter until the temperature inside the holder reaches 3°C or 38°F. Temperature can be measured with a thermometer probe or through the built in temperature sensor used in the temperature control. Measure the temperature through the sensor by measuring the voltage across its output going into the temperature control. This voltage is linearly proportional to the centigrade temperature meaning at 25°C the resultant voltage is 250mV.

The voltage – temperature relation is seen graphically in Figure 48.

P a g e | 98

Figure 48 – LM35 Voltage Temperature Relation

2. The target temperature is set by adjusting R1. The resultant voltage Vref over

R2 corresponds to the target temperature. This voltage can be calculated by equation (10). Note that this desired voltage should not exceed 5V.

𝑉𝑟𝑒𝑓 = (𝑡𝑒𝑚𝑝𝑒𝑟𝑎𝑡𝑢𝑟𝑒 (°𝐶)

100) (

𝑅𝑑

𝑅𝑐+ 1) (10)

The values for R1 and R2 can be obtained from equation (11) with (10).

𝑉𝑟𝑒𝑓 = 𝑉𝑠 (𝑅2

𝑅1 + 𝑅2)

(11)

3. After the temperature controller is tuned, test the cooling unit with the

temperature controller. Observe peak high and low temperature and the length of time it takes for the controller to shut off indicating target temperature is within threshold. Threshold temperature should be about ±1ºC about the target temperature. A good approximation for figuring the target, or center, temperature is to take the reference voltage and subtract 10mV. This voltage represents the center temperature (10mV per degree C). This is because only

P a g e | 99

one supply is used so hysteresis thresholds are skewed about the reference voltage. This approximation compensates for this.

4. Figure 49 is a schematic of the LM555 for monostable operation. After

temperature controller is tuned, test the cooling unit with the temperature controller. Observe peak low temperature and the length of time it takes for the holder to shut off indicating target is reached. If peak low temperature is below 3°C, the 555 timer cycle may be too long or the target temperature is not adjusted correctly. If so, repeat steps 2 to 3 until satisfactory settle time is achieved.

Figure 49 – LM555 Schematic Monostable Operation

7.3 Software Testing Environment

Test procedures for identifying and verifying the DocBox software system are laid out in the following sections. Testing is performed in a controlled environment with data collection to verify the results. Testing takes place during the entire development process on the development machine. Final testing takes place on the actual hardware before and after installation inside the DocBox.

P a g e | 100

Table 22 – Holder Troubleshooting Guide

7.4 Software Specific Testing

Testing of the system started with testing each subsystem individually. Once each

component was tested and working, a well-organized test procedure was followed

to find flaws in the system before production. The three software subsystems

involved are the operating system software (OSS), embedded software, and the

laboratory portal application (LPA).

7.4.1 Application Software Testing

The DocBox application required extensive testing to eliminate the possibility of malfunctions in the field. The UI is the interface that connects the customer to the functionality of the machine; therefore, the UI must work as planned. Testing of the software involved multiple levels of testing to realize a successful platform.

P a g e | 101

The most important testing involved allowing test users to interact with the UI. Test users are chosen to reflect all different ages and technical backgrounds. By not being familiar with the path the software should take, the customer will click all sorts of different areas that the designers may not try. This provides a better variety of actions that a user may try when approaching the Doc Box. Different technical backgrounds provide feedback into the usability of the system. After each user has spent some time navigating the UI they were asked to fill out a short survey that provides the designers with immediate feedback that was integrated into the final design.

Another aspect of the UI tested was the functionality of the system. To test the UI’s ability to complete the actions requested by the user sample runs were taken. The process of request and vend was repeated over and over again to ensure repetitive use did not jam the system and the appropriate number of tubes were dispensed with the correct information.

Logging was important process in the testing phase. The application software is capable of logging all events that take place in the system. This provides detailed data about the events and what time these events take place. This data allowed for precise adjustments to be made throughout the system.

7.4.2 Barcode Reading Software Testing The barcode reading software only requires minimal testing to ensure a capture is made every time a sample tube is present. The barcode reading system is tested using a system maintenance tool (SMT) that allows direct control over all properties of the DocBox hardware and software. The SMT is used to trigger the barcode reader in repetition and at varying intervals to test that the system always captured a reading when requested.

7.4.3 Magnetic Card Reading Software Testing

The magnetic card reader used for processing payment was tested in a similar manner as the barcode reader. Test swipes were done at regular and varying interval while the SMT captures the data. This method tests that the device is working properly. Test swipes are also done during different frames of the UI to make sure the reader only accepts a value at the right time. Testing this is crucial to make sure random swipes do not affect the UI. Testing revealed a weakness in the component purchased. After numerous swipes the reader began to read data incorrectly. This showed a better unit need be purchased.

7.4.4 Embedded Software Testing

Extensive testing took place on the embedded software. Since the embedded software is the internal control of the DocBox system it must always function as according to plan. If the embedded software malfunctions the entire system is compromised and will have to shut down. To avoid this, a detailed plan of testing is laid out in the following section.

P a g e | 102

The embedded software was created using Code Composer Studio 5.5.0 (CCS). CCS provides useful debugging tools to observe code execution. The register view window allows the register file to be observed. The entire block of code on the microcontroller memory is stepped through while observing the register file to look for any mistakes that could cause undesired operation. A memory viewing tool is also available that is observed the same way the register viewer is. The memory is observed to look for any incomplete tasks that could place the unit at a security risk.

Before any portion of the embedded software, and all the inputs and outputs associated with it, were implemented inside the system each component was individually tested. Each subsystem was configured in the laboratory on prototyping equipment to test its functionality. Once each system was tested and verified a complete prototype system was configured. With the complete system configured the SMT tool was introduced. Using the SMT, every procedure that the DocBox does was executed without the use of the UI. Observing each procedure executed and completed correctly ensures the system works properly.

With the functionality in place the embedded software system was connected to the UI for further testing. The idea of this test procedure is build the unit up in individual components, testing along the way, then combine them with more testing. Every procedure previously tested is again tested using the UI rather than the SMT. This was the final level of testing for the embedded software. When the unit began executing dispense and retrieval procedures through instructions from the UI the system was near completion.

7.4.5 Laboratory Portal Software Testing

The laboratory portal application (LPA) was tested by installing it in multiple remote locations. Each location is chosen to have a different operating system with different hardware. This tests that the LPA will work on different PCs since each laboratory location may be using different computers. The application is also tested on different network connections. This is useful to ensure a connection to the database can be made from through a variety of connection types and speeds.

7.4.6 Serial Communication Testing

The serial communication system is the link between the DocBox application and the microcontroller. This link is vital for the operation of the DocBox. The communication link was tested by passing every possible piece of data that the system may use and looking for bit errors. The link was observed using an oscilloscope to view and verify the data being passed is in fact the data requested. The Tx and Rx pins were observed using two channels of the oscilloscope. The waveforms generated were logged and compared to the data sent to look for errors.

P a g e | 103

7.4.7 Database Software Testing

The database system is managed by Amazon Web Services which is a reputable and reliable host. The testing involved herewas to flood the database with as many users as possible to see if the data is handled properly and none is lost. The database was set up to handle more users than the DocBox expects and is also scalable to expand if necessary. MySql Workbench 6.0 is an application that allows configuration, development, and testing of the database. This software is used extensively to manage and test the integrity of the database.

8 Project Operations

8.1 Initial Setup

To set up a new DocBox, begin by loading the test tube hopper completely with factory labeled test tubes. Refill the hopper alternating the orientation of the test tubes occasionally. Make sure all potential obstacles are clear of the system’s moving components. Next, connect the system to 120VAC by means of the cable located at the lower left corner on the reverse side. Next, press the center button of the main computer to begin the startup process. Once booted, the main screen will show the DocBox home screen of the user interface application as seen in

Figure 50.

Figure 50 – DocBox Main Screen

8.2 Purchasing a Test

To purchase a new saliva test, start by touching the button titled “Purchase a Test”. The following screen lists the four available tests for purchase. Select the

P a g e | 104

desired test for purchase and the test information is displayed. For this example,

an allergy test is purchased. Continue by selecting “Purchase” as seen in Figure 51.

Figure 51 – Test Purchasing Screen

At this point, a summary of charges is displayed for the selected test procedure.

Select “Confirm and Pay” as seen in Figure 52

Figure 52 – Payment Confirmation Screen

Next, a major credit card is needed to be swiped and a billing zip code must be entered as seen in Figure 53 and Figure 54.

P a g e | 105

Figure 53 – Card Swipe Prompt Screen

Figure 54 - Zipcode Screen

At this point, a valid email address must be entered for the delivery of the saliva

diagnostic report. Once entered, select the continue button as seen in Figure 55.

32816

P a g e | 106

Figure 55 – Email Address Screen

Now the DocBox will dispense two test tubes while the screen in Figure 56 is

displayed.

Figure 56 – Dispensing Test Tubes Screen

Once the dispensing process has completed, the bag door is unlocked and the

system displays the prompt to take the test tubes as seen in Figure 57.

P a g e | 107

Figure 57 – Successfully Dispensed Test Tubes Screen

The system then displays an instructions page and prompts you to take a plastic

bag from the illuminated door as shown in Figure 58.

Figure 58 – Saliva Collection Instructions Screen

P a g e | 108

The system prompts, after a few seconds, if more time is needed to get a bag as

seen in Figure 59. If a bag is obtained, “No” can be selected which returns the

system to the home screen.

Figure 59 – Bag Timer Query Screen

8.3 Returning a Sample

To return a saliva sample to the DocBox, touch the button titled “Return a Sample”. If you do not already have a plastic bag to seal your test tubes, the bag door is unlocked in order to obtain one at this time. If you have a bag and are

ready to return your samples, select the button titled “continue” as seen in Figure 60.

Figure 60 – Sample Return Instruction Screen

Please Take a Plastic Bag

from the Illuminated Door

Below

P a g e | 109

At this point, the DocBox unlocks the return door. Drop your saliva samples into the chute behind the illuminated door. Once the system detects your samples

have been returned, the display will show a thank you screen as seen in Figure 61. You have now successfully returned your samples and will receive your test

results by email within a laboratory-specified processing time.

Figure 61 – Confirmed Collection Screen

9 Administrative Content

9.1 Milestone Discussion

At the beginning of the project, Group 12 laid out a plan list of project milestones to be completed within the two semesters of the project. Figure 62 shows the layout of the milestones. Throughout the course of the first semester of the DocBox project, the deadlines and many definitions of milestones changed from what was originally established. Nevertheless, many of the milestones specified in Section 2.2 were successfully completed, which can be verified by comparing the shown milestones with the entire DocBox system. It is noted that the specific dates laid down within the milestones did indeed act as motivational landmarks for the project as a whole. The main helpful component of the milestone chart is the segregation of each of the groups into the description, research, test and design phases. Such an addition to the chart improved the effective performance of the groups’ mindset, so as to understand what to be

P a g e | 110

thinking about in the present as well as the future. Examples of specific significant milestones of Group 12 are:

Creating the design group: Although it has been stated that there are many important hardware and software components of the DocBox system, the entire planning of the system, and the future implementation of the building phase was only possible through a cooperative team environment. With this in consideration, it is first of all noted that the formation of Senior Design Group 12 was a significant milestone for the DocBox project, for without the group, the project would likely not exist.

Project Definition and Sponsor Interaction: After hearing the initial proposal of the DocBox, Group 12 unanimously agreed to take up the project, for the fact of seeing the great potential that there is not only in gaining more Electrical Engineering experience, but also to produce a product that can potentially change society. Additionally, the meeting of the sponsors of the project (DocBox Inc.) was a strong milestone of the group, due to the fact of obtaining a strong communicational relationship between the design group and the sponsor that lead to a project that satisfied the requirements given by the sponsor. After meeting with the sponsor on multiple occasions, the definitions of the project were a lot clearer, and therefore led to a more clearly defined research, design, and testing of the project.

Research of Subsystem Requirements: After defining the project, the design group was able to composing initial design plans, so as to invoke a mindset of what to research for result in more detailed design of the project components. The research of the initial design ideas was an extremely important part of any technical design, for the fact of checking the validity of the design, and even finding more effective solutions. Consequently, not all of the initial designs remained past the initial research stage, however, they did act as productive stepping stones toward the final design of the first generation of DocBox.

Dispenser and Software Interface Design: After the researching milestone was completed, the design of the subsystems began, and one particularly important subsystem was designed: the Dispenser. The Dispenser underwent multiple design revisions, since it plays a very important role in the overall system. Therefore, upon receiving the final design of the dispenser, a large milestone of the DocBox was achieved. Additionally, the software for the control of the system via the microcontroller and CPU reached an important milestone upon determining and testing the method of serial communication between the two.

PCB Fabrication and System Testing: The members of Group 12 started early on the design of the PCB for the motor, sensor, and solenoid control of the system. This head start allowed for more time to be dedicated toward a better quality board than one designed quickly in order to meet the project deadlines. By the one month mark until the project was due, Group 12 already designed, populated, and tested two generations of the PCB, which was extremely helpful for system testing. With the PCB functioning a month from the end, peripheral circuit testing, as well as

P a g e | 111

mechanical system testing was also possible, and therefore allowed for Group 12 to assemble the entire assembly and test the system.

Overall, Group 12 utilized the initial project milestones in order to give a general idea as to what needed to be completed by the final deadline. Throughout the entire duration of the project, Group 12 stayed mindful of what needed to be done, prioritized, and knocked out one piece at a time.

The following table is the Gantt chart of the milestone predictions for Group 12 at the beginning of the DocBox project. The corresponding table of these milestones can be seen in Section 2.2.

Figure 62 – Milestone Gantt Chart

It is further noted that the milestones predicted for the testing phase are not allotted until January of 2014, since this is the beginning of the implementation phase of the Senior Design course. Additionally, the design phase was also prone to have additional milestones in the corresponding to potential design flaws that required redesign of the component/system.

P a g e | 112

9.2 Budget and Finances

The DocBox system is a project that is fully funded by DocBox Inc. The desire of the sponsor was to deliver a product that is of the highest quality. Although all expenses for the project are fully covered by DocBox Inc. the desire of Group 12 was still to produce a product that is of the best quality, yet cost effective. The component information from Section 6.1 has been taken into consideration, and has been used to generate the both the projected and final overall cost of the

DocBox system, shown in Table 23.

Table 23 – Projected Overall DocBox Cost

It is additionally noted that the results of the projected system cost in Table 23 are

for the initial development of the entire system. Given more time and further development of the DocBox, the entire system cost is capable of dropping to an even lower cost.

P a g e | 113

10 Appendix A

10.1 Works Cited

[1] "Medbox," Medbox Inc, [Online]. Available: http://www.thedispensingsolution.com.

[Accessed 17 November 2013].

[2] Southern California Edison, [Online]. Available:

https://www.sce.com/NR/rdonlyres/A152092A-9FC5-410C-80DC-

F19257EC19EA/0/Refrigerated_Vending_Machine_Fact.pdf. [Accessed 20 November

2013].

[3] "Vessel Sanitaion Program," 15 July 2009. [Online]. Available:

http://www.cdc.gov/nceh/vsp/cruiselines/shipping_info.htm. [Accessed 2 October 2013].

[4] "Salimetrics Literature," 2012. [Online]. Available: http://www.salimetrics.com/literature.

[Accessed 5 September 2013].

[5] "CODE OF FEDERAL REGULATIONS (ANNUAL EDITION)," 1 October 2012. [Online].

Available:

http://www.gpo.gov/fdsys/browse/collectionCfr.action?selectedYearFrom=2012&go=Go.

[Accessed 15 November 2013].

[6] "GS1 General Specifications," 2013 July 2013. [Online]. Available:

http://www.gs1.org/genspecs. [Accessed 3 November 2013].

[7] "Enhancing Barcode Scanner Design," [Online]. Available:

http://www.silabs.com/products/mcu/Pages/barcode-scanner-design-using-a-32-bit-

microcontroller.aspx. [Accessed 5 November 2013].

[8] "Barcode Scanning," 2007. [Online]. Available: http://ap.motorolasolutions.com/kr/msi-

retail/docs/msi/T_MotorolaRetailVerticalssiteresourcesWhitepapersLaser_Scan_Digital_I

mage_WP_New.pdf. [Accessed 7 November 2013].

[9] "Stepper Motors," 25 July 2007. [Online]. Available:

http://www.allaboutcircuits.com/vol_2/chpt_13/5.html. [Accessed 13 November 2013].

[10] "Brushless DC Motor," 25 July 2007. [Online]. Available:

http://www.allaboutcircuits.com/vol_2/chpt_13/6.html. [Accessed 9 November 2013].

[11] Occupational Safety and Health Administration, "Ground-Fault Circuit Interrupters (GFCI),"

[Online]. Available:

P a g e | 114

https://www.osha.gov/SLTC/etools/construction/electrical_incidents/gfci.html.

[Accessed 20 November 2013].

[12] J. Rowley and F. Slack, Designing Public Access Systems, Brookfield: Gower Publishing

Limited, 1998.

[13] "The GTK+ Project," 2007-2012. [Online]. Available: http://www.gtk.org/. [Accessed 28

October 2013].

[14] "Qt Project," 2013. [Online]. Available: http://qt-project.org/. [Accessed 28 October 2013].

[15] "Qt-Project Graphics View Famework," 2013. [Online]. Available: http://qt-

project.org/doc/qt-4.8/graphicsview.html. [Accessed 30 October 2013].

[16] "Texas Instuments," July 2013. [Online]. Available:

http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=slau144j&fileTy

pe=pdf. [Accessed 30 October 2013].

[17] S. Wayne, "Basic Electronics Tutorial," 11 2013. [Online]. Available:

http://www.electronics-tutorials.ws/io/io29.gif. [Accessed 20 October 2013].

[18] Humboldt State University, "Vapor Compression Refrigeration System," [Online]. Available:

http://www.humboldt.edu/engineering/resources/equipment-handbook/refrig.

[Accessed 15 November 2013].

[19] P. Binneberg, E. Kraus and H. Quack, "Reduction In Power Consumption Of Household

Refrigerators By Using Variable Speed Compressors," 2002. [Online]. Available:

http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1614&context=iracc. [Accessed

23 Nov 2013].

[20] W. R. Chang, D. Y. Liu, S. G. Chen and N. Y. Wu, "The Components and Control Methods for

Implementation of Inverter-Controlled Refrigerators/Freezers," 2004. [Online]. Available:

http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1695&context=iracc. [Accessed

12 November 2013].

[21] VFDs.com, "What is a Variable Frequency Drive?," [Online]. Available:

http://www.vfds.com/what-is-a-vfd. [Accessed 15 November 2013].

[22] D. Brown, N. Fernandez, J. Dirks and T. Stout, "The Prospects of Alternatives to Vapor

Compression Technology for Space Cooling and Food Refrigeration Applications," March

2010. [Online]. Available:

P a g e | 115

http://www.pnl.gov/main/publications/external/technical_reports/pnnl-19259.pdf.

[Accessed 16 November 2013].

[23] C. Mathas, "Temperature Sensors - The Basics," [Online]. Available:

http://www.digikey.com/us/en/techzone/sensors/resources/articles/temperature-

sensors-the-basics.html. [Accessed 12 November 2013].

[24] M. Duff and J. Towey, "Two Ways to Measure Temperature Using Thermocouples Feature

Simplicity, Accuracy, and Flexibility," Analog Devices Inc, October 2010. [Online]. Available:

http://www.analog.com/library/analogDialogue/archives/44-10/thermocouple.html.

[Accessed 16 November 2013].

[25] "Temperature tutorial: Thermocouple vs. RTD vs. thermistor," 19 April 2007. [Online].

Available:

http://www.controleng.com/index.php?id=483&cHash=081010&tx_ttnews[tt_news]=59

28. [Accessed 15 November 2013].

[26] National Instruments, "Working with Thermistors and RTD," National Instruments,

[Online]. Available: http://www.ni.com/white-paper/2948/en/. [Accessed 17 November

2013].

[27] "1541L 15-inch LCD Open-Frame Touchmonitor," 2013. [Online]. Available:

http://www.elotouch.com/products/lcds/1541L/default.asp. [Accessed 20 November

2013].

[28] "1N4733A,"April 2009. [Online]. Available:

http://www.fairchildsemi.com/pf/1N/1N4733A.html. [Accessed 1 November 2013].

[29] "SSM6N36FE," 26 February 2008. [Online]. Available: http://www.digikey.com/product-

detail/en/SSM6N36FE,LM%28T/SSM6N36FELM%28TCT-ND/2257814. [Accessed 7

November 2013].

[30] "MSP430G2553IPW20," May 20213. [Online]. Available:

http://www.digikey.com/product-detail/en/MSP430G2553IPW20/296-33465-5-

ND/2695695. [Accessed 2 November 2013].

[31] "TRS3221CPWR," 14 July 2007. [Online]. Available: http://www.digikey.com/product-

detail/en/TRS3221CPWR/296-25017-2-ND/1908930. [Accessed 12 November 2013].

[32] "LM555," 21 March 2013. [Online]. Available: http://www.ti.com/product/lm555.

[Accessed 11 November 2013].

P a g e | 116

10.2 Table of Tables

Table 1 – Doc Box Project Milestones From Fall 2013 to Spring 2014 ................. 6

Table 2 – Comparison of Energy Consumption of Fixed & Variable Compression

Refrigerators/ Freezers [19] ................................................................................ 34

Table 3 – Alternatives to Vapor Compression Technology [21] .......................... 35

Table 4 - 1541L Touch System Specifications ................................................... 39

Table 5 – Boot Dimensions ................................................................................ 42

Table 6 – Dispensing Chute Specifications ........................................................ 43

Table 7 – Component Specifications for Motor Driver Switch Circuit .................. 46

Table 8 – SN754410 Logic Input Truth Table ..................................................... 47

Table 9 – Component Specifications for Tilt Motor Circuit .................................. 47

Table 10 – Component Specification for Detection Circuit ................................. 48

Table 11 - Microcontroller Requirements ............................................................ 57

Table 12 - MSP430G2553 Electrical Characteristics [29] ................................... 58

Table 13 - PC Specifications .............................................................................. 64

Table 14 - Current Draw Approximations ........................................................... 65

Table 15 - UART Control Registers .................................................................... 71

Table 16 - Execution Command Scheme ........................................................... 72

Table 17 - System Status ................................................................................... 73

Table 18 – Dispenser Parts Listing ..................................................................... 86

Table 19 – Dispenser Hardware Specific Testing ............................................... 94

Table 20 - Door Lock Troubleshooting Guide ..................................................... 96

Table 21 - Bag Sensor Troubleshooting Guide ................................................... 95

Table 23 – Holder Troubleshooting Guide ........................................................ 100

Table 24 – Projected Overall DocBox Cost ...................................................... 112

10.3 Table of Figures

Figure 1 – DocBox Top Level System Block Diagram ....................................................................... 7

Figure 2 – Dispenser Wheel Logic Methods: Discrete Rotation .................................................... 16

Figure 3 – Dispenser Wheel Logic Methods: Sensor Feedback ..................................................... 16

Figure 4 – Dispenser Wheel Dynamics ........................................................................................... 16

Figure 5 - Power Supply Diagram .................................................................................................. 18

Figure 6 - Range of Users ............................................................................................................... 21

Figure 7 - Signals and Slots ............................................................................................................. 24

Figure 8 – QgraphicsView .............................................................................................................. 26

Figure 9 - GraphicsView Coordinates ............................................................................................. 27

Figure 10 – Serial Data Protocol ..................................................................................................... 29

Figure 11 - Cross Section of Pull-Type Solenoid ............................................................................. 32

Figure 12 – The Vapor Compression Cycle .................................................................................... 34

P a g e | 117

Figure 13 – VFD Schematic ............................................................................................................ 35

Figure 14 – RTD Resistance Vs Temperature [25] ......................................................................... 37

Figure 15 – DocBox System Enclosure ........................................................................................... 39

Figure 16 – Dispenser Operation Diagram ..................................................................................... 41

Figure 17 – Boot Dimensions ......................................................................................................... 42

Figure 18 – Dispenser Motor Voltage Vs. Speed ........................................................................... 44

Figure 19 – Adjustable LDO Voltage Regulator ............................................................................. 45

Figure 20 – Dispenser Motor Driver Switching Circuit ................................................................... 46

Figure 21 – Tilt Motor Driver Circuit .............................................................................................. 47

Figure 22 – Photo Detection Circuit ............................................................................................... 48

Figure 23 - Locking Circuit .............................................................................................................. 50

Figure 24 - Bag Dispense Flow Diagram ......................................................................................... 50

Figure 25- State Diagram of Collector Operations ......................................................................... 52

Figure 26 - Optical Capacity / Return Sensor ........................................................................... 53

Figure 27 - Temperature Control Circuit ........................................................................................ 54

Figure 28 - Temperature Control Flow Diagram ............................................................................ 55

Figure 29 - MSP430 Power Diagram ............................................................................................. 58

Figure 30 – General Purpose Output Buffer / Level Shifter ........................................................... 59

Figure 31 – Microcontroller Opto-Isolation Interface ................................................................... 60

Figure 32 – Microcontroller 5v to 3v Input Buffer ......................................................................... 60

Figure 33 – Dispenser Printed Circuit Board Layout ...................................................................... 63

Figure 34 – ATX DC Power Supply ............................................................................................ 65

Figure 35- Software System Overview ........................................................................................... 66

Figure 36 - System Software Stack ................................................................................................. 67

Figure 37 – Application Flow .......................................................................................................... 69

Figure 38 - Serial Communication Class ......................................................................................... 71

Figure 39 - Database Classes .......................................................................................................... 73

Figure 40 - Embedded Software Details ........................................................................................ 75

Figure 41 – Side View of Subsystem Placement ............................................................................ 77

Figure 42 – Top View of Subsystem Placement ............................................................................. 78

Figure 43 - Lock Detail .................................................................................................................... 80

Figure 44 - Detail of Sensor ............................................................................................................ 81

Figure 45 - Concept Illustration of System ..................................................................................... 82

Figure 46 - Block Diagram of Temperature Control ....................................................................... 83

Figure 47 - MSP430 Peripheral Control .................................................................................. 85

Figure 48 – LM35 Voltage Temperature Relation .......................................................................... 98

Figure 49 – LM555 Schematic Monostable Operation .................................................................. 99

Figure 50 – DocBox Main Screen ............................................................................................ 103

Figure 51 – Test Purchasing Screen ....................................................................................... 104

Figure 52 – Payment Confirmation Screen ............................................................................. 104

Figure 53 – Card Swipe Prompt Screen .................................................................................. 105

Figure 54 - Zipcode Screen ....................................................................................................... 105

P a g e | 118

Figure 55 – Email Address Screen........................................................................................... 106

Figure 56 – Dispensing Test Tubes Screen ........................................................................... 106

Figure 57 – Successfully Dispensed Test Tubes Screen ..................................................... 107

Figure 58 – Saliva Collection Instructions Screen ................................................................. 107

Figure 59 – Bag Timer Query Screen ...................................................................................... 108

Figure 60 – Sample Return Instruction Screen ...................................................................... 108

Figure 61 – Confirmed Collection Screen ............................................................................... 109

Figure 62 – Milestone Gantt Chart .............................................................................................. 111

10.4 Permissions

P a g e | 119

P a g e | 120

[1]