Rutgers Physics Student Response System

History of the Project

[ This page is not yet complete.]

Motivation for the project

Early in 1993 a conjunction of number of events led to to proposal for the design and installation of a student response system for the large lecture hall in which most of our introductory physics courses are taught. The first event was the arrival of Suzanne Brahmia as Associate Director of the Math and Science Learning Center (MSLC) and Director of the Gateway Program in Physics. Suzanne, who had just come from Cornell, was inspired by her very favorable experience with a student response system designed and built by Prof. Raphael Littauer at Cornell in 1971. Our department had spent considerable attention on trying to improve the efficacy of our introductory courses, and research on active learning by means of electronic responses showed very promising results.

At the same time, there was a request for proposals from the Rutgers Teaching Excellence Center (TEC) for grants to improve teaching of up to $5,000. George Horton, a Professor in the Department, had a NSF-DUE grant with some money available for interactive learning, and he was able to offer matching funds. Brian Holton, who was Director of the MSLC at the time, and David Maiullo, our Physics Support Specialist in charge of demonstations in the Physics Lecture Hall, were both enthusiastic to join in on the project.

Raising funds

Thus I wrote a proposal to the TEC, with Suzanne, Brian and Dave, asking for $5,000 from them plus $5,000 in matching funds from George's grant. I had no real idea how much it would cost to do the whole auditorium, and admitted that $10,000 would probably not do the whole job in the application. But the grant was accepted, except that they decided the $2,000 I had asked for for a PC with 48 line parallel port was overpriced and could be bought for $1,500, so I started off with a budget of $9,000, and I planned for a system for which $9,000 could do a substantial part of the lecture hall. My only experience in building electronics was a brief bit of computer hobby work during the '70's, when people did that kind of thing.

Preliminary design

The most difficult part of constructing a system with 330 input and output devices is bringing it all together. The auditorium involved is an amphitheater with a thick concrete floor over a storage area. Each of the built-in seats has a folding writing surface rotating on the end of an armrest. We decided right at the beginning that the keypad device for the students would have to be hard-mounted somewhere, because we felt a system with a keypad attached only by a cable would incur unacceptible levels of loss, and we could not have a person distributing and collecting keypads for over 300 students. The keypad also had to be resistant to abuse, including casual efforts to damage it.

At the very least, a system should be able to handle multiple choice questions with five answers. Littauer's system used 5 robust pushbuttons and a light. But surplus telephone keypads are not much more expensive than five good quality pushbuttons, and are easier to mount and connect, and provide a great deal more capability for input, including the input of arbitrary floating point numbers and student identification numbers. I felt that some feedback mechanism was necessary. Pushing a button to record your opinion without confirmation that it has been received is likely to result in scepticism and frustration. I discovered that telephone keypads are essentially a 4 x 3 matrix of buttons which, when pressed, short the column conductor to the row conductor. Thus it has seven wires to connect. With one additional wire to control a light for each column, I was able to make a keypad with three lights (red, yellow and green) and twelve input buttons, connected by eight wires to the rest of the system. Eight wire modular cable is quite standard and easy to work with. Other than the components mentioned, all there is on the keypad are four diodes, a socket, and a small printed circuit board to hold it all together.

Three lights are not a very flexible form of feedback, and it would have been significantly better to provide each student with a multidigit display. The cost of such displays was prohibitive, however, even before investigating what circuitry would be needed to drive them.

Of course it is a rather daunting prospect to have 330 cables, each with eight wires, converging into one PC after passing through a concrete floor and traveling about 150 feet each. I considered that infrared or radio communication might work better, as there would be no need for cabling. I had no experience with such a system. I was concerned with issues such as clothing blocking the signals. I was also concerned that the inclusion of a transmitter, a receiver, and the controller which connected them with button presses and lights respectively, would make the individual keypads too expensive and too delicate and too hard to maintain, as they would require batteries. I found an enthusiast with some experience with infrared systems, Paul Zucchino, but after thinking about the number of stations involved, he said he thought it would not be possible to do within my constraints.

Robustness was a major consideration in our design - we quickly ruled out membrane telephone keypads after seeing how quickly they could be destroyed with a pencil point. We also decided to mount the keypad in the fixed armrest rather than on the writing surface, because the latter would have required either exposed flexible cable or a very complicated arrangement to span the two perpendicular hinges on which each surface swivels.

Because it is relatively easy to connect the seats in one row of one section in the auditorium, but quite difficult to run wires between the rows or sections, I decided the seats in one row and section would be controlled by a collector, which came to be called the subsubstation. The longest rows have 14 seats, so I designed a controller for 16. The structure of the keypads requires some sort of polling scheme, which I implemented by grounding one column at a time and detecting which of the row lines, each connected through a resistor to a voltage source, were pulled down. This is trivial to extend to all the columns in a row of seats, which could be logically viewed as one keypad with 48 columns and four rows. The light corresponding to each column can be lit only during the period that its column is selected.

