Portable detection response task unit implementation

(1)

Defence Research and Development Canada

Reference Document DRDC-RDDC-2021-D129

Portable detection response task unit implementation

Christopher Apostoli James Zapasek

DRDC – Toronto Research Centre

Terms of Release: This document is approved for public release.

(2)

Template in use: EO Publishing App for SR-RD-EC Eng 2021-02-11.dotm IMPORTANT INFORMATIVE STATEMENTS

This document was reviewed for Controlled Goods by Defence Research and Development Canada (DRDC) using the Schedule to the Defence Production Act.

Disclaimer: This publication was prepared by Defence Research and Development Canada an agency of the Department of National Defence. The information contained in this publication has been derived and determined through best practice and adherence to the highest standards of responsible conduct of scientific research. This information is intended for the use of the Department of National Defence, the Canadian Armed Forces (“Canada”) and Public Safety partners and, as permitted, may be shared with academia, industry, Canada’s allies, and the public (“Third Parties”). Any use by, or any reliance on or decisions made based on this publication by Third Parties, are done at their own risk and responsibility. Canada does not assume any liability for any damages or losses which may arise from any use of, or reliance on, the publication.

Endorsement statement: This publication has been published by the Editorial Office of Defence Research and Development Canada, an agency of the Department of National Defence of Canada. Inquiries can be sent to:

[email protected].

The portable Detection Response Task unit outlined in this document was not manufactured to FDA or ISO13485 standards. This device was a proof of concept prototype to gather operationally relevant data.

(3)

Abstract

The portable Detection Response Task unit (pDRTu) implementation document provides design, test and application methods for a portable data acquisition device built in reference to the Road vehicles – Transport information and controls systems – Detection-response task (DRT) for assessing attentional effects of cognitive load in driving (ISO 17488:2016) standard. Commercial off the shelf DRT products are limited to static participant movement and proprietary software. The pDRTu was developed to assess the cognitive load associated with a primary task while enabling its application in experiments that involve dynamic activity (e.g., running). The developed device was required to record performance data, which related to understanding how new equipment could impact completing an objective. A prototype pDRTu was constructed to address these concerns. This document contains design decisions and provides information on how to recreate the pDRTu utilized for experimentation.

Significance to defence and security

Future land operations are expected to place greater cognitive demands on soldiers. The Canadian Army is concerned that information overload, and the increasing prevalence of information systems in the operating environment, will increase the cognitive load the soldier experiences. Hence, there is a need to be able to measure the cognitive load experience by the soldier in operations, and to validate methods that allow cognitive load measurement in mobile situations (e.g., when the soldier navigates). Laboratory studies have validated the use of the detection response task (DRT) to measure soldier cognitive load in a static setting. The next step was to adapt the DRT used in these studies to measure cognitive load in a more realistic field context. This report describes the development of a portable DRT unit (pDRTu) for a field trial run at Canadian Forces Base Valcartier in 2019. The field trial required each soldier participant to navigate a set of waypoints through forested terrain using traditional map and compass (baseline) or the Integrated Soldier System – Suite (ISS-S) battle management system. While navigating, the participant responded to tactile signals from the pDRTu. Slower response times and missed signals generally imply greater cognitive load. In general, pDRTu response times were shown to be greater in the baseline condition than with ISS-S, indicating greater cognitive load in the former case. Subjective measures of workload were also greater in the baseline than with ISS-S. The study demonstrated that the pDRTu was sensitive to the study’s manipulation, and correlated with participants’ subjective workload. Moreover, the pDRTu withstood a range of environmental conditions (including rain and motion due to being mounted on the participant’s back). Limitations to the system as implemented are described.

(4)

Résumé

Le document de mise en œuvre du dispositif portable de tâche d’intervention de détection (pDRTu) fournit des méthodes de conception, d’essai et d’application pour un dispositif portable d’acquisition de données construit en référence à la norme Véhicules routiers – Systèmes d’information et de commande du transport – Tâche d’intervention de détection (DRT) pour l’évaluation des effets attentionnels de la charge cognitive lors de la conduite (ISO 17488:2016) (en anglais seulement). Les produits commerciaux de DRT sur étagère sont limités aux mouvements statiques des participants et aux logiciels propriétaires.

Le pDRTu a été conçu pour évaluer la charge cognitive associée à une tâche primaire tout en permettant son application dans des expériences qui comportent une activité dynamique (p. ex., la course). Le dispositif mis au point devait enregistrer les données sur le rendement, ce qui contribuait à comprendre comment un nouvel équipement pouvait influer sur la réalisation d’un objectif. Un prototype de pDRTu a été construit pour répondre à ces préoccupations. Ce document contient les décisions de conception et fournit de l’information sur la façon de recréer le pDRTu utilisé pour l’expérimentation.

Importance pour la défense et la sécurité

Les soldats devront composer avec des exigences cognitives plus grandes lors des opérations terrestres de l’avenir. L’Armée canadienne craint que la surcharge informationnelle et la prévalence croissante des systèmes d’information dans l’environnement opérationnel n’augmentent la charge cognitive du soldat. Il est donc nécessaire de pouvoir mesurer la charge cognitive du soldat dans les opérations et de valider les méthodes qui permettent de mesurer la charge cognitive dans des situations mobiles (p. ex., lorsque le soldat s’oriente et se déplace). Des études en laboratoire ont validé l’utilisation de la tâche d’intervention de détection (DRT) pour mesurer la charge cognitive du soldat dans un environnement statique. L’étape suivante consistait à adapter la DRT utilisée dans ces études pour mesurer la charge cognitive dans un contexte de campagne plus réaliste. Le présent rapport décrit la création d’un dispositif portable de DRT (pDRTu) pour un essai sur le terrain mené à la Base des Forces canadiennes Valcartier en 2019. L’essai sur le terrain exigeait que chaque soldat participant s’oriente et se déplace dans un ensemble de points de cheminement sur un terrain fortement boisé à l’aide d’une carte et d’une boussole (ligne de base) traditionnelles ou du système de gestion du combat de la suite d’équipement intégré du soldat (SEIS).

Tout en se déplaçant, le participant répondait aux signaux tactiles émis par le pDRTu. Des délais de réponse plus lents et des signaux manqués sont généralement le fruit d’une plus grande charge cognitive.

