Hardware and timing

Notes related to setting up behavioural experiments and such. Experiment design Hardware and timing Experiment building - on timing · on online experiments · on counterbalancing E-Prime notes · PsychoPy notes · Experiment builder notes · Gorilla notes · PsychToolbox notes · OpenSesame notes · DMDX notes

Manage your expectations

Humans and mechanics and timing

Even if you would have sub-millisecond recording in an electronic sense, consider that buttons travel before they connect.

this disconnect-and-connect graph helps put some intuition and some numbers to that. Physically there's a spring loaded contact flipping over pretty quickly and decisively. Normally we might only see the connect happening, but this graph reminds us that that too was an event that took some time. Around 1.5ms on that particular button.

...and that's once it was depressed enough for that to happen - you can count on that being a few millisecond after the finger started moving the button.

Even humans show some variability in just the physics of their hand, but that moves into the area where it becomes part of the reaction time we are measuring, or at least it's variability that is impossible to control for, so we can pretend that's out of our control.

Buttons and timing

tl;dr:

• assume a basic button needs order of 25ms to say for fairly-sure it's a real press rather than some spurious signal
• specific hardware, and specific types of recording it, may be pushed down to 5-10ms
• there are specific tricks to get that down to 1-2ms
  • particularly when reporting it later is okay - but that requires specific analysis after the fact, and/or specific recording methods

Contact bounce

Electric output from a switch that just closed and is still bouncing (most of the mess in 2ms)

Hardware buttons bounce. This is literal: metal contacts bounce physically when they arrive to make contect. Since this is the conductor that carries the signal, this bouncing is reflected in the electric signal.

(and yes, there are e.g. optical switches and magnetic switches that do not bounce in this way, but they are not free of other issues)

You should generally assume this bouncing lasts at least a few milliseconds, up to a dozen or two milliseconds for some switch types/sizes.

Debouncing refers to some way of ensuring that this mass of flip-flopping is registered as a single event.

...which takes time, because it comes down to "watch the thing and see if it becomes consistent." In an everyday sense, the time this takes is negigible - you can assume many buttons you have pressed in your life actually reacted dozens of milliseconds later, and you never noticed.

Yet in reaction time experiments this can be important to at quantify, and probably minimize as well.

💤 "Can we do better?"

Absolutely, but only if you are willing to build in some specific assumptions of both your hardware and your people interacting with that hardware.

The hardware assumptions better be true for your hardware setup, or you still get misbehaviour

The people assumptions better not restrict things you actually did want later.

The simplest 'fix' is to shorten the debounce time, e.g. to 10ms.

The problem with that is that if your button did any bouncing after that time, you will register multiple presses. Rather fewer than if you didn't debounce at all, but still multiple.

The people assumption you can bake in here is that no one presses twice within, say, 100ms.

The faster you want the response, the more it will register multiple responses -- or possibly even react to your phone lying a little too close.

You can improve things a little more by micro-managing things like specific types of swtiches, reacting to breaking rather than making contact (this happens to be cleaner so we can get away with a shorter debounce time), the length of wire and the wire's capacitance, related to the size of the pullups/pulldowns, given the amount of EM noise in your specific environment, (down to potential grounding issues if you do EEG).

But, as gamers using gaming keyboard users will report, that only only so far. Under 5ms or so things may still go weird, and that's not as fast as experimenters might like.

Yet unlike games, which need to interactively react as soon as possible, we only need to record.

There is nothing against reporting "we verified now that a thing that started 50ms in the past is a real button press".

That wouldn't be of much use in a game - for the dumbly practical reason that it should have reacted already (and "no actually I shot you already" is begging for specific kinds of cheating) - but in experiment we are only recording the fact, and only really 'reacting' to it when loading our data into a statistics software much much later.

So where around any interaction with the real world, the best we can do is

• see a possible event, silently keep watching to verify and report it as a real press some time later

But if we may report in the past, we can separately record

• when a possible event started
• also keep watching to verify and report it as a real press some time later

For example,

• the Black Box Toolkit seems to have one general "something happened now, watch my other outputs to see what"

a good trick, but you can't really report things happening in parallel

• Chronos box keeps a clock in sync with its host PC, to be able to

interally record what it is, when it started and that it was verified later

later report an timestamp a little back in time

a good trick, but complex and a little pricy

Keyboards and timing

tl;dr:

• Assume that a generic keyboard may have 8-25ms of latency, probably on the 20ms end.

It might well be lower, but you should never assume it.

this is a mix of debounce (as mentioned above)

and the fact that USB doesn't read out a keyboard very often

• sometimes more importantly, there is variation in the response time

even if this keyboard is triggered by atomic-clock precision, this variation will show up as a few milliseconds of standard deviation in your data

• Avoid wireless

In particular bluetooth can adds a handful of milliseconds, and possibly more depending on how busy the air is right now.

• So if we care about 1ms accuracy, do not use keyboards.

The OS or hardware does not care about precisely the human pressed a keyboard.

It's not that it couldn't be designed that way, it's that it isn't designed that way.

And when you step back, there is a very pragmatic reason for this imprecision: most keyboardists don't care.

You probably never noticed that your keystrokes arrived two dozen milliseconds later, and no one presses the same key more than 50 times per second, or types at 3000-or-so characters per minute it would take for it to probably start losing presses(verify).

There are also low level reasons. One is debounce, as already mentioned. A relatively safe 10 to 20ms of debounce time is perfectly fine for all typing needs - same numbers as just mentioned.

Another is an OS / USB / driver level choice: with most USB keyboards, the PC will only check whether the keyboard had anything to say at most 125 times per second - again, because that's faster than most people type.

Variation

When you do care about timing at the millisecond scale, you have two issues. One, you know it arrives late. You do not know how much.

Two, you do not know this "fetch from USB" schedule. While it's probably strictly regular, it's on its own timer, at a different rate from your screen updates.

So relative to screen updates (specifically the first in a stimulus, which determines timing start), the keystroke arrives in an also-regular but unrelated schedule. Which, to frame-based timing, looks like it is variable.

Gamer keyboards may both have a faster readout (e.g. 1000Hz=1ms interval instead of 8ms), and may choose a shorter debounce time.

Note that "1000Hz keyboard" means it reduces the average latency as well as reducing the variation, but is unrelated to the delay from debounce -- which was larger to start with. Assume even fancy stuff never gets under a handful of milliseconds - and measure to actually know.

Displays and timing

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.