read serial data from UNI-T UT61E DMM using Linux?

[JBeale]

I got the UNI-T UT61E meter mostly for the serial port function so I could log some data.  I assumed it would "just work" but turns out not.  My model came with a plain DB9/F serial cable, not USB.  I found an old USB/serial adaptor but it had issues with both Linux and Windows, so I got a new PL-2303 USB to DB9/M cable claiming to work with all known OSes. Sure enough it does work on Windows, but I want to log to a Linux box.  There is a program called "sigrok" that claims to do this https://sigrok.org/wiki/UNI-T_UT61E but it just gives me the cryptic error "HID feature report error: LIBUSB_ERROR_PIPE." and googling that string only shows that other people are in the same boat as me.

I know it can work, because the below minimal Python3 program running on Linux does show the raw data coming in at 2 lines per second.
 Any preferred tool for reading this meter under Linux?

Code: [Select]

import serial
port = '/dev/ttyUSB0'
ser = serial.Serial(port, 19200, timeout=2, bytesize=7, parity='O', stopbits=1)
ser.setDTR(True) # DTR-RTS pin voltage diff powers UNI-T serial cable opto-isolator
ser.setRTS(False) # note: using PL-2303 USB to DB9/M serial cable, 067b:2303
while True:
  s = ser.readline()
  print(s)
Sample output from above in "ohms" mode, of a 10k thermistor with changing temperature, first reading is 12.748 k ohms

Code: [Select]

b'212748300020\r\n'
b'211468300020\r\n'
b'210599300020\r\n'
b'210085300020\r\n'
b'209747300020\r\n'
b'209507300020\r\n'

In case of interest here's the sigrok output:

Code: [Select]

$ sudo sigrok-cli --driver=uni-t-ut61e:conn=067b.2303 --continuous -l 5
sr: [00:00.000001] log: libsigrok loglevel set to 5.
sr: [00:00.000053] backend: libsigrok 0.5.0/4:0:0 (rt: 0.5.0/4:0:0).
sr: [00:00.000110] backend: Libs: glib 2.54.1 (rt: 2.56.3/5603:3), libzip 1.1.2, libserialport 0.1.1/1:0:1 (rt: 0.1.1/1:0:1), libusb-1.0 1.0.21.11156, libftdi 1.3.
sr: [00:00.000122] backend: Host: x86_64-pc-linux-gnu, little-endian.
sr: [00:00.000136] backend: SCPI backends: TCP, RPC, serial, USBTMC.
sr: [00:00.000187] backend: Sanity-checking all drivers.
sr: [00:00.000206] backend: Sanity-checking all input modules.
sr: [00:00.000215] backend: Sanity-checking all output modules.
sr: [00:00.000220] backend: Sanity-checking all transform modules.
srd: libsigrokdecode loglevel set to 5.
sr: [00:00.006612] hwdriver: sr_config_list(): key 2147418112 (NULL) sdi (nil) cg NULL -> [uint32 20000]
sr: [00:00.006738] usb: Trying to find USB device with VID:PID = 067b:2303.
sr: [00:00.006782] usb: Found USB device (VID:PID = 067b:2303, bus.address = 1.17).
sr: [00:00.006800] usb: Found 1 device(s).
sr: [00:00.006827] hwdriver: Scan of 'uni-t-ut61e' found 1 devices.
sr: [00:00.006849] usb: Trying to open USB device 1.17.
sr: [00:00.006906] usb: Opened USB device (VID:PID = 067b:2303, bus.address = 1.17).
sr: [00:00.006961] session: Using thread-default main context.
sr: [00:00.006969] session: Starting.
sr: [00:00.006975] std: uni-t-ut61e: Starting acquisition.
sr: [00:00.006979] std: uni-t-ut61e: Sending SR_DF_HEADER packet.
sr: [00:00.006991] session: Running transform module 'nop'.
sr: [00:00.006996] transform/nop: Received packet of type 10000, passing on unmodified.
sr: [00:00.007002] session: bus: Received SR_DF_HEADER packet.
cli: Received SR_DF_HEADER.
Press any key to stop acquisition.
sr: [00:00.017813] uni-t-dmm: Successfully detached kernel driver.
sr: [00:00.017935] uni-t-dmm: Successfully claimed interface 0.
sr: [00:00.017958] uni-t-dmm: Sending initial HID feature report.
sr: [00:00.017975] uni-t-dmm: HID init = 0x00 0x4b 0x00 0x00 0x03 (19200 baud)
sr: [00:00.018259] uni-t-dmm: HID feature report error: LIBUSB_ERROR_PIPE.
sr: [00:00.018307] uni-t-dmm: HID chip init failed: -1.
sr: [00:00.018334] session: fd_source_finalize: key 0xffffffffffffffff
sr: [00:00.018410] session: Stopped.


