Thoto.net

Introduction / Explaination of the problem

Just a few days ago I got a new "toy": an Agilent (now Keysight) U1233A digital multimeter.
It has some neat features, which made me decide to pay a bit more for it. Mainly that it has cool and helpful functions like a flashing display in case an alert occures and not just an audible message other devices have. Moreover it has a low impedance voltage mesurement function (called VZ_low) which helps to avoid measuring ghost voltages at long wires for example and contactless voltage alert which prevents me touching the wrong wire. It has a nice accuracy (0.5% ± 2 digits at DC Voltage 600mV ) which is much more than I will need in near future.

One of the most interesting features, that made me decide to buy this device is the compatibility to the Agilent U1177A Infrared (IR)-to-Bluetooth Adapter . With this tiny box attached to the back of the device you are able to get your measurements live to your Android® device or to your desktop computer. Agilent provides Android apps ( [1], [2]) and a Windoze application ([3]) to watch and log these values remotely. You no longer have to be in place at your point of measurement or put somebody else there to keep an eye on the display and take actions at some other point. If I switch off a fuse down in cellar it can send a message to my second mobile phone to tell me that I switched of the right one. You don't have to be in a dangerous area with high voltages right next to you just to read values appearing on the meters display.

But my problem was that there is no useful Linux software so I'm unable to measure with my preferred devices. I want to put a Raspberry Pi®, Cubieboard® or my laptop next to the device under test and get a message on my phone or log data for a long period of time. dmmutils ([4]) seemed to provide this functionality but when I tried it for the first time I was unable to get any useful or correct value out of it. Even after I fixed the hardcoded /dev/ttyUSB0 in it's code to read /dev/rfcomm0 instead it didn't work. It was intended to work with the USB-IR adaptor but I also doubt that it would work with this one. (Why? See below, I doubt the CR-LF problem doesn't appear here.) It's also packaged as one archive file for Linux and Windows® each with no seperate source code available. I would not write that kind of code yet I really like C and software written in C. But look for yourself and maybe fix it.

But apart from all the nagging about it it has a really neat and nicely formatted documentation as plain text file in it which also explains how the author figured out how the protocol works ... that is awesome! It also lists all commands being transmitted to the device. I tried to type them into minicom (9600 Baud, 8N1, no FC) but that didn't work for me first. I sniffed the serial interface and noticed that it uses DOS linebreaks (0x0d 0x0a which is ASCII CR LF which means a carriage return followed by a line feed) instead of UNIX ones (0x0a which means just LF / line feed) which minicom uses. I googled for it and found out you can send DOS linebreaks in minicom by pressing CTRL-j. That worked for me.

TL;DR

For short: With the U1177A Bluetooth® adaptor you have to send your commands terminated by CR LF. A command like FETC? shows you the current numeric reading of the display in scientific notation as ASCII text.

About the code

After I found this out I wrote a small program in Common LISP using SBCL which now also works on ARM® architecture since version 1.2.1. The program is listed below. It just fetches values if you execute (fetch-value). This function returns an integer instead of a string and omits every obsolete linebreaks which makes this function that complex for the job it does, namely just writing and reading to resp. from to a file (device).

It is only possible to execute commands returning one line like it's done in (fetch-value) with this code. I leave it to you to modify the code to get other commands working. Please publish your enhancements like I did. (The code should be taken as public domain and no warrenty is given upon it's function or malfunction or anything else. It may destroy your device or house or kill your dog or your cat or may directly lead to Ragnarök.)

The DMM also sends out-of-band messages for example the current selection when you turn around the dial (messages *0 to *7) and in case an error occures (*E). The code I wrote does not implement any kind of server and by this is not able to cope with that. It is also unaware of the device being switched off or losing connection. Your own code utilizing this functions should implement it. It's just a proof-of-concept which I might extend in near future. And it's not hard to do so, but my time is rare. ;-)

LISP Code

And now these 22 lines of code and magic:

; agi.lisp V0.0.2
(defun do-command (file command &key dbg)
  "Executes arbitrary command of u1177a's protocol which returns just one line"
  (with-open-file (f file :direction :io :if-exists :overwrite) 
    ; clear input buffer of serial line:
    (do ((l (listen f) (listen f))) ((not l) t) 
      (if dbg (format t "~a" (char-code (read-char f))) (read-char f))) 
    (when dbg (format t "~%--- Cleared input buffer to recieve command ~%"))
    ; write command including CR-LF (#x0d #x0a)
    (format f "~A~C~C" command (code-char #x0d) (code-char #x0a)) 
    (finish-output f) ; write command to device
    (when dbg (format t "--- Command sent ~%"))
    ; read result
    (multiple-value-bind (r) (read-line f) r))) ; mvb to skip second return
    
(defun fetch-value-string (&key dbg)
  "Fetches current reading from multimeter"
  (do-command "/dev/rfcomm0" "FETC?" :dbg dbg))

(defun fetch-value (&key dbg)
  "Fetches current reading from multimeter and returns it's value as number"
  (multiple-value-bind (r)  ; mvb to skip number of characters read
    (read-from-string (fetch-value-string :dbg dbg)) r))


	

Executing

If you are not familiar using Common LISP just a few comments on how to execute this code and how to get your values. Just save the file above to you disk. Start SBCL by entering sbcl to your shell prompt. When it is done loading (it load's a lot of stuff you may remove, so don't be afraid of the times it takes to load sometimes) you should see a prompt like * . Type (load #p"agi.lisp") to load the file named agi.lisp. Replace the name by the one you have chosen. Alternatively you may also simply paste the contents of this file to your SBCL REPL prompt. After doing that you should set up your bluetooth connection (see below). By typing (fetch-value) You should see the current reading of you multimeter's display. That's all.

Some remarks

By the way: What kind of bothers me, is that it's not possible to attach a current clamp to the U1233A like to the U1231A ... it should not be too hard to implement this. But well, you should buy a "real" current clamp if you are interested in this application. Still it is one more tool you have to carry around.

Fun notice: After I bought this device I noticed that the Fluke® 117 seems to be nearly the same device. Quite the same design, quite the same functionality, nearly the same price. Just a few features less and a slightly different look. Maybe it's some OEMs reference design ... which is quite well engineered if both Fluke and Agilent/Keysight would buy it. Or one device is a clone of the other. It would be interesting if somebody else has any information about this.

Setting up bluetooth

To set up bluetooth you need to connect to the device and add the configuration below to /etc/bluetooth/rfcomm.conf. Of course you need to replace MA:CM:AC:MA:CM:AC by your Bluetooth IR transmitter's hardware MAC address.

rfcomm0 {
	bind no;
	device MA:CM:AC:MA:CM:AC;
	channel 1;
	comment "u1177a";
}
	

After doing so you start up your Bluetooth daemons, unblock it's rfkills and setup the remote serial interface by rfcomm connect hci0 where hci0 is you bluetooth interface. Please don't forget to connect your device "as usual" and set the switch of your U1177A to the On position and select a mode on the multimeter.

This document was last modified at Wednesday, 02-Dec-2015 20:27:57 CET.