Sous Vide and Thermocouples

A while back, I built a DIY sous vide cooker. It’s gone through a major revision since the original. My current one uses power outlets to connect the teacup heaters, rather than hard wiring them in. I’m in the midst of making another big change to it, which is to use an ESP8266 with custom programming, rather than an off the shelf PID controller, and also to use a different temperature probe.

Which brings me to this post. The original instructions used a k-type thermocouple, probably because it’s cheap and easily available. After some research, I think the accuracy range of the k-type thermocouple is unacceptable for sous vide.

The accuracy of a k-type thermocouple, for the temperature range we care about for sous vide, is ±2.2C. Now, the FDA recommends that food never be stored between 5C and 54.5C for more than four hours. That means if you’re cooking beef at a medium-rare temperature of 56.5C, a k-type thermocouple could be below the safe temperature.

It’s also worth mentioning that the k-type thermocouple’s temperature range is far beyond what we need for sous vide. We want something that will be accurate inside 50C and 100C. The tighter range of the t-type thermocouple is still more than we need, and its accuracy (for what we care about) would be ±1.0C.

We may be able to do better still. Resistance Temperature Detectors (RTD) probes are more accurate still. A probe with Class-A accuracy would be ±0.35 or less. It may also be cheaper, as you avoid the need for an amplifier chip, which you need with a thermocouple to convert its microvolts into something readable on normal electronics. RTDs just need something that can read resistance.

Which would be no problem on an Arduino with two ADC channels. You need the second one to read a resistor with a known value and then do some math to compare. Unfortunately, the ESP8266 (needed for some of the wireless features I want) only has one ADC channel. There’s some ways to fix that, but they involve some extra hardware. Might end up being a wash in terms of price and complexity. Still, I think it’s worth it for the extra accuracy.

Edit: doing it with a single ADC is possible with a voltage divider, which just needs a resistor with a known value. Cheap and easy.

How did Linux become a second-class citizen on Arduino?

Using Linux with Arduino reminds me a lot of using Oracle with Perl; it works, but there’s a lot of things that aren’t up to the same level as other combinations. For Oracle and Perl, it’s somewhat understandable, as Perl comes from a FOSS background and Oracle, well…doesn’t.

That’s not true of Arduino however. Mac OSX seems to have better support than Linux, and Windows is almost seamless. I find it all very odd, because when it comes to most FOSS stuff, Linux support is easy, Mac OSX tends to work with minimal effort, and you’re a bit surprised when things work right on Windows. Somehow, Arduino has gone the other way round.

Just some examples I’ve come across:

  • I haven’t tried the latest versions of the IDE, but burning the Arduino bootloader to a fresh ATmega from the Arduino IDE doesn’t work. The reason is that the Makefile needs to know which of the USB ports to use, but it doesn’t even use the port that you selected in the GUI. The port that it does use is hardcoded to a Windows naming convention.
  • The Arudino IDE serial port monitor always crashes on me.
  • I’ve been playing with UnoJoy lately, which turns an Arduino Uno into a USB joystick. Which is great, but look at the instructions and download pages. There’s all the help you need on Windows and Mac OSX. There’s a wiki page for help on Linux, and it starts with “I really don’t know much about Linux at all . . . “
  • A while back, I was playing with HCDlib for controlling small toy quadcopters. When I tried to compile it, there was a compiler error about a missing arduino.h file. When I raised an issue with the author, he said my environment was screwed up. Once I dug a little deeper, the problem was that the proper name of the file is Arduino.h. Assbackwards compatibility on Windows means that you can get away with case-insensitivity like that, but not on Linux.

I suspect that these issues came about because Arduino was successfully marketed to people outside of the normal FOSS community. This meant a lot of people were developing and testing things on Windows and often Mac, but rarely Linux.