Other Parts Discussed in Post: LM35

Aaron Kondziela is an IoT entrepreneur and designer who is guest blogging to discuss a recent project.

As engineers, I’m sure you all agree that there are two very important things in our personal and professional lives: data and coffee (not necessarily in that order).

For coffee, I prefer my water flowing through a full-city roast from the Sumatra region, or perhaps a well-picked Kona. For data, I prefer my messages flowing through composable topologies that connect cloud-based data services. So for this project I used the wot.io data service exchange to get up and running quickly. I thought, why not mash up TI’s resources with some data services and see what happens?

But first, coffee. Lately, I’ve been playing with a pour over, and getting tasty results. But I’m always in search of the perfect cup. Along with bean quality and water purity, the brewing temperature is critical for making great coffee. Each bean and roast has its own character, and I wanted to empirically optimize the results by automatically collecting and analyzing temperature data. From the Specialty Coffee Association of America (SCAA) standard, I found this recommendation:

“Cupping water temperature shall be 200°F ± 2°F (92.2°C–94.4°C) when poured on grounds.”

 

That’s a pretty tight range! And beyond that, I will want to check ambient conditions, the temperature of the brewing apparatus, and the cool-down curve during the brew. These are all good reasons to automate the logging and connect data services to perform the analytics—a perfect application for Internet of Things (IoT) technologies.

 

Part selection

I need a temperature sensor, and I’d prefer one that doesn’t require spinning a board, so I need one in a leaded package rather than a quad flat no-leads (QFN) or wafer-level chip-scale package (WLCSP). On the TI site is a sensor products landing page, and from there I found my way to the analog temperature sensor product selector tool. The choice of an analog part over a digital part came down to package constraints and software concerns. For example, the only digital part in a TO92 package is the LMT01. It has great specs, but the digital interface is a pulse train that needs a time-gated counter on the controller to read it. I’ll be using fully-asynchronous communications with the data services wot.io provides, and so was worried that I’d block incoming messages if I were in a count loop. Or worse, I’d have to add an extra routine to check if I’d get an interrupt, the count would go screwy and give me bad data, and I might run into issues with non-reentrant code. Pulse trains are a fine choice in many cases, but I had an analog pin free and went with it.  And hey, audiophiles say analog sounds better, so wouldn’t analog-measured coffee taste better? Am I pushing the metaphor a little too far, perhaps?

So how do you find the right part?

 

Figure 1: TI analog output product selector tool

Back to the product selector tool, as shown in Figure 1.  From the checkboxes at the top, I chose a mil-spec component for maximum accuracy and a TO92 case for easy prototyping. The tool filtered the choices down to three parts—all tagged “HighRel” for high reliability—excellent! The coffee must flow! Out of these three parts, only one option gave me the best accuracy range and an output in Celsius: the LM35. I did a quick cross-check with Octopart and found that the usual distributors have stock and the price is right. That’s my part.

The LM35 analog temperature sensor

The SCAA specifies the use of a resistive temperature device. A common negative temperature coefficient thermistor from a reputable manufacturer has an absolute accuracy of about ±12ºC, and a nonlinear temperature/resistance relationship. While you could argue that this would be sufficient for measuring coffee, anyone obsessed enough to chase the perfect cup wants better, and the LM35 delivers.

As a military-grade part, the LM35 has a number of attractive features for my project. First, it’s low power and low self-heating. Typical thermistors that read a nominal 10KΩ at a 25ºC drop to 700Ω at coffee temperatures will have 7mW dissipation at a 5V supply! That’s not power-friendly, and it hurts accuracy. With the LM35 there’s very low self-heating, drawing only 60μA and dissipating just 0.3mW. That’s a healthy order of magnitude better, and much nicer to my battery.

The LM35 relies on the well-studied physics of a PN junction to sense temperature, and wraps it in some precision buffering that’s balanced and trimmed at the wafer level during fabrication. A PN junction thermal sensor is very linear. (If you’re curious, look up the Shockley diode equation.) A thermistor is not at all linear; it’s more of a log response. Platinum resistance temperature detectors (RTDs) are linear (and the basis of the ITS90 temperature standard), but they are challenging to read and require some serious instrumentation engineering to get good precision.

The linearity and precision of the PN junction eliminates the need for empirical testing and calculation of correction coefficients. Additionally, I don’t need to worry about how the nonlinear response would affect quantization errors in the analog-to-digital converter (ADC), which would end up changing with temperature. There’s also an advantage with a part providing output directly in Celsius vs. Kelvin, or worse, an arbitrary “physics-y” reading, which is common elsewhere. There is no need to subtract a significantly-sized constant from the measurement to find the reading I want to work with or run it through a mathematical model. This lets me focus on creating the hardware, and along with the composable data services, get into production quickly.

Stay tuned for my next post in this series to find out how I tested the sensor to ensure the perfect cup.

Additional resources

Anonymous