Hi all,
There has been a long-standing thread on this forum about the
difficulty in collecting responses from a fORP using
PsychHID('KbCheck'). For OSX, this problem was "fixed" by some users
by upgrading their computers and/or operating systems. For example,
our G4 (OSX 10.3) never detected fORP keypresses, but our G5 (OSX
10.4) detects them without any apparent problem. However, it has been
unclear why some computers/operating systems work and some don't.
Ben Dugan from Current Designs (the fORP manufacturer) has discovered
a potential explanation for this. Here is what he says:
"USB HID keyboards send 8 byte packets, of which six are used for the
keycodes themselves. If we think of those 6 as bytes 1 through 6, it
seems that most keyboards always put the first keypress in byte 1. If
only one key is pressed, it appears in byte 1. This is how the
keyboard data looked from keyboards I checked, but its not the way
the fORP does things, except in position 6. In the other switch
positions, the fORP sends only 5 possible keycodes (for 4 buttons and
the trigger), and they are fixed in their byte location in the
packet. For instance, the keycode for 'r' is always sent as byte 6,
even if no other keys are pressed. From what I can see, the USB spec
does not require byte 1 to be used first, but that is a natural way
to do things when you're making a keyboard with 100 or more keys. For
our unusual case of 4 keys (in most fORP program switch positions),
the way I did it made sense (to me, anyway!). I suspect that some
programs that read the packets at a low level expect the first byte
to have data if any keys are pressed."
Position 6 on the fORP is designed for eight-button devices, but it
works fine for four-button devices. Pressing the four buttons on the
response pad will cause the fORP to send characters 1, 2, 3, and 4
(not r, g, y, and b, as in some of the other positions), and TTL
pulses will be sent as character 5 (not t). We tested position 6 on
our G4 and it worked perfectly. The same setup did not record any
responses when the fORP was in position 0.
Ben encourages all Psychophysics Toolbox users to contact him with
questions or feedback at bdugan@.... If this turns out to be a
general solution, he plans to change the byte ordering in all the
fORP positions to make it more like USB HID keyboards.
Cheers,
Michael Silver
--
--------------------------------------------------------------------------------
Michael Silver
Assistant Professor
School of Optometry and Helen Wills Neuroscience Institute
360 Minor Hall, #2020 (mailing address)
582 Minor Hall (actual lab location)
University of California, Berkeley
Berkeley, CA 94720-2020
TEL: (510) 642-3130
FAX: (510) 643-5109
http://vision.berkeley.edu/vsp/content/people/faculty/silver.html
There has been a long-standing thread on this forum about the
difficulty in collecting responses from a fORP using
PsychHID('KbCheck'). For OSX, this problem was "fixed" by some users
by upgrading their computers and/or operating systems. For example,
our G4 (OSX 10.3) never detected fORP keypresses, but our G5 (OSX
10.4) detects them without any apparent problem. However, it has been
unclear why some computers/operating systems work and some don't.
Ben Dugan from Current Designs (the fORP manufacturer) has discovered
a potential explanation for this. Here is what he says:
"USB HID keyboards send 8 byte packets, of which six are used for the
keycodes themselves. If we think of those 6 as bytes 1 through 6, it
seems that most keyboards always put the first keypress in byte 1. If
only one key is pressed, it appears in byte 1. This is how the
keyboard data looked from keyboards I checked, but its not the way
the fORP does things, except in position 6. In the other switch
positions, the fORP sends only 5 possible keycodes (for 4 buttons and
the trigger), and they are fixed in their byte location in the
packet. For instance, the keycode for 'r' is always sent as byte 6,
even if no other keys are pressed. From what I can see, the USB spec
does not require byte 1 to be used first, but that is a natural way
to do things when you're making a keyboard with 100 or more keys. For
our unusual case of 4 keys (in most fORP program switch positions),
the way I did it made sense (to me, anyway!). I suspect that some
programs that read the packets at a low level expect the first byte
to have data if any keys are pressed."
Position 6 on the fORP is designed for eight-button devices, but it
works fine for four-button devices. Pressing the four buttons on the
response pad will cause the fORP to send characters 1, 2, 3, and 4
(not r, g, y, and b, as in some of the other positions), and TTL
pulses will be sent as character 5 (not t). We tested position 6 on
our G4 and it worked perfectly. The same setup did not record any
responses when the fORP was in position 0.
Ben encourages all Psychophysics Toolbox users to contact him with
questions or feedback at bdugan@.... If this turns out to be a
general solution, he plans to change the byte ordering in all the
fORP positions to make it more like USB HID keyboards.
Cheers,
Michael Silver
--
--------------------------------------------------------------------------------
Michael Silver
Assistant Professor
School of Optometry and Helen Wills Neuroscience Institute
360 Minor Hall, #2020 (mailing address)
582 Minor Hall (actual lab location)
University of California, Berkeley
Berkeley, CA 94720-2020
TEL: (510) 642-3130
FAX: (510) 643-5109
http://vision.berkeley.edu/vsp/content/people/faculty/silver.html