UT61E Protocol Description

Posted by on March 18, 2013


The protocol used by the UT61e is quite simple, each packet contains 14 bytes. It constantly streams packets as the screen is updated at around 2 packets a second. The 14 bytes are basically a string where the range, digits, function, status are contained.

The serial interface settings are:

19200 baud, odd parity, 7 data bits, 1 stop bit, no handshake.

Describing the protocol:

This snippet shows you how the data is separated, I handle the 14 bytes as a string, which simplifies the process of separating each portion and since this is a low sampling rate application with low priority, it’s not a resource hog.

If ReadSerialPortData( port, @inp, 14 )
	If AddElement( *this\sample() )
		*this\sample()\range 		= Asc(Mid(inp,  1))  ; RANGE
		*this\sample()\digits		= Mid( inp, 2,  5 )  ; DIGITS
		*this\sample()\function 	= Asc(Mid(inp,  7 )) ; FUNCTION
		*this\sample()\status		= Asc(Mid(inp,  8 )) ; STATUS
		*this\sample()\option[0]	= Asc(Mid(inp,  9 )) ; OPTION 1
		*this\sample()\option[1]	= Asc(Mid(inp, 10 )) ; OPTION 2
		*this\sample()\option[2]	= Asc(Mid(inp, 11 )) ; OPTION 2

I believe the last two digits are the “end of packet” limiter (CRLF) however I currently cannot test this, I wrote the code a long time ago and I forgot to comment on this slight detail, but as you can see I’ve defined the CRLF contants, so it must be there.

A list of constants:

Here are some constants from my UT61e (unpublished) library…

#FUNCTION_VOLTAGE 		= %0111011
#FUNCTION_CURRENT_22A		= %0110000
#FUNCTION_OHMS			= %0110011 
#FUNCTION_DIODE			= %0110001 
#FUNCTION_ADP			= %0111110

#RANGE_ONE			= %0110000 ; Example: 22.000nF
#RANGE_TWO			= %0110001 ; Example: 220.00nF
#RANGE_THREE			= %0110010 ; Example: 2.2000µF
#RANGE_FOUR			= %0110011 ; Example: 22.000µF
#RANGE_FIVE			= %0110100 ; Example: 220.00µF
#RANGE_SIX			= %0110101 ; Example: 2.2000mF
#RANGE_SEVEN			= %0110110 ; Example: 22.000mF	
#RANGE_EIGHT			= %0110111 ; Example: 220.00mF

#DIGIT_0			= %0110000
#DIGIT_1			= %0110001
#DIGIT_2			= %0110010
#DIGIT_3			= %0110011
#DIGIT_4			= %0110100
#DIGIT_5			= %0110101
#DIGIT_6			= %0110110 
#DIGIT_7			= %0110111 
#DIGIT_8			= %0111000
#DIGIT_9			= %0111001

#STATUS_OL			= 1 < < 0
#STATUS_BATT			= 1 << 1
#STATUS_SIGN			= 1 << 2
#STATUS_JUDGE			= 1 << 3

#OPTION1_RMR			= 1 << 0
#OPTION1_REL			= 1 << 1
#OPTION1_MIN			= 1 << 2
#OPTION1_MAX			= 1 << 3

#OPTION2_0			= 1 << 0
#OPTION2_PMIN			= 1 << 1
#OPTION2_PMAX			= 1 << 2
#OPTION2_UL			= 1 << 3

#OPTION3_VAHZ			= 1 << 0
#OPTION3_AUTO			= 1 << 1
#OPTION3_AC			= 1 << 2
#OPTION3_DC			= 1 << 3

#UT_CR				= %0001101
#UT_LF				= %0001010

That's all for now, I currently don't have a serial interface to test with (Ain't got the USB cable either) so I can't finish the library as to post it, but hopefully I'll get it done eventually.

The supplied software by UNI-T is pretty bad and it's Windows only, hence the drive to write my own.

As it is, it should give someone a head-start if they're about to write their own front-end. On the datasheet of the UT61e controller it's all explained in fine detail, but I can't recall the number at the moment.

This whole thing was part of a bigger picture, but I had to give up the concept due to lack of funding.

Alright, enough of this shoulda, coulda, woulda!


10 Comments on UT61E Protocol Description


  1. Robert says:


    Will this library work on OS X?
    That would be perfect because there is no way to get the ut61e work with a mac.
    I’ve tried others (e.g: http://www.steffenvogel.de/2009/11/29/uni-trend-ut61e-digital-multimeter/) which compile fine but finally don’t work on OS X.


    • GuShH says:

      Hi Robert, I don’t have a way to cross-compile for mac directly at the moment, I would need to ask someone with a mac to compile it for me. The code is cross-platform, it’s just unfinished because I lost interest at the time. I don’t see why it wouldn’t work provided you had a COM interface (proper ftdi serial to usb or an actual serial interface). But as a library it would just expose a few functions, an utility would be required to make use of it.

      • Robert says:


        Thank you for your very quick answer.
        Unfortunately I’m quite bad in c-language, but i need only a command line utility which shows the actual value.
        Would you give me a try to compile your library?


        • GuShH says:

          The code is not C, it’s PureBasic (the language I choose for quick projects) sadly it’s not freeware. Which OSX version are you running?, I’ll let you know if I can come up with something. Cheers.

          • Robert says:


            Thank you for your answer.
            I’m running 10.7 and 10.8 and tried to compile the sources of Steffen Vogel, which
            works on Linux but not on OS X 10.7 or 10.8 on the same machines.


          • GuShH says:

            Robert, could you try this on your mac? http://gushh.net/tmp/ut61e.app.zip, it’s a terminal application, it will prompt you the com device name/number, if successful it should display the captured data on screen. On Windows and in my case it was COM1. Let me know how it goes, I’ll release the source later on.

  2. Robert says:


    I’m now back at home to try your software:
    Unfortunally it seems to hanging in a loop ( according to dtruss output) without any output or error message…


    • GuShH says:

      Hi Robert, it’s very hard for me to test it without a Mac, I just compiled the same unmodified code I’ve run on Linux and Windows using an OSX VM. Initially it waits for input on which COM device to listen to, then it loops and outputs the contents from the buffer. If I can I’ll try to interface some serial device to the VM and run some live tests with the meter. I’m not into Macs but that doesn’t mean I shouldn’t try to support the platform whenever I can.

  3. Robert says:

    Hello, me again!

    Just found a working solution of OS X:
    obviously posted 2 days ago.

    Thank you very much for your effort!


    • GuShH says:

      That’s great news for OSX users!, too bad UNI-T never answers my emails… That just about sums up their level of support.