Each subsubstation, and our system has 30 of them, must still be connected to the central computer through a hole drilled in the concrete floor. Each has a 15 conductor cable. This is still too much to converge on one PC, so I introduced two more intermediate stages, the first a substation which collects up to eight subsubstations. Finally the five substations are connected to a controller which somehow acquired the name of boss, because it has active logic to controll the state of the system. This is necessary to avoid having the PC spending all its time controlling the system, as it must also handle communication with the instructor and display of the results.

Communication between the boss and the substations also utilizes polling, at a higher baud rate, and the distances involved are fairly long, so I felt I needed to use differentially driven pairs. This considerably complicated the circuitry. I also found that the lectern was connected to the rest of the lecture hall only by a rather small conduit, so the boss had to be split in two pieces, one near the computer and one near the substations, connected again by differentially driven twisted pairs.

The design of the logic was done using primarily TTL logic, probably because that is what I was familiar with from my hobbyist era, but also because the devices that grounded the LEDs had to take as much current as possible. Each LED is lit at most two percent of the time, and this is borderline adequate even at the 48 ma currents which old fashioned 7438's could handle. Newer, lower power IC families were therefore problematic. In fact, most of the power consumed by the system goes into driving the LEDs and driving the terminated differentially driven pairs, so it is not clear how much could be gained by moving to a lower power technology.

Prototyping and testing

The system just described requires 330 keypads, 30 subsubstations, five substations, and one of each half of the boss to be constructed. It was obvious from the beginning that the keypads and subsubstations would have to be made using printed circuit boards, while the boss, especially the "intelligent" part involving complex and irregular connections, would be most easily implemented using wire-wrap. I expected there would need to be considerable debugging, so I felt I needed to be able to make small quantities of the printed circuit board quickly and inexpensively. Mistakenly, I concluded that this meant producing my own. There are several methods of laying out designs on a printed circuit board, ranging from paste-ons to photographic techniques. I wanted to lay out the board on my computer, so I tried methods which transferred the design from a printer to the board. One way which was somewhat successful is to print on special sheets costing about a dollar apiece, which I got from Techniks Inc, called PnP-Blue. You print backwards on these, and then iron the sheet onto a copper surface, peel and etch. They also made another kind which is soaked off. While both of these worked in most places on lines thicker than 30 mils, they were not completely reliable, and I had much frustration in making the complex circuits for the substations. Also very difficult was lining up two sided circuits. My best efforts were often off by 30 mils, enough to make for considerable problems. With Brian, I also tried using boards with photoresist. But our success with these were not noticably better. At about this time I discovered that it is possible to get small batches of printed circuit boards made commercially, as described below for production.

I also thought my very limited budget did not enable the purchase of commercial software for the design, especially as my computer of choice is a Sun. Thus I produced all the designs using primative tools, writing directly in postscript. This too was undoubtedly a mistake, for the amount of time I spent laying out printed circuit boards far exceeded my expectations.

Debugging the system was very difficult. The subsubstation and keypads could be tested statically with a simple test controller, but this gave no indication of the way the lights would work in a polled system. Dynamic control of the system in a testbed arrangement required detecting the voltage levels on the row lines at particular time slots in a long sequence, so I built a small test module which could be connected to a PC using the same parallel input board which would eventually be connected to the boss. The boss itself required considerable debugging, and only the clock part could be debugged without the whole system in place. The substations and the rest of the boss controller were debugged entirely by having a small version of the whole system running. It was during this frustrating period that I decided the extra problems due to poorly etched PC boards was clearly not worth the money saved by home etching.

Production and installation

Once a prototype was debugged, we focussed on the production of the components and their installation. It was clear that the subsubstations would have to be produced commercially. Our electronics engineer, Ed Bartz, told me of a company called Alberta Printed Circuits, (APC), which will produce as few as two boards of a design if sent to them in Gerber format electronically. Ed had a PC design program which would produce the Gerber files, but it meant he had to lay out the board from scratch, using his program. He did this, and we ordered two prototypes for less than $100. After correcting a couple of minor flaws in the prototypes, had forty boards produced for $573.

As I was having such a hard time with the substation boards, I wanted to have them made commercially as well, but Ed was too busy with other projects, and I found it too inconvenient to use the system on which his program resided. Thus I was forced to add to my postscript controls with which I could convert the files to Gerber files with my own software. Later on, when it became clear that we needed to have spares for all parts of the system, I decided that even the boards which were not duplicated in the system should be made commercially. Now all parts of the system, except the commercial I/O board in the PC, are on boards produced by APC.


