Last week I bought a used, but purported working, Agilent U1272A 30,000 count multimeter on ebay and it arrived today.
The meter feels fantastic in my hand, and looks great. The rubber case isn't like the Fluke holster and doesn't seem to be made to come off, but I like it. Its definitely doesn't feel as robust as a Fluke, but I bought it for an accurate lab meter. I don't need a meter that I can throw at the wall and laugh, since I already have two Flukes (I'll get to these later...). Changing the batteries was easy enough, but they use two different sizes of Phillips head screws for the battery compartment and the body, which was annoying since the battery compartment screws require a pretty small Phillips driver. It would have been nice to be able to be able to use a #2 or something, but mostly thats just me being a The probes that come with it have that good quality silicone feel, and I like how only the tips are exposed so you're less likely to accidentally short the leads to a case or the other leads.
In terms of usability, the interface is about as unintuitive as I could imagine. Be prepared to thumb through the manual for just about everything (... and spend some time experimenting after reading the manual). I suppose its difficult to cram all the functionality into a handful of buttons, but the labels on the buttons are super confusing. As far as I can tell each button has at least 3 functionalities:
- A short press will toggle between things on top of the fraction (i.e. Hz % ms) or unlisted options (i.e. dual, the second numerical display),
- A long press (1 sec) with nothing pressed before it will do the thing on the bottom (i.e. Log),
- A long press with something pressed beforehand clears whatever has been done.
Nothing too bad except that the things you want to do certainly aren't going to be described by 3 word/symbols max. To use it easily, it feels like you will either need the manual close at hand or to be using it regularly.
Addressing Over a IR to USB Cable
I also bought an Agilent U1253A, with a broken OLED display, (which also arrived today) that came with the IR to USB connector, and I thought I'd try out the connector on the working U1272A first.
First off: I understand why a company might want to make a proprietary connector for their devices. It adds another source of revenue to the device and maybe it even adds some features, such as in this case full optical isolation from the computer. But I will always hate non-standard connectors. After non-standard connectors the next thing on my list is not releasing code to interface with the device. If I just spent hundreds of dollars on a piece of equipment that is able to communicate with the computer you better let me talk to it however I want not just through your shitty software! In this case it's especially annoying since the connector is apparently just a USB to serial device with an optical interface, using a form of SCPI. It's not like you're reinventing the wheel here Agilent (Sorry, Keysight! ugh...), a Python library would probably be too much to ask, but at least give us a communication protocol. I know it's written down somewhere over there!
Of course Agilent's (supposedly) shitty code is only for Windows anyway, so after a quick googling I found that some eevblog members had put a little work into some cross platform code for scripting. In particular I used user pdnyberg's dmmutils code which can be found here, on sourceforge. The code compiled and recognized my meter right away, but it seems that the protocol was written for a different model and I needed to make some minor changes as the data was not being read.
Basically is came down to a couple things:
- First off the syntax seems to have been wrong and I ended up switching to user insurgent's syntax.
LOG:HAND xxxxx(my model has 10,000 memory entries, why it couldn't be 0 - 9,999 and save a byte in communication I don't know...),
- the model that is was designed for doesn't have the third type of data logging "Triggered mode". A little copypasta fixes this changing
- I was getting a plus/minus error as well. The 8th MSByte of the data string that is read contains info about the polarity of the measurement, bxxxxxx1x is 0 for positive and 1 for negative. bxxxxxxx1 seems to be the lock on the measurement,
- Finally there was some very minor output formatting that is not interesting.
Once I hear back from the original author I will post a link to the modified code.
Anyway with a little effort I now have a brand (to me) new 30,000 count, soon to be calibrated lab-quality, data-logging, script-capable multimeter!
Pretty exciting stuff for a first real post.