Frequency counter calibration

In two previous posts I described how I first repaired and then checked the calibration of a Racal-Dana 1992 frequency counter. The oscillator of the counter seemed to be within 100 ppb (parts per billion), which based on the aging specification of the oscillator is about as close as it needs to be calibrated. However, I don't think the unit had been calibrated in a very long time, which hints that the aging specification may be very pessimistic. In any case, calibrating the unit seemed like an interesting thing to do.

The 1PPS output of the GPS receiver I was using to check the calibration is specified at 50ns RMS error. This figure alone isn't quite accurate enough for my needs. However, the mean value of the output should be almost exactly 1 second (ignoring any possible gross error, such as loss of GPS fix). Averaging over a number of measurements should then give a much increased accuracy, which can then be used to tune the oscillator. Averaging 100 measurements should give one tenth of the error, which in this case would be about 5 nanoseconds, assuming a normal distributed error.

To easily get averages over the measurements the easiest route was to use GPIB. Unfortunately I didn't have a GPIB interface on my computer, so I needed to build one. See my previous post on building the interface.

Now that I could get readings from the counter, I wrote a simple piece of software for averaging the counts. The calibration procedure would then be simply:

1. Acquire 100 measurements
2. Compute average
3. Adjust accordingly

After doing this, I collected data over one night (around 7.5 hours) to check the calibration. The results of which is shown below.

PPS period measurement over one night.

There are a few outliers during the night, perhaps from short GPS coverage losses. They do not contribute much to the average, since there are only a few, and the distribution seems to otherwise be very close to the normal distribution.

The mean value of the measured PPS period is just 4.04 +- 0.64 nanoseconds shorter than 1 second, which corresponds with the oscillator running just 4 parts per billion too fast.

The next thing I want to investigate with this setup is the long term stability of the oscillator. For this purpose I'll record the measurements over a long period of time, preferably at least some months. This should give a general understanding of the actual aging behavior of the oscillator, since the specified aging seems to be very pessimistic. This setup should also be accurate enough to capture GPS timing errors like the one observed not too long ago (in Finnish), albeit those are very rare.

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.