En général, les délais de réponse du pDRTu se sont avérés plus longs dans l’environnement de référence que ceux de la SEIS, ce qui indique une charge cognitive plus importante dans le premier cas. Les mesures subjectives de la charge de travail étaient également plus importantes dans l’environnement de référence qu’avec la SEIS. L’étude a démontré que le pDRTu réagissait à la manipulation de l’étude et que ses résultats étaient corrélés à la charge de travail subjective des participants. De plus, le pDRTu a résisté à diverses conditions environnementales (comme la pluie et les mouvements dus au fait qu’il était monté sur le dos du participant). On décrit les limites du système tel qu’il a été mis en œuvre.

(5)

List of figures

Figure 1: pDRTu illustration of components. . . 10

Figure 2: Switch Debouncing (Greensted, 2010). . . . 19

Figure A.1: pDRTu Engineering Bill of Materials list per unit. . . . 24

Figure A.2: pDRTu component block diagram. . . 26

Figure A.3: pDRTu stimuli cable connection diagram. . . 27

Figure A.4: pDRTu response button cable connection diagram. . . . 28

Figure A.5: pDRTu control build of material peripheral connection diagram. . . 29

Figure A.6: pDRTu engineering build of material list total. . . . 30

Figure A.7: pDRTu 3D-printed case dimensions. . . . 31

Figure B.1: Flow-through of how to upload files to Arduino microcontroller. . . 32

Figure B.2: Flow-through chart of Arduino programming logic. . . . 34

Figure B.3: Flow-through of how to operate pDRTu. . . . 36

Figure C.1: pDRTu RTC Arduino code. . . 38

Figure C.2: pDRTu Main Arduino code. . . . 42

(8)

List of tables

Table 1: Benefits and limitations of commercial DRT products. . . 4

Table 2: Primary DRDC–TRC DRT design objectives. . . . 5

Table 3: Secondary DRDC–TRC DRT design objectives. . . . 7

Table 4: pDRTu electronic component specification. . . . 8

Table 5: Arduino NANO pin-out description based on engineering schematic. . . 11

Table 6: LED activation description to identify error codes. . . . 13

Table 7: pDRTu operating checklist. . . 14

Table 8: pDRTu start and stop data output description example. . . 16

Table 9: Miss, hit and false alarm data output description example. . . . 16

Table 10: pDRTu load measurement. . . . 19

(9)

1 Introduction

1.1 Purpose

The portable Detection Response Task unit (pDRTu) implementation document provides design, test and application methods for the portable data acquisition device built in reference to the Road vehicles – Transport information and controls systems – Detection-response task (DRT) for assessing attentional effects of cognitive load in driving (ISO 17488:2016) standard (International Organization for Standardization, ISO 17488:2016). The DRT was originally used to assess cognitive load attentional effects while driving road vehicles. However, such a device was tethered to a computer and did not allow for data collection where the participant was required to move dynamically (e.g., running). The advantage of the pDRTu is that data acquisition may be tethered to the participant, which broadens experiment scope to include dismounted experimental scenarios. The document provides an overview of the DRT method, its applications and justification for pDRTu development.

1.2 Scope

The pDRTu was designed to assess the cognitive load associated with a primary task. The created device was required to record performance data, which related to understanding how a new piece of equipment could impact completing an objective. To effectively gauge the participant’s cognitive load, the pDRTu was required to meet operational size, power, and personnel interface specifications, in order to minimize the devices impact on performance.

1.3 Deployment

The pDRTu was developed and deployed to support the 2019 Canadian Forces Base Valcartier, Integrated Soldier System – Suite (ISS-S) field trial. The pDRTu captured relevant cognitive load data during experimentation. This document will not go into depth regarding the description or outcome of the field trial. A brief description is as follows. The field trial required each soldier participant to navigate a set of waypoints through forested terrain using traditional map and compass (baseline) or ISS-S battle management system. While navigating, the participant responded to tactile signals from the pDRTu.

Slower response times and missed signals generally imply greater cognitive load. In general, pDRTu response times were shown to be greater in the baseline condition than with ISS-S, indicating greater cognitive load in the former case. Subjective measures of workload were also greater in the baseline than with ISS-S. The study demonstrated that the pDRTu was sensitive to the study’s manipulation, and correlated with participants’ subjective workload. Moreover, the pDRTu withstood a range of environmental conditions (including rain and motion due to being mounted on the participant’s back).

Limitations to the system as implemented are described in Section 4: Lessons learned.

(10)

2 DRT background

This section provides a description of the DRT, how it works, its intended application, commercial production, and use limitations.

2.1 Description

The DRT is a method for assessing the relationship between attention and cognitive load during a primary task. As a secondary task, the DRT is introduced to the participant while the primary task is being conducted. When there is a higher cognitive demand during the primary task, it is expected that there will be reduced performance for completing or acting on the secondary task. The relationship between “task demand” and “attention required for task completion” can be impacted by requiring the participant to take part in additional non-primary tasks.

An example of this occurs while driving a vehicle, the primary task, and talking to a passenger, secondary task (Tillman, Strayer, Eidels, & Heathcote, 2017). The demand of safe driving could be inhibited by multi-tasking, examples being talking to a passenger and/or interacting with an electronic device.

Quantifying cognitive load is achieved through obtaining participant hit accuracy and reaction time when responding to a secondary task. The following case example of the DRT was based on the standard (International Organization for Standardization, ISO 17488:2016). There are three types of stimuli that are used: (1) light (head-mounted), (2) sound (buzzer), (3) vibration (tactor).

A response button was placed on the underside of the participants dominant hand index finger, as per the standard (International Organization for Standardization, ISO 17488:2016). The participant was instructed to press the response button with their thumb when the stimulus was activated. Activation occurred for a maximum of 1s within a repeating time span of 3 to 5 seconds. The stimulus stopped if the response button was pressed within 250ms to 1s after stimulus activation. The minimum time (250ms) was required because a human cannot acknowledge the stimulus and press a button quicker than 250ms, as per the standard (International Organization for Standardization, ISO 17488:2016). Metrics associated with the secondary task include:

1. Hit – pressed response button within 250ms to 1s after stimulus activation.

2. Miss – did not press response button before 1s had lapsed after stimulus activation.

3. False Alarm – pressed response button before 250ms or after 1s when the stimulus was off.

This research testing process utilizes vigilance tasking where one stimulus is applied in order to obtain cognitive load data. There are instances which require two or more stimuli; these are known as discrimination tasks. The participant can be asked to return a response only when the specific stimulus activates. Hits, misses and false alarms apply, while also including two more metrics:

4. Correct Rejection – response button correctly not pressed for stimulus activation.

5. Incorrect Rejection – response button pressed for wrong stimulus activation.

The results of these metrics provide two important pieces of information:

(11)

