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')

[larsoner]

(this is with no keypresses, by the way)

[habboud]

Hello Eric, thank you for the detailed and meticulous research. Are you looking for a programming job? :-)

There is indeed a drift still. One “improvement” over the drift in XID 1.x is that this one is constant, so it’s possible to correct for it.

Our electronics engineer has purchased GPS-based timing equipment so that we can fix this issue once and for all. However, I tasked him with another higher priority project. This will be fixed and validated.

[larsoner]

Ahh, good to know that the drift is constant! Any idea what the constant is (assuming it's fixed across 740 devices)? If there is a known value to some high precision that I could plug in that would be great, otherwise I'll just figure it out experimentally and post it back here.

[habboud]

I prefer that you do the math as a) i don’t have a number ready, and b) it would give us something to compare to, in order to validate the bug fix.

[larsoner]

@habboud the correction factor I get for the system time versus PyXID query_base_timer is about 0.00100064206973. A factor of 0.001 is expected because of the conversion from ms to sec, which means that there are 1.000642 computer seconds per XID second. This ~642 microsecond / sec factor appears to be a small but reliable drift. See here for the computation. Knowing this factor should be good enough for us to proceed for now, but it would be great if there were a firmware update at some point in the future to correct for this factor.

[habboud]

Thanks Eric. I’ll post a follow up here when it’s fixed.

[mmagnuski]

Hi @habboud, are there any news on the drift issue?