The system requires programming at three levels. At the highest level, we need programs which incorporate what the instructor would like to present and record, given the inputs and outputs from the students. We expect there to develop with time several different ways in which the system can be used, with different and perhaps evolving high level programs to implement them. The design of these programs should not depend on an understanding of the details of the way the system communicates with the PC, which is handled by the ``low level'' routines which run on the PC. At the most primitive level, there is the program that runs on and controls the "boss". These were, of course, developed in the order opposite to that just given.

Low level programs controlling communication of the PC and boss were used even in the early debugging stage, when the system was just running tests of pieces of the system. But only small parts could be tested without the program which controls the boss itself. This program is extremely primitive, as it does not even require a CPU to run it - it is an EPROM addressed by a clock, with one output which resets the clock at the end of a loop. This program puts the boss through a cycle during which one of the 48 columns in each subsubstation has its light controlled and its column of keys read, for all of the substations. The cycle, which lasts 793 microseconds, is repeated 48 times to handle all the columns, each time transfering the state of the buttons to a RAM and reading from that RAM the state of the lights for that column on each of the subsubstations. After the 48 cycles are complete, the boss waits for the PC to take control to transfer data to and from the boss. I was expecting considerable agravation in debugging the EPROM program, for each flaw would require reburning of the program into the EPROM. Fortunately, the program worked the first time.

The low level program is run on each clock interrupt of the PC, which occurs 18.2 times each second for standard DOS. During this time, the keypress data is transferred from the RAM on the boss to an array in the PC, and the status in which the LEDs should be placed is transfered from an array on the PC to the RAM on the boss. As soon as this is complete, the PC relinquishes control to the boss, and the polling cycle begins again.

This phase of the development was very extended, because each bug in the software or in any phase of the hardware would cause a total loss of communication between the parts of the system I could examine and manipulate easily, namely the PC and the keypads. Further difficulty was caused by the decision that, in order to get as much possible running on the $9,000, I decided to try to survive temporarily with an antique 8088 hand-me-down machine. This machine was so slow and inadequate that only after rewriting the program in assembly language, which speeded it up by a factor of ten, could I make the data transfer fast enough to handle the one section of 108 seats that I intended as a proof of concept to request the rest of the money needed. Later on, after I got the required extra funds and bought a decent pentium machine and installed a decent compiler, did I find out that assembly language was unnecessary. In the later stages of this development, I had assistence from an undergraduate student, Orlando Lopez, who was unfortunately only available for short time, and two other students who were not as successful at understanding the system.

With the lower level software in place it was fairly easy to debug the hardware system and each new board that was built could be added and checked fairly easily. It was then time to start producing a higher level program that an instructor could use. At the time, only Suzanne had declared a willingness to use the system, and she wanted only untagged multiple choice questions, with an initial answer period, a histogram of the results, a pause, and then a second answer period during which the students could give their reconsidered opinions. This program was written by a very enthusiastic and capable student, Jason Litowitz, with later help from another student, Yik-Pun Law.

By the beginning of summer, 1995, the system was installed in one section (the left central section) of the lecture hall, and the program for untagged multiple choice questions was available. This was used for one class during the summer. By the beginning of fall '95 term we had the rest of the seats installed, and work was underway to have a program running in tagged mode. We had a lot of trouble ironing out bugs in this tagged program, but by the end of term it was reliably working.

Involving instructors

During the fall '95 term several of the instructors teaching in the lecture hall expressed interest in using the system in tagged mode. As that mode was not yet reliably working, results were not satisfactory. By the beginning of the spring '96 term the system was fairly reliable, and and most of the instructors of the courses were happy to use the system. Of the nine courses taught in the lecture hall that term, the system was used regularly in seven, mostly for taking attendance. Some details and the result of a student evaluation of the system in one course is here.

It is difficult to communicate with the prospective instructors about the system, even though they are members of the same department. The instructors are very busy and need to be convinced it is worthwhile for them to learn about the use of the system. It also seems to be easier to get them to listen to a talk than to read even a short document.

In order to publicize the system I held a meeting with potential instructors before the spring '96 term. In February I gave an open seminar talk, "High Tech Instant Student Response Lecture Hall in Action: A Practical Demonstration and Future Prospects", in the lecture hall. Then at the beginning of April there was a discussion meeting of the users and potential users of the system.

During the summer the large lecture courses are taught by people who are not professors from the department, so a completely separate approach to informing them is necessary. The largest class has so little lecture time that the instructor felt he could not spare the time necessary to use the system. One of the other two classes does use the system regularly. As these classes are smaller, there is less need for an automated feedback system.

Results and plans for more results

The author will be presenting a talk at the AAPT meeting in Maryland on the development of this system. There will also be a talk by David Maiullo on it. We will then try to develop some controlled method to evaluate the effects of its use during the fall '96 term. For our current results see the section on pedagogy.
Last revision June 18, 1996