1. Response Time – subtraction of stimulus activation time to button press time during a hit.

2. Miss Rate – ratio of number of misses to number of stimulus activated.

Section 3.9 Analysis provides a short summary on how to utilize these metrics to analyze performance.

2.2 Application

To date, the DRT method has primarily been applied to understanding the cognitive effects while driving a vehicle. The Road vehicles – Transport information and controls systems standard – Detection-response task (DRT) for assessing attentional effects of cognitive load in driving (ISO 17488:2016) is an example where the interaction with visual-manual, voice-based and haptic interfaces were evaluated (International Organization for Standardization, ISO 17488:2016). DRT results have been used by the National Highway Traffic Safety Administration to discourage the introduction of distracting devices in vehicles as a way to promote safety while driving (Ranney, Baldwin, Smith, Mazzae, & Pierce, 2014). Furthermore, Tillman et al. evaluated the impact of conversation with the driver in different environments: (1) single (driving only) task; where drivers drove a simulated car and responded to the red light, but were not engaged in any type of conversation; (2) Dual task “passenger”; driving and conversing with a passenger seated next to the driver; (3) Dual task “cell phone”; driving and conversing, through a cell phone, with another person seated in a separate room (Tillman, Strayer, Eidels, & Heathcote, 2017). This work showed that information was not lost while talking, rather that drivers became more cautious when responding in demanding situations. In addition, the DRT method was utilized in a 2015 report written by Strayer et al. which found that significant impairments to driving occurred as a consequence of voice- based systems in vehicles (Strayer, Turrill, Cooper, Coleman, Medeiros-Ward, & Biondi, 2015). These studies illustrate the influence the DRT method had in assessing the attention requirement of a primary task and why it can improve design development works.

2.3 Commercial product

The DRT unit is an electronic data acquisition device that controls the activation of stimuli, while also recording a participant’s response to create an output of metrics that can be used to the determine effectiveness of a participant during a task. These metrics are listed in Section 2.1.

A single commercial off the shelf (COTS) unit, quoted to support the 2019 Valcartier ISS-S field trail, ranged from $4000–5000 CAD (at the time of this report) (DETECTION RESPONSE TASK). Additional stimuli and accessories may also incur additional costs from $300 to $2500 CAD (for replacements). This unit required the device to be connected to a computer to operate. The typical device could not be programmed for specific occurrences or trials and was not designed to utilize a mobile power system.

The typical COTS DRT product has specific use case scenarios and is ideal for environments or case studies listed in Section 2.2. From its design specification, it can be used in laboratory environments where the participant is static. The product benefits and limitations are shown in Table 1.

(12)

Table 1: Benefits and limitations of commercial DRT products.

Benefits Description

Ready to use COTS product that can be used in a lab or stationary setting.

Customer Support Available to receive support for the product.

Limitations Description

High cost Multiple configurations and consumable/replacement parts increase procurement time and operating costs

Tethered Capability

The unit does not have the ability to store data locally (on the device). It must be connected to a computer that contains proprietary software for data to be transferred/viewed.

The unit cannot be configured for battery usage. There is no internal storage of data that could be uploaded to a computer.

Trials in the field, or where a participant is non-stationary, cannot be completed. Only stationary activities can be performed.

Proprietary software The unit cannot be easily integrated with other systems.

Cannot be edited for an alternative use case, e.g., more than two stimulus.

Impact resistance Not designed to withstand impact—not ruggedized.

Susceptible to parts breaking in non-stationary scenarios.

Response Button

Can only be placed on participant’s finger.

Experiments that require relocation of the response button cannot be performed. Would require a new mounting solution.

Modifying the existing response button may void support or warranty agreements.

(13)

3 Project objectives

Due to the limitations and modifications of the COTS DRT systems, Defence Research and Development Canada – Toronto Research Centre (DRDC–TRC) was tasked to develop a solution that was capable of meeting DRT functional requirements and could be used as a development platform for future requirements not outlined in the initial expectation. This section outlines the objectives for the DRDC–TRC DRT system.

3.1 Primary

Primary objectives are a set of DRDC–TRC DRT design considerations to replicate the core functions within the commercial DRT unit. It sets the minimum threshold for guidance regarding how the DRDC–TRC DRT must perform to produce an output that can be used in a scientific setting. Table 2 displays the primary objectives of the DRDC–TRC DRT.

Table 2: Primary DRDC–TRC DRT design objectives.

Objective Criteria Metric

(True or False) Constraint Justification Should control

stimulus activation

Ability to turn stimulus on and off

Can control stimulus

Must be a wired connection

Required to complete DRT method

Should record response button press

Ability to record response button presses

Can record button press (recorded or not recorded)

Must not record when response button is not pressed and/or add additional mechanical delay

Required to complete DRT method

Should control stimulus duration

Ability to activate stimulus for known duration

Can activate stimuli for set times (1, 5, 10, 20 seconds)

Must reliably turn on and off, and remain consistently on for specified durations or off when response button is pressed

The 1, 5, 10, 20 second allotments were based on equipment configuration and verifying the stimuli in its most optimal usage case.

Should provide a time stamp when recording events

Ability to time stamp events such as button press and stimulus activation

Can time stamp events in Unix time (e.g., 1624987070)

Must sync time stamp with universal time

Required when analysing data to understand sequence of events to calculate hits, misses, false alarms, and correct rejections. Meet

portability requirement.

(14)

(True or False) Constraint Justification Should write

output data to µSD card

Ability to output data in a .txt file

Can match events with .txt file records

Must allow µSD card to be serviceable and replaced to obtain data

Required to analyse the data from the participant.

Meet portability requirement.

Should be inexpensive unit price

Ability for an inexpensive total unit price

Can sum all part costs—

including spares

Must not cost more than $200 CAD per unit

Required to build 10 units at a price of $200 per unit to verify initial concept (at time of writing)

Should operate without being tethered to an immobile power source

Ability to power unit using an internal or mobile external source

Can support readily available battery types (9V, AA, AAA)

Must store battery packs internally.

Must have access to battery source for maintenance and operational activities.

A wired connection will not always be possible.

(Rechargeable battery field charging and potential risk in battery combinations of NiCd, NiMH and LiPO battery packs.)

Should have an operational runtime supports 1.5x trial activity duration

Ability to support run time activity duration without changing/replacing the battery pack

Can measure runtime duration in seconds

Must be operations for no less than 1.5X the runtime of the trial activity.

Required to support data collection throughout entire trial. Adjust battery amounts to accommodate trial length.

Should be impact resistant and electrically insulated

