# good news regarding fORP and PsychHID('KbCheck') **URL:** \ **Category:** Uncategorized\ **Created:** [June 15, 2007, 5:06pm UTC](https://psychtoolbox.discourse.group/t/good-news-regarding-forp-and-psychhid-39-kbcheck-39/947 "2007-06-15T17:06:37Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Allen\_Ingling](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Allen\_Ingling](https://psychtoolbox.discourse.group/u/Allen_Ingling)\ **Post date:** [June 15, 2007, 5:06pm UTC](https://psychtoolbox.discourse.group/t/good-news-regarding-forp-and-psychhid-39-kbcheck-39/947/1 "2007-06-15T17:06:37Z")
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@...](mailto: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](http://vision.berkeley.edu/vsp/content/people/faculty/silver.html) ---
**Author:** ![vvanwass](https://avatars.discourse-cdn.com/v4/letter/v/ed655f/32.png) [@vvanwass](https://psychtoolbox.discourse.group/u/vvanwass)\ **Post date:** [June 15, 2007, 11:18pm UTC](https://psychtoolbox.discourse.group/t/good-news-regarding-forp-and-psychhid-39-kbcheck-39/947/2 "2007-06-15T23:18:21Z")
Hi and sorry I realized I did not give an update on the situation with the Dell PC. We actually found the solution by doing the following (part of this was suggested by Mario): - non-auto release: standard keycodes - button presses were now detected as 'r, g, y and b' in Matlab - KbCheck functions well and gives great timing -Virginie **_Michael Silver \_** wrote: > > 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@curdes. com](mailto:bdugan%40curdes.com). 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](http://vision.berkeley.edu/vsp/content/people/faculty/silver.html) > > > > * * * > Take the Internet to Go: Yahoo!Go puts the [Internet in your pocket:](http://us.rd.yahoo.com/evt=48253/*http://mobile.yahoo.com/go?refer=1GNXIC) mail, news, photos & more. ---
**Author:** ![Allen\_Ingling](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Allen\_Ingling](https://psychtoolbox.discourse.group/u/Allen_Ingling)\ **Post date:** [January 14, 2009, 11:32pm UTC](https://psychtoolbox.discourse.group/t/good-news-regarding-forp-and-psychhid-39-kbcheck-39/947/3 "2009-01-14T23:32:47Z")
Hello, I have an intel Mac from 2006 running Mac OSX 10.5.6 where psychtoolbox works well with our fORP interface at our fMRI scanner. A friend of mine recently got a new MacBook Pro (two weeks ago) and tried to run the exact same psychtoolbox program with the same version of matlab, etc. on that machine. In helping her troubleshoot, I tried a few other machines that people have in our lab, including a macbook from 2007 (same OS) and a MacBook from the same time as my own. On my computer and the other Mac from the same time as mine, the button box (fORP) works well on all settings (we use 4 to get numeric output). However, on the newer machines, the "4" setting does NOT work. From the message below, I tried using the "0" setting, in which case we are able to collect the byrg output, but cannot get it to output numbers. Is there a solution here, short of just converting the data once it has been read in? Thanks! Emily > --- In [psychtoolbox@yahoogroups.com](mailto:psychtoolbox@yahoogroups.com), Michael Silver \ wrote: > \> > \> 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](http://vision.berkeley.edu/vsp/content/people/faculty/silver.html) > \>