In 1998, electrical-engineering professor Jesús del Alamo was teaching transistor physics to both undergraduates and graduate students, and he was getting frustrated. “Neither of the two classes I was teaching at the time had any lab component,” del Alamo says. “I thought it was very important for the students to have a chance to measure the characteristics of these transistors in simple circuits and evaluate to what extent what we were telling them in class is actually what they see.”

MIT’s Microsystems Technology Laboratories had a single piece of equipment that could perform those measurements: a semiconductor parameter analyzer that cost tens of thousands of dollars. Granting each of the 80-odd students in del Alamo’s undergraduate class a half-hour alone with the machine was impractical, so he enlisted a student to help him put it online. A little more than a decade on, that relatively modest exercise in networking has expanded into a program called iLab, run by MIT’s Center for Educational Computing Initiatives (CECI). The program seeks to make MIT equipment accessible to outsiders and, perhaps more important, to provide other universities with tools for creating their own networked experiments. So while college students in Saudi Arabia will soon be using the system to make measurements using a neutron beam from MIT’s nuclear reactor, high-school students in Illinois are using it to access a radioactive-decay experiment in Australia, and universities in countries from Asia to Africa are using it to grant neighboring schools access to their own equipment.

Creating a system flexible enough for such a wide range of uses required a lot of early trial and error. Although the current version of the iLab software can grant users real-time control of distant lab equipment, the first experiment, for del Alamo’s transistors class, required students to upload lists of measurements to be performed on a device hooked up to the analyzer. “If the lab report is due Friday at noon, most students actually perform the lab–and they’ve charted this–between 1:00 and 5:00 a.m. on Thursday night,” says Jud ­Harward, associate director of CECI. So if the device blew out in the early morning hours, students were left stranded. One of the first modifications that del Alamo and his student collaborator made was thus a “switching matrix” that let them hook as many as eight devices to the analyzer at a time. “That allowed us to build redundancy,” says del Alamo, “so we could have two or three samples of the same device to be used in a given assignment.”

Soon, del Alamo’s team began thinking about adapting its approach to put other MIT equipment online. “We realized that this very first system that we put together was very much of a homemade, completely custom system,” he says. “We thought that we really needed to start from scratch with a standardized architecture with a very modular design.” With support from the iCampus initiative, which had $25 million in funding from Microsoft to investigate innovative educational techniques, they went to work.

The current version of the iLab system has three components. One is the computer that controls the experimental setup. Another is the user interface, the software on the computer of the person accessing the apparatus. The third is the service broker, which mediates between the other two, scheduling access to different iLab equipment around the world. Communication between parts of the system must adhere to formats specified by the MIT iLab team, but otherwise, developers have a good deal of latitude.

At Makerere University in Uganda, one of three African universities in the program, iLab development has become part of the curriculum. Like other early participants, Makerere initially used the system simply to access MIT equipment. In much of Africa, however, Internet connections can be erratic, and Makerere students with lab assignments due couldn’t always get online.

With support from iCampus, del Alamo and his collaborators had already begun investigating low-cost equipment that universities without MIT’s resources could use to create their own networked experiments. They had homed in on National Instruments’ Educational Laboratory Virtual Instrumentation Suite (ELVIS); the size of a deluxe Scrabble set, it contains electrical components and software that let it emulate devices such as oscilloscopes or function generators. Already inexpensive by lab equipment standards, it has been offered at steep discounts to the African iLab universities.

In 2007, Sandy Tickodri-Togboa, an electrical-engineering professor at Makerere, visited MIT with students who had been performing experiments on del Alamo’s analyzer, and the iLab team introduced them to the ELVIS. Since then, seniors in Tickodri-­Togboa’s classes have designed new iLab experiments for the device as their final projects. In the spring, the students accompany him to Cambridge, where the iLab team helps them iron out kinks in their software. By the next fall, the new experiments, in such fields as digital signal processing and telecommunications, have been incorporated into undergraduate coursework.

Tickodri-Togboa says his students are enthusiastic about iLabs. “Their predecessors passed through the university without doing a single experiment, or just doing one experiment if they were lucky,” he says. Graduate student Olayemi Oyebode ‘09 noticed similar excitement when he spent three weeks in January helping students at the three African universities configure the iLab software to allow people to do experiments with the ELVIS. “The big thing for a lot of them was the fact that ‘we’re usually dealing with theory,’ ” he says. “And at some point, theory just gets boring.”

The flexible design of the user interface has proved surprisingly important, says James Hardison ‘02, a researcher at CECI who began working on the iLab project as a UROP in 2000. Some users are technically sophisticated and want precise control over the apparatus; others are high-school students, who need intuitive ways of visualizing what an experiment demonstrates. Those with limited bandwidth want spare control systems that download quickly.

Hardison points to the first iLab experiment at the University of Queens­land, in Australia, as an example of what good interface design can achieve. “We had just gotten the first version of the service broker up and running and the source code available for people to download,” Hardison recalls. The iLab team at MIT began getting e-mails from Joel Carpenter, a Queensland undergrad, who was trying to put a standard control-systems exercise online: students had to accelerate a pendulum at just the right rate so that it would come to rest pointing upward. Carpenter’s interface offered an animated depiction of each run of the experiment and a way to compare animations of different runs. But it also indicated which part of the control program was being executed at each point in the run. If something went awry, students could immediately determine which lines of code were responsible. “The success rates of people being able to balance this pendulum went way up,” Hardison says. Indeed, even students who were physically in the lab with the pendulum chose to use Carpenter’s iLab interface rather than the standard control system, which simply allowed students to set the initial conditions for the pendulum’s acceleration.

Like the students in del Alamo’s transistor physics class, however, many of the students who have used the iLab system seem most enthusiastic about the flexibility it offers in scheduling. Its chief benefit is “the ability to repeat the experiments as many times as possible until a concept is fully understood,” says Moninuola Olufola, who used the system to run experiments on the ELVIS as an undergraduate at Nigeria’s Obafemi Awolowo University. “I could learn at my own pace with no instructor to shout at me, and I can even go back to perform an experiment long after every other person has forgotten about it.” Even, presumably, between 1:00 and 5:00 a.m. on a Thursday night.