Blog Archives

3D printed response box. The future. It’s here.



This may not look like much, but it’s actually pretty cool. It’s a new five-button response-box being built for our MRI scanner by one of the technicians where I work. The cool thing is that the main chassis has been custom-designed, and then fabricated using a polyethylene-extruding 3D printer. The micro-switches for the four fingers and thumb and the wired connections for each have obviously been added afterwards.

3D printing in plastic is a great way of creating hardware for use in the MRI environment, as, well… it’s plastic, and it can create almost any kind of structure you can think of. We sometimes need to build custom bits of hardware for use in some of our experiments, and previously we’d usually build things by cutting plastic sheets or blocks to the required shape, and holding them together with plastic screws. Using a 3D-printer means we can produce solid objects which are much stronger and more robust, and they can be produced much more quickly and easily too. I love living in the future.

More on response hardware: parallel port and USB.

I received a couple of e-mails this week from the inimitable, the mighty, the intrepid Prof. Chris Rorden, related to one of my earlier posts about parallel port response boxes. This pleased me greatly a) because he sent me a butt-load of really great information and links that I hadn’t been aware of, and b) because it’s exactly the kind of interaction with researchers that I was hoping that this blog would initiate.

Anyway, he pointed out a lot of new information. First of all, the paper that I cited from 2007 was essentially a re-tread of an older paper from 1992 which also has some nice circuit diagrams in, as well as some useful Turbo Pascal code (does anyone use Turbo Pascal anymore? I guess someone must…). He also directed me to this page which has a lot of information and circuit diagrams for experimental control of a PC.

Another hint he passed on was that on some computers the D0-D7 pins on the parallel port are not bidirectional – so may not work well for some applications, but the C0-C3 pins apparently always work for this kind of application (bottom right in the diagram below).

Parallel port pin diagram showing the three registers (data, status and control) and the ground pins (in green)

Regarding using USB input – he pointed me to this fascinating paper (PDF here) which has some theoretical analyses related to the relationship between true and measured RT, with limited resolution clocks. The surprising conclusion is that even with a clock with only a 30ms resolution, the effect on measured RT is negligible. This means that the 125Hz/8ms default USB-polling rate might not be such a big problem after all. Of course one should still be very careful about using ‘standard’ USB devices (i.e. keyboards, mice) for response timing as they can introduce significant errors as well.

Most interestingly, he pointed me towards a really sexy little device board from a company called U-HID.

The U-HID board – takes an input and transforms it into any kind of ‘standard’ computer input (key press, mouse-click, game-pad button – whatever!). Awesome.

What this does, in Chris’ words is:

“This allows 8 digital inputs to be read through the USB port. What is great is that it comes with software that allows you to assign any input to any keyboard or mouse button. The included software allows you to flash these changes to the device, so afterwards any computer will see the mappings you assigned. By default, this has a pretty good polling rate of 5ms.”

So, you can attach any kind of switch or input on one end, and when that switch is closed, the computer will see it as a key-press, a mouse-click, or whatever else you assign to it. The ‘Nano’ version of the board is really tiny, and is available from this site for only $35! This looks to be an incredibly useful bit of kit, and is probably the best solution I’ve seen for hooking up arbitrary devices to a USB input – really cool. Chris mentioned that he uses these boards for collecting responses in experiments, and also for reading the optical triggers from a Siemens Trio MRI scanner with his EZlog software (described here).

So – fantastically useful information – many thanks Chris! I’m a fan of keeping things simple, and parallel port inputs for collecting reaction times are certainly a good and easy solution; unfortunately parallel ports are largely obsolete these days, and most new computers don’t have them. The cards are still available for desktops, but in a few years these simple in-out ports may be completely unavailable. We’ll all have to move to USB devices at some point, and the U-HID boards are definitely the best-looking (and cheapest!) solution I’ve seen. I am definitely going to order a couple to try out.

Anyone else have any experience with the U-HID boards? Let me know in the comments. TTFN.

How to make your own parallel port response boxes

