By andy - 3/6/2008
Hi all,
I've got a little problem using my cedrus response box (rb830). I
installed the the driver from the cedrus homepage and now wanted to
test it. I used the seriell port monitor to check whether I receive
correct signals from the response box and I get them only for 6 of 8
keys. The keys top left and top right don't send signals (probabely they
should send the scancodes 64 and 128 - because the others send 1, 2, 4,
8, 16 and 32).
First I thought that there is something damaged in my box, but
meanwhile I tested seven different boxes and I get the same problem for all of
them.
Can anyone help me solve that problem?
Best,
Andy
p.s. I set the baud rate to 9600 and I put the DIP switches 1,2,3
upward as described in the instructions
(http://www.cedrus.com/support/rb_series/tn1044_dip_switches.htm)
p.p.s. I encounter the same problem using Inquisit2, too
|
By andy - 3/6/2008
Hi,
I found another interesting fact. I used the command "/inputdevice =
xid1" instead of "inputdevice=com1", changed the positions of the DIP
switches appropriately and then checked the box with the port monitor
again. Now all keys sent signals (so the two keys are probabely not
damaged) but I got the same signal from all eight keys.
Could the drivers be responsible for that?
-Andy
|
By seandr - 3/7/2008
Hi Andy,
Actually, the Serial Port Monitor wasn't designed to be used with a response box set to XID mode, so that's why you're seeing the same response for all the buttons. To properly test out XID mode, run the test script I whipped up below. Press each of the 8 buttons on each of the 8 trials. At the end, you can check the data file and see the response code for each button.
In the meantime, I'll look into the issue you mentioned in the previous post.
-Sean
<text test>
/ items = ("test")
</text>
<trial test>
/ stimulusframes=[1=test]
/ inputdevice = xid1
/ response = anyresponse
/ posttrialpause = 500
</trial>
<block test>
/ trials = [1-8=test]
</block>
<expt>
/ blocks = [1=test]
</expt>
|
By andy - 3/10/2008
Hi Sean,
thanks for the test script. Indeed I get a different response für each
key in the output file. The recorded responses are: 240, 112, 144, 48,
16, 183, 176, 171. Are that the expected values?
If so, can I use the xid mode as a standard for all my experiments, or
is there anything I have to consider - particularly concerning timing
accuracy ?
Do you already have an idea why defining "/inputdevice=com1" produces my problem (that two of the keys don't work at all)?
Best,
Andy
|
By andy - 3/11/2008
Hi Sean,
in the meantime I also encountered a problem with the xid-mode. The response box doesn't react on each single keypress in this mode espescially in fast series of reactions so that I sometimes have to press the key twice until Inquisit receives my reaction. Probabaly this is also not due to the box itself, because I've got the same problem with all of our response boxes.
Perhaps this might shed some light on the problem.
All the best,
Andy
|
By seandr - 3/11/2008
Andy,
I'll check into both of the issues you mentioned (com1 and xid1). When using xid mode, latencies are based on the dedicated timer in the response box itself rather than the CPU. They should therefore be more accurate, although my testing has shown pretty close correspondence between the CPU timer and that of the response box.
Just to be thorough, it might be a good idea to send your script in case it's related to some specific logic in it. You can email it to inquisit at millisecond dot com.
Thanks,
Sean
|
By andy - 3/12/2008
Hi Sean,
I emailed you the script.
-Andy
|
By seandr - 3/13/2008
Thanks, Andy.
Just tested the script out and xid mode seems to be working fine on my test computer. So, the first thing we should check is that your port and response box are both configured correctly.
First, make sure dipswitches 1 and 2 are down to set the box to xid mode, then make sure dipswitch 3 is down to set the baud rate to 115k.
Now, open Inquisit, select Tools->Serial Port Monitor, set the port number to 7 (or whatever number you are using), and click the Configure... button. You should see the following settings:
Bits per second: 115200
Data bits: 8
Parity: None
Stop bits: 1
Flow control: None
Let me know if this doesn't fix the problem and we'll take it from there.
-Sean
|
By andy - 3/13/2008
Hi Sean,
I followed your instructions, set all the dipswitches down, chose port
#7 and started the serial port monitor. Doing that I get a bit rate
different from yours. These are my settings:
Bits per second: 9600 (even so dipswitch 3 is down)
Data bits: 8
Parity: None
Stop bits: 1
Flow control: None
If I try to change the bitrate to 115k and restart the serial port
monitor the bitrate is at 9600 again.
Next I set the bit rate for the port to 115k using the device manger in
the control panel and now the serial port monitor shows the bit rate of
115k. I ran your test script above once again and in the output file I
now get some different responses (scankeys): 240, 112, 144, 48, 16,
208, 176, 80.
If I run another test script I wrote (to test each single key of the
response box) there still occurs a mistake I already encountered before
changing the settings: pressing one of the keys skips one or more
trials just as if I had pressed one of the keys in response to these
(skipped) trials, too. Even more interesting: looking at
the outputfile, I once more get different responses (scankeys): 240,
224, 112, 96, 144, 128, 48, 32. That's very confusing!
I'll send you this short test script to inquisit (at) millisecond dot
com. Perhaps this might help you. If I can do anything to assist you,
please let me know.
Kind regards,
Andy
|
By seandr - 3/14/2008
Hi Andy,
I just ran your script, and I understand what's happening.
The response box issues a signal both when you press and release a key. Since your script defines /validresponse = (anyresponse), both key presses are releases are treated as valid. If you pressed a key on one trial, the release of that key will be treated as a valid response on the next trial. The press code is different than the release code, which is why a given key might produce one of two different response codes.
Also, always make sure the baud rate on the port and response box are set to the same value as you did above (setting the port in device manager is just fine). If they are using different baud rates, presses are sometimes missed or result in strange unpredictable codes.
Here's a better script for testing the values of keys (both press and release).
<defaults>
/ inputdevice = XID3
</defaults>
<data>
/ columns = [response latency]
</data>
<expt>
/ blocks = [1=test]
</expt>
<block test>
/ trials = [1-20=test]
</block>
<text responsefeedback>
/ items = ("Response: <% trial.test.response %>")
/ position = (50%, 50%)
</text>
<trial test>
/ stimulustimes = [1=responsefeedback]
/ validresponse = (anyresponse)
</trial>
|
By andy - 3/18/2008
Hi Sean,
thanks for the script. I didn't know that the response boxes generate
two different signals for a press and a release. I ran your script and
got different scankeys for presses and releases just as you said.
Unfortunately, using that script I still got several severe problems with the boxes:
1) The key up right only produces a press signal and no one for a release!
2) Sometimes (on some trials) I get new scankeys different from the intended scankeys.
3) If I press the keys very fast - just like knocking on them- I only get the press key and no one for a release, too.
4) In my actual experimental script I still have some misses, when I
press on of the keys so that I have to press them twice to move on to the next trial.
Com
port settings and dip switches are set as described above.
These are the scancodes my boxes produce: (p=press; r=release; s=sometimes different key(s)
__________________________________________________________________
|
|
|
p: 112
p:
208
|
| p: 240
r: 96
r: 192
p:
16 |
| r: 224
s: 1/52/46 r: none |
| s: 72
|
|
p: 144
p: 176
|
|
r: 128
r: 160
|
|
s: 41
|
|
|
|
|
|
p: 48
p: 80
|
|
r: 32
r: 64
|
|
s: 94
|
|
|
__________________________________________________________________
Does that help you to get a clue of the problem?
Best,
Andy
|
By seandr - 3/19/2008
If you press more than one scan key at a time, you would get different scan values. For example, hold the key for 240 down, then press the one for 112. The result of the second press should be something other than 112. Could that be the reason you are seeing different code values?
If that's not it, let me know if the script you sent is up to date. If not, resend it to me and I'll see if I can figure out the problem.
-Sean
|
By andy - 3/19/2008
Hi Sean,
the script is still the same one I sent you some days ago. I did what
you suggested and I do not get the strange scankeys pressing two keys
at on time. The keys then are as they should be - I get the strange
scankeys pressing only one key. I tried the same in the "com mode"
(/inputdevice = com3; baud rate = 9600; dipswitches 1,2,3 up, 4 down)
and here I got the problem you described: if I press two keys
simultanously the resulting scankey (a new one) is the sum of the
scankey values of the single keys. In the com mode I additionally still
have the problem that the top right and top left keys of the response
box don't work at all (as I wrote in my first post to this thread).
Please let me sum all of the problems I found with my boxes to make the issue more clear:
In the xid-mode (/inputdevice = xid3; baud rate = 115k; dipswitches 1,2,3,4 down):
1) The key up right only produces a press signal and no one for a release! (this is probabely the worst problem in the xid mode
2) Sometimes (on some trials - perhaps on of 100 or 200) I get new scankeys different from the intended scankeys.
3) If I press the keys very fast - just like knocking on them- I only
get the press key and no one for a release, too (this happens nearly
always I do that).
4) In my actual experimental script I still have some misses, when I
press on of the keys so that I have to press them twice to move on to
the next trial (this also happens only very rare perhaps about five
or six times during my actual experiment)
In the com mode (/inputdevice = com3; baud rate = 9600; dipswitches 1,2,3 up, 4 down):
1) The fact that the top right and top left key do not work at all.
---------
I also contaced cedrus and got a test script for a demoversion of
superlab and in this script all the keys of the boxes worked correctly
- as far as I can judge- so it seems to me that it is not a problem on
the hardware side (but I can't say that definitely, too).
What do you think is the most probable source of the problem? (a
mistake in my scripts and/or the testscripts - a mistake in my
installation of the drivers - a hidden problem in the hardware - a
hidden problem in Inquisit - anything else). I hope you're able to find
the problem.
Kind regards and thanks for you efforts,
Andy
p.s. please let me know if I can do anything else to assist you.
|
By seandr - 3/20/2008
Andy,
Issue 1: So far, I've been unable to replicate this, although I have some other ideas for testing. Does the test script you got from Cedrus register both a key press and release for the upper right key?
Issue 2: Which script does this happen on, the test script I sent, your experiment script, or both?
Issue 3: If you repeatedly knock on the keys as fast as you can, I would expect Inquisit to miss some of the key presses and releases no matter what script you are using because there will always be a brief period of time between trials when Inquisit isn't listening for a response. At the beginning of each trial, Inquisit prepares the stimuli and waits for the beginning of a screen refresh interval to present the stimulus before it starts checking for a response. Unless you are running a task that requires the participant to knock on the keys as fast as possible, this probably isn't the best way to test whether the response box is working.
Issue 4: I've run your experiment a few times but still haven't replicated this. When you've had to respond twice, is it possible you are responding before the stimulus is presented? Your trials have a 200 ms pause at the end, so any key press during that time would be ignored.
Just to narrow the testing down a bit, I've modified the test script that I posted earlier. In this new script, you have to wait until the "GO!" stimulus appears before responding, you can't just respond at any point. Can you try this new script and let me know if Inquisit is still missing key presses that occur after the go stimulus appears?
-Sean
<defaults>
/ inputdevice = XID3
</defaults>
<values>
/ response = 0
</values>
<data>
/ columns = [response latency]
</data>
<expt>
/ blocks = [1=test]
</expt>
<block test>
/ trials = [1-200=test]
</block>
<text responsefeedback>
/ items = ("Response: <% trial.test.response %>")
/ position = (50%, 50%)
</text>
<text go>
/ items = ("GO!!")
/ position = (50%, 50%)
/ txcolor = green
</text>
<trial feedback>
/ stimulustimes = [1=responsefeedback]
/ timeout = 500
</trial>
<trial test>
/ stimulustimes = [1=go]
/ branch = [if (true) trial.feedback]
/ validresponse = (anyresponse)
</trial>
|
By andy - 3/20/2008
Hi Sean,
once more thanks a lot for the test script. I think, we could already solve one of the problems with it.
I tried out your test scripts and didn't get any misses. I also removed
the posttrialpause in my script and always explicitly waited until the
next stimulus was presented. I ran the experiment several times and
didn't have any misses in it any longer. So indeed the problem with the
misses probabely was due to too fast responses. Thanks for solving that.
Issue1: In fact I do not definitly know that (I don't know too much
about the SuperLab Software), but I already contacted cedrus to
clearify that. I let you know as soon as I know more.
I also used your new test script to replicate the problem with the top
right key and I also got the problem with the new script. If I just
press one of the keys I get the correct responses for all keys ("16"
for the top right key). If I keep one of the keys pressed after
one trial until the next "GO" appears and then release the key I get
the scankeys for the releases. This works fine for all keys except the
top right one. I do not get a release-response from this key at all.
Issue2: This happened on your former test script (from post #1420).
Issue3: Sorry, I didn't describe this problem clearly enough. For this
problem it's enough to press the key only once, but do this very fast
and with a lot of force (so that there is only very few time between a
press and a release). So this might perhaps be due to some kind of a
too short refresh rate or something comparable.
Issue 4: Solved!!
The most severe problem to me now are the keys that do not work
correctly in the xid as well as the com mode (I let you know the
response from cedrus on that).
Best,
Andy
|
By seandr - 3/21/2008
Good, glad to hear we're making some progress.
A quick follow up question on issue 2 - do you still occassionally get the wrong scan code with the new test script seems I sent?
-Sean
|
By andy - 3/30/2008
Hi Sean,
sorry for my delayed response. I havent't been in my office last week.
In the meantime I once again checked your test script and unfortunately
I found some wrong scankeys in that test script, too. I ran 600 trials
and for the key of the right indexfinger I once got the scancode 249
and once 105 instead of 176. (the script doesn`t test the key
releases - perhaps this might also produce some mistakes).
All the best,
Andy
|
By seandr - 4/1/2008
Hi Andy,
I'm in touch with Cedrus now to working to resolve this. I will post back when I get more info.
-Sean
|
By seandr - 4/7/2008
Andy,
I just released Inquisit 3.0.2.0, which I believe has the fixes for the issues you discovered. I've also put together an article with detailed instruction on how to configure the response box and the serial ports for use with Inquisit. You'll find the article here.
Try downloading the new version and taking a look at the article, and let me know if you see any more issues.
Regards,
Sean
|
By andy - 4/10/2008
Hi Sean,
thanks for the fixes in the new version. Now we are making real progress. Here is a short summery of my test results:
Problem1: Solved!! Now I get a release scankey for all keys. The scankeys are as follwos:
-------------------------------------------------
pr.:240 pr.:112
pr.:208
pr.:16
re.:224 re.:96
re.:
192 re.: 0
pr.:144
pr.:176
re.:128
re.:160
pr.:48
pr.:80
re.:32
re.:64
-------------------------------------------------
Problem 2: Solved! I didn't encounter any strange scankey any more! Yep!
Problem3: Solved!
Problem4: Already Solved before!
Thanks for helping me with all these problems!!!
Unfortunately I also have a new problem with version 3.0.2.0. Inquisit
seems to have a problem with recognizing my response box, because when
I start an experiment the box doesn't work at all. This happens wtih
all my experiments as well as with the test scripts you sent me.
But!, when I start a superlab test script I do not have problems with
my boxes at all. And most interstingly after having the superlab demo
run, the box also works with Inquisit - this time perfectly with all
four problems mentioned above solved. When I then restart my computer
the problem starts again and I have to run the superlab demoscript
before I can use the response box with Inquisit. Do you have an idea
what the reason for this could be?
All the best,
Andy
|
By seandr - 4/11/2008
I wonder if the SuperLab is automatically configuring the port settings when you run the script? You might try checking the settings in Device Manager, then running the SuperLab script, then checking them again to see if they change. That would be clue.
Another thing I've noticed is that when changing the dipswitches back and forth, I sometimes have to unplug the cable from the box in order for the changes to take effect.
-Sean
|
By andy - 4/13/2008
Hi Sean,
after running the superlab script, port settings are still the same as before
(all settings are just like they are recommended for the xid mode). I
also tried unplug and replug the usb cable, but that didin't change
anything, too. Do you have another idea for the problem?
Kind regards,
Andy
|
|