Thanks to support from @Axel (Driver-side handling of old instrument without EOI line - #4 by Axel) I was able to complete my works on the driver for the venerable Racal-Dana 90x5A series counter instrument which includes the models 9015A (tested) and 9035A (untested, but just a 9015A + pre-scaler for an additional 100-500 MHz channel).
This Racal-Dana counter model was frequently used by the German army and might be still remembered by one or the other radio amateur that was on duty between 1980 and 2000, maybe even later. It can still be found on army surplus stores, often listed with its front sticker designation “Racal-Dana 9000 series” as it was (afaik) the first model of the 9000 series and the specific model was only labled on a backside sticker where also all options where listed. Racal-Dana is more famously known today for the later counter models “1991” and “1992”.
The 9015A/9035A models become an interesting choice by the additional options that where available on order: GPIB, ovenized instead of temperature compensated oscillator with the additional option to get a high-precision version with 5x10E-10/day aging rate, switchable 50Ohms input and pulse measurement capabilities. From what I have seen, the models used by the army where usually equipped with all of these.
Notes from the release on github:
- the instrument uses a pre-SCPI command set
- the instrument does not use an End-Or-Identify line to finalize commands, which is why a custom identifier is definied via GPIB_EOLread parameter
- the gate/time multiplier options span a vast range of values and some extreme ones on each end are not usable in all operating modes; because checking all possible combinations of permitted values and operating modes would have caused at least two pages of additional IF statements, this check has not been implemented but the permitted operating modes have been added as text in brackets to each gate/time multiplier option in the GUI interface
- the totalizer mode requires a start and stop use to define the time within all events are supposed to be counted; I was unsure to implement it, which is why, for the time being, I added the option of defining a time span within events are supposed to be counted. An ideal implementation would be to detect if the driver has been called the first or the second time in totalizer mode as so to either start a counting sequence or to stop it and retrieve the result
Additional notes, partially from the source code comments:
- The inverting function is of more benefit than obvious on first sight: the manual states that for frequencies below 10kHz, a higher precision can be achieved by measuring the period and using the inverting function to get a frequency read-out.
- the choice of gate/time multiplier will define the measurement time frame and have direct impact of the resolution. There is an “As-Is” setting than leaves the choice to the power-on/reset setting for each operation mode but curiously, this will often priorize reading speed over resolution, letting you miss a lot of digits. As a sidenote here: “As-Is” is a bit misleading as a reset is implemented each time the instrument gets initialized by SweepMe. On a second though, we should either relable it to “Reset State” or remove the reset command.
- There is a kind of odd behaviour if the measurement result is either exactly zero or an overflow, so there are checks implemented before returning the result.
- As usual with these old machines, check that the GPIB address dip switches are not set to force the machine into a pure “talker” mode.
Have fun counting,
Christian