Rutgers Physics Student Response System
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.
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.
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.
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.
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.
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.