Max-Planck-Institute for Psycholinguistics

MPI Tools

NESU

Nijmegen Experiment Setup
Key points

Design

Devices and Boxes

A Simple Experiment Example

Experiment Preparation and Statistics

Typical Pictures of NESU Setups

Go to NESU manual
 

NESU Keypoints

  • NESU is an environment for rapidly developing, prototyping and executing psychological, physiological, and similar sorts of experiments on PCs with audio/visual stimulus material.
  • NESU is a visual, interactive tool for designing and creating trial based applets; as far as we know NESU is the only experiment environment with a visual design tool.
  • NESU does not assume prior computer programming experience, i.e. it makes the scientist independent of programmers.
  • NESU is designed to run a wide range of experiments (~ 90 % at the MPI) quickly and easily.
  • NESU offers a great degree of flexibility in mixing different trial types in one experiment.
  • NESU offers 1 ms timing accuracy and high speed optimal text and graphics presentation.
  • NESU offers automated verification of all time-critical experiment events.
  • NESU offers dual monitor display and multi-subject control.
  • NESU can easily be adapted to new types of devices such as hard-disc video recorders or eye trackers.
  • NESU dramatically reduces the turn-around time for experiments.
  • NESU is an almost ideal tool for students who need to design and run simple experiments.

For simple experiments NESU is very easy to handle. Of course, there are more complex experimental designs which require a high level of concentration and knowledge during teh design phase.

 

 

NESU Design

The idea for NESU (Nijmegen Experiment Set-Up) was born when PCs were introduced to MPI gradually and replaced the PDPs, which were the standard computers need for control experiments before the arrival of the much cheaper PC. The main result of the change to PCs was that the number of available computers increased while the number of programmers remained essentially the same. This is depicted in the following:

 

70's/80's:
Experimenting in the 70's and early 80's usually meant having a small number of experiment computers (often PDPs) and a small number of programmers. The scientist was heavily dependent on the availability of both, since there were more experimenters and experiment ideas that could be programmed or run on the available computers. The better programs were parametrized, i.e. the user could change some numbers. But he/she could not run a different experimental paradigm without the involvement of a programmer.

 

80's/90's:
Experimenting in the late 80's and in the 90's changed dramatically, since with the arrival of the PC many more experiment computers became available. In fact, every scientist and student assistant now has his/her own machine to run experiments. The availability of computers was no longer the bottleneck in the life cycle of an experiment. It became apparent that the availability of programmers would become the new bottleneck, since the number of programmers would remain the same while the number of computers increased. In fact, the relationship between programmer time on the one hand and available experimenting resources on the other hand even got worse, since the number of scientists and student assistants also increased.

 

The solution to the problem was, of course, to take the experiment programmer out of the life cycle of an experiment and instead to enable programming by the experimenter him/herself. Only this idea offered the chance to maintain, or even reduce the turn-around time between having an experiment idea and executing that idea. From our experience we knew that this was only possible if we were able to provide a specification interface for the user which was very simple to use and which could be used by experimenters for a very high percentage of experiments in a self-supporting manner. This was the reason to behind creating NESU, and this led to the design NESU still has.

 
The most important part in building an experiment is to specify exactly the sequence of actions and events - the Trial Timing. Here, the trial is seen as the nucleus of an experiment which is repeated again and again. A simple Trial Timing could take place from a sequence such as the following:

 

  • at the beginning of the trial, display an image with variable content on the screen for 2 seconds
  • at the beginning of the display time, open a voice key and wait for a verbal description from the subject
  • measure the time from stimulus onset to reaction as reaction time and write this time to the result file

To specify this in formal terms, NESU offers an environment in which one can graphically specify such a sequence with the help of the mouse, a selection of devices to be used, and the specification of some parameters. The timing, of course, is completely independent of the content of the image. This changes from trial to trial. So, the trial timing includes a number of variables of different sorts: image contents, timer settings, image planes, etc.. During experiment runtime, of course, these variables must be bound. This binding is maintained by means of the trial stack - a list of records with as many columns as there are variables in the timing scheme. This list can be prepared with the help of ordinary text editing tools.

 

Assuming that the experimenter has prepared all his/her stimuli in advance, such as images and speech files, he/she would now be ready to run the experiment. In fact, when a trial timing is specified by the user, a Smalltalk applet is generated invisible to the user which can be integrated directly in the experiment runner and be executed.

 

It is clear from the above decription that NESU has an orthogonal design, i.e. all components such as trial timing, sequence of stimuli, condition codes added to the stimuli records, and run-time specific aspects are kept separated from each other. Existing trial timings therefore can easily be used with other stacks, a new trial timing can be specified without having to change the trial sequence, etc.. Therefore, NESU significantly reduces the turn-around time. An easy activation of the environment to specify the trial timing after some tests makes it possible to adapt it and directly execute the new version. For an advanced user, NESU even offers the possibility of changing parameters within the experiment runner.

 

The experiment runner has a number of unique features such as opening several experiments simultaneously, running multi-subject experiments, automatic hardware presence detection, test of all low-level device functions, an option to directly change experiment parameters and the short comprehensive trial applet, and a pause/resume option.

 

Another option makes NESU a good tool for rapid prototyping. Normally, NESU requires various hardware devices to be fully operational. However, external devices can be simulated in the experiment runner by standard pseudo-PC devices for testing. To guarantee high accuracies (=< 1ms) when measuring reaction times with push buttons, NESU normally requires some special electronics. If these are not available, the standard PC keyboard can be used - of course, at the price of less accuracy.