Ability to be durable to

withstand multiple trials and typical wear and tear issues

Can record servicing or repairs (number of uses)

Must not be obtrusive to regularly

performed actions

Required to reliably acquire and retain data gathered in a trial setting, during normal operation or compromised operation (damaged)

Should check Unit preliminary self-test for: Real Time Clock, micro SD module and stimulus on every power cycle

Ability to self-test verifies all critical components are connected and operational

Can verify the functionality of all connected peripherals

Self-test must not produce false passes.

Notify the operator if the device no longer becomes reliable during device operation

Required to signal / notify experimenter a component / function not performing correctly. (i.e.. damaged response or stimulus cable)

(15)

3.2 Secondary

Secondary objectives listed in Table 3 are a set of design considerations that are not required to achieve core function. Implementing these objectives will improve the reliability and ease of use of the DRT system.

Table 3: Secondary DRDC–TRC DRT design objectives.

(True or False) Constraint Justification Should have

modular design for easier field service requirements

Ability to change/replace parts without the use of specialized equipment

Part can be changed.

Can be

repairable in the field with generic non-powered hand tools.

Must be able to change buttons and stimulus wiring components

Required when part breaks and may need to be changed in the field

Should support wireless

communication

Ability to transmit data or update program wirelessly

Can connect to the unit wirelessly and transmit data

Must not require a physical or direct contact with the system

Required to reduce continuously opening the device to obtain data—leads to failures Should support

multiple stimuli connections

Ability to connect and utilize multiple stimuli

Can control and utilize multiple stimuli

Must have minimum of two stimuli connection ports

Required to add discrimination task capability

Should develop a Printed Circuit Board (PCB) for finalized variant

The PCB shield has the ability to add modular components

The PCB can support primary objectives

The PCB modular system must meet the space constraints of the pDRTu

The PCB modular system must improve the performance of the existing pDRTu

3.3 Microcontroller selection

Micro controller selection was primarily based on short supply lead times and relatively low cost point data acquisition capable system. Initially, three systems were identified: (1) Arduino based platforms, (2) National Instrument Data Acquisition devices utilizing LabVIEW and (3) Raspberry Pi platforms. All three systems are capable of integrating electrical components to control and record stimuli and response button presses through the use of an adapter board or PCB. The Arduino microcontroller was selected based on available documentation produced by Dr. Bengler of TUM Department of Mechanical Engineering, Technical University of Munich. Dr. Bengler had created reference documentation which demonstrated how to utilize an Arduino microcontroller as the base platform to create an in-house DRT (Bengler). The work conducted by Dr. Bengler represented a starting point, which provided insight on typical parts required and code logic utilized to produce and operate a DRT unit.

(16)

3.4 Engineering bill of materials

The engineering bill of materials (EBOM) contains a list of components, assemblies and materials required to reproduce the pDRTu described in this document. The EBOM provides the minimum quantity batch order and vendors that were used to source each component in addition to the minimum amount of components to obtain functionality without affecting safety or performance. Please see the EBOM DRDC-RDDC_DRT (Single STIM)_BOM_1.0.pdf document in Annex A.1, Figure A.1 pDRTu engineering bill of materials list. The total cost of parts used to create the pDRTu was $73.20 CAD.

The Arduino NANO was selected based on its unit cost and small form factor. The Arduino UNO was used as the initial prototype to provide a proof of concept. When producing the new variant of the pDRTu, a number of Input/Output (I/O) pins were not required for the target deliverable date. The NANO had been selected as it had a sufficient number of I/O pins, a lower cost than the UNO and a smaller mechanical footprint. The RTC module was chosen to fulfill the requirement to track time, the portable unit had to rely on an external time tracker to record events which were time stamped with the current date and time. Data collection was managed by the file I/O libraries and a micro SD module. Table 4 contains a list of the modules used to produce the pDRTu.

Table 4: pDRTu electronic component specification.

Name Description Specification

Longrunner Mini NANO V3.0 ATmega328P 5V 16M Micro Controller Board Module for Arduino (Arduino Nano)

Microcontroller.

- ATmega328P with 32 KB memory - 2 KB used for the bootloader - Operating voltage: 7–12 V - 16 MHZ Clock Speed

- ATmega328P supports C compiler

- 30 pins of which 14 are digital input and output pins (6 pulse width modulation, 8 Analog IN pins, 2 GND pins, 2 RESET and remaining pins for VIN, 5V, 3V and REF respectively) Willwin Micro SD

Card Micro SDHC Mini TF Card Adapter (Willwin 5PCS SD Card Module Slot Socket Reader Reading Writing Sensor Shield Module for Arduino Write SD Card Slot Socket Reader ARM MCU Control Board 3.3V 5V

Programable)

Writes to a micro SD card.

Used as a data logger.

- Supports SD card - Power supply 4.5 ~ 5.5V - 3.3V regulator circuit board

- All SD SPI pin-outs: MOSI, SCK, MISO, CS, VCC, GND

XCSOURCE DS3231 AT24C32 IIC Precision Real Time Clock Memory

Programmable clock. Used to timestamp events.

- Operating voltage: 3.3~5.5 V

- Clock chip: High-precision clock chip DS3231 - Memory chips: AT24C32 (storage capacity 32K) - Battery type: CR2032 rechargeable battery

(17)

Module for Arduino TE536 (XCSOURCE 5pcs DS3231 AT24C32 IIC Precision Real Time Clock Memory Module for Arduino TE536)

- Dimension: Approx. 38mm x 22mm x 14mm - Pin outs: SCL, SDA, VCC, GND

DC 3V 12000RPM Two Wired 10mm x 3mm Coin Cell Phone Vibration Motor (BestTong 15 PCS 10mmx3mm Mini Vibration Motors DC 3V 12000rpm Flat Coin Button-Type Micro DC Vibrating Motor for Mobile Cell Phone Pager Tablet Household

Appliances)

Tactor used in the experiment.

(Equivalent to product listed in the EBOM.)

- Rated Voltage: DC 3V - Rated Speed: 12000 RPM - Size of cell: 10mm x 3mm - Wiring: VCC, GND

3.5 Engineering schematic

The engineering schematic illustrates how to reconstruct the pDRTu with the parts listed in Section 3.4.

Annex A.2 contains drawings of each major component. The DesignSparks suite had been utilized to draft the electrical and mechanical drawings (DesignSparks PCB). Figure A.2 consists of the pDRTu layout via a block diagram. Figure A.3 details how to create the stimulus cable—using heat shrink and epoxy to support the solder joints. Figure A.4 details how to create the response button cable. Figure A.5 depicts the pDRTu control box, which outlines the peripheral connections to the Arduino NANO microcontroller.

