Some notes on the readings you get from USB TEMPer2 temperature sensors

September 21, 2022

A while back, I tweeted something that has a story attached:

A person with a single machine room temperature sensor knows the room temperature (where the sensor is). A person with three temperature sensors lined up next to each knows only uncertainty (and has a wish for a carefully calibrated and trustworthy thermometer).

If you set out to get some inexpensive USB temperature sensors to supplement a more well developed and expensive temperature sensor system, it's quite likely that you'll wind up with the PCsensor TEMPer2 or something in that line, and then you might be curious about how accurate their readings are. Having now collected readings from three of them over a while, my summary is that you shouldn't expect industrial or lab grade results from them, although the results are probably useful if handled cautiously. So here are some observations, which are almost certainly specific to our version of the TEMPer2 (which Linux reports as having USB vendor and product IDs of 1a86:e025).

(It's clear that 'TEMPer2' is a brand name that's been used on a variety of different pieces of electronics over the years, even if the external appearance and general functionality has stayed the same.)

Since this is long and observational, I'll put the summary up front. If you're going to use TEMPer2s, you need to test the behavior of each of your specific units, you probably want to trust the probe temperature more than the internal temperature, and you want to use a USB extender cable (partly to get the probe far enough away from your computer, since the TEMPer2 only comes with a relatively short wire for the probe).

The TEMPer2 has two temperature sensors, one inside the USB stick and another that uses a temperature probe on a wire. As far as the internal USB or 'inner' temperature goes, you definitely want to read Halestrom's article on indoor air sensor products and then get yourself a USB extender cable so that you aren't plugging the USB stick directly into your computer. Although both temperature sensors have anomalies, you're probably better off with the probe's temperature if you have to use one (although you want to test this). When I initially had all of our TEMPer2s plugged directly into computers (two servers and one desktop), their USB temperature was extremely stable and unchanging; using a USB extender cable gave them more realistic variation.

