Arduino Detection Response Task DRT

Source code is available in our GitHub repository: https://github.com/InstituteOfErgonomics/ArduinoDRT

<iframe width="560" height="315" src="https://www.youtube.com/embed/56n4U_L-ERo" frameborder="0" allowfullscreen></iframe>

Information about this Documentation

Structure of the document: You may have one of the following interests:

  • Build the hardware. The hardware section can be your starting point
  • Operate a DRT. Someone has build up the hardware for you? You can directly jump to how to operate the device
  • Connect to a PC. If you want to connect the device to another device (e.g., PC, driving simulator, etc) the transmission formats can be of interest

Introduction

The Detection Response Task (DRT) is a method used to objectively obtain values for mental or cognitive workload of a task or task set (e.g. drive a vehicle while navigating through an infotainment system or speaking on the phone). The DRT is used as a part of the task set and performed at the same time as the other tasks.

To perform the DRT, persons must detect a stimulus (appearing randomly between a defined interval, typically between 3 and 5 seconds) and press a response button as quickly and accurately as possible to indicate they have perceived the stimulus. The stimulus can be visual or tactile: a red LED peripheral to the test subject (remote DRT) or mounted to his/her head (head mounted DRT), a vibrating motor placed on the participant’s shoulder (tactile DRT), respectively.

The DRT values (miss rate and reaction time of hits [RT]) are interpreted as the DRT measurement for the tasks under evaluation. The longer the RT, the higher the assumed cognitive workload resulting from task set performance. Miss rates reflect the degree to which the participant did not or was not able to detect the stimulus and or press the button.

The described hardware and software gathers these reaction data with an Arduino.

The DRT is currently being standardized (ISO/CD 17488), however, the values presented here do not necessarily reflect the “standardized” values or those under discussion by the DRT working group.

Why Arduino?

It is (relatively) cheap, wide spread, easy to program (even for non-programmers), the integrated development environment is simply a folder with an exe-file, it uses straight C-programming, with simplifications by supporting libraries. Additionally, it is a simple micro-controller board, without any nuisances for the programmer (no mnemonics, 80C166-paging, etc.). An important fact for this project: It uses no operating system (OS), thus, no scheduler or OS-functions will disrupt functionality and accurate reaction times are achieved without the need for a realtime OS.

The Project(s)

First, we introduce the Plain-Arduino-DRT on an Arduino Uno. This version simply carries out a DRT experimental protocol and saves the results on a SD card. The experiment can be controlled via serial commands (ex. start/stop) or manually with a start/stop button. The results can also be transmitted via USB/COM.

This simple version can also be expanded to the Ethernet-Arduino-DRT with an Arduino Uno and an Ethernet shield. This version fundamentally performs the same operations, but it additionally controlled via Ethernet and can also transmit results via the network. This allows the DRT to connected, for example, to a driving simulator.

Finally, an additional expansion of the Ethernet-Arduino-DRT was added to create the Mega-Arduino-DRT on an Arduino Mega and an Ethernet shield. This allows for more program code storage and additional hardware pins for increased connections. With this version of the DRT, it is possible to implement a setup with up to eight LEDs. Additionally, a real time clock is included with DHCP and NTP functions.

measure tactors logging to SD card USB Ethernet DCHP RTC&NTP Multi-LED
Plain-Arduino-DRT X X X
Ethernet-Arduino-DRT X X X
Mega-Arduino-DRT X X X X X X

Need a similar mobile solution: We also have an open source Mobile Detection Task (MDT) for Android The Arduino DRTs above can be also remote control and powered from USB OTG capable Android devices. Information and an open source application is available: USB remote control app

Please know that the sources are intentionally open source (GPL) in order to enable you to adjust the projects to your needs. It is up to you!! You can transfer it to an Arduino Nano, connect a GPS module or LCD, implement another transfer protocol better suited for your driving simulator, etc.

However, if you happen to find a bug – please report this to us via the github repositories or by emailing krause@tum.de

If you connect wires and equipment to a subject, please do it with caution and obey e.g., electric safety.

If setups are used while driving, special care must be taken. E.g. no cables or parts should interfere with being able to safely operate the vehicle. Think about what can fail while preparing the experiment (something gets loose, gets stuck to other parts,…).

This documentation is not in the public domain, but the following is valid for it:

THE DOCUMENTATION IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE DOCUMENTATION OR THE USE OR OTHER DEALINGS IN THE DOCUMENTATION.

Plain-Arduino-DRT