Use this page in conjunction with Figure A.6, the EBOM, to understand where each component connects.

Figure A.7 shows the computer-aided design (CAD) drawings of the housing unit for which each component was placed. The housing of the pDRTu was a COT product; however, a 3D printed version can be produced to achieve the same outcome. An example of the pDRTu components are illustrated in Figure 1: tactor stimulus with cable, response button with cable, start/stop button, next phase button, and bar LED display.

(18)

Figure 1: pDRTu illustration of components.

3.6 Arduino code

The following sub-section will define variables set in the Arduino code and provide logic for how the code was constructed. To access the functions called from the classes within code, the following libraries must be present on the development machine:

 DS3231 RTC – Real Time Clock function library for DS3231;

 wire.h – I/O library;

 RTClib.h – Real Time Clock function library;

 SPI.h – Synchronous serial data protocol used by microcontrollers with SD adapter; and

 SD.h – Read and write to SD cards using SD adapter.

Pin-out declaration was based on the requirement of the component. See Table 5 for the allocation of each pin-out. Phase 1, 2, and 3 represent flexibility in the code to allow the programmer the ability to create stimulus parameters for two scenarios which might require different: (1) lengths of stimulus activation and (2) stimulus onset asynchrony (SOA). Where SOA represents the time to wait before the stimulus activates. When reviewing the function setPhase, the parameters gStimMinGen (minimum SOA),

(19)

gStimMaxGen (maximum SOA), and gStimLengthGen (length of stimulus activation) can be set. It is important to remember that the pin-out described below is specific to the Arduino NANO because of predetermined special pins. If using another microcontroller, such as an Arduino UNO, check the board pin layout. See Annex B.1: Upload file to Arduino microcontroller for more details on how to upload Arduino code to the microcontroller.

Table 5: Arduino NANO pin-out description based on engineering schematic.

Pin (Digital, Analog)

Component

Connected Variable Name Description D2 Response Button /

LED strip panel 1 RESPONSE_

BUTTON Pin D2 is allocated for interruptions. Defined via attachInterrupt(0, buttonISR, RISING) where the interrupt occurs when the input signal detects a rising edge. LED panel turns on when the button is pressed.

D3 LED strippanel 19 EXP_RUNNING

_ LED Activate LED to signify the code is in experiment mode and on pause.

D4 Micro SD Adapter

/ LED strippanel 17 chipSelectSD Communicate with the micro SD card adapter.

D5 LED strippanel 15 PHASE_1_LED Activate LED to signify the code is in phase 1.

Converted to error identification.

D8 Button #1 on unit START_STOP_

EXP_ BUTTON Normally open circuit that closes when the button to start/stop experimentation is pressed.

D9 Button #2 on unit NEXT_PHASE_

BUTTON

Normally open circuit that closes when the next phase button is pressed.

D10, D11,

D12, D13 SPI header No variable Not in use. Controlled by the Serial Peripheral Interface of the Arduino NANO as a synchronous serial data protocol.

A0, A6 Stimulus #1/LED

strippanel 9 OUTPUT_

INDICATOR_1_

LED, OUTPUT_

READ_CHECK

A0 controls activation of stimulus #1. Turns on LED panel. A6 to read stimulus is working correctly.

A1 Stimulus #2/LED strip panel 7

OUTPUT_INDIC ATOR_2_LED

Controlled the activation of stimulus #1. Turns on LED panel. Converted to error identification.

A2 Stimulus #3/LED

strip panel 5 OUTPUT_INDIC

ATOR_3_LED Controlled the activation of stimulus #1. Turns on LED panel. Converted to error identification.

(20)

Pin (Digital, Analog)

Component

Connected Variable Name Description A3 Stimulus #4/LED

strip panel 3 OUTPUT_INDIC

ATOR _4_LED Controlled the activation of stimulus #1. Turns on LED panel. Converted to error identification.

A4, A5,

A7 RTC DS3231 RTC_DS3231,

RTC_SQW_

READ_CHECK

SDA = A4 | SCL = A5 | SQW = A7 are specific pins on the Arduino NANO. These are required to communicate with the RTC.

To operate the pDRTu it was essential to understand the meaning behind the LED Bar that provides visual cues. Please reference Table 6 to identify error codes.

(21)

Table 6: LED activation description to identify error codes.

Event LED Sequence:

10 (Left) to 1 (Right) Description Illustration

pDRTu turned on

- All 10 will activate sequentially left to right, one after another, starting from position 10

- Duration 1 second each

- Confirm all ten LED’s are working - If stimuli connected, should activate once

Write to micro

SD adapter

- Position 9 will activate turning the LED red - Duration 1 second

Micro SD card write

function called Response

button pressed

- Position 1 will activate - Duration 1 second

Response button

activated

Stimulus activated

- Position 5 will activate - Duration 1 second

Stimulus set high for

1 second then to low Test Outputs - Position 10

- Duration 1 second blink Test RTC and Stim Experiment

Paused

- Position 10, 5, 2 will simultaneously activate - Duration 1 second blink

Experiment paused/has

not started

Micro SD adapter error

- Position 10, 9 will simultaneously activate - Duration 1 second

Must fix micro SD Adapter

Turn off pDRTu

RTC error

- Position 8, 7, 6 will simultaneously activate - Duration 1 second blinks

Must fix RTC

Turn off pDRTu Stimulus error

- Position 4, 3, 2 will simultaneously activate - Duration 1 second blinks

Stimulus not connected

Turn off pDRTu Two .ino files located in Annex C: pDRTu Arduino code are required to be uploaded into the Arduino NANO to configure the device for first time use or any event that requires replacement of the 3.3V DC coin cell used in the RTC module. The first upload is pDRTu_RTC_CA_1.0.ino (Figure C.1), used to set the current time of the RTC module. The second is pDRTu_Main_CA_1.0.ino (Figure C.2), the main code used to execute the experiment.

(22)

3.7 Testing procedure

See the flow-through chart in Annex B.2: Arduino programming logic and B.3: How to operate the pDRTu which outline the steps necessary to test and operate the pDRTu. The checklist in Table 7 should be used to ensure reliable pDRTu performance, and is ordered based on operation sequence of events.

Table 7: pDRTu operating checklist.

No. Check Purpose Possible Solution

Phase: Setup 1 Connect Arduino NANO to computer.

(This will turn on the Arduino NANO.) Make sure Arduino is not receiving external battery (switch is off).

