Sunday, February 21, 2016

Bluetooth adapter for UNI-T UT61E multimeter

This is a useful little project I did already quite some time ago. Since it may be of interest to some people I want to write something about it.

My UNI-T UT61E multimeter has a data out port, which can be used for data logging on a PC. The meter comes with a data cable to connect it to a RS232 port. This has two problems. RS232 ports on computers are quite difficult to come by these days, and even if you have an RS232 port, you have to have a cable connecting the meter to the PC. UNI-T sells a USB cable to get around the first problem, but you still are limited by the cable length.

For my own solution I wanted to go wireless using Bluetooth. I had a spare Bluetooth serial port module laying around, which was suitable for the job. First thing to do was to check how to interface the UT61E. I found the schematic of the RS232 cable at I've recreated the schematic here. The author of that other blog modified the RS232 cable to interface it with a USB low level serial adapter. I however wanted to use the cable unmodified.

Schematic of the UT61E RS232 adapter.
The data transfer from the UT61E is optoisolated using an IR led in the UT61E and a phototransistor in the adapter. The circuit in the adapter works as follows. If there is no light transmitted from the multimeter, D1 will not sink current. Q2 will thus be in cut-off and its collector will be pulled to -12V. No current thus flows on the base of Q1 and hence R3 pulls RxD to -12V. However, if light lands on D1, it will sink current through the base of Q2. Thus Q2 turns on and the voltage on its collector rises to near +12V. Q1 then acts as an emitter follower pulling RxD near +12V. On RS232 the logic levels are such that negative voltage is a 1 and positive voltage is a 0. Thus, when the UT61E wants to transmit a 1 it turns the IR off and when it wants to transmit a 0 it turns the IR on.

The bitrate at which the multimeter operates is rather slow at 19200 bps (actually 19230 bps to be exact). This allows a lower voltage than 12V to be used and still have the RxD swing quickly enough. In fact, connecting the -12V line (RTS) to GND and the +12V line (DTR) to 5V still produces good output.

Even if running at 5V, as described above, the RxD line still can't be directly fed into the Bluetooth module. Firstly, the module uses 3.3V logic and is not 5V tolerant. Secondly, the polarity is inverted to what the module is expecting. However, both of these problems can be solved using a simple level shifting inverter as shown in the schematic below.

Simple adapter to connect the UT61E serial cable to a Bluetooth module.

I had already made a carrier board for the Bluetooth module I used. These can now be bought online for cheap, and I wouldn't bother to roll my own anymore. I've omitted any details related to that carrier board. The main point is that the Bluetooth module is still removable so that it can be configured using a USB low level serial adapter.

Bluetooth UT61E interface. Top side.
Bluetooth UT61E interface. Bottom side.
The UT61E RS232 cable connects to the DE9 connector and power can be applied for instance from a 9V battery. I've used this about 10 meters away from the computer and have still read measurements without problems.

As a final note, the Bluetooth module I used didn't support the 7-O-1 framing that the UT61E uses. Luckily this frame is compatible with the more conventional 8-N-1 framing with the parity bit getting decoded as the last data bit. This extra bit can then be handled in software. The software I'm using to record data is a modified version of Steffen Vogel's dmmut61e. You can download my modified version here.


  1. Could you upload your modified software? I put a BLE module inside my UT61e (using the regulated 3V and direct signal from the ic) and have the same framing issue.

    1. Putting the module inside is quite elegant indeed! Do you have some way to disable the module to limit current draw, or is that not an issue?

      I've added a link to my modified version. It is nothing special. It just opens the device using a different configuration. I hope it is useful for you. I changed the output format from Steffen's code as well, so it will unfortunately not work with his graphing software. The changed format includes a time stamp and is in more or less standard CSV format. I think you can just use the original main.cpp if you want to keep the original output format.

      To compile, call "g++ *.cpp -o dmm61e" in the directory where you extract the files.

      To run, just call ./dmm61e (e.g. ./dmm61e /dev/rfcomm0). You also probably want to direct the output to some file to capture the data.

    2. Thanks! Although i already have a solution. I am wondering, are these changes in SerialPort.cpp really necessary? In theory it should make no difference on emulated serial ports (rfcomm), that parity bit gets cut off in main.cpp.

      Current draw is not a issue in my opinion, that's the point of the Bluetooth 4.0 "Low Energy" module. Yes, it decreases the battery life, the meter alone draws only about 2mA and the module (HM-11) adds 8mA, but this should still give me at least 20h on-time from a rechargeable 9V block or 50h with an alkaline block.
      Bluetooth 4.0 (specifically this custom serial caracteristic) is not well supported on Desktop Linux, so i had to write a python script with modified "pygatt" to get the incoming data to stdout. Then there is a nice ut61e python package, which interprets the data and creates .csv files.

      Now i am working on an Android App for this purpose, because a phone is easier to carry around than a notebook ;) I have implemented a "UT61E interpreter" in Java and the receiving+decoding works so far, an usabel UI, some graphs und logging to the SD card is on my TODO list.

    3. Seems I did the modification too long ago and didn't remember the specifics. You're right, the most important change is in main.cpp, where the additional bits get cleared.

      I did some changes to SerialPort.cpp as well, as I recall I was having trouble with the way the port was originally opened. It seems that not only did I change it from 7-O-1 to 8-N-1, but I also set it to non-canonical mode with 14 byte chunks without timeout. This is not ideal though, as the data could easily go out-of-sync. I haven't had any problems though.

      I really like your modification. I think I'll have to do something similar :-). Are you planning on releasing your phone app when it's done?

    4. Did you test it for a longer period of time? Because i had problems that caused my software to crash after a few minutes. Could be because of the IC(ES51922) actually sends out with 19230 baud and the module expects 19200. Now with input checks (length + parity) and throwing away the garbage data packets it works fine.
      Btw: your blog and the idea to just use 8-N-1 was really helpful, i first thought this won't work at all because of the unsupported framing, but with the parity info it's even better :)

      Yes, i plan to release my app when i think it's good. At the moment the whole bluetooth and UI part is still sample code from Google, so i cant't promise anything.

    5. Now almost 2 years later i have finally released my android app ;)
      Look here on Google Play:

      Also i have described the hardware modification and the app on my blog, in case you are still interested: