I would like to send a signal into my RB-730 to provide a timestamp to synchronize my external device. I don’t know whether my device is in General Purpose or Reflective mode. How can I switch it into General Purpose mode?
I have the Accessory Connector connected, with the naked 8 wires at the ready but touching any two of them together seems to have no effect on the buttonbox data (except for touching the power pin to the ground pin, which crashes the device). This is why I think I may be in Reflective mode, am I thinking along the right lines here?
By default, the response pads are set to Reflective mode. If you are communicating via XID mode (I assume you’re doing some programming), you can switch modes using an XID command. We also provide a utility program called Xidon (pronounced Zydon) that lets you switch modes.
oh, that’s great news. I’m working on OSX, programming in Python, so I can’t run the .exe utility unfortunately. Probably you don’t have a version for OSX, so can you tell me the XID command I should send? I am new to XID communication though. So you see what I’m doing, to reset the clock I send the buttonbox the string ‘e5’. I’ve posted the full details at: http://openwetware.org/wiki/Holcombe:ButtonBox
You need the a1 command, “Set Accessory Connector Mode”.
BTW, you may need to add a few milliseconds delay in between commands sent to the response pad. I’m working on a web page that describes any needed latencies.
thanks, I now have managed to communicate successfully with the response pad across the USB port using XID and using all the commands I need (switching to general purpose mode, setting the lines to input mode to allow external trigger, resetting the reaction timer, detecting and reading external trigger and button events).
However almost every one of these functions is very unreliable, even though I always insert code to wait for 100 ms after each command or trigger event. For instance, often when I send the command ‘a10’ to switch the response pad into General Purpose mode and then ask the box what mode it is in (’_a1’) it tells me it has not switched. Usually after a few more tries it works, but sometimes up to 10 tries are needed. For every single message I send to the response pad, I have to build a loop into my code where I check for success and then try again and again when it occasionally fails. However, these problems are only time-consuming annoyances, requiring me to write dozens of lines of code for error checking and testing, but not show-stopping for my experiments.
The show-stopper is that the pad has about a 5% failure rate for detecting the trigger I send into it when that trigger is part of a stream of repeated triggers.:mad:
I have done extensive tests sending in an external trigger every 200 ms, or every 700 ms for several seconds. The button box usually records each trigger accurately with an accurate timestamp. However 5-10% of the time no event is registered by the pad in response to the input line trigger. I have done no tweaking of the ‘bounce’ interval but presume this wouldn’t be an issue for inter-trigger intervals of many hundreds of milliseconds like I am using. Am I going to have to give up on the response pad as a timer for several precisely-timed triggers in a row? Is it possible I am doing something wrong? It seems unlikely since I am doing exactly the same thing in my code many times, and only occasionally these randomly creates a failure. Because the trigger is from a photocell, I can see with my own eyes that each of the triggers is actually occurring. Will this (and the annoying difficulties referred to earlier) be fixed and if so, how soon? I see that the MATLAB-using psychtoolbox people have also reported unreliability in their tests (http://docs.psychtoolbox.org/CedrusResponseBox)
Boosting the voltage I am using for the extrenal triggering event with the Accessory Connector has resulted in it now being reliable All events now seem to be registered.
The other problem I had, with unreliable communication with the box over the USB, remains but the work-around of sending the XID messages as many times as it takes makes the box usable.
I don’t know if this is explicitly documented anywhere, but on some models, it’s an important detail:
In addition to the delay between commands, the processor also needs a delay between bytes. Considering the way USB works, it may just be enough to send each byte separately one after another, but SuperLab inserts a 1.5ms delay between bytes on the necessary models to make sure.
All events now seem to be registered.