Test Arduino NANO

is functioning. Replace Arduino NANO if cannot connect to COM port or NANO does not turn on. Look for short circuits within the integrated circuit.

2 Open serial monitor to confirm timestamp of RTC is correct.

Required for data analysis.

RTC error will occur. Replace RTC and/or check wiring.

3 Stimulus activates once during Arduino NANO boot up for approximately 1.second.

Confirm stimulus is working and connected.

Multiple solutions:

1. Stimulus/wire is broken – replace.

2. Stimulus is in wrong connector – move.

Phase: Stimulus and Response Button 4 Press response button, LED should

activate.

Confirm output to serial.

Confirm button is connected.

Confirm baud rate is 115200.

Replace response button.

5 Pressing “Start/Stop” button to activate stimulus.

Confirm output to serial.

Confirm Start/Stop button is connected.

Confirm stimulus activates correctly.

Button is stuck pressed in, fix.

Button not connected, check wiring.

Stimulus is not connected correctly.

6 Press Start/Stop and Next Phase button simultaneously.

Confirm both buttons work to get to next phase.

Fix sticky button.

Button not connected, check wiring.

Phase: Experiment 7 Stimulus activation after x time lapse.

Confirm output to serial. Check length of stimulus activation. Do not press response button. Check serial for Miss.

Confirm random start is working.

Confirm length of activation is set correctly.

Confirm correct unit of measure.

Check serial to check that experiment phase has begun.

Check stimulus wire is connected.

(23)

No. Check Purpose Possible Solution 8 After stimulus activates and stimulus

is off, press response button. Check serial for False Alarm.

Confirm correct metric.

Check code logic.

9 While stimulus is active, press the response button. Check serial for Hit.

Confirm stimulus turns off.

Confirm correct metric.

Check code logic.

10 Press Start/Stop and Next Phase button simultaneously. Confirm LED turns on and flash. Check serial for output.

Pauses experiment. Check wiring. LED should turn on with button press.

Check code logic.

11 Press Start/Stop and Next Phase button simultaneously. Confirm LED turns off. Check serial for output.

Resume experiment. Check wiring. LED should turn on with button press.

Check code logic.

12 Pause experiment, disconnect from the computer. Retrieve the micro SD card. Upload its contents to the computer to confirm that the outputs in serial match the output in the text file.

Confirm micro SD card is writing correctly, as this data will be used in analysis – data logger.

Check that micro SD card is formatted correctly and or replace micro SD card.

Phase: Portable (disconnected) Test

13 Turn on the Arduino NANO. Device can turn on. Check batteries and battery pack connection. Replace as deemed necessary.

14 Repeat steps 3 to 13. If the unit is not connected to the computer; serial for output will not work.

Unit is functioning correctly.

Problem solve associated with the step above.

15 Leave the unit in Experiment phase until it shuts off

Test battery limits on the unit to ensure it meets minimum time threshold.

Add or remove batteries by changing the type or quantity of battery.

3.8 Data output

Data was stored by writing directly to the micro SD card that was inserted into the micro SD adapter component. The following sub-section outlines the different write commands and their descriptions.

Outputted data has two purposes: (1) testing the function of the pDRTu and (2) record experiment events—for post hoc analysis. Table 8 defines the write commands used when the pDRTu was turned on, experiment was started, and experiment was paused.

(24)

Table 8: pDRTu start and stop data output description example.

Table 9 defines the data output when a hit, miss or false alarms occurred. Column Exp Time/FA Time to Stim Lapse was used to record the characteristics associated with the stimulation. The Exp Time to Unix Timestamp was used to record the exact moment the participant clicked the response button.

Table 9: Miss, hit and false alarm data output description example.

* Exp stands for Experiment.

** The millisecond difference between the start of the stimulus and when the false alarm occurred.

The UNIX time stamp was defined as the number of seconds that has lapsed since 1/1/1970. Therefore, using any software, add UNIX seconds to the 1/1/1970 to get the timestamp in date time format. An example, in Excel use the formula = (UNIX - Date(1970, 1, 1)) *86400.

Label Experiment Time

(Milliseconds) UNIX Timestamp Description (not in output)

Start of DRT 8003 1567588535 pDRTu turned on

Start Button Pressed 30507 1567588557 Begin/Resume

Stop Button Pressed 4928650 1567593454 Pause

Exp*

Time (ms)

Next SOA (ms)

Actual SOA (ms)

Stim Start (ms)

Stim Min (ms)

Stim Max (ms)

Stim Lapse (ms)

Exp*

Time (ms)

State Result Response

Time UNIX

Timestamp

263895 27709 27709 291604 18000 30000 1000 292605 1 M 0 1567588819 291604 22440 22441 314045 18000 30000 1000 315038 1 H 993 1567588841 FA**

Time (ms)

Next SOA (ms)

Actual SOA (ms)

Stim Start (ms)

Stim Min (ms)

Stim Max (ms)

Stim Lapse (ms)

Exp*

Time

(ms) State Result Response

Time UNIX

Timestamp 1125 27923 27923 263895 18000 30000 1000 265020 1 F 0 1567588791

(25)

3.9 Analysis

This sub-section outlines an example of how analysis can be conducted using DRT data. A frequentist approach includes performing descriptive (means, standard deviation, standard error) and inferential (significance) statistics.

For example, a vigilance scenario where two conditions, x and y, are evaluated for their ability to enhance participant navigation time and accuracy. There are two navigation tasks: (1) planning the route and (2) maneuvering the planned route. Focusing specifically on the cognitive load associated with planning and maneuvering, the independent variables are: condition, and navigation type. The dependant variables are response time (RT) and miss rate (MR)—defined in Section 2.1.

A two way analysis of variance (ANOVA) can be used to evaluate DRT RT for: (1) 2 (x, y) by 2 (Plan, Navigation). To adhere to the normality requirement of the ANOVA, all RT data can be evaluated using the Shapiro-Wilks test. RT data can be log transformed to ensure normality due to the Shapiro-Wilks returning the alternative hypothesis true. DRT MR has a distribution that is right skewed and bound at 0.

An ANOVA requires a normally distributed dependent variable; therefore a negative binomial model can be applied to fit the condition and phase. Given the MR data may be non-parametric, a Wilcoxon-signed ranked test can be used to evaluate the significance of x vs y during planning and navigating.

