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 http://blog.avrnoob.com/2014/03/uni-t-ut61e-rs232-serial-interface.html. 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.

Sous-vide cooking controller

I've been experimenting with sous-vide cooking recently. The main appeal for me is to be able to buy meats when they are on sale and put them in the freezer. Then later thaw and cook them in the sous-vide machine with very little effort. To keep things simple, I wanted to use a rice cooker as the heater and water container. With this setup I only needed to build a simple temperature controlling device to get started.

The board, which I repurposed as the temperature controller. It was originally built for driving an electrodynamic shaker.

Bottom side of the controller board.

For the temperature controller, I happened to have an old board laying around, which I originally built to drive an electrodynamic shaker. The board has an ATmega48 microcontroller, with a number of GPIO pins brought out to headers as well as an open drain output capable of driving inductive loads, such as a relay coil, so it was well suited for the task.

Relay box for controlling the rice cooker.

The relay box with its cover removed. Everything is submerged in hot glue. The relay disconnects both terminals. The clearance between the low-voltage and high voltage is about an inch. I'm very confident that this is completely safe.

The temperature sensor I chose to use was a waterproofed DS18B20 sensor from eBay, which I also had laying around. While for the power switching I built a relay box out of an old in-socket power switch. The relay coil connections are brought out to the controller board, while all the mains voltage connections are contained within the relay box case.

I implemented a simple bang-bang temperature controller which turned the heating on whenever the temperature was below 60 Celsius and turned off the heating whenever the temperature was above 60.5 Celsius. In the first test I had a small computer fan submerged to act as a circulation pump. I was expecting it to work underwater for a long time, but it turns out that 5V is still high enough to cause the wires to corrode and break in a matter of hours through an electrochemical reaction. However, I noticed that there was no real need for water circulation, as in the end the surface water temperature matched the bottom temperature within 1 Celsius. Circulation might speed up the cooking time a bit, but I'll investigate that at some later point in time.

The first roast beef I made with this setup turned out very good. I used the original vacuum plastic bag which the meat came in and this worked well. Setting everything up, however, was a convoluted operation. Changing the cooking temperature for instance required reprogramming the microcontroller.

Wiring in the connections for the LCD and encoder. More wiring is on the other side of the protoboard.

Controller board in place. Showing also the back side piece of the case.

Testing the LCD interface. The display shows 1 temperature sensor found on the 1-wire bus, which is reading 492 counts = 30.75 Celsius.

To make the device useful, I added an HD44780 LCD, for which there was just barely enough GPIO. I had to move the temperature sensor to share a pin with the ISP interface to make room for the LCD. For the user input I had planned on using an encoder with an integrated push button. This would however require 3 additional GPIO lines, which I did not have available. As a compromise, I had to share GPIO between the LCD and encoder. The sharing is done simply by having the switches in the encoder pull down the LCD data lines through 1k resistors. These resistors are small enough to pull low against the internal pull-up resistors on the GPIO when the port acts as an input, but large enough to not interfere with port operations when the port is acting as an output. As writing to the LCD only takes a very short time, this port sharing doesn't cause any real concurrency issues (that is, just an occasional encoder pulse goes undetected every now and then).

The controller keeping water in the rice cooker at 60 Celsius. "T:60.0" indicates the set temperature. "=60.3" indicates the measured temperature. "o" indicates that the relay is off (it shows "i" when relay is on). Manual override is not enabled, as there is no "m" next to the "o". "85%" indicates the currently observed duty cycle. The 8 last characters form a graph of the duty cycle over the last 8 hours.

The user interface I came up with is very simple. The display shows the set temperature, the current temperature (or a possible error condition), duty cycle of the control as well as the relay state. The observed duty cycle is also displayed on an ~8 hour graph. Turning the encoder changes the set temperature in an intuitive way. Pushing the encoder button for the first time activates manual override mode with relay set to off. Pushing it a second time continues in manual override mode with the relay set to on. A third push exits manual override mode and the relay is again under temperature control. There is also an indication on the LCD when manual override mode is chosen.

Now I'll just have to wait for bargains on meats to fill the freezer. Yum.

One last picture.

Checking the calibration of a frequency counter

In the previous post I went through how I repaired a Racal-Dana 1992 frequency counter I had obtained from the dumpster. After the repair the instrument seemed to function correctly, but I wasn't sure if it still were anywhere close to calibrated. Given that I don't have an atomic frequency standard, and I'm not planning on buying one, the options I was left with were to either borrow an atomic standard or to use some other frequency source to check the calibration on the 1992.

I've been interested about synchronizing clocks using GPS signals and have been wondering if the cheap GPS receivers (Fastrax uPatch100) I have are any good in this respect. Their data sheet lists their PPS (1 pulse per second) output accuracy as 50 ns RMS, which is 50 ppb (that is 50*10^-9 relative error). The aging rate of the oscillator in the 1992 is specified at 3 ppb/day. The accuracy of the PPS output would thus seem to be adequate for determining whether calibration is required.

Fastrax uPatch100 GPS receiver with a DC/DC converter to power it from a lithium battery. The coax carries the PPS signal.

The GPS receiver had to be placed outside to get a signal. The coax goes back inside and connects to the frequency counter.

An interesting feature of the 1992 is what is called (R-X)/Z mode. In this mode the unit subtracts some programmable constant X from the measurement and divides the result by Z. Programming X=1 and Z=1 allows to easily check the deviation from 1 PPS. At first this deviation was reading around 3 microseconds, which was due to the lowish accuracy of operating only from the crystal oscillator in the GPS receiver. Once the receiver got a position fix, the deviation dropped down to between 10 and 100 nanoseconds, which is about what could be expected with the 50 ns error specification of the GPS receiver. However, I'm somewhat confident that the error in the PPS output of the GPS receiver should have zero mean value. As I'm almost exclusively reading positive values, it suggests the 1992 is running a tiny bit too fast.

Racal-Dana 1992 showing the period error. Here the PPS output is measured as being 23 nanoseconds longer than a second (or what the 1992 considers to be a second).

In conclusion, the unit seems to have an accuracy of around 100 ppb. That is very good considering the aging specification of the oscillator as it would still be within spec even if it were calibrated just a couple of months ago. Though this in fact hints that the oscillator may be much more stable than what is specified. I might investigate this more later.