I’ve previously written about the importance of response hardware for doing timing-accurate experiments – in a nutshell, anything you connect via USB is likely to be sub-optimal,* because the operating system only polls (or looks for an input) on the USB port some of the time – in Windows the USB polling rate is 125Hz, or every 8ms.

So, for accurate timing of responses, we want to use something other than the USB port. There are various options – my personal favourite is to use the 25-pin parallel (or ‘printer’) port. Some newer desktop models unfortunately don’t have parallel ports anymore, as they’re largely obsolete for connecting peripherals, however any model older than two or three years should have one – and you generally don’t need a super-fast, up-to-date computer for running stimulus programs and collecting data.

I needed a couple of response boxes for a project recently, and decided to just make them up myself. I came across this fantastic little paper  (PDF) which describes a simple method of taking apart a couple of standard computer mice, and rewiring the switches into a parallel port plug – this gives you up to six buttons. The circuit diagram is really, really simple:

Circuit Diagram for a six-button, parallel port response box. Reproduced from Voss, Leonhart and Stahl (2007).

It’s just the switches, and a 100-ohm resistor for each one, wired up to different pins on the data register of the port, with a common ground (pin 18). Honestly, if you were being lazy, you could even just forget about the resistors and it would still work fine. I decided not to take apart any mice, but just to use some buttons I bought off-the-shelf, as I only needed two for each box. Getting the right buttons is really important for this kind of thing – you want them to be a decent size, and have a good clicky-action, without being too difficult to depress. I also got some small plastic boxes, some multi-core cable (I used standard network cable as it’s quite stiff and robust, but almost anything will do), and some parallel port plugs. You can buy everything you need from Maplin or Radio Spares (Radio Shack, if you’re in the US) for about £10-15. I just drilled some holes in the boxes fairly roughly and secured the buttons there with a dab of epoxy resin, but you can get as fancy as you want in that respect.

The only really tricky bit is deciding which pins on the parallel port you want to wire your switches up to. This will largely be determined by which pins the software you’re going to use can read from. Psychology software like Inquisit or E-prime is able to read inputs from pins 2-9 on the data register (see below diagram) but it’s worth doing a bit of reading about the different pins on the parallel port and what they’re used for. A good place to start is here. Probably what you want to do is use one of the data pins for one pole of each switch, and wire the other pole to a common ground pin, as in the above diagram.

Parallel port pin diagram showing the three registers (data, status and control) and the ground pins (in green)

So there you have it – the most simple, inexpensive and accurate solution for recording response times in cognitive experiments. If you’re at all handy with a soldering iron you can probably knock up a couple of these in half an hour or so. If you’ve never done any electronics or soldering before, then this would be an ideal first project to get started with! This was my finished article:

Nice, huh? Happy soldering! TTFN.

*Not quite true – some of the expensive button-boxes you can buy from psychology software companies are USB, but have their own electronics inside them to get around this and time things accurately.

Running Experiments 2: Response Hardware

We have the tools, we have the talent!
– Winston Zeddemore

In the last post I talked about timing of experiments in general, and mentioned that timing of responses is critical for success in a reaction time-type experiment. This topic will discuss some of the options for hardware that’s available for collecting responses.

The simplest solution is just to use the human-interface hardware which you’ve already got i.e. get your participants to click a mouse button, or a key on the keyboard as their response. However, there are several reasons why this will generally be undesirable. Most mice and keyboards on modern computers connect via USB, and this introduces a slight lag. The computer ‘looks at’ or ‘polls’ its USB-connected peripherals at a standard rate of 125Hz (meaning 125 times per second, or every 8 milliseconds). This means that if you make a response, there may be a (variable) lag of anywhere between 0 and 8 ms between the response and the computer actually ‘seeing’ it. USB-keyboards have a similar problem. In addition, mice (and keyboards) have a lot of internal circuitry which can also introduce timing lags of variable durations. This paper (Plant et al., 2003) presents the results of some bench-testing of a set of mice. The best mouse they tested had a minimum button-down latency of just 0.4ms, whereas the worst one showed a minimum lag of 48ms! Running timing-critical experiments with the latter mouse (where the effect you might be chasing could be in the range of 20-30ms) would clearly be disastrous. Read the rest of this entry