Agilent DSO-X 2002A driver for Mac OS X

Update, October 2^nd, 2014: a more recent adavancement in running SCPI on mac, can be found here.

Update, December 10^th, 2015: Updated terms, changed Agilent to Keysight.

December again, another year passed. Traditionally, this is a month when I am taking a long break. But I was up to something in the past days and I wanted to share.

I have created a driver for my KeysightAgilent DSO-X 2002A oscilloscope. Maybe not a big deal, but huge for me because this is the first time I am programming kernel extensions. And this works, without any kernel panics or other issues.

For those who do not know, KeysightAgilent DSO-X 2002A is a great tool. I bought it almost two and a half years ago and I still did not have the time and patience to write about it and about its great capabilities. It is a dual–channel 70 Mhz scope, comes packed with features and you can extend these via additional software options that you can buy licenses for: built-in function generator (with AM and FM modulation), mask limit testing and six–sigma compliance testing, segmented memory, memory upgrade (software !), bandwidth upgrade up to 200 Mhz, serial decoding, CAN and I2C etc. The best part is that all these can be remotely controlled via SCPI commands and sophisticated testing routines can be set up.

But one of its biggest shortcomings is the lack of a driver for Mac. There is an excellent free software suite from KeysightAgilent, for PC, called “Command Expert”; you can find more about it here. This allows SCPI communication supported by VISA (Virtual Instrument Software Architecture) instrument drivers which makes remote controlling this tool a breeze. Couple this with the extensive KeysightAgilent I/O Libraries documentation and superb .NET support, thus integration and communication with these devices from Windows platforms is very easy. Unfortunately — nothing similar for Mac. Maybe they had some solid reasons for not providing any support for Mac OS X but from my perspective this sucks. Maybe they will read this post and decide to create at least a driver. See below why “at least”. Of course I could heavily relied only on my little Toshiba chick for doing the job, but I decided to build a Mac driver and use it to remotely control my scope and capture measurement data.

Another problem is that there is no support for Mac OS X for VISA instrument drivers too. Some vendors (most importantly National Instruments with their NI-VISA 5.1.2 for Mac OS X) have their own proprietary drivers for products they market. But I found no open–source projects for Mac. Just bits and pieces and scarce information. Fortunately there is USBTMC. This stands for USB Test & Measurement Class. USBTMC is a protocol built on top of USB that allows GPIB-like communication with USB devices and this an open standard, extremely well documented. From the user’s point of view, the USB device behaves just like a GPIB device. For example, you can use VISA Write to send the SCPI *IDN? query and use VISA Read to get the response. The USBTMC protocol supports service request, triggers and other GPIB specific operations. USBTMC allows instrument manufacturers to upgrade the physical layer from GPIB to USB while maintaining software compatibility with existing software, such as instrument drivers and any application that uses VISA. This is also what the VXI-11 / LXI protocol provides for TCP/IP and I could’ve easily done my job with a LAN interface for my scope. But why not make things more difficult and more rewarding ?

It is important to note that not all USB devices are USBTMC–compliant. The device manufacturer has to add the support in the device firmware to support USBTMC. Traditional instruments (such as DMMs and scopes) with USB ports are most likely to support USBTMC so I assumed that KeysightAgilent was not so stupid to do otherwise. Luckily, my KeysightAgilent DSO-X 2002 A is USBTMC–compliant. Hooking the device and using Mac’s USB Prober to explore USB descriptors shows that this device is IEEE-488 compliant:

Using Mac USB Prober application reveals support for USBTMC / IEEE-488 for KeysightAgilent DSO-X 2002A.

Now this leaves with the question of implementation. I was tempted to try communicating with the scope from within application space and discard any kext development effort. This is a pain and I am not very familiar with driver development. Unfortunately, Apple decided to make my life difficult because its USBCDC driver matched the scope and locked it exclussively making it impossible to discover the USB interfaces in the application space. The only option I had was either to create a kextless driver and match the device based on VID/PID pair provided by the driver’s Info.plist; and do the rest in the application space; either to augment the driver code and provide entry points for Write and Read commands, implement as much functionalities as possible in the driver plane hoping that it would make life easier on the application side. I had one more argument in favour of a driver, the possibility to add support for more USBTMC–compliant devices in the future (with simple personality addition in the driver’s Info.plist file).

This post will not discuss practical implementation of the driver, I kept this for a separate article because that has a story of its own. Bottom line, I managed to successfully match the DSOX 2002A, probe it, start the driver and communicate with my scope as shown in the console output below:

KeysightAgilent DSO-X 2002A Oscilloscope on my MacBook Pro: custom I/O Kit driver output in console. Attaching and probing the device and its USB interface, starting the driver and exposing the interface for application–space use.

A quick view in I/O Registry Explorer shows matching with my custom driver class, ro_alauda_DSOX2002A:

I/O Registry Explorer &mdash: DSO-X 2002A matched against my custom driver (see class name in left pane, ro_alauda_DSOX2002A) with a score of 13.001 (??).

KeysightAgilent DSO-X 2002A on Mac, custom driver, I/O Registry Explorer — driver property table entries. I have removed the scope serial for security reasons. Note the complete descriptors and match to my custom driver cpp class, ro_alauda_DSOX2002A.

Next steps

The most difficult part comes now: implementing all USBTMC methods and first SCPI tests in the application space. But given the fact that I managed to do so much by now without too many kernel panics (sic !), I am very confident that I will manage to close this project with a working application that will remotely control my Agilent DSO-X 2002A from my Mac Book Pro. And if I did this in a week, I am sure Agilent can do it in a month. They can spare me of some effort. 😉

Stay tuned and don’t forget to comment.