Studies that have evaluated the DRT method provide examples of how to conduct analysis. The scenario above resembles closely to research conducted by Jenness et al. where the DRT method was used to evaluate driver in-vehicle controlled interface workload while driving (Jenness, et al., 2020). In another study using the DRT method, a Bayesian approach was taken (Tillman, Strayer, Eidels, & Heathcote, 2017). There are multiple approaches in literature as to how analysis can be conducted.

Raw data had been exported from the pDRTu to alleviate parsing/structuring data at the time of result generation where a post-hoc activity can be performed to analyze and organize the information.

(26)

4 Lessons learned

4.1 Problems encountered

This sub-section will highlight the lessons learned during the development of the pDRTu.

4.1.1 Power supply and unit run time

The required operational run time for the pDRTu was three to five hours. Extensive tests were performed with power sources available at DRDC–TRC in order to understand the battery configuration required.

The first operational concept had a requirement to provide a more intuitive method of displaying information to the pDRTu operator.

The first iteration resulted in a high power consumption due to the bright intensity of the light emitting diode (LED) bank. The LEDs had primarily been in an “on” state in order to display information to the operator, which had depleted the 9V battery at a faster rate than anticipated. The LED panel was set to an

“on” state in order to provide the experimenter with information regarding pDRTu function. As a result, if any of the indictor LEDs were off, an error was present. Running the pDRTu unit in this mode resulted in a runtime of approximately 30 minutes before the 9V 280mAh battery became depleted. In an effort to increase the operational duration of the system without modifying the enclosure, a secondary 9V battery was installed. However, the results from utilizing two 9V batteries achieved an operational duration of approximately one hour and thirty minutes. It was necessary to modify the software to display LED prompts when there was an error. This caused the lights to flash continuously, or to signal a button press and stimulus activation. With this change, one 9V battery allowed the unit to last over six hours over moderate usage. Thus the battery requirement time duration was solved by switching from an always “on”

to momentarily “on” state.

Additional pDRTu’s were produced; however, upon testing the second pDRTu, the micro SD card adapter was not detected by the micro controller. The micro SD card adapter was removed and tested. Some adapters were in the batch were found to be faulty. A new micro SD card adapter was installed and the unit was verified. Unfortunately, the fault was still present. This result led to testing the Willwin Micro SD card adapter and assessing load requirements of the system. Table 10 contains the current draw specifications for each major circuit.

The diagnosed cause of the Willwin micro SD card adapter was a faulty batch of AS1117 DC to DC regulators (AMS1117). While the part was intended to take voltages up to 15VDC, multiple units from this batch were not able to function correctly at voltages exceeding 7–9VDC, resulting in premature part failure. To circumvent this problem, and not modify the battery harness, a single AA cartridge consisting of four AA batteries had replaced the 9V adapter. The use of the four AA batteries met the minimum voltage threshold for the peripherals to function correctly while increasing the “on” time substantially due to the higher mAh rating of the new battery configuration. The battery form factor change did not inhibit the function of the pDRTu.

(27)

Table 10: pDRTu load measurement.

Component Current Draw (mA)

Real Time Clock Module 20

SD Card Adapter 20

LED module (all set to on) 400

Tactor stimulus 350

4.1.2 Reading response button press

The response button was an integral part to executing the DRT method. If the Arduino NANO falsely detected a button press, it could diminish all validity of the unit. It was extremely important to ensure the response button was read precisely considering the test relies on recording presses to the hundreds of milliseconds. In the first iteration of the response button an arcade button was used. The button required for the study needed to be large due to the location of the button being fastened to the participant’s chest vest (allow dynamic movements). The arcade button (see Section 3.4) was directly connected to the Arduino NANO. Initially, when it was pressed, the Arduino NANO would read multiple button presses.

The circuit was normally open, and when the button was pressed it closed the circuit which caused a sharp spike and an unreliable reading—also referred to as Switch Debouncing (Greensted, 2010)—as per Figure 2.

Figure 2: Switch Debouncing (Greensted, 2010).

(28)

The preferred option was to apply a Schmitt trigger circuit; however, the extra space requirement was not ideal. Three alternative solutions were proposed based on lack of printed circuit board space:

1. Add a resistor to the connector between the button and the Arduino to have a simple pull-up circuit to try and remove extra pulse from the input signal.

2. Add a capacitor to the connection between the button and the Arduino to attenuate the input signal.

3. Add a function in the Arduino code to check for highs and lows of the signal to ensure that one button press did not produce multiple reading.

After testing was completed, implementation of solution 3 solved the problem and was incorporated in the final design.

4.1.3 Checking micro SD card, RTC and stimulus operation

The pDRTu required a self-test to confirm the micro SD card, RTC and stimulus functioned correctly.

Due to the portability of the unit, the experimenter had to rely on the pDRTu to identify an error, especially if the RTC or micro SD card components failed and/or the stimulus stopped activating. To solve this problem, self-test functions were implemented into the Arduino code.

The micro SD card adapter was tested when a write command was executed using the write2SDCard function. Code logic was incorporated to check if the output text file on the micro SD card existed and could be opened. If the file was not accessible, an error was thrown. The lights on the LED panel would blink, signalling the experimenter of the error—as per Section 3.6, Table 6.

The RTC would be verified every time a write operation to the micro SD card occurred, executing the command rtc.now() to retrieve the current timestamp in UNIX time. When the RTC was not functioning correctly, the UNIX time would translate to a date that was either not possible or the default date that would be present on a RTC power failure. The rtcInit function was executed to mitigate the risk of recording incorrect timestamps. The retrieved date was then verified against the specified date range for the exercise to ensure it was within the range. A date and time that was outside the specified range would result in an error code that indicated the RTC was not functioning correctly. The indicator lights on the LED panel would blink, signalling the experimenter of the error—as per Section 3.6, Table 6.

Verifying the stimulus operated correctly required a hardware modification to the assembly since software alone could not verify it activated. The new circuit was an additional response button type circuit where the stimulus closed the normally open circuit. When the stimulus was activated, the input on the Arduino NANO pin would be read as closed, confirming that stimulus was working correctly. However, after testing this solution, the voltage read from the input pin would change drastically for each tactor, each time the stimulus would activate. The varying response characteristics of the available stimuli had a large margin for error which made it difficult to determine whether the stimulus was truly connected. This self-test was not implemented prior to the experiment, and the stimulus connection had been verified by confirming activation when the RTC and micro SD card were tested during the start-up of the pDRTu.

Future revisions would address this concern to ensure the pDRTu stimulus is reliable. To circumvent this problem, experimenters made sure to query the participant on stimulus activation within a specific period of time—e.g., one minute intervals.

(29)

