GPIB interface build

In a previous post regarding the Racal-Dana 1992 frequency counter (a long ago), I mentioned that although technically it is in spec I might still want to calibrate it to an even better accuracy. To do this and for other future projects, I needed a way to record the readings.

The instrument has a GPIB port, but unfortunately I didn't have a GPIB interface to a computer. Digging around the internet it seems that GPIB adapters are either too old, too expensive or you have to build your own. So I went with building my own.

There are several different well-documented projects online to choose from. Looking at several options, I chose to go with the GPIB-RS232 interface by Sven Pauli (website in German). There were two main reasons for me to go with this design:

1. It uses a standard interface, namely the HP Universal Language Interface over RS232.
2. It uses a microcontroller for which I have development tools already available.

Some of the parts I already had and the remaining I ordered off eBay. The most difficult part to source was probably the GPIB connector itself (which can be found by searching for a 24-pin right-angle Centronics receptacle). After a long wait, all the parts had arrived and I could start building the adapter.

Sven Pauli has provided all the Eagle files for the board layout. I did a small modification to the board by adding a ground pour. I did this mainly to reduce the amount of copper that needed to be etched. I printed the layout on standard copier paper and soaked it in vegetable oil to make it translucent (I do this because my printer doesn't coat overhead projector transparencies very well). I exposed the PCB with a fluorescent desk lamp and developed the resist in a 1% solution of sodium hydroxide. The etching was then done in a box of ferric chloride. Agitation during the etching was achieved using a rocking mechanism built from LEGO :-).

Holes were drilled and the components were populated. This was straightforward. When came the time for testing, however, the current consumption of the board was strange. At times it would be happy with 150mA while sometimes it would draw as much as 700mA! Also it would often start up drawing 150mA but then suddenly begin drawing huge currents. I suspected the GPIB driver ICs and checked their data sheets for the typical current consumption. Sure enough, they should not be drawing nearly that much. They were not getting hot though, so I ignored the issue for a while. At some point, after the board had been drawing 500mA for some time, I noticed that the culprit was in fact the MAX232 level shifter as it had become really hot. I thought the MAX232 was bad, and replaced it. The second one I tried however was also drawing similar currents. I found a thread online discussing this same issue, unfortunately without a solution. I checked and double checked the polarities of the capacitors, the condition of the capacitors and for shorts on the board. I cleaned the board of any flux residue and still the problem persisted. At some point I started to think that this might a power supply issue, so I added more bypass capacitance all around the board. This seems to have solved the issue at least partially. I can still get the IC to draw large currents occasionally, but at least it was stable enough to start testing.

I'm using a RS232-USB adapter to connect to the GPIB adapter. Though it does seem kind of silly to first level shift from logic level to RS232 and then back to logic level, but I didn't want to change the design of the adapter. Although with hindsight of the MAX232 problems, I probably should have just replaced the MAX232 with a Bluetooth serial module or something.

The GPIB adapter is supposed to have an automatic baud rate detection logic built in, which measures the timing of the first byte of data transmitted to it, and then configures the USART peripheral accordingly. This is done in the initialization part of the code. Testing the interface for the first time, it turned out that the execution got stuck at the autobauding. This could either have been because of some error in the code or because the signal was not getting to the microcontroller. As this should be working code, I turned to the latter possibility. Checking with the oscilloscope, however, showed that the signal was making its way fine to the microcontroller. I ended up commenting out the autobauding part and replaced it with a fixed baud setup. This made the adapter finally functional.

There are still a number of bugs in the firmware, which I intend to fix at some point. The biggest problem (IMHO) lies with the fact that there is no timeout implemented for the GPIB transmissions. For example, the ULI ENTER command receives data from the instrument until either a newline is received, or the data count limit is reached. If the instrument is not in a mode that produces output, the adapter firmware execution hangs at the ENTER command handler. It is then not even possible to command the instrument into a mode which would produce output.

Having the adapter use ULI also comes with other problems. For example, in ULI the SRQ calls are not handled through the actual interface, instead the ULI driver is supposed to produce events into the BASIC interpreter, which can be handled in an interrupt request like manner. This could perhaps be emulated through one of the RS232 control lines, but unfortunately they are left unconnected in the hardware.

Regardless of the problems, I can now successfully control my Racal-Dana 1992 and read out measurements.