The Open Source Software

The open source code can be found at: https://github.com/InstituteOfErgonomics/ArduinoDRT

Hardware

So, let’s start with a wire diagram (Fig.1) a schematic (Fig. 2) and some photos of an early prototype (Fig.3).

Figure 1, wiring example. Plain-Arduino-DRT
Figure 2, schematic Plain-Arduino-DRT

The SD card connection is only indicated in the schematic. In the early prototype we used a micro SD adaptor and 1k-2.2k resistor voltage dividers to connect to a SD card. If you also want to do this, you can get further information from other sites e.g., http://nathan.chantrell.net/20111128/diy-micro-sd-shield-for-arduino/ or http://arduinodiy.wordpress.com/2012/03/28/sd-card-on-arduino/ .The later Ethernet-Arduino-DRT has an SD slot on the Ethernet shield, anyway. General information for Arduino and SD cards and connectors can also be found at http://arduino.cc/de/Reference/SDCardNotes .

We continue the description at Pin9 and get backwards to Pin2.

On Pin9 the Arduino outputs the stimulus signal. If this pin is high the LED is on and/or the tactor is running. For a typical stimulus LED the resistor of 150 Ohm should give a current of 20mA, change it according to the LED data sheet and purpose of your setup. The 470 Ohm for the stimulus control LED results in about 7mA, that’s enough that the examiner can see if the test subject currently gets (or should get) a stimulus signal. To switch the vibating tactor a Darlington NPN setup is sketched e.g. with BC547. With 2.2k it needs below 2mA from the stimulus pin. An alternative is an integrated Darlington (e.g. TIP 122), which provides lower saturation voltage drop and higher max. current rating. Another possibility we successfully tried, is to use an IC (e.g. TI DRV2603) for motor control; in the source code is a comment line how to get the 30kHz PWM to drive the IC.

