[SOLVED] Can't get UT61E RS232 interface working on Linux

[TheoB]

The UT-61E came shipped with a nice optical RS232 cable. I connect it via a RS232 to USB converter to my PC. But it does not work. I see data but the data is different from what it should be. I want to isolate the problem to either the UT61E being broken or the RS232 adapter being "bad". I found this thread that explains which adapter is supposed to work, and which one not. But RS232 is such a simple protocol I think it should work with any adapter (if drivers are OK, but since I'm on LInux I don't have those issues...)
So I decided to investigate and measured the RS232 interface signals on the connector. From there I could see the levels that were used, the timing and the data being send.
This is an example of a "1" captured (ASC=49, 0b110001):

The problem I see with the UT61E is that a logic bit should be 52us (1/19200) but I measure 69us. The captured signal consists of a start bit(1) 7 bits of data (1000110) a parity bit (1) and a stop bit (0). So 10 bits are exactly 10/19200=520us. The timing of each character is exact, but the 1 is always 69us and a 0 is always 35us. To me this looks like a lot of margin is eaten by the UT61E. 69us is 69/52=1.32 bit interval. A perfect receiver should determine the value in the middle of each bit, at 1.5. If my Chinese adapter also needs such a margin, it is not going to work. Is my meter not OK, or are such deviations normal for RS232?

[DimitriP]

Since you are on linux, what happens if you do
cat < /dev/PortNameHere 
?
if the port is receiving data, you should see characters flying by, if it looks like gibberish, the port is set to the wrong speed.

[TheoB]

Yes that works. But what I receive is a byte valued 3 were I expect a byte values 48 ("ascii 0"). I measured the speed and it is exactly 19200 Baud. I've found several references about this, for instance https://www-user.tu-chemnitz.de/~heha/hs/UNI-T/UT61E.LOG. I tried with all kind of terminal emulators. All seem to have the same problem, garbage out. And of course I still tried all settings as well, but no success.

[DimitriP]

which adapter is supposed to work, and which one not. But RS232 is such a simple protocol I think it should work with any adapter

Well... RS232-USB  adapters have ruined many perfectly good afternoons and weekends for many people over the years... At this point you probably should try a different adapter which is  easier (and cheaper) than trying a different UT61E

[cdev]

Has anybody managed to use their UT-61E with a USB-to-serial adpater ? On WIndows or under Wine.

[BBBbbb]

I've used mine without any problems (FTDI chip), but I did have a problem of optical alignment on the UT61E end, the connector was small/short and the IRs were just a little bit under the ones on the UT, so I had to pull it up just a little bit to work. Just small blind movement up and trying the communication until I got it in place.

Sent from my C6903 using Tapatalk

[Sairus]

Is my meter not OK, or are such deviations normal for RS232?

http://www.cyrustek.com.tw/spec/ES51922.pdf page 21

Has anybody managed to use their UT-61E with a USB-to-serial adpater ? On WIndows or under Wine.

