Computer History Project 2018: Bringing back a Morrow V9054 1.8 GHz spectrum analyzer back to life

After having revived a HP E1498 VXI controller, which is a VXI Slot sized version of a HP9000 UNIX workstation from the late 90ies of the last century (LINK here) and the revival of a military use Subsonic analysis VME mainframe, it was only a question of time and opportunity to start the next computer history project.

The opportunity came in march 2018. Someone at eBay sold several new old stock Spectrum Analyzers.
I always looked for such a tool but was not willing pay 700 Euros or more for it. The eBay offer was roughly 300 Euros including delivery from USofA and customs. The reason for the low price was that the Analyzer came as a VXI slot card. This means no display, no input knobs and switches. A VXI mainframe controls the card and allows to transfer the data to a PC.

For most people, this is not very attractive. But I have a beautiful VXI  mainframe running, no problem to insert the spectrum analyzer card. So I decided to buy it. Some days later the analyzer arrived.

Morrow Technologies V9054 1.8Ghz Spectrum Analyzer

Morrow Technologies is a company that developed complex hardware solution for its customers. At some point in the mid 90s, they decided to develop some measurement devices because they need such tools themselves and to sell them in the VXI market.
They produced several Spectrum Analyzers, most of them are VXI based devices, which was a unique selling point then and as far as I know, is still today. They went out of the Spectrum Analyzer business later but are still
present with their main product line, which are industrial displays. Maybe I am leaving out important things, but this is what I understand from their website and company history.

My device is a Morrow V9054. It can be used in the range 100KHz .. 1.8GHz. It is a C sized VXI card which occupies two slots in the mainframe. Control is completely via VXI Bus. This means all control commands are send via VXI Word Serial Protocol and all responses (e.g. traces) are sent back by the same channel.

Displaying analyzer data in real-time, can this be done?

Displaying trace data with e.g. 25 frames per second requires transferring roughly 25*2K bytes per second from the VXI mainframe to the PC (for 1024 trace points with 16 bit value per point). This is roughly a continuous transfer of 50 KByte/s. Rendering must be able to process 1K data values with a rate of 25 frames per second.

I want to display the data in a web browser and to transfer the data with WebSockets.
So my first evaluation was to check if these requirements can be met with that technology.  I wrote a backend that generates some fake data and runs on the mainframe controller. This backend uses libwebsockets, a C implementation of WebSockets. The frontend was a simple TypeScript browser application that uses a HTML5 Canvas to render the data as pixels like a scope display.

The first test, without rendering, just pure transmission speed test, showed that I can transfer 600KBytes/second between a C written client and server. The VXI mainframe offers only 10MBit LAN access. So the data transfer
will have no problem with the required data transfer rate. The transmission rate would allow more than 200 frames per second.

The second test was to add HTML5 rendering and to use a browser as client. I experimented with several frame rates between 10 and 50 frames per second and found that the browser is not dropping frames up to 40 frames per second. My requirement is 25 fps, so rendering is also no problem.

To summarize, the targeted technologies would allow a nice rendering of the  analyzer data.

The question is then, how fast can the spectrum analyzer deliver its data?

Accessing the Spectrum Analyzer

The Device arrived with one diskette and one CD.
The diskette (20 years old) contained some libraries for Windows 95 and some include files for programmers. The CD contains a Windows 95 application which can access all spectrum analyzers from Morrow.

The libraries for Windows 95 include a PnP driver, a spectrum analyzer library and several transport layer libraries. These libraries include ISA Bus, VISA and TCP/IP. The later supports some Morrow developed protocol for some of their products that allow TCP/IP access. My device does not allow this. It only allows VXI Serial Word Protocol.

The „closest“ library for my environment is the VISA library. It uses SCPI codes to control the  device. My VXI controller supports SCPI so I am able to access the V9054 with that technology.

First test to access the device was successful. The following C program reads  out the firmware version number of the device.

#include <sicl.h>
#include <stdio.h>