At this point, we have three TEMPer2 units in use, all with the probe fitted, the USB stick on an extender cable, and the probe sensor next to the USB stick (so they should read the same). One is in a machine room right next to our regular machine room sensor for that room, one is in a machine room relatively near our existing sensor, and the third is attached to an office desktop. Both machine room TEMPer2s show changes in both USB and probe temperature readings that track temperature changes from our regular sensor, and they appear to be similar in magnitude (although we haven't had any big temperature swings). None of the TEMPer2 readings agree with the regular sensor readings, not even the one where the three sensors are next to each other; however, they aren't that far off (it looks like typically around 1 C below our regular sensor reading). One machine room TEMPer2 has the probe reading higher than the USB one (by about 0.5 C I think), while the other one has them generally the same or very close to it. The desktop TEMPer2 has the probe reading below by about 1 C.

(When I've looked at my desktop thermometer, which is near the desktop TEMPer2 USB and probe, it's been quite close to the USB's measured temperature.)

All three TEMPer2 units sometimes show what I consider to be reading anomalies where the USB temperature, the probe temperature, or both will latch on to some value for a long period of time, with absolutely no variation in reading for hours on end. One machine room unit does this quite frequently for the USB temperature (and sometimes for the probe), the desktop unit does it quite frequently for the probe temperature (and sometimes for the USB), and the other machine room unit doesn't seem to do it very much or for very long.

(The probe temperature on the desktop unit commonly latches at 21.06 C and its USB temperature at 21.68 C, while the machine room TEMPer2 latches the USB temperature at 19.56 C and sometimes latches the probe temperature at 19.81 C. The other machine room TEMPer2 sometimes latches the probe temperature at 23.56 C. As you can see, there's a lot of variation here. These TEMPer2 units apparently report their temperatures over USB in hundredths of a degree C, so the two digits are authentically what they're reporting.)

Unless something changes when the desktop TEMPer2 unit is moved into a machine room and connected to a different computer, it seems like it's a less trustworthy unit than the other two. It definitely seems to have a different behavior where the USB sensor varies its readings more often than the probe and may be more trustworthy (my office is probably not the same temperature to the hundredth of a degree for hours on end). Given this unit's behavior and the varied behavior of all three of them, we definitely need to test any future units under controlled circumstances to see how they behave, even if that's just putting them next to another unit with more known behavior to compare.

In the past, people have measured various PCsensor branded hardware (including 'TEMPer2' units) and found that its accuracy varied with the true temperature. If precise accuracy is important to you, you probably don't want to use a TEMPer2 in the first place but if you have to, I think you should calibrate it over the temperature range you care about. Given our results so far, the only use we'd make of TEMPer2 units is to get a vague idea of the temperature of some place and be able to tell if it's gone up a lot.

PS: The TEMPer2 units can report small temperature variations from reading the reading; for example, I've seen probe readings of 19.62 C, 19.68 C, and 19.75 C, and USB readings of 22.87 C and 22.93 C. So in general the 'latching' isn't as simple as the internal precision being way less than .01 C (although I can't imagine it's that precise, so presumably there's some rounding and noise happening).

(Although the raw data is in our metrics system, there's no convenient way to find out how many different sensor readings we've seen. It does appear that the smallest variation between any two readings is 0.06 C, and the largest one is 0.75 C (observed for the internal sensor; the largest variation for a probe is 0.56 C). This comes from readings that are generally taken 30 seconds apart.)

Comments on this page:

Good to hear you have compared measurements. It looks like you might have something that is useful and valid for your purposes :)

latch on to some value for a long period of time, with absolutely no variation in reading for hours on end.

Internally the temperature sensor ADC won't be measuring temperature in base 10 units. If you graph the temperatures without line interpolation they will look like they are taking stairsteps of some fixed size.

Or in other words: don't confuse the apparent precision (number of decimal places) with the resolution of the readings (how many bits of depth). Those magic numbers are the only ones the device can possibly read, nothing in between will be possible.

If the OEM doesn't spec the resolution then you can crack one of the units open and look for the (internal at least) temperature sensing chip, then look up its datasheet online.

A (hopefully) unlikely alternative explanation: the devices might be failing to read their sensors and instead retransmit old readings. Depending on how they wrote their I2C/1-wire/etc code this might be very easy to do; and high-electrical noise environments (or just bad design) can make communications unreliable. Also watch out for devices misbehaving after exactly 49.7 days or 25 days of uptime (millisecond counter overflow).

I've been thinking about your application in server rooms & closets. You might want to consider strapping your temperature sensors to the air intake vents of your servers/switches with cable ties. This has a few advantages:

1. The forced air means you don't really see the effects of self-heating inside the USB sticks (assuming the server fans run permanently).

2. You don't necessarily then need to bother with the external probes.

3. It's possibly the most "valid" temperature measurement for your purposes. You don't really care what's coming out of the servers or even the "average" temperature in a closet, only what's going into them.

Maybe. Maybe not.

By cks at 2022-09-22 23:23:44:

I should have been clearer about the latching: we've seen this behavior in situations where both the other sensor and the machine room's normal temperature are showing temperature changes, with the machine room sensor reporting a swing of, say, 0.5 C. Since the units will report variations down to 0.06 C, that should be more than enough temperature shift to be reported to some degree. These units clearly have a substantial amount of firmware code and they're very consumer units, so I can certainly believe in bugs or 'retransmit the last reading if I feel I should' issues. Although I have unplugged the TEMPer2 connected to my desktop to completely reset it, plugged it back in, and had the probe sensor pick right back up reporting 21.06 C, so who knows (that probe will show temperature variation if provoked, so it's not completely stuck).

(Our units haven't been active quite long enough to hit 25 days, at least if I assume that they're completely reset any time they lose USB power due to being unplugged or having the server rebooted. But it's something I'll have to remember to look out for.)

These are clearly consumer-focused units so the specifications are at best informal and I'm not sure they're trustworthy. Although now that I look at the vendor web page (also), it does indeed report 'Resolution rate: 0.06C', matching the observed behavior (and claims a precision of +/- 2C, by which I think they mean accuracy).


If these units end up requiring lots of man hours to reset: might be worth checking the DS18B20 suggestion I made in a later comment on your previous article.

This will require lots of man hours upfront, but the userspace implementation will be very simple (a few lines of shell script is enough) and it will let you actually fix bugs rather than be forced to tolerate them for years.

Written on 21 September 2022.
« Why the ZFS ZIL's "in-place" direct writes of large data are safe
The TLS client's view of Certificate Transparency and CT Logs »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Sep 21 23:40:17 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.