1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
Hardware compatibility
=======================
Video cards
-----------
We generally have good experiences with recent NVIDIA or ATI cards. OpenGL
mode should work with all drivers that use an OpenGL specification >=
2.0. Drivers implementing an older OpenGL specification (>= 1.4) should work
when the 'GL_ARB_texture_non_power_of_two' extension is present.
On some some integrated Intel cards syncing to the vertical retrace does not seem to work!
Working configurations
~~~~~~~~~~~~~~~~~~~~~~
Here is a list of configurations we observed to work:
* Nvidia GTX 650 (Linux-x86; NVIDIA driver 310.14)
* Nvidia Quadro NVS 290 (Linux-x86; NVIDIA driver 295.40)
* Nvidia Quadro NVS 290 (Windows XP SP3; NVIDIA driver)
*We recommend to always use the Expyriment test suite to check the
performance of your specific configuration!*
External devices
----------------
Besides standard serial and parallel port communication, there is special
support for:
* `Event button box`_
* `Streaming button box`_
* `Trigger input`_
* `Marker output`_
* `Cedrus response devices`_
Event button box
~~~~~~~~~~~~~~~~
An event button box is a simple device which sends out values (bytes) whenever
a button is pressed (or released).
Event button boxes can be used by initializing an
:doc:`expyriment.io.EventButtonBox`
object::
bb = expyriment.io.EventButtonBox(expyriment.io.SerialPort("COM1"))
key, rt = bb.wait() # Wait for any value
Streaming button box
~~~~~~~~~~~~~~~~~~~~
A streaming button box constantly sends out a certain baseline value (e.g. 0)
in predefined intervals (e.g. each 1 ms). Button press (or release) events (if
present) are added to the baseline.
Streaming button boxes can be used by initializing an
:doc:`expyriment.io.StreamingButtonBox` object::
bb = expyriment.io.StreamingButtonBox(expyriment.io.SerialPort("COM1"),
baseline=128)
key, rt = bb.wait() # Wait for any value other than 128
This allows for instance for calculating the response timing without relying on
the computers internal clock, but by "counting" the incoming bytes from the
button box::
bb = expyriment.io.StreamingButtonBox(
expyriment.io.SerialPort("COM1"), baseline=128)
bb.clear()
exp.clock.wait(1000)
rt = bb.interface.read_input().index(129) # Get reaction time by counting
# input events since last clear
It is important to notice that operating systems only buffer a certain amount
of bytes (usually 4096). To prevent an overflow of this buffer, the button box
has to be checked regularly. Additionally, an ``input_history`` can be used on
the :doc:`expyriment.io.SerialPort` object which is automatically updated
whenever the serial port is polled or cleared. By setting the
``os_buffer_size`` correctly, a warning will be logged whenever the amount of
bytes in the OS serial port buffer reaches maximum capacity. **The important
part now is to update the input_history regularly**. To gain maximal control,
this should be done manually at Sending to external deviceappropriate places in
the code. However, Expyriment provides also the possibility to register a
callback function which will be called regularly during all waiting methods in
the library. By registering the ``check()`` method of the streaming button box,
the ``input_history`` will be updated fairly regular, which should suffice for
most use cases::
expyriment.control.register_wait_callback_function(bb.check)
bb.interface.input_history.check_value(129) # Check if 129 was
# received at any time
# RT by counting elements in input history
start = bb.interface.input_history.get_size() - 1
exp.clock.wait(1000)
rt = bb.interface.input_nput_history.check_value(129,
search_start_position=start) - start
Trigger input
~~~~~~~~~~~~~
Expyriment can wait for triggers from external devices, like for instance an MR
scanner.
When updated regularly, Expyriment can also keep track of the amount of
triggers that have been received. Importantly, this has to be done manually
Trigger inputs can be used by initializing an :doc:`expyriment.io.TriggerInput`
object.
**Basic usage**
In most of the cases, a researcher knows when a trigger is to be expected and
he can wait for it explicitly. Code execution will be blocked until the trigger
is received::
trigger = exyriment.io.TriggerInput(expyriment.io.SerialPort("COM1"))
trigger.wait(1) # Wait for code 1
**Advanced usage**
In some cases, code blocking might not be a solution, since a trial has to
continue while waiting for the trigger. For instance, in an fMRI study, a trial
might consist of several components and span several TR. One way to solve this
would be logging constantly all input events in a separate thread. However,
this will introduce timing uncertainties, since the operating system is in
charge of how and when threads communicate. We thus decided against an
implementation with threads for the same reasons Expyriment does not implement
a main event loop: Maximal control by the user. Nevertheless, input events can
still be buffered without introducing timing uncertainties, given the following
two conditions:
1. Incoming events are streaming, either by sending some baseline in regular
intervals (e.g. a 0 each millisecond), or by a regular incoming signal of
interest (e.g. a constant TR from the MR scanner).
2. The input device is polled regularly, such that the serial port OS buffer
does not overflow. (Most implementations use an OS buffer of 4096 bytes).
If those two conditions are met, an ``input_history`` can be used on the
:doc:`expyriment.io.SerialPort` object which is automatically updated whenever
the serial port is polled or cleared. By setting the ``os_buffer_size``
correctly, a warning will be logged whenever the amount of bytes in the OS
serial port buffer reaches maximum capacity. **The important part now is to
update the input_history regularly**. To gain maximal control, this should be
done manually at appropriate places in the code. However, Expyriment provides
also the possibility to register a callback function which will be called
regularly during all waiting methods in the library. By registering the
``get_trigger()``
method of the input trigger, the ``input_history`` will be updated fairly
regular, which should suffice for most use cases::
trigger = exyriment.io.TriggerInput(expyriment.io.SerialPort(external"COM1",
input_history=True, os_buffer_size=3000))
expyriment.control.register_wait_callback_function(trigger.get_triggers)
print trigger.trigger_count
Marker output
~~~~~~~~~~~~~
Expyriment can send markers to external devices, like for instance EEG
computers.
Marker outputs can be used by creating an :doc:`expyriment.io.MarkerOutput`
object.
**Basic usage**
Sending out markers is straight forward. Some devices (e.g. EEG systems) expect
a 0 to be send after the code. We can specify this by telling the output marker
at what duration this 0 is supposed to be sent::
marker = expyriment.io.MarkerOutput(expyriment.io.SerialPort("COM1"), duration=20)
marker.send(1) # Send code 1
Cedrus response devices
~~~~~~~~~~~~~~~~~~~~~~~
Expyriment comes with a high-level wrapper for Cedrus response devices
expyriment.io.extras.CedrusResponseDevice_, which allows you to easily use all
Cedrus response devices.
To use these devices, however, the third-party Python package pyxid_ needs to
be installed on the system.
**Installing pyxid**
* Download_ pyxid
* Install as described here_.
.. _pyxid: https://github.com/cedrus-opensource/pyxid
.. _Download: https://github.com/cedrus-opensource/pyxid/zipball/master
.. _here: http://docs.python.org/install/index.html#the-new-standard-distutils
.. FIXME: io.extas.CedrusResponseDevice is not in docu yet
|