The three loads sum up to around 30mA on Pin9. Acceptable if you do it only on one pin ( http://playground.arduino.cc/Main/ArduinoPinCurrentLimitations ). The tactor output is an open collector output, to connect easily to other devices.

On Pin7 and Pin8 a duo LED (e.g., KINGBRIGHT – L-937EGW) is used and indicates the status of the SD card logging. A duo or bi color LED is nothing else than two LED chips in one housing. You can also connect a red and green LED anode to cathode and cathode to anode and get the same result. The 470 Ohm is uncritical if you want a brighter indicator take 150 Ohm.

On Pin6 and Pin5 normal indicator LEDs are connected. The 470 Ohm is uncritical, if you want brighter indicators take 150 Ohm.Pin6 echoes back via software, if the reaction button is pressed. So the examiner can quickly check before the experiment, if the hardware button is working. During the experiment he or she sees that the test subject is responding. The LED on Pin5 indicates that an experiment is currently running. To start and stop an experiment you can send control commands via USB/COM to the Arduino or the examiner can press manually the start/stop button on Pin3.

Pin4 is intentionally left blank. The SD cards slots on Ethernet shields typically uses 4 for the SPI chip select signal to communicate to the SD card. If we build up the peripheral without Pin4, we can use it later unchanged with an Ethernet shield.

On Pin2 the response button for the test subject is connected. Pin2 has an important feature: Interrupt capability. One can enable interrupts only on some Pins. Pin2 is one of these. We need interrupts to easily get accurate values for the reaction times.

For the PlainDRT the analog input A0 is connected to the vibration motor, as a sense wire. Therefore it would be possible to detect, if a motor is connected and if the motor is running or stalled. The plainDRT includes a measurement function, we are currently testing. We hope to get data via the sense wire, to make the reaction time results from different motors comparable (see Back Electromotive Force BEMF application note: http://www.precisionmicrodrives.com/application-notes-technical-guides/application-bulletins/ab-021-measuring-rpm-from-back-emf ). Due to memory size restrictions the measurement capability is not included in the EthernetDRT.

Timing

To get the reaction times the projects relies on Arduino’s micros()-function (http://arduino.cc/en/Reference/Micros ) . Thus, the time quantization is 4 microseconds with the default timer and prescaling setup of an Arduino Uno. The resolution of 4 microseconds is judged to be more than enough, to assess human performance in the mentioned reaction tasks. By the way, the more important technical data is the accuracy of the timing, caused by the 16 MHz oscillator (Arduino Uno). It is preferred that the board/controller is running a crystal resonator and not on a ceramic resonator. Assume a worse conditioned ceramic resonator is accurate to say ~1%, you can measure 1 second with an uncertainty of about 10 milliseconds. A worse conditioned crystal is maybe two orders of magnitude better, thus the uncertainty is 0.1 milliseconds. With respect of this, it is maybe enough to report milliseconds, when you communicate your results. So e.g., report that you have found an average reaction time of 348ms or 0.348s. Please, do not report microseconds, but you can use it in your calculations.

Connectors

To connect the experimental setup (LED, tactor, response switch) it is convenient to use connectors, so you can change equipment parts. You are totally free in choosing the right connectors for your application, just some hints: It’s always a good decision to use common connectors, that are wide spread. You can easily get it, maybe you already have it and they are probably low priced. A drawback is that someone connects erroneously your device to equipment which is not intended for this purpose.

Aside, about how we selected the connectors for the prototype: For the stimulus LED we selected a chinch female connector. For the tactor a chinch male connector. For the response button a ¼ inch jack plug. Please keep in mind: If you plug in a jack plug it is possible that different metal parts inside the connector are unintentionally short-circuit. For our reaction button connector that’s not severe. A benefit is that for the close button you can directly use other devices, like keyboard pedals or guitar pedals, if they are wired as normally open (NO). All connectors are typical for audio, so cable extensions are widely available. A drawback of the male chinch connector in the pictures above: It can be easily short-circuit by metal parts. For the prototype it is ok; in the later Ethernet-Arduino-DRT it is replaced by two 4mm jacks, which are widespread in technical labors. Normally the clamping forces of the mentioned connectors are sufficient. If you want to make it even more robust BNC (bayonet lock) can be a choice.

Random stimulus onset

For the seed of the random function the code reads from the floating analog input A3. Please keep this in mind, if you make extensions and A3 is maybe not floating anymore, because you connected it.

Evaluation

If you have tweaked the code and want to evaluate if the project is working correctly, one first plausibility check is to have a look on the recorded onsetDelay values. If you find from time to time unusal high values, it’s likely that there is a misconception in the program flow / program architecture. E.g., if you transmit serial data or store data at the wrong time of the experimental protocol. In the projects these time consuming things are intentionally handled after a reaction or when the response window of 2500ms of the current stimulus onset is over. The next stimulus can be issued 3000ms (earliest) after the current one. Therefore the microcontroller has at least 500ms to manage data transmission and storage. 500ms are a long time for a microcontroller, normally. A hardware solution to check timings regarding the IRQ is, to use a CMOS 4040 and connect the stimulus onset to the reset pin of the 4040 and the Q12 to the reaction button pin. Then clock the input of the 4040 with an accurate laboratory frequency generator e.g., at 2.048MHz. The 4040 divides the clocking frequency and your program should record typical reaction times of about 1004 microseconds. (hint: For this test you have to invert some logic values in the source code or use inverters to connect the 4040)

Equipment

This document intentionally holds no information on how to apply the stimuli, by now. Just one note: If you are doing a tactile DRT, ensure that the test subject could not see the stimulus controll led on the device and thus gets an unintended visual stimulus.

Response Button

The following figures show, how you can make a response button from a cable, a hook-and-loop fastener, a micro switch and some two-component adhesive. Some micro switches are maybe used out of specification (e.g. total travel position), so don’t expect to get the full lifetime. It is a good idea to directly build two or more switches, for replacement.

response button; test subject can actuated it, by pressing against the thumb or the steering wheel

LED

The stimulus LED in the figure is a Kingbright L-53HD (Bright Red 700nm)@~20mA. If you do experiments, please report in your publications which equipment you use . Be carefull if you think about really bright LEDs (high output), they can cause harm to the test subjects, especially when mounted near to the persons as in some DRTs. The above mentioned LED emits only ~5mcd (the ‘bright’ for this LED is related to the color), this is enough for indoor use, without direct sunlight (e.g., driving simulator, dimmed laboratory).

stimulus LED mounted to a swan neck of an USB lamp (original LED including resistor replaced)

Vibro Motor

The vibration motor in the pictures was extracted from an old Alcatel One Touch Easy 302 phone and covered by a shrink tube. Other motors can be simply purchased, e.g., http://www.precisionmicrodrives.com/, http://www.robotshop.com/en/solarbotics-vpm2-vibrating-motor.html or https://www.sparkfun.com/products/8449. These motors a typically rated for ~3V. The schematic above connects the motor to 5V. The darlington configuration substracts from these about ~0.8V, thus the motor would be operated at about ~4.2V. Another option is, to put a fuse in series with the motor. (e.g., a F100mA 5×20), with the current of a motor this can reduces the 5V by another ~1V, together with the darlington the motor is than operated at about ~3V. The Arduino gets only little or no extra protection by the fuse (the Arduino 5V voltage regulator should be short circuit safe anyway). In case of using thin and long wires (e.g. audio cables) their resistance also has to be taken into account.

Another idea was, to attach the vibrator to a cheap piezo element (see picture) and measure frequency and typical starting lag (delay) of the tactor. The source code for the plain-DRT contains some measurement cabailities (in V2.0 state), to get indicational data about a tactor via a cheap piezo element. The measurement procedure is triggered via remote command ‘m’ (measure). The DRT switches on the tactor ten times and tried to get the vibration back via the piezo element. We got good results for frequency measuements, but unreliable results for other values. Thererfore, we switched in plainDRT V2.1 to Back Electromotive Force (BEMF http://www.precisionmicrodrives.com/application-notes-technical-guides/application-bulletins/ab-021-measuring-rpm-from-back-emf ) measurements. More information and a video about BEMF can be found at http://www.lfe.mw.tum.de/drt-rc

vibration motor from an old mobile phone, mounted inside a shrinking tube
different tactors
we connected a cheap piezo to get some indicational data from the tactors
TI DRV2603 in a prototype to drive an Linear Resonant Actuator

Audio

The output for the vibrating tactor is an open collector. Thus, you can try to connect other stuff. If the Arduino is set to an PWM value < 255, it outputs an square wave of about 500 Hz. Therefore, it can be directly used as audio output. If you connect headphones make sure you design a proper circuit (e.g. with resistors/voltage dividers) to protect e.g., the hearing of your test subjects. If you connect loudspeakers, calculate if the voltage regulator of the Arduino, the (USB) power supply and the output transistor are able to drive it. Maybe a safer way is, to use an high impendance input of another audio device (e.g. amplifier). Keep in mind, that depending on the type of the input (mic/line in) lower voltage levels are expected than ~4V (typ. <1V).

Operation

Normally an FAT formatted SD card should be inserted. The examiner than powers up the device, e.g. by plug in an USB cable from a safe power supply. If the SD card status LED flashes three times red and stays off the SD card initialization failed. If SD card init is ok, the SD status LED stays green after some seconds (with a lot of files the startup will take longer). By pressing down the experiment start/stop button an experiment can be started or stopped. Alternatively the experiment could be started via USB/COM by sending a ‘#’ char or Code 32 (Space bar) sign to the Arduino. To stop, send a ’$’ or code 27 (ESC button) at 115200 bit/s. While an experiment is running the ‘experiment running’-LED is on. You can send triggers to the Arduino via USB/COM to mark experimental conditions. Currently the ASCII-Codes 48-57 are supported (number buttons from 0 to 9).

It is possible to use the device without SD card logging (transmission to PC), if no SD cards is present at power up. If a SD card is present at power up and later failes during experiments, the device hangs intentionally. If you rely on SD card logging make shure that after power up the SD card LED gets green.

The results are logged to the root directory of the SD card. The file number is incremented before every experiment. The file number is stored in the Arduino EEPROM so it survives a power down. Every time the Arduino is powered up the file number is set to the next full hundred and incremented before each experiment. So, if you finish an experiment with a test subject logging to file number 106 and power down and power up the device for the next test subject the logging will use file number 201. This behavior can help to organize the results. Some drawbacks of the implementation: The root directory can hold only 512 files. For safety your Arduino will hang and the SD card status LED will fast blink red (10Hz), when it detects more than 500 files in the root directory. Solve the problem by empty the SD card or use another one.

The file number is stored in an unsigned Integer which will overflow at 65535. For safety your Arduino will hang and the SD card status LED will slowly blink red (0.5Hz), when it detects file number integer is greater 65000. To solve the problem you should reset the EEPROM file counter (command ‘~’). File numbers start again at 0. For clarity the SD card should also better be changed or emptied at this time. By the way, if a file number already exists on a SD card, for whatever reason, the logging data is appended at the end of to the file.

If you power the Arduino-DRT from a small powerbank you have a compact setup to do experiments mobile (e.g. Arduino on belt of the subject). Most powerbanks have a current threshold. If the connected device consumes less current, the powerbank is switched off after some seconds. The Arduino alone is often below this threshold. If an experiment with an vibro tactor is in progress the current could be high enough to keep the powerbank on. You can use this behavior as an advantage: If no experiment is running the power bank automatically switches off after some seconds and saves battery. If this behavior bugs you, simply connect a small load (e.g. one or two 100 Ohm 1/4W resistor in parallel) internally to the Ardunino +5V to consume some extra 50-100mA.

Another option is to power the Arduino DRT with an USB OTG adaptor from a phone or tablet. Further information and an app for USB remote control on Android: http://www.lfe.mw.tum.de/drt-rc

File Logging Format

In Version 1 the following CSV logging format is used.

count;stimulusT;onsetDelay;soa;soaNext;rt;result;marker;edges;edgesDebounced;hold;buttonDownCount;pwm

  • count, incremented with every stimulus starting with 1
  • stimulusT, micro seconds of this stimulus onset since begin of this experiment. In really long experiments (> 70 minutes) don’t expect in results analysis that stimulus is increasing monotonically due to an overflow of this long value (read ‘Notes on stimulusT overflow’ below)
  • onsetDelay, micro seconds difference between planned stimulus onset and actual stimulus onset stimulusT (normal around 20-50 micro seconds, and below 80 micro for the ethernetDRT and megaDRT).
  • soa (stimulus onset asynchrony), planned onset of this stimulus in relation to last stimulus. So: [stimulusT of last stimulusT (n-1)] + [soa(n)] + [onsetDelay(n)] = stimulusT(n) or you get the same value with [stimulusT of last stimulus (n-1)] + [soaNext(n-1)] + [onsetDelay(n)] = stimulusT(n)
  • soaNext, planned soa of next stimulus. Next stimulus should appear at: stimulusT(n) + soaNext(n). Rational: If you (or your program/driving simulation) know when and where the next stimulus will appear, you can synchronize other events to the stimulus and e.g., do priming experiments.
  • rt, reaction time in micro seconds. This is what you are mainly interested in.
  • results, classification of rt: ‘C’ cheat, test subject too fast. ‘H’ hit, ok. ‘M’ miss, test subject didn’t react. In case of miss rt = 0.
  • marker, default ‘-’ or ‘0’ to ‘9’ to mark experimental conditions
  • edges, detected signal edges on reaction button pin since last log line
  • edgesDebounced, detected signal edges after debouncing on reaction button pin since last log line
  • hold, hold time of button in micro seconds. Read ‘Notes about hold time’ below.
  • buttonDownCount, incremented everytime a button down press is detected, reset for every experiment
  • pwm, PWM stimulus strength 1-255. See ‘Notes about PWM stimulus strength’ below.
  • The header also includes information about the experimental plattform: V = Version number; -plain -e(thernet) -m(ega)

Example of a recorded file “00003101.TXT”:

count;stimulusT;onsetDelay;soa;soaNext;rt;result;marker;edges;edgesDebounced;hold;buttonDownCount;pwm;V1-plain

1;3806884;16;3806868;3142480;203648;H;-;1;1;0;1;255 2;6949372;8;3142480;3597687;235880;H;-;2;2;128388;2;255 3;10547092;33;3597687;3401512;295132;H;-;2;2;119992;3;255 4;13948628;24;3401512;4141807;204668;H;7;2;2;102924;4;255 5;18090444;9;4141807;4570770;203124;H;7;1;1;80460;5;255 6;22661236;22;4570770;3825528;234448;H;7;2;2;104392;6;255 7;26486776;12;3825528;4165387;186976;H;7;1;1;64736;7;255 8;30652200;37;4165387;3936967;194300;H;7;3;3;117904;8;255 9;34589196;29;3936967;4056133;197180;H;7;1;1;75744;9;255 10;38645352;23;4056133;4037160;0;M;7;0;0;103268;9;255 11;42682548;36;4037160;3046476;0;M;7;0;0;103268;9;255 12;45729064;40;3046476;3487363;230296;H;7;1;1;103268;10;255 13;49216460;33;3487363;3648362;179468;H;7;2;2;144340;11;255 14;52864856;34;3648362;4843072;1964;C;7;21;19;143140;21;255 15;57707972;44;4843072;3821353;205384;H;7;43;40;74124;41;255 16;61529364;39;3821353;4179251;0;M;7;0;0;96968;41;255

or formated as table:

countstimulusTonsetDelaysoasoaNextrtresultmarkeredgesedgesDebouncedholdbuttonDownCountpwmV1-plain
138068841638068683142480203648H-1101255
26949372831424803597687235880H-221283882255
3105470923335976873401512295132H-221199923255
4139486282434015124141807204668H7221029244255
518090444941418074570770203124H711804605255
6226612362245707703825528234448H7221043926255
7264867761238255284165387186976H711647367255
8306522003741653873936967194300H7331179048255
9345891962939369674056133197180H711757449255
103864535223405613340371600M7001032689255
114268254836403716030464760M7001032689255
12457290644030464763487363230296H71110326810255
13492164603334873633648362179468H72214434011255
145286485634364836248430721964C7211914314021255
15577079724448430723821353205384H743407412441255
166152936439382135341792510M7009696841255

You see 16 stimuli were presented the last about 62 seconds after the experiment started. The subject achieved 12 hits, 3 misses and 1 cheat. From buttonDownCount you can see 41 presses for 16 stimuli?! If you have a closer look at the buttonDownCount value of each line the subject began from line 13 to 14 to cheat (buttonDownCount jumps from 11 to 21) and continued to cheat (buttonDownCount jumps from 21 to 41). Before line 4 the experimenter set a marker (7). It is a hypothetical example, the reaction time is around 200ms and the subject has 3 misses and a cheat, not very typical.

Notes on stimulusT overflow: Like the micros()-value on Arduino Uno can overflow after about 70 minutes, the same thing can happen to stimulusT after 4,294,967,295 microseconds. The other values are not negatively affected by this overflow. If you really using the device in an experiment where a subject should operate the device continuously 70 minutes (without starting/stopping the experimental protocol) you will experience that in the recorded data the stimulusT value wraps around, so one line might report e.g., 4,294,000,000 and the next e.g., 3,000,000. Keep this in mind, if you analyze the data and rely on a monotonically increasing stimulusT. By the way, normally an experimental DRT condition is around 1 to 10 minutes. If you really want to distress your test subjects continuously 70 minutes, there is maybe something wrong in your experimental design.

Notes on hold time: The program directly sends and logs the result data, when the subject reacts (button down) and does not wait for button release. So the hold time comes always delayed and shifted in the next line. If the subject does not react (miss) the hold time is not calculated and left unchanged in the transmission packets. The hold time of the last stimulus is transmitted (USB/COM) in the experiment stop (result = ‘$’) packet; for SD logging it is discarded. To our knowledge up to now, the hold time does not hold valuable information for a DRT experiment. Typically it is below 200 millisec.

Notes about PWM stimulus strength: If you send ‘+’ and ‘-’ via serial line the stimulus strength can be adjusted. The PWM duty cycle value can be between 1 and 255. The value 0 can not be reached by sending ‘-’ signs, it stops at 1! The adjusted values are stored in the Arduino EEPROM (byte location 3) and thus survive power downs. If on power up the value 0 is detected in EEPROM-byte location 3, it is replaced by 255. So if someone clears the EEPROM, or use the software on a new Arduino, the PWM is set to full on. Normally it is enough to adjust the Arduino-DRT stimulus strength to a clearly perceivable value and is not altered during an experiment. Increments and decrements needs write-cycles to the flash memory. These cycles are limited depending on used flash technology (typ. 10,000-100,000 cycles).

If your experiment/setup extensively is altering PWM values, try to implement a better method (shortcut). E.g., that directly switch from one PWM level to another (high/low), needed in your experimental setup, and therefore reduces write cycles. If you have an experiment were you have to adjust the stimulus strength to every single test subject, you can turn the stimulus signal on (by sending ‘t’ via serial line) and adjust then by sending ‘+’ or ‘-’ and sometimes look at the pwm value you get back via the periodic ready packets (result = ‘R’).

Please, remember: The PWM value is stored in the EEPROM that holds this value even when power is disconnected.

If you have an Arduino DRT that worked for some time and now gives no or strange signals, check also the PWM value, if someone adjusted it to a hardly noticable value.

Connect

Transmission Format

The UART is set to 115200. You can use the Arduino IDE Serial Monitor (see Figure below) to send the commands manualy, or use any other COM/serial programs. Commands to send and receive over serial ports are also very wide spread (e.g. in Matlab, LabView, etc).

The control is achieved with a one byte protocol:

  • send ‘#’ char or Code 32 (space bar) to start experiment
  • send ’$’ or code 27 (ESC button) to stop experiment
  • send ‘0’, ‘1’, ‘2’, ‘3’, ‘4’, ‘5’, ‘6’, ‘7’, ‘8’, ‘9‘ to set experimental triggers also called marker
  • send ‘r’ to switch transmission from Arduino to a ’r’eadable format
  • send ‘b’ to switch transmission from Arduino to a ’b’yte format

If no experiment is running you can:

  • send ‘t’ to toggle the stimulus state between on/off for ‘t’esting, so the LED and/or motor gets on/off
  • send ‘+’ to increment the stimulus PWM strength by one step
  • send ‘-’ to decrement the stimulus PWM strength by one step
  • send ‘~’ to reset file name/number counter to 0

The later Ethernet-Ardunio-DRT has the following additional command, which can be send if no experiment is running:

  • send ‘p’ to ‘p’ing the Arduino. Usefull to determine roundtrip times.

The later Mega-Ardunio-DRT has the following additional command, which can be send if no experiment is running:

  • send ‘i’ for output of the IP-adress over serial.

Transmission from Arduino to e.g., PC

The binary format or readable output transport the following packet. For further information please look at the information at File Logging Format above. There are only some minor differences to the description above. The transmission to the PC contains a field for the file number currently the data are logged to. In the tranmission protocol are some statistical fields (mean reaction time, hit rate, hit count, cheat count and miss count), that are not logged directly to the file on the SD-card, because of redundancy. These values can be easily calculated from the logged results (e.g. with Excel).

If the Arduino currently not running an experiment it sends every second a ‘R’ eady packet (see field ‘result’). If an experiment is started the Arduino sends a ‘#’ start packet. At the end of experiment a ‘$’ end packet. If an error while logging to SD happens it sends an ‘E’rror packet. If on power up no SD card is detected it sends a ‘N’o SD card packet. The Ethernet Arduino can also output a ‘P’ing packet.

Packet:

type name note
unsigned int count stimuli/packet count
unsigned long stimulusT stimulus shown microsec (us) after start of experiment
unsigned long onsetDelay error in us of onset compared to schedule
unsigned long soa random stimulus onset asynchrony in us; current
unsigned long soaNext random stimulus onset asynchrony in us between current and next, you know when the next stimulus is coming, so you can e.g., prime or sync an event in driving sim
unsigned long rt reaction time in us; in case of miss, rt is set to 0
byte result ‘H’ hit, ‘M’ miss or ‘C’ cheat. status message ‘R’ ready to start, ‘#’ experiment started, ‘$’ experiment stopped, ‘N’ no sd card, ‘E’ error while logging, Ethernet Arduino can also output ‘P’ing packets.
unsigned long meanRt mean reaction time in this experiment, up to now
unsigned long hitCount count hits in this experiment
unsigned long missCount count miss in this experiment
unsigned long cheatCount count cheats in this experiment
byte hitRate hit rate in this experiment, up to now (0-100)
byte marker received marker ’0′ to ’9′
unsigned int edges edge count to detect hardware malfunctions
unsigned int edgesDebounced edge count to detect hardware malfunctions; edges after debounce
unsigned long hold button hold time at previous stimuli
unsigned int buttonDownCount how often button is pressed down during one experiment
unsigned int fileNumber to which file we are currently logging
byte stimulusStrength PWM signal strength of stimulus

If you want more from the transmission protocoll than just see the running experimental data, e.g. logging the data remotely on a PC and synchronous to another data source, depending on transmission line and required accuracy, the duration for the data transmission maybe has to be taken into account.

At the moment, we are setting up an Android application that parse the (readable / plain text) transmission from the Arduino DRT and to control an experiment over an USB OTG adaptor. This also has the advantage to power the Arduino DRT directly from a phone or tablet. Please visit again…

Ethernet-Arduino-DRT

Arduino Ethernet

The Ethernet-Arduino extends the Plain-Arduino-DRT by Ethernet capability.

The open source for the Ethernet-Arduino-Sketch sketch can be found at: https://github.com/InstituteOfErgonomics/ArduinoDRT

and compiled with about 30K code size. Thus, no space to use DHCP. To adjust it to your network, search for the code line

“IPAddress gIp(192,168,2,2);” and edit it.

The schematic is similar to the Plain-Arduino-DRT above (except the SD card connection). An Ethernet shield (with W5100 chip) is connected to the Arduino, therefore the SD card is directly on board. Serial and Ethernet can be used together, so it would be possible to start an experiment via serial commands and log results via Ethernet, or any other combinations. The communication and commands are the same (see above).

A SILAB snippet may can help you, to connect the Ethernet-Arduino-DRT to your SILAB driving simulation: silabSnippetEthernetDRT.txt

For tests or to control an experiment, you can simply use a telnet client. In newer Windows versions the Win-telnet has to be enabled manually ( http://social.technet.microsoft.com/wiki/contents/articles/910.enabling-telnet-client-in-windows-7.aspx ). If your Win-telnet is working, you can e.g. connect to your Ethernet-DRT by typing in “o 192.168.2.2 7008″ (adjust IP and port adress if needed). Then you can controll the DRT via the commands shown above (see “Transmission Format”) Socket communication is available in many programming languages and programs. Hint: Telnet clients are also available for Android smart phones. You can e.g., control an experiment with your smart phone.

Mega-Arduino-DRT

The Mega-Arduino-DRT uses a Arduino-Mega board and extends the Ethernet-Arduni-DRT by a real time clock (RTC). Thus the experiment files get the current time. To set the realtime clock, the sketch uses the network time protocoll (NTP). The sketch also uses DHCP for automatic IP configuration.Another feature is the use of a CMOS 4051 multiplexer. Up to 8 LEDs could be connected. So, the test subject has to react to more than one LED. The code uses extensive libraries and functions from other projects. This demonstrates how easy this kind of “mesh ups” can help you.

The open source for the Mega-Arduino-DRT can be found at: https://github.com/InstituteOfErgonomics/ArduinoDRT

and compiled with about 40K code size.

To get the sketch running, you need some timing and RTC functions that can be downloaded from: http://playground.arduino.cc/Code/time within a “Time.zip” file.

A SILAB snippet may can help you, to connect the Mega-Arduino-DRT to your SILAB driving simulation: silabSnippetMegaDRT.txt

The schematic indicates that with Mega-Arduino-DRT you can do even more interesting things. The 250K storage and the additional pins of the Arduino Mega put less limit to you.

What’s different to the above Arduino-DRTs?

It uses DHCP on power up (automatic IP configuration). It tries to get the correct time via Network Time Protocol (NTP) and set the connected Real Time Clock (RTC). If NTP fails, it uses simply the time from RTC. The RTC seconds are used for the dates and times of the files on the SD card and also added to every single logged data line. It is often easier to mange experimental results, if you know that a result was recorded e.g. at 7. January 2014 17:12:31.

Another difference is the use of a CMOS 4051 multiplexer. So the PWM stimulus output is not directly feed to a single stimulus LED, else it is switched by the 4051 randomly to one out of 8 stimulus LEDs. Please note, that the on-resistance of the 4051 is used as resistor for the LEDs. Check the data sheet, or better measure your 4051 and LEDs if this fits your purpose.

On power up the Arduino switches each stimulus LED sequentialy on, so it is easy to see everything is wired up correctly and working.

For other setups locate the code line: “const int STIMULUS_MULTIPLEXING = 5;” and adjust to your number of LEDs in the experiment.

 

The file logging format and the packets send via serial and ethernet are extended by three fields:

unsigned long unixTimestamp; //UTC seconds since 1970 this stimulus was issued

byte stimulusMultiX; //on which output the multiplexer randomly switched this stimulus; 0 is output/LED 1!

byte nextStimulusMultiX; //on which output the multiplexer will switch the next stimulus; 0 is output/LED 1!

You may wonder, why all protocols above include information about the time (soaNext) and output (nextStimulusMultiX) of the next stimulus after the current one. Rational: If you (or your program/driving simulation) know when and where the next stimulus will appear, you can synchronize other events to the stimulus and e.g., do priming experiments.

References

  • Krause M., Conti A., Späth M., Bengler K.(2014). Testing Open-Source Implementations for Detection Response Tasks. In Proceedings of the XV International Conference on Human Computer Interaction (Interacción ’14). ACM, New York, NY, USA, , Article 60 , 4 pages. DOI=10.1145/2662253.2662313 doi.acm.org/10.1145/2662253.2662313
  • Knott, V., Krause, M., & Bengler, K. (2013). Einsatz des KOLIBRI-Ampelassistenten im realen Straßenverkehr – Eine kognitive Belastung für den Fahrer?. 59. Kongress der Gesellschaft für Arbeitswissenschaft (pp. 437–440). Dortmund: GfA Press, Dortmund. If you used the project in an experiment, we would be thankful for your feedback.

Also if you altered the source code, or even made a new project out of it. Maybe we can set a link.