I use cheap adapter from ali (it look like that one  https://www.aliexpress.com/item/USB-to-RS232-cable-USB-serial-transfer-line-laptop-serial-mini2440-OK6410-tiny6410-Wholesale/32525491623.html) work ok.

Just for fun I use OTG cable with  this adapter and got data from DMM by using terminal app.

[thisguy]

Yes that works. But what I receive is a byte valued 3 were I expect a byte values 48 ("ascii 0"). I measured the speed and it is exactly 19200 Baud. I've found several references about this, for instance https://www-user.tu-chemnitz.de/~heha/hs/UNI-T/UT61E.LOG. I tried with all kind of terminal emulators. All seem to have the same problem, garbage out. And of course I still tried all settings as well, but no success.

Here's the stty command that I use to set up the port. I issue this:
'stty -F /dev/ttyUSB0 ispeed 19200 cs7 parodd istrip igncr'
then
cat /dev/ttyUSB0
and get the expected result.

It looks like you might have the polarity backwards on the scope decode. Try changing the rs232 decode polarity. Also, the scope rs232 decode only understands what's on the screen, so if what is being displayed doesn't start with the start bit, the decoded data will be wrong.

If the above stty command doesn't fix it for you, it's possible that polarity from the UT61E serial cable doesn't match your serial/USB adapter. (RS232 logic: low=1. ttl logic: high=1) If that's the problem, a single $0.02 transistor between rx pin, rx wire and ground might fix it.

Sorry, never messed with it on wine or windows.

[SingedFingers]

Incidentally I couldn't get mine to work at all with various USB<->serial cables. I had to plug it into my desktop which has a real serial port. Worked fine there.

[TheoB]

Here's the stty command that I use to set up the port. I issue this:
'stty -F /dev/ttyUSB0 ispeed 19200 cs7 parodd istrip igncr'
then
cat /dev/ttyUSB0
and get the expected result.

It looks like you might have the polarity backwards on the scope decode. Try changing the rs232 decode polarity. Also, the scope rs232 decode only understands what's on the screen, so if what is being displayed doesn't start with the start bit, the decoded data will be wrong.

If the above stty command doesn't fix it for you, it's possible that polarity from the UT61E serial cable doesn't match your serial/USB adapter. (RS232 logic: low=1. ttl logic: high=1) If that's the problem, a single $0.02 transistor between rx pin, rx wire and ground might fix it.

Sorry, never messed with it on wine or windows.

The scope decodes fine. I put it on line to show the exact bits it sees (which are correct).
I tried the exact same stty command and get this (od added to show the values, otherwise it is garbage):

Code: [Select]

$ cat /dev/ttyUSB0|od -c
0000000 003 003 003 003 003 033 002 003 003 023 003  \v  \b 021 003 003
0000020 003 003  \v 032 002 003 003 023 003  \v  \b 021
0000034
$ cat /dev/ttyUSB0|od -x
0000000 0303 0303 1b03 0302 1303 0b03 1108 0303
0000020 0303 1b03 0302 1303 0b03 1108
0000034
I know it should end with\r \nl (0D 0A). This link gives a nice overview of what the meter outputs.

I partly solved the duty cycle distortion by pulling the adapter a bit out from the meter. The pulse width reaches close to 52us just before it completely fails. I do see some bits toggle during the exercise, but the data is not correct. I think that rules out the UT61E.
Found some old threads about the ch341 device driver (ch341 5-1:1.0: ch341-uart converter detected). It mentions it did not support parity. But I can easily work around that in software (just assuming 8 bits of data and stripping the MSB).
Probable best to try the aliexpress adapter.......

[TheoB]

Dual booted to Windows 10. Tried Putty and that did not work as the DTR (data terminal ready) line did not go high (and that is the power of the sensor). I could manually get it to work by powering it externally. I then tried dmm.exe and that worked out of the box. So meter is OK, rs232 => usb adapter is ok. It must be a driver issue under Linux.
Any suggestions for an adapter not based on the 341 chip that runs under Linux?
I just noticed the 341 driver is loaded but the chip reports 340. 

Theo

For ther record: I'm running Linux Mint with kernel 4.4.0-57-generic
Adapter details:

Code: [Select]

sudo lsusb -s 005:002 -v

Bus 005 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x1a86 QinHeng Electronics
  idProduct          0x7523 HL-340 USB-Serial adapter
  bcdDevice            2.54
  iManufacturer           0
  iProduct                2 USB2.0-Ser!
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               96mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      1
      bInterfaceProtocol      2
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

$ modinfo ch341
filename:       /lib/modules/4.4.0-57-generic/kernel/drivers/usb/serial/ch341.ko
license:        GPL
srcversion:     9E73466FFB6B6191F10D294
alias:          usb:v1A86p5523d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v1A86p7523d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v4348p5523d*dc*dsc*dp*ic*isc*ip*in*
depends:        usbserial
intree:         Y
vermagic:       4.4.0-57-generic SMP mod_unload modversions


[joeqsmith]

I tried mine under Windows 10 using an FTDI adapter and with the built-in port on my new PC.  I also tried it with my old PC and it seemed very solid.   

[TheoB]

Here's the stty command that I use to set up the port. I issue this:
'stty -F /dev/ttyUSB0 ispeed 19200 cs7 parodd istrip igncr'
then
cat /dev/ttyUSB0
and get the expected result.

If the above stty command doesn't fix it for you, it's possible that polarity from the UT61E serial cable doesn't match your serial/USB adapter. (RS232 logic: low=1. ttl logic: high=1) If that's the problem, a single $0.02 transistor between rx pin, rx wire and ground might fix it.

Sorry, never messed with it on wine or windows.

Do you have a ch341 based adapter?
I tried to invert the rx line and that also does not work. Instead of 3 I now receive 18 as value for zero (should be 48). Reason I still try to make it work is that I have to wait for another adapter for a couple of weeks to be delivered. So in the mean time I play around to see if I can get it to work. I found one other mention of the data inversion. The Linux driver was not detecting that automatically. So that made me do this one transistor exercise.
I plan to buy a PL2303HX based one to see if that works better.

[cv007]

Maybe you have done this already, but try using 8N1 letting the parity bit come in as data (MSb set or not set- just discard MSb). If the driver is botched, I would think they would at least get 8N1 right.

Also, just jumper tx/rx on the adapter, then send data (a text file or whatever) over the terminal with echo off and see what you get back. Try it with 8N1 and 7O1 and see if 7O1 even works.

[Marc M.]

I purchased the GW Instek version (GDM-461) because it had better input protection compared to the Uni-T version.  I repair CNC machining centers and occasionally I run into intermittent faults which may not appear for a few days making them exceedingly difficult to troubleshoot.  To help find these faults I wanted to set up a data logger with time stamps for long term monitoring of a suspected supply voltage, input line, etc.  but couldn't justify the $$$ for a commercial meter.

I have a bunch of Arduino Mega's laying around so I picked up the 461 to use with one and roll my own logger.  I ran into the same issue, I couldn't get either my laptop thru a RS232 to USB converter or the Mega to read the 461 data stream.  I hooked up my Rigol to it and found the RS232 output was inverted. Whacked together an inline inverter and both were able to read it without a problem.

I designed a shield for the Mega with a micro-SD slot, RTC, inverter, buzzer, and a relay. I should be getting the boards from iTead next week. The idea behind the buzzer was to alert the user if whatever was being monitored exceeded a preset parameter, typically under/over voltage/current.  Similar idea for the relay allowing me to stick a light outside of the electrical cabinet where you probably won't hear the buzzer, shut things down if it's critical, etc.

My biggest hurdle is the software side.  I suck at software and struggle with getting even simple things to work correctly . I've got it decoding properly, it's really the UI that's been very slow going .  If someone is interested in writing the software for it, I'd be happy to send them a shield in return. PM me to work out the details.

[thisguy]

Here's the stty command that I use to set up the port. I issue this:
'stty -F /dev/ttyUSB0 ispeed 19200 cs7 parodd istrip igncr'
then
cat /dev/ttyUSB0
and get the expected result.

If the above stty command doesn't fix it for you, it's possible that polarity from the UT61E serial cable doesn't match your serial/USB adapter. (RS232 logic: low=1. ttl logic: high=1) If that's the problem, a single $0.02 transistor between rx pin, rx wire and ground might fix it.

Sorry, never messed with it on wine or windows.

Do you have a ch341 based adapter?
I tried to invert the rx line and that also does not work. Instead of 3 I now receive 18 as value for zero (should be 48). Reason I still try to make it work is that I have to wait for another adapter for a couple of weeks to be delivered. So in the mean time I play around to see if I can get it to work. I found one other mention of the data inversion. The Linux driver was not detecting that automatically. So that made me do this one transistor exercise.
I plan to buy a PL2303HX based one to see if that works better.

My adapter uses a ch340 chip. It does 3v or 5v ttl voltage levels. I had to invert rx to make it work.

[TheoB]

Maybe you have done this already, but try using 8N1 letting the parity bit come in as data (MSb set or not set- just discard MSb). If the driver is botched, I would think they would at least get 8N1 right.

Also, just jumper tx/rx on the adapter, then send data (a text file or whatever) over the terminal with echo off and see what you get back. Try it with 8N1 and 7O1 and see if 7O1 even works.

I played with that idea indeed. I can remove the parity myself if that would be the only thing. The jumper between TX and RX I had not tried so that's a good suggestion. I tried and the result is weird. It does not work, so I monitor on the scope. I can see that the TX data is plain wrong. 8N1 coded data comes out with some characters correct if I ignore the MSB bit (so 7 bit decoded on the scope). But others characters come out upper case instead of lower case. There is no difference in upper and lower case anyhow. Regardless of how it's encoded, I should see difference between upper and lowercase characters.
I compiled the driver from the manufacturer website (CH341SER_LINUX) and get the same result. Unless someone has an idea I have to wait for the PL2303HX I ordered.

[TheoB]

Solved. I had to take the following steps:
Driver needs to be patched. I followed this article
Data should not be inverted. The data is correct coming from the UT61E.
Data should be read as 8N1 So 8 bits no parity 19200 baud. Reason for that is that the driver does not support 7 bit data. I'm not sure if that is true, but it is mentioned in the driver patch:

/* CH340 doesn't appear to support variable stop bits or data bits */

I tried and 7 or 8 bits gives exactly the same output.
After I read in the data I ignore the MSB (parity bit).
Now my output looks like this:

Code: [Select]

python read_dmm.py
1
0
0
0
0
0
;
0
0
0
8
0
Not very exiting yet, but I can now focus on the python code   

[lordvader88]

My cheap DDM can be modded to use its RS232 chip pinout.

But how old r all these DDM chips if RS232 is all they mainly use??? Even new very expensive quality DDMs use it , WHY ??

[cdev]

They use it both out of habit and because

it's the standard in this context, simple, and usually works. It's the subsidiary adaptors that make it difficult. Problem is solved magically if you have a real serial port, or better adaptor. It's not the chip so much as the presence of the other lines in the adaptor.
 UT61s use of opticals isolation makes it more useful. Another option would be Bluetooth.