int main(int argc, char **argv) { 
 unsigned short response; 
 unsigned short rpe;
 unsigned int ret;

 INST id = iopen("vxi,126");

 unsigned short cmd = 0xc8ff; // abort normal operation
 ret = ivxiws(id, cmd, &response, &rpe);
 if (response != 0xfffe) {
   printf("Error1: %xn", response);
 cmd = 0xfcff; // begin normal operation
 ret = ivxiws(id, cmd, &response, &rpe);

 cmd = 0x7c00; // get version
 ret = ivxiws(id, cmd, &response, &rpe);
 int major = response >> 4;
 int minor = response & 0xf;
 printf("Version: %d.%dn", *major, *minor );

The only two SICL functions used in this low level example are iopen() and ivxiws(). iopen() opens a communication channel to the device and ivxiws() is executing the Word Serial Protocol.

The card was sold with some manuals. I hoped to get a programmer’s guide in paper or on the CD. But I got no programmers guide. At least I have the Windows 95 compiled libraries…

We have 2018, IT has moved to mystical areas today. So hey, let’s decompile the DLLs.
I checked the available free decompilers. My first try was with Snowman (LINK). It was able to decompile, but I was not able to understand the resulting C code 🙁 . After some hours of trying, I gave up.

Second try was with RetDec. The results were much more  understandable for me, but I need two days to get the first clue whats going on in the decompiled source. Each DLL decompiled in a ~40.000 line of code file.
Most of the functions were named function_0xabfdssada() or so, and so were the parameters and variables.

I searched for known command values in the C Code. I knew some of the codes from the technical guide.  Some other codes are standard codes defined by the VXI spec. All codes are 2 byte words like 0x7c00 or 0xc7ff.
After several hours of searching, I found a function in the code that inquires the firmware version from the Spectrum Analyzer. Yahoo!
Soon I found further codes, all in the Visa library. This was the first sign that that what I was trying was possible with my means.

One of the header files describe a very large struct SA9052 which contains all configuration for the device. This device is used all through the spectrum analyzer library mtcsa32.dll .
The decompiler of course did not know anything about that header file. This means an original code like:

analyzer_config->start = 0.0; // a float value

was decompiled to:

(a1 + 16) = 0;
(a1 + 20) = 0;

So it is very important to know / calculate all byte offsets in the struct. Then the decompiled code can be converted to the original lines, which are of course much more readable.

I needed 2 further days to analyze the struct byte offsets. The compiler aligns contained datataypes to addresses. E.g. a double value is 8 bytes size and its start address inside the struct must then be a multiple of 8.
If the address which would be possible as next free address (e.g. 12) is not a multiple of 8, the next higher value dividable by 8 is used as offset (here: 16). The same is true for 4 byte data types like int32 and two byte data types
like int16.

My calculated offset values were mostly correct, but not all. By analyzing the code, I found a field used by the code but not contained in the struct definition. All offsets after that missing fields were wrong. Puh!
After inserting that field in the struct definition, I could decode all assignments back to the original source code.
I can do that manually. But when looking at ~130.000 LOC, this is not possible. An automated replacement is more or less required, but currently I am still doing this manually at the code pieces I am working on.
The replacement must be quite smart and requires a C code parser…

Going forward

After having a basic understanding what to do and how to do it, I wrote a simple test program for the first API function called mr90xx_init() .

#include <sicl.h>
#include <stdio.h>
#include <math.h>
#include <stdlib.h>
#include <sapform.h>
#include <sa_defin.h>
#include <str_9052.h>
#include <mr_defin.h>
#include <mrapp.h>
#include "helper.h"

int main(int argc, char **argv) {
  char sessionString[50];
  ViChar message[128];
  ViStatus mr90xxStatus;
  ViSession sessionId;

  sprintf(sessionString, "vxi,126");
  mr90xxStatus = mr90xx_init(sessionString, VI_TRUE, VI_TRUE, &sessionId);
  if (mr90xxStatus != MR90XX_IE_SUCCESS) {
    printf("Error mr90xx_initn");
  } else {
    printf("mr90xx_init OKnn");

Then I created empty files for the three decompiled DLLs named sa.c (for mrtsa32.dll), pnp.c (for mrtpnp32.dll) and visa.c for (mrtvsa32.dll). These files should contain at the end the manually changed code. I call these files the Clean Room Files.

The API function mr90xx_init() is inside mrtpnp.dll. So I copied that function to pnp.c The function calls other functions, so I copied all functions that were called by any function into the file.

By trying to compile and link my test.c , the Linker tells me what functions are still missing.

Result was that I have the complete code from the PnP DLL for the single function mr90xx_init() in a source file and not more.
Remaining are references to functions outside (to other DLLs) and to Windows APIs.

For all referenced functions in mrtsa32.dll, I did the same job and copied everything into the file sa.c. This results in a file sa.c that contains the complete code from the mrtsa32 DLL for the single function mr90xx_init() in a source file and not more.

I found that for the last library, the libvsa32.dll, the Morrow developers used another approach. There is no direct reference to VISA functions in the PnP code. They use a function table to call the transport driver function. This is a feature and allows to call different transport drivers. The driver DLL is loaded by the library depending on its configuration.

The issue here is to find the mapping and to understand how function parameters and return values are handled. I see offsets that are outside the SA9052 struct and that maybe the function pointers. But how are the functions are actually called?

At about that time I started to move my code to github. The complete project is there.

This post will be continued… newest development is always on github…

HP75000 Series C (Agilent E8401A) VXI Mainframe

The text below describes a HP75000 Series C mainframe. I also have a file describing a HP75000 Series B mainframe.

Meanwhile this beast occurred in my lab…

This is a large, noisy, but super-flexible VXI solution. All 14xx modules from HP and all older 13xx modules (with adapters) can be used inside this mainframe.

HP 75000 in general

The HP75000 is a VXI mainframe. A VXI mainframe is a standardized infrastructure where individual measurement devices can be simply plugged in and used. This is only possible because the two important areas of standardization have been addressed by VXI:

  • Hardware: VXI defines the physical layer where devices, even from different vendors can be integrated. The hardware layer includes electrical characteristics, wire protocols and such.
  • Software: VXI defines the software related characteristics to access and control the devices plugged into a mainframe.

By having standardized both software and hardware characteristics, devices can be developed by big vendors like HP and used in any VXI infrastructure.

Each HP75000 mainframe has a backplane offering several slots to plug in devices.  A mainframe needs a controller („command module“) which coordinates the devices plugged in and which communicates with the outer world, e.g. with a PC connected.

HP75000 were sold in three versions, named  „Series A“, „Series B“, and „Series C“.

HP 75000 Series C

My HP75000 series C is a VXI mainframe offering 13 „C-size“ slots for modules.
There is no built-in command module (like in Series B). A Command module must be added in Slot 0. This module can be a command module with RS232 and GPIB input or a specialized single board computer that fits into a Series C slot. The module in Slot 0 is responsible to control the devices and to communicate with the outer world.

For HP75000 Series C, the following features are important:

  • Devices like Multimeters, Frequency Generators, Digital I/O Boards and Switch-Boxes (Multiplexers) can be inserted
  • Access from PC to the VXI mainframe is (for the HP75000) via multiple ways like LAN or RS232

Details on slots: 13 C-Size slots, all with P1 and P2 connectors.


HP Agilent E8401A C-Size VXI Mainframe

Up to 13 modules can be inserted. The Mainframe supervises power condition. For example, I soldered my AUI transceiver adapter cable together in a wrong way, thus shorting the +12V and GND lines :-((( . This was no problem at all, the mainframe simply came up with SYSFAIL condition and nothing else happened…


HP E1498A Controller

This is a real beauty on its own. The HP E1498A is a complete VME-Slot-sized  UNIX workstation. Inside there is a single CPU (PA-7100LC, PA-RISC version 1.1c 32bit) with 100Mhz and up to 128MB RAM.

Regarding names The CPU and/or Board occurs in documents as „s700“. The board seems also often to be called V743 or V743i. But, at least I have seen a board called also v743 in B size form factor. The hardware offers the usual connectivity like:

  • Keyboard, Mouse (standard PS/2 connectors)
  • Video
  • Network (AUI)
  • SCSI (50 pin HD connector)

Because its an VXI controller we also have:

  • GPIB
  • several system clock and trigger connectors

The operating system is a real UNIX from the old days, namely HP-UX 10.2.

Below are some pictures of the HP E1498A.

HP E1498A

Right : CPU with cooler. Mid: 4 RAM modules 4x32MB=128MB.




PA-7100LC CPU @ 100Mhz

SCSI cable, some socketed PROMs containing the Boot code




There are two multi-pin connectors for mezzanine cards



NVRAM/RTC battery

3 big FPGAs are doing the peripheral work like SCSI, network etc.


Boot ROMs



HP-UX 10.2

Note that HP-UX 11.x will not run on the CPU.

HP-UX 10.2 is from the late 1990ies. But no worries. I have used Linux the last 25 years and also Solaris, AIX and even HP-UX 11.x on HP9000-workstations. From today, it’s fascinating how modern the HP-UX 10.2 is. If you’re familiar with Linux command line, you can use it right away. Some things are different, but not too different. After having worked several days now with HP-UX 10.2 I think it’s a pity that it was not free in the 1990ies. Many people would have liked to work with it, remember that Linux was then in it’s very early days and not as much comfortable as HP-UX 10.2 then was.

A bad thing from today’s hobbyist perspective is that all connectors of the E1498A (besides: Keyboard, Mouse and SCSI) are of a very special form factor. All are „Micro Sub D“.

Some of those Micro Sub D connectors. You can see that the complete RS232 connector contact area is about 5mm size

HP sold in the old days adapter cables (I suppose 1 adapter cable for a large gold nugget 🙂 ) and you can today buy those connectors from various sources.  If you’re a millionaire or otherwise crazy, this is an option – a single connector is not below 40 Euros!!!

I created the connectors I required myself from scratch…

Dimensions of the RS232 connector in mm.

Each DIY connector consists of the correctly sized small plates (from PCB material). They are glued together, between them the pins are hold in place by the glue. For the pins itself I used transistor pins.

DIY connector with 9 pins for RS232

After the successful creation of a 9 pin connector (RS232) I built the 15 pin one (LAN connector).

The connectors I created have no screws to mount them to the E1498 connectors, so they require a friendly environment 🙂

Standard transistors (e.g. BC557) have 1.27mm pin pitch. So I glued 3 transistors together on a plate. They are the 8 pin line of the 15 pin connector after 1 pin (leg) was removed.
A second plate was glued on top of the transistor pins for fixation.


Three further transistors with 2 legs removed were glued on the other side of the inner plate and fixed with a third plate.


I would not fly to the moon with these connectors but for installation and friendly use its stable enough.


Set up HP-UX 10.2 Operating System

My HP E1498A came from USofA without anything. No cables, no software, no nothing. So I ordered old HP-UX 10.2 installation disks via eBay – from Australia. HP licensed per machine/CPU in the old days, so if you have the hardware you’re safe (but I am not a lawyer). From those disks, a „cold install“ can be done.

First boot, without disc or anything attached. I just put the oscilloscope probe to the RS232 Tx pin and switched my Rigol to RS232 decoding. The E1498A dumps ~360 bytes which I can read before its hanging waiting for boot devices. The decoded (green bottom) line here says „All rights reserved“. So it’s working 🙂

A SCSI disk must be attached as installation target and a SCSI CD drive as installation source (there are other options like network installation but I decided to keep it simple).

The mainframe, on top of it SCSI CD-ROM and harddisk. Network connectivity via AUI-Transceiver.

Installation arrangement: SCSI CDROM drive plus an on-the-fly self-made external SCSI harddisk.

At the beginning of installation, the partition sizes (logical volumes) can be define. The default values are crazy small, some megabytes here and some megabytes there. You must change these values, otherwise it will give very soon problems when adding OSS software etc. I made partitions not smaller than 512MB, for /usr, /opt and /home several GB sizes. There are some volume group parameter values to tweak in the installation gui for such large sizes named pe_size and max_pe, see here.

In my personal stock, I found a usable 18GB harddrive to use.

After the base installation from a single CD, other applications can be installed from software depots (CD-ROMs, files, network).

Online software depots are almost gone for HP-UX 10.2. There are still some ftp Servers offering compiled packages for gcc, bash, bzip2 and more. See links at end of this post.

Using the „sam“ tool, many administration tasks can be executed.

CD-ROM mount

Checking all disk devices:

% ioscan -fnC disk

Class     I  H/W Path   Driver      S/W State   H/W Type     Description
disk      0  2/0/1.4.0  sdisk       CLAIMED     DEVICE       HP 18.2GST318406LW
                       /dev/dsk/c0t4d0   /dev/rdsk/c0t4d0
disk      1  2/0/1.5.0  sdisk       CLAIMED     DEVICE       YAMAHA  CDR400t
                       /dev/dsk/c0t5d0   /dev/rdsk/c0t5d0

The mount command is then

mount -o ro /dev/dsk/c0t5d0 /cdrom

# df

/cdrom               (/dev/dsk/c0t5d0     ):        0 blocks         0 i-nodes 
/home                (/dev/vg00/lvol4     ):  7385992 blocks    673591 i-nodes 
/opt                 (/dev/vg00/lvol5     ):  3520138 blocks    335703 i-nodes 
/tmp                 (/dev/vg00/lvol6     ):   882914 blocks    237891 i-nodes 
/usr                 (/dev/vg00/lvol7     ):  3179068 blocks    324120 i-nodes 
/var                 (/dev/vg00/lvol8     ):  1558032 blocks    469323 i-nodes 
/stand               (/dev/vg00/lvol1     ):   424334 blocks     41070 i-nodes 
/                    (/dev/vg00/lvol3     ):   890816 blocks     80391 i-nodes

Mount harddisk in mainframe slot

HP offered 1-slot modules with harddisk+floppy (e.g. HP E4208). I use an B-Size – To – C-Size Adapter and mounted there a harddisk inside. The P1 connector of the adapter has the required voltages for the harddisk (5V, 12V and GND). I connected the harddisk there and a SCSI cable connects the harddisk with the V743 module.

As soon as NFS works, the external  CD ROM is not really required anymore.

Software installation

The command swlist lists all installed packages. Below is the output after base installation:

# swlist
# Initializing...
# Contacting target "vxi1"...
# Target:  vxi1:/
# Bundle(s):
#  B3782EA               B.10.20        HP-UX Media Kit (Reference Only. See Description)
   HPUXEngCR700          B.10.20        English HP-UX CDE Runtime Environment

The command swinstall serves to install software. Start it with a source argument or without any arguments and enter interactively the required values. Finally the command can be started from inside sam.

 swinstall -s <hostname>:/<source-path>

If the user is not allowed to install software (I had this for root at some point) you can extend the „Software Access Control List“ with swacl.

Export current ACL to a text file:

swacl -l host >

Add with an text editor a line for the user that should be added to the ACL, e.g.:


Re-import extended file to ACL system:

swacl -l host -F

Adding of patch bundles and other software

There are many patches for HP-UX 10.20. Some of them are patch bundles containing hundreds of patches in one big chunk. Bundles can be installed like any other software using the swinstall tool. Look for the „General release“ and „ACE“ bundles.

Patches I installed:

      • XSW700GR1020 (more than 100 products)
      • ACE workstation (updating ~116 products, i.e. packages)
      • ACE networking (seems to be contained more or less 🙂 in the workstation patch bundle)

I hoped the ACE patches raises nfs to v3, but it does not.

After base installation I have installed several things:

      • Java (JRE+JDK)  (super-old version 1.0.3),
      • A Patch bundles named „XSW700GR1020“ (General Release Patches for HP-UX 10.20 Workstations)
      •  B6378DA:Networking ACE and B6193EA Workstation ACE patch
      • E2091F: HP  I/O Libraries (see below)
      • Several OSS tools like bash, gcc etc.
 # Initializing...
 # Contacting target "vxi1"...
 # Target:  vxi1:/
 # Bundle(s):
 B3782EA                       B.10.20        HP-UX Media Kit (Reference Only. See Description)
 B5455AA_APZ                   B.01.03        HP-UX Development Kit for Java* (S700)
 B5457AA_APZ                   B.01.03        HP-UX Virtual Machine for Java* (S700)
 B6193EA                       ACE.199912.01  Workstation ACE for HP-UX 10.20 (December 1999)
 B6378DA                       ACE.199912.01  Networking ACE for HP-UX 10.20 (December 1999)
 E2091F                        G.01.02        HP I/O Libraries for HP-UX
 HPUXEngCR700                  B.10.20        English HP-UX CDE Runtime Environment
 XSW700GR1020                  B.10.20.33     Extension Software Patch Bundle
 # Product(s) not contained in a Bundle:
 bash                          4.3.30         bash
 binutils                      2.9.1-1        GNU binutils
 bzip2                         1.0.6          bzip2, bunzip2 - a block-sorting file compressor
 gcc                           4.2.2          gcc
 grep                          2.21           grep
 gzip                          1.3.9          gzip
 lsof                          4.80           lsof
 tar                           1.20           tar


Set Up Networking

HP E1498A contains everything required for network access. It has a 15 pin AUI connector in the Micro Sub D form factor (female).

Get a male connector for that and a female 15 pin Sub D connector. Wire pin numbers 1:1 together. Then an AUI-Transceiver can be connected to the female connector. The other side of the AUI Transceiver is 10Base-T, which can be connected to any modern network. AUI-Transceiver pin numbering is standardized, so you can use every transceiver you want.

My used CentreCOM 210TS AUI-Transceiver, bought from China for ~6 Euros.
On the left you can see the yellow 10Base-T cable, on the right the 15 pin connector. The transceiver is powered via the 15 pin connector from the E1498A.

Using sam, the LAN interface („lan0“) can be configured with an IP address, DNS server etc. Having done this, the interface is immediately up and running.

HP-UX can run several network services, e.g. telnet or nfs (v2), automounter can be used out of the box.

Note: Change nsswitch order (in sam, to take /etc/hosts first). Otherwise the machine may not find itself 🙂

ntp time synchronization

When trying to set up ntp, the client program refuses to synchronize to my time server (a fritz box which synchronizes itself from a public time server). During installation, it was not possible to enter a date behind 1999 and so I entered a date from 1996 (today-20 years). When later setting up ntp, xntpd did not like this and prints out:

Aug 28 01:10:49 vxi1 xntpd[5826]: Clock appears to be 631564685 seconds slow, something may be wrong

Aug 28 01:10:49 vxi1 xntpd[5826]: system event 2: System or hardware fault.

To overcome this a sync can be forced using this command:
     ntpdate <time_server_ip_address>

After that the system clock is correct and will be correctly synchronizing in the future.

Set up X Windows

The HP E1498A runs X11R6. If a keyboard and a mouse and a monitor is attached to it, the X Server is started. Otherwise  X clients can only be used with a remote display (i.e. X Server). The base installation has only a few x clients to run.

On OpenSuse Leap 42 I was not able (easily) to let the X Server  listen to port 6000, which is required for X clients without a ssh connection. Finally I use a socket forwarding command like this:

socat -d -d TCP-LISTEN:6000,fork UNIX-CONNECT:/tmp/.X11-unix/X0

After this, clients can connect in this way:

export DISPLAY=my-pc:0.0

Error messages: /var/dt/Xerrors

Set up VXI software

After the basic OS is running, I added required software for accessing the VXI devices. To control VXI devices from the HP E1498A, two things are needed:

  • Hardware:
    • Either a GPIB controller/Command Module that fits into the mainframe. This thing is called HP E1406A.
    • Or use the VXI backplane together with ISCPI interface (see below). Then no GPIB is used at all.
  • Software: HP provided all the required software on a CD called „E2091F I/O Libraries for HP-UX 10.20“.

This software is not anymore provided by Keysight. You have to buy it somewhere else, eBay is your friend here.

After install, use the tool iosetup (an X Windows client) to configure the VXI- and the HPIB device inside the V743 board. iosetup will reconfigure those as new interfaces and recompile the Kernel. After a reboot, note that /dev/sicl is populated with many new devices.

Also, add ISCPI (Interpreted SCPI) as an interface. This allows to control HP measurement devices directly via VXI backplane, even without the need for a command module. This approach translates transparently SCPI commands to register-based calls.

iosetup GUI after adding vxi, hpib and iscpi interfaces (click right mouse button ‚open image‘ to enlarge)

After having all done this, devices in the mainframe can be accessed. The following C code accessed my HP E1411B digital multimeter at logical address 8 (code taken from HP documentation). It uses the ISCPI interface by using the device address „iscpi,8“ .

#include <sicl.h>
#include <stdio.h>

void main()
INST dvm;
char strres[20];

/* Print message and terminate on error */
ionerror (I_ERROR_EXIT);

/* Open the multimeter session */
dvm = iopen („iscpi,8„);
itimeout (dvm, 10000);

/* Initialize dvm */
iwrite (dvm, „*RSTn“, 5, 1, NULL);

/* Take measurement */
iwrite (dvm,“MEAS:VOLT:AC? 1, 0.001n“, 23, 1, NULL);

/* Read measurements */
iread (dvm, strres, 20, NULL, NULL);

/* Print the results */
printf(„Result is %sn“, strres);

/* Close the multimeter session */

Compile this with HP’s cc or gcc.
gcc vximesdev.c -o vximesdev -L /opt/sicl/lib/ -lsicl

Output looks like this:
bash-4.3$ ./vximesdev

Result is +1.220703E-002


Installation and Configuration Guide for Linux I/O Libraries (41 pages, for Linux, but you get idea for HP-UX too)

HP E1411A Digital Multimeter

This is like the HP E1326A but in a C-sized form factor.

Jumpers for GPIB secondary address (here: 8) and IRQ (here: 1).


HP E1411A Service Manual


  • Micro D / Micro D-Sub / Micro Sub-Dmale layouts document
  • Micro D / Micro D-Sub / Micro Sub-D 9 female pin layout document
  • Micro D / Micro D-Sub / Micro Sub-D 15 female pin layout document

Further readings