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.

Racal-Dana 1992 repair

Racal-Dana 1992 in my lab on top of an old signal generator.

I recently got an old Racal-Dana 1992 frequency counter from the dumpster. The unit looked very good and did power up and in fact did measure frequencies. However, the user interface was completely non-responsive. It was stuck in Freq A mode. After googling around, I found out that a typical failure mode of these instruments is that the push buttons themselves die. The rubber springs have hardened and deformed after all these years (the quality control stickers and IC date codes seem to indicate early 1989). I looked through Mouser, but these switches or anything that would directly accept the switch hat are no longer made.

Front panel removed.

Front panel PCB with the broken switches. The hats are held on the switches just by friction.

Inspired by a post in the EEVblog forums about replacing the buttons, I ordered a bunch of 6x6 mm tact switches to mount diagonally with two of the legs cut off. The original poster used tact switches with a long shaft, which were then shaped to accept the hat. I wanted to go a different route, as I considered shaping the shafts too tedious. I decided to have the hats mounted on the original plastic pieces of the old switches and then have these pieces attached to the tact switches. For this I needed to drill a 3.5mm hole in the bottom of each hat holder piece, to fit the shaft of the tact switch, and then fix the piece to the tact switch shaft with a drop of super glue.

6x6 mm tact switch with two of the legs cut off. This fits perfectly in place of the original switches.

Halfway there. I forgot to take pictures of the desoldering process.

There are 33 switches, so the process of desoldering the old ones and replacing them with the new ones took one whole evening. After this I could finally test the instrument, and find that this repair had indeed fixed the problem. A quick look into the operation of the instrument shows that repairing this unit seems to be well worth the time and effort I've put into it. The drilling of the hat holders and gluing them on the tact switches then took one more evening.

All switches replaced and board cleaned from flux residue.

Testing the instrument with the newly replaced switches. Everything's good!

Front panel PCB back in the front panel casing. Switches seem to line up. Next up is gluing the hat holders on the tact switches.

Hats in place and glue curing.

Front panel in place and everything working correctly. Win.

Overall, I'm very happy with how everything worked out. It is a beautiful instrument with very interesting features. Next up is to check the calibration somehow. Then perhaps I can finally think of getting rid of my old oscilloscope, as I wouldn't need it even for its frequency counter any longer.