Millisecond Forums

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

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

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>

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

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

Hi Sean,



I emailed you the script.



-Andy

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

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

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

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>