The short version
I wrote a toy Perl program which talks to the Agilent U1272A: feel free to play with it!
- 2011-06-20: Version 0.1.
The Agilent U1272A
Agilent make a very nice and particularly orange multimeter: the U1272A. Like many bits of modern test kit, one can connect it to a computer. In this case there's an infra-red dongle which connects the meter to a USB port.
Although it's nice to see the current reading, the computer connection is particularly useful in conjunction with the meter's ability to log data autonomously to its internal memory.
For example, one can leave the meter recording a voltage every 10s then come back the next day and see the result. We're limited to 10,000 measurements which is roughly a day's worth of samples if they're 10s apart.
Unsurprisingly Agilent provide pretty Windows software to handle all this, but I use a Mac. Happily kind people have done most of the hard work already. Building on this, I wrote a toy Perl program which talks to the meter. In the absence of proper documentation it's far from production quality but you might find it useful or at least fun.
We'll begin with the hardware. It transpires that internally the IR dongle is based around a Prolific 2303 USB to Serial bridge. These are quite common devices, and there's a Mac driver. Actually there are two:
I used Failberg's driver, but I should say that I can't and don't vouch for the quality of either driver. Install them at your peril!
Assuming that you are feeling lucky and install the driver, you should find that when you plug the cable into your Mac, a device is created:
$ ls /dev/tty.PL* /dev/tty.PL2303-003312FD
The key part here is the /dev/tty.PL2303: the serial number which follows is presumably some unique device ID.
Once the dongle's installed and you've got a suitable /dev/tty.PL entry, then it's fairly straightforward to talk to it.
Inevitably, there's the usual serial configuration mess to navigate. My meter was set to 9600 baud, 8-bit, no parity and 1 stop-bit, but you should check for yourself in the meter's setup (see section 4 of the fine manual for details). I tried to set the baud rate to 19200, but failed: I'm not sure why.
One other minor issue: if the meter's in logging mode it seems keen to send each reading over the port as it's made. That might be handy for some applications, but it's not compatible with my code. You could of course use this to test the comms though!
The Mac isn't well blessed with nice serial terminal emulators, but the screen program can be press-ganged into the task. A word of warning: it's hardly user friendly!
To try it:
- Start the screen program:
$ screen /dev/tty.PL* 9600
- Type the following (note that you won't be able to see what you're typing):
- Send the command by hiting CTRL-J. You should see the meter identify itself:
- Make sure that the meter's data logging mode is set to AUTO. Start the meter logging data by holding the 'Hz % ms / Log' button down until the 'LOG' icon is displayed. You should see a message every time a new datum is stored. Frankly I don't understand the format properly, but the meter reading seems to be stored in the third to seventh digits (XXXXX) in this example:
- Stop the logging by holding the 'Hz % ms / Log' button down until the 'LOG' icon disappears.
- Quit screen by typing CTRL-A k.
Sadly there's not yet any proper documentation from Agilent for commands the meter understands, but the Internet is full of helpful and knowledgable people. Thanks to `insurgent' on the EEVblog forums for posting the basic information.
Obviously it's a pain to keep typing commands into a terminal emulator, so I wrote a toy utility to save my fingers. Perl seemed a good choice because compiling's a bore, and nothing here is remotely performance critical. Given that the command set is based on SCPI I'd hoped to find some helpful Perl modules lying around on CPAN too.
A couple of things seemed as though they might help: GPIB and Lab::Instrument. Sadly though, neither actually helped. Both packages are large and quite complicated: GPIB seems to have suffered bitrot and didn't compile, whilst Lab::Instrument wants an underlying C library.
All of this seems rather large and baroque: the SCPI spec runs to nearly 1000 pages, and both of Perl libraries bristle with classes. If you're building a big experiment I can see the sense in this, but I just wanted a simple way to tickle the serial port.
So my toy program is a thin wrapper around Device::SerialPort It's a noddy program, very much in the `send a line, read a line' style, but knows enough to handle error conditions from the meter, and to iterate through the saved data log.
I should emphasize that it's not proper production quality code though: regard it more as research than solution. For example, the code assumes that there's just a single /dev/tty.PL* device and that it corresponds to the Agilent meter.
A more significant limitation is its failure to do much parsing of the data coming back from the meter.
The only real dependency is Device::SerialPort, which you can get from CPAN. So, once you've installed the device driver all you'll need to do is:
$ sudo cpan Device::SerialPort ... $ curl http://mjo.tc/atelier/2011-06/u1272a.pl -o u1272a $ chmod a+rx ./u1272a $ ./u1272a
The basic command queries the meter for some basic data. You'll notice the absence of any parsing!
$ ./u1272a Opened /dev/tty.PL2303-003312FD :) — battery: 77% config: '"V,0,DC"' identity: 'Agilent Technologies,U1272A,MY12345678,V1.30' reading: +4.23800000E-02 reading2: +2.09500000E+01
If you want to watch what's happening at a low-level add the --trace option:
$ ./u1272a --trace Opened /dev/tty.PL2303-003312FD :) 0.000 >: *IDN? 0.070 <: Agilent Technologies,U1272A,MY12345678,V1.30 0.070 >: SYST:BATT? 0.092 <: 77% 0.092 >: CONF? 0.110 <: "V,0,DC" 0.110 >: FETC? 0.142 <: +4.23500000E-02 0.142 >: FETC? @2 0.174 <: +2.09500000E+01 — battery: 77% config: '"V,0,DC"' identity: 'Agilent Technologies,U1272A,MY12345678,V1.30' reading: +4.23500000E-02 reading2: +2.09500000E+01
Probably the single most useful task for the program is to grab the meter's data logs. The --get_log option does this, but the returned data are parsed very crudely. Please check the output carefully.
Specifically we read the entire log and write it to a text file, one measurement per line. The meter returns a string of digits like "AABBBBBCCCCCC" for each datum, where BBBBB contains the measurement. This is written to the file as NNNNN BBBBB AA CCCCCC, where NNNNN just counts upwards.
So, to plot the readings get the x-coordinate from the first column, and the y-coordinate from the second. In gnuplot:
gnuplot> plot 'auto.txt' using 1:2 with dots
Here's an example:
$ ./u1272a --get_log=AUTO Opened /dev/tty.PL2303-003312FD :) Grabbing AUTO log: 0: ......... 1000: ......... 2000: ....... Finished 2727 data from AUTO log written to auto.txt
The graph below was produced using the code. It shows the voltage across an alkaline AA cell as it's cruelly discharged through a small resistor.
Data were logged every 10s by the meter, then the logs downloaded to the computer. The data were scaled, then plotted with gnuplot. There's a real pleasure in measuring and plotting 1700 points so easily!
As you'll have seen, very little of this is Mac specific. I expect it would work as-is on a Linux box and there are some suggestions that a suitable USB driver is already baked into the kernel.
Device::SerialPort is supposed to emulate the API of the Windows specific Win32::SerialPort module, so perhaps a Windows port wouldn't be hard either.
On the device side, Agilent's official software claims to support the U1230 and U1250 as well, so perhaps they'd work with this software too.