Other Parts Discussed in Post: LM35

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

In the first installment of this series , I discussed design goals, component selection constraints, and TI’s resources that helped my design process. As every good designer knows, it’s always prudent to challenge assumptions and to validate claims with empirical data. In this second installment, I show how I tested the LM35 sensor’s performance, built it into a coffee probe, and wrote code to read the temperature.

Testing the sensor

Before writing the code, I wanted to be sure that the sensor output matched what the LM35 data sheet claims (always check assumptions!). A quick setup on a breadboard (see Figure 1) proved the data sheet to be true.

 

Figure 1: The breadboard, including TI’s LM35

The temperature of the LM35 sensor body measured ~24.1ºC with a calibrated FLIR thermal camera (with an assumed emissivity of ε0.90 for the plastic TO92 case), as shown in Figure 2.

 

Figure 2: The temperature of the LM35 sensor body

The output of the device was 245mV, right on target, as shown in Figure 3.

 

Figure 3: Power output of the LM35 sensor

Based on this result, I don't need a correction factor in software. The LM35’s power dissipation is tiny, so for now I’ll skip measuring the self-heating of the sensor.

Building a probe

The next step was to turn the LM35 into an actual temperature probe. I can’t just dip it in the coffee, as the liquid would short out the wires. And personally, I prefer my coffee free of solder, epoxy and flux. But maybe that’s just me.

I’m putting the probe in near-boiling water, so I want something rated for the job. I scared up a Pyrex test tube made of borosilicate glass, shown in Figure 4. These test tubes have a low coefficient of thermal expansion, making them resistant to thermal shock damage, and being made of glass makes them sanitary and good for use in something I’ll be drinking.

 

Figure 4: Temperature probe using a Pyrex test tube

I can’t just drop the LM35 into the tube, either. There needs to be a good thermal bond between the glass and the sensor to transfer the heat from the coffee to the chip. I used some Arctic Silver thermal epoxy to connect the LM35 to the end of the tube. I’m not too worried about the thermal resistance of the overall assembly, as coffee temperatures don’t change very rapidly and the probe should be able to stabilize quickly enough.

You’ll notice that there’s an LED in there as well. It does two things: first, it lets me know that the power is on and that I connected the probe properly. Second, it looks cool.

Sending temperature data

For this project, I used Kinoma Create, which is a development and prototyping tool that you can program with JavaScript. The code below is an excerpt from the git repository, and it represents the heart of things: a message handler that processes the analog value results from a periodic ADC read triggered by a timer. The system uses a PubNub JavaScript library to get the messages transmitted, so I don’t need to worry about that part.


 

I took the temperature reading and made some basic adjustments based on how the ADC returned the value. The LM35 sensor outputs 10mV/ºC, so 22ºC would be 220mV on the output pin. This goes into my analog pin, which when read gives a floating-point value from 0 to 1, representing 0V up to whatever the I/O voltage is set to: 3.3V or 5V.

Note that I am running the sensor at 3.3V, but the data sheet lists 4V as the low end. I tested 3.3V vs. 5V, and the LM35 still worked exactly the same. I chose to push the envelope in this case, as 920mV (or 92ºC) is a greater percentage of 3.3V than it is of 5V. By doing this, I get a smidge more resolution out of the ADC. I’d probably reconsider this choice in a production product.

I now do some conversion to get the temperature, scaling the 0 to 1 range back into millivolts, multiplying by 100 to get degrees Celsius, and subtracting one degree for self-heating. (As I mentioned above, I didn’t take the time to experimentally determine that one degree offset. My correction factor is probably on the high side, but I wanted it sketched out in the code to remind me to take care of it later.)

 

Astute readers may notice that I used only a small range of the ADC’s potential for expected temperatures, and this results in lower-resolution data. Ideally, I’d pre-scale things using a DC amplifier with a gain of 2 or 4 so that the temperature signal uses more of the available input range. A precision instrumentation operational amplifier like TI’s OPA27 would be perfect here, with its low noise and low offset voltage.

After adjusting my temperature data, I send some messages to the application to let other listening objects know that the temperature value (and analog pin value) has changed. These objects use the messages to trigger updates to the user interface, displaying the values on the Kinoma Create’s LCD screen.

Finally, I take the temperature and send it as a message to PubNub as a JSON object. From there, it will flow onto the wot.io message bus, and I can link my data services to it. The bus is fully configurable, and I can dynamically change the message routing to suit. This is an ideal system for iterative development of the analytics applications I need here.

Stay tuned for the third and final installment of this series to finish creating the perfect cup.

Additional resources

Anonymous