Hi All,

is there a way to accomplish a continuous "button pressed" recording with a Cedrus response box (RB-830)?

We are planning to do an experiment where the subject is supposed to press and hold a button while certain stimulus events are displayed on screen. We need to record a response as long as the button is depressed.

We cannot rely on the "button released" signal from the Cedrus box because the release may occur during an inter-trial interval and thus not be recorded.

What we would like to implement is a trial with a length of, say, 350msec that branches into itself. With continuous recording each trial where the button is still depressed would record the respective response code.

Bye, Malte

Those are XID devices, aren't they? If so, might be possible through the <xid> element and its properties:

https://www.millisecond.com/support/docs/v4/html/language/elements/xid.htm

That is massively helpful! I wasn't aware that there is an XID element in v4. I'll play around with that... NOW.

My current line of thinking is:

xid.XID_cedrus.erase=0

Maybe that will do already. I'll test and report.

I was thinking more along the lines of using the lastevent property. Shouldn't matter whether said event occurred during an ITI or not. I.e. you should be able to detect a state-change in any case.

That's interesting. Did not think about it, d'oh. I'll try that!

Huh, I just posted a longer answer to Dave's previous post but it doesn't show up. So I'll write again.

I just read into the XID protocol and looked at the abstraction layer http://cedrus-opensource.github.io/xid_device_library/d3/dfe/a00025_source.html. It offers some basic function to control an XID responsepad, such as get_next_response() and clear_response_queue(). Inquisit must be using these to control the Cedrus response pads. Apparently, my problems arise due to a very particular combination of circumstances.

(1) The XID function get_next_response() pops the oldest element from the queue, thus reducing queue length by 1.

(2) An XID responsepad offers three basic modes of signalling: continuous, pulse and doublepulse. Obviously, what I would require is "continuous" but Inquisit initializes to "pulse".

(3) Inquisit probably calls the clear_response_queue() function during trial initialization so that responses issued during the inter-trial interval are lost.

May I call on Sean Draine whether there is any way to either change (2) or (3) from within an Inquisit script?

Ok, did some testing.

The xid.XIDname.lastevent displays the last registered response, not the last actual response. This is probably due to Inquisit implementing the following control flow:

polling for response
  |
response is registered
  |
response polling stops and posttrialpause starts
  |
trial ends and pretrialpause for the next trial starts
  |
Inquisit does all preparations and as one of the final steps it clears the response queue
  |
with an empty response cue stimulus presentation starts

I always thought those modes only affected / applied to the box's *accessory connector*, not the box itself (cf. http://www.cedrus.com/xid/acon.htm; http://www.cedrus.com/xid/a1_set_mode.htm). I might be wrong, though. My personal knowledge of these pads is limited and I personally don't have one handy for testing.

I fear so, too, which would mean that the responsepad implements different behaviors for different output lines at the same time.

I got word from Cedrus support. They write:

"If
you are meaning to ask if the response pads can do an “auto repeat” like the
standard keyboard does, then the answer is no. It can not send a continuous
signal if you are holding down a key. It only sends a signal upon button press
or release."

There you go.

Seems that the only solution for my problem would be if Inquisit did not clear the response queue at the beginning of a new trial.