Note, every pDRTu was serviced after experimental use. This was to ensure a full battery bank, to verify all peripherals were operating correctly, and data collection was downloaded and logged for the relevant participant.

4.2 Future design

The version of the pDRTu configured in this report has addressed all of the primary objectives the unit was set out to achieve in Section 3.1. Time constraints prevented completing most secondary objectives in Section 3.2 The next revision of the pDRTu will rectify the following concerns and allow for improvements such as:

– Improve reliability during data acquisition:

 Develop a self-test that verifies the stimulus is working correctly during operational activities.

– Perform vigilance and discriminations tasks:

 Add additional breakout connectors to allow for multiple stimuli activation capability.

– Ease of use:

 Wireless communication to the microcontroller;

 WiFi—to support multiple participants on a single network;

 Allow for remote configuration and test protocols; and

 Increase distance between experimenter and participant to avoid skewing results.

– Improve error identification:

 Use OLED display in place of LED panel, for easier status/error notifications.

– Improve ability to fix/replace broken components:

 Modular interior components that would allow for rapid field servicing. i.e., battery compartment, micro SD card, and microcontroller component access.

(30)

References

[1] International Organization for Standardization, Road vehicles – transport information and control systems – detection-response task (drt) for assessing attentional effects of cognitive load in driving, ISO 17488:2016.

[2] G. Tillman, D. Strayer, A. Eidels and A. Heathcote, “Modeling cognitive load effects of conversation between,” Attention Perception Psychophysics, vol. 79, p. 1795–1803, 2017.

[3] T. A. Ranney, G. H. S. Baldwin, L. A. Smith, E. N. Mazzae and R. S. Pierce, “Detection Response Task,” National Highway Traffic Safety Administration Vehicle Research and Test Center, East Liberty, OH, 2014.

[4] D. Strayer, J. Turrill, J. Cooper, J. Coleman, N. Medeiros-Ward and F. Biondi, “Assessing Cognitive Distraction in the Automobile.,” Hum Factors, vol. 57, no. 8, p. 1300–1324, 2015.

[5] “DETECTION RESPONSE TASK,” Red Scientific, [Online]. Available:

https://redscientific.com/detection-response-task.html [Accessed 19 March 2020].

[6] P.K. Bengler, “ARDUINO DETECTION RESPONSE TASK DRT,” [Online]. Available:

https://www.lfe.mw.tum.de/en/downloads/open-source-tools/arduino-drt/ [Accessed 19 March 2020].

[7] “Arduino Nano,” [Online]. Available: https://components101.com/microcontrollers/arduino-nano [Accessed 20 March 2020].

[8] “Willwin 5PCS SD Card Module Slot Socket Reader Reading Writing Sensor Shield Module for Arduino Write SD Card Slot Socket Reader ARM MCU Control Board 3.3V 5V Programable,”

[Online]. Available: https://www.amazon.ca/Willwin-Adapter-Reader-Interface-

Arduino/dp/B076HKYDHM/ref=sr_1_fkmr0_1?keywords=Willwin+5pcs+Micro+SD+Card+Micro+

SDHC+Mini+TF+Card+Adapter+Reader+Module+for+Arduino&qid=1585581892&sr=8-1-fkmr0 [Accessed 20 March 2020].

[9] “XCSOURCE 5pcs DS3231 AT24C32 IIC Precision Real Time Clock Memory Module for Arduino TE536,” [Online]. Available: https://www.amazon.ca/XCSOURCE-AT24C32-Precision-Arduino- TE536/dp/B01IV3Z76E/ref=sr_1_1?keywords=XCSOURCE+5pcs+DS3231+AT24C32+IIC+Precisi on+Real+Time+Clock+Memory+Module+for+Arduino+TE536&qid=1585582556&sr=8-1

[Accessed 20 March 2020].

[10] “BestTong 15 PCS 10mmx3mm Mini Vibration Motors DC 3V 12000rpm Flat Coin Button-Type Micro DC Vibrating Motor for Mobile Cell Phone Pager Tablet Household Appliances,” [Online].

Available: https://www.amazon.ca/BestTong-12000RPM-Wired-Phone-

Vibration/dp/B071WYG59X/ref=sr_1_2_sspa?keywords=DC+3V+12000RPM+Two+Wired+10m m+x+3mm+Coin+Cell+Phone+Vibration+Motor&qid=1585585518&sr=8-2-

spons&psc=1&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUEyV1BWQTBETFJITVUwJmV [Accessed 20 March 2020].

(31)

[11] DesignSparks PCB, RS Components Ltd & Allied Electronics and Automation.

[12] J. Jenness, L. Boyle, J. Lee, E. Miller, S. Yahoodik, R. Huey, J.Y. Lee, A. Benedick and E. Petraglia, “In-Vehicle Voice Control Interface Evaluation: Preliminary Driver Workload and Risk Analysis (Report No. DOT HS 812 813),” National Highway Traffic Safety Administration, Washington, DC, 2020.

[13] “AMS1117,” DigChip, [Online]. Available:

https://www.digchip.com/datasheets/parts/datasheet/015/AMS1117.php [Accessed 1 May 2019].

[14] D.A. Greensted, “Switch Debouncing,” The Lab Book Pages, 17 June 2010. [Online]. Available:

http://www.labbookpages.co.uk/electronics/debounce.html [Accessed 1 May 2019].

(32)

Annex A pDRTu EBOM & schematic

A.1 pDRTu engineering bill of materials list

If accessing this document electronically, double click on Figure A.1 to open the electronic pdf which contains the bill of materials used to create the pDRTu.

(33)

A.2 Engineering schematic of pDRTu components

Figure A.2 depicts the component block diagram, relating the periphery components: battery pack, RTC, micro-SD adapter, LED screen, stimulus, and response button to the microcontroller. Figure A.3 depicts the stimulus cable connection diagram. Figure A.4 depicts the response cable connection diagram.

Figure A.5 depicts the control box diagram, outlining specific connection from periphery components to the microcontroller. Figure A.6 contains a bill of material list, with records of venders and equipment costs. Figure A.7 depicts the 3D printed case dimensions.

(34)

Figure A.2: pDRTu component block diagram.

(35)

Figure A.3: pDRTu stimuli cable connection diagram.

(36)

Figure A.4: pDRTu response button cable connection diagram.

(37)

Figure A.5: pDRTu control build of material peripheral connection diagram.

(38)

Figure A.6: pDRTu engineering build of material list total.

(39)

Figure A.7: pDRTu 3D-printed case dimensions.

Portable detection response task unit implementation

Defence Research and Development Canada