[smithnerd]

This should work, provided that you have the serial driver compiled in (you can check with sigrok-cli -L | grep uni-t-ut61e-ser):

Code: [Select]

sigrok-cli --driver=uni-t-ut61e-ser:conn=/dev/ttyUSB0 --continuous

[JBeale]

Thank you, indeed it does work. I was following a web page that suggested the other way using the USB vendor:product ID format. Apparently there's some bug with that method, but your more user-friendly /dev/ttyUSB0 device name works OK. Hooray!

Code: [Select]

$ sigrok-cli --driver=uni-t-ut61e-ser:conn=/dev/ttyUSB0 --continuous
P1: 18.004 V DC AUTO
P1: 18.003 V DC AUTO
P1: 18.003 V DC AUTO
P1: 18.003 V DC AUTO
P1: 18.003 V DC AUTO
P1: 18.003 V DC AUTO
P1: 18.003 V DC AUTO
P1: 18.002 V DC AUTO
P1: 18.002 V DC AUTO


[JBeale]

To clarify the issue: there are two incompatible ways of connecting to UNI-T meters. One uses a cable going from the meter to a USB interface and that uses the HID type driver I tried first:   --driver=uni-t-ut61e

The other type goes from the meter to a DB-9 RS-232 serial interface, that most people then connect to a USB-to-RS232 interface. My meter came with the latter type RS232 cable so I added a USB-Serial adaptor.  For that you need:   --driver=uni-t-ut61e-ser

My problem was I was trying to use the former type HID driver, just going from a web page written for that case.  So I got an obscure error message, but the root problem was it was the wrong driver for the kind of cable I had.

I think it is an easy mistake to make as both drivers start with the same meter name instead of the actual USB interface type, so it would be nice if the error message gave some hint about what might be happening. Anyway, that's what happened.

[JBeale]

Plotting the voltage on a 50V 4700 uF electrolytic cap as it discharges through the ~11 megohm resistance of the meter, going from 17.471 V to 7.146 V in 12.8 hours (almost one RC time constant). The plot is pretty boring which here is a good thing.  Sometimes the reading has 1 mV worth of non-monotonicity but still not too bad, given the price of this 4 1/2 digit DMM.  I wrote "self-discharge" on the plot which is only true if you consider the meter part of the "self"

[linux-works]

I know this is an old thread, but curious if people still use/care about this meter (ut61e) ?

I've recently bought 2 more (maybe close-out deals?) and I spent some time designing a bluetooth, sd-card and web-based REST interface for this meter.

if there's interest, I can start a new thread to describe it.  the code is going to be on github shortly.

the top head unit has an sd-card, oled display, bluetooth sender and opto interface to the meter.  uses ESP8266 inside.

the box on the side has a bluetooth receiver (hc05), tft color display, also an sd-card.

both are REST based for remote control and config.

... and there is still more soldering on these (some switches and things are not even wired up yet) and a lot more sw features have to be finished, but its a WIP and this is the current state of this project.

[JBeale]

Very nice! I still use this meter often, I think it's quite a good deal for the price. In resistance range it can measure up to 200 megohms, and I did a recent PMT bias divider project where that range was useful.  I have more expensive meters that do not go that high.

[linux-works]

here's the latest status.  its getting pretty mature and I'm hoping to get it all ready to post to github this week or next.

I'm using 'espnow' and liking it, so far.  I have 2 meters with 2 'heads' and those are on the same wifi as the graph display (also esp arduino).  I'm using espnow to send updates from the heads to the display.  I also have a smaller box that is similar to the 'heads' but meant to just have usb going to a pc, where it can get the serial ascii update stream.

this forced me to learn a bit more openscad than I knew before.  so now all printable files are in .scad format.

I will start a new topic when things are a bit closer to being '1.0' ready.

[linux-works]

using 3d printed 'board' to hold the ESP chip so that you dont even need a perf or pcb at all.  its just 4 wires from the chip to the obligatory oled.  such a simple circuit - and I can print the 'board' at home in 1/2 hour.  no traces, of course, but for just 4 wires, this works ok in small quantities.

[JBeale]

Nice use of OpenSCAD. I used to use it much more, but for complex stuff I found the online GUI CAD tool OnShape to be faster to get things done with, and then I ended up using it for even simpler things. I keep expecting they're going to kill free access to it, but so far not yet.