RB 834 Timing

Hardware General
1

Hello,

I was just wondering if there was a method to check the timing on the RB 834 in XID mode. I saw that there are some samples on the website, but it said that they had not been tested, so I wasn’t sure if I should use these or not. When I tried testing the timing using the language’s built in time function, it would differ slightly from the information given by the box, and I wasn’t sure whether this was due to port reading timing or something else. Any insight into this would be much appreciated.

Thanks,
Anthony

2

Hi Anthony, the timing difference is most likely due to the USB driver. This is the part we haven’t been able to measure so far. The response pad’s built-in timer gets around the USB driver’s delay when the user presses a button because it time-stamps the information. However, the computer still needs to send a “timer reset” command to the response pad, and it’s that part that introduces some variability.

3

Thank you very much for your reply. If I am understanding correctly, the variable time difference between the Cedrus time-stamped RT and the time I’m getting with my software clocks is due to the Timer Reset command (“e5”). Correct? This raises a couple follow-up questions:

  1. Are there also similar delay issues with ALL of the port commands? For example, even though the time is stamped by the Cedrus button box, does it take some additional time to read the port values, which would also add some variability compared to the software clock?

  2. What is the longest RT that can be collected by the Cedrus time stamp? What happens if you go over that time? If the time is sufficiently long, would this work as an alternative: (a) use the timer clock reset at the beginning of the experiment instead of each trial, (b) use a button press to start a trial and store that time-stamped time, © collect another button press for the response time and use the difference between (b) and © as the actual reaction time. If the timer can’t go a whole experiment without overflow, maybe using this technique every X trials.

We are dealing with issues that require millisecond resolution so we need to eliminate as much of this variability as possible. Any other suggestions or information would be much appreciated.

Thanks again!

4

If the variable time difference is in the order of a few milliseconds, then yes, it’s most likely due to the delay in sending out the Timer Reset command.

Regarding question 1), yes, there are delays on the way back. That’s precisely why we added time stamping of responses inside the pad itself – to make the return delay irrelevant.

Regarding 2), it’s very long. I don’t recall exactly how long, but it’s long. You can try the approach that you describe.