No timestamps!

[RyanHope]

pyxid is not returning any time data making this library fairly useless.

[habboud]

This is note in the release notes. The response pads currently have a time drift, so we opted not to return the time-stamp information.

[RyanHope]

Isn't the whole point of a response pad to get better timing than one would get with a keyboard?

[habboud]

It is, and we're fixing that in the next gen

[habboud]

I'd note that the built-in timer, even when working drift-free, doesn't entirely resolve the timing issue. That's because the timer needs to be reset, which is done by a computer command that is sent over USB. And a USB driver introduces its own delay. That's why we're adding two new non-USB timer reset options in the next gen models.

[achetverikov]

Are there any workarounds or patches for the time-drift issue, that can be appied to the current version of pyxid?

[habboud]

Alas, no. The time drift issue will require a hardware update (not firmware). We're working on revisions.

[RyanHope]

So these button boxes are just big buttons :(

[habboud]

Please see my notes from 5 days ago. If you're presenting a trial and asking the participant to press a key, the time drift issue does not affect users. Only users require several key presses per trial are affect, e.g. tapping experiments.

[achetverikov]

habboud, that's great news, thanks for the clarification.

[achetverikov]

I there still no progress on that?

[kkheller]

The fifth generation of response pads (known as the RB-x40 line) is now available.

News release: http://community.cedrus.com/showthread.php?t=1968

These models have new hardware and new firmware, and the timer drift has been addressed.

Additionally, a light sensor can be used to automatically trigger the reset of the RT timer at the onset of a visual stimulus on the screen.

In pyxid, it will still be necessary to set: pyxid.use_response_pad_timer = True (as described in the ReadMe)

[achetverikov]

We have older buttons and were looking for a way to run tapping experiment with them. I understand that novel boxes don't have this problem, but what should the people who have older ones do? How big is the time drift? Does it have a constant rate?

[kkheller]

The drift accrues each time a user presses a key. This is because, unfortunately, the timer is software-based.

The currently shipping response pads (Lumina 3G and RB-x40 models) use a hardware-based timer, which resolves the issue.

[larsoner]

@habboud should the README be updated to show that the drift does not affect the x40 models? I'm happy to open a PR if it makes sense.

[larsoner]

I am running a RB740 box, and it looks like there is still a drift relative to the computer clock. I expect the < 1ms jumps here, but not the slope:

Code:

import numpy as np
import pyxid
import time
import matplotlib.pyplot as plt

devices = pyxid.get_xid_devices()
dev = devices[0]  # get the first device to use
ts, vals = [], []
for _ in range(100):
    ts.append(time.time())
    vals.append(dev.query_base_timer())
    time.sleep(0.1)
ts = np.array(ts)
vals = np.array(vals)
diffs = 1000 * ts - vals
diffs -= diffs[0]
ts -= ts[0]  # make the start t=0

plt.plot(ts, diffs)
plt.ylabel('relative diff (ms)')
plt.xlabel('Time (s)')
plt.show()
plt.axis('tight')