TEMPerHUM USB hygrometers

11.10.2015 14:19

Last month at a project meeting in Ghent, Hans Cappelle told me about PCsensor TEMPerHUM hygrometers and thermometers. At around 23 EUR per piece, these are relatively cheap, Chinese made USB-connected sensors. I was looking for something like that to put into a few machines I have running at different places. Knowing the room temperature can be handy. For instance, once I noticed that the CPU and motherboard temperature on one server was rising even though fan RPMs did not change. Was it because the change in the room temperature or was it a sign that heat sinks were getting clogged with dust? Having a reading from a sensor outside of the server's box would help in knowing the reason without having to go and have a look.

TEMPerHUM v1.2 USB hygrometers

When I took them out of the box, I was a bit surprised at their weight. I assumed that the shiny surface was metallized plastic, but in fact it looks like the case is actually made of metal. Each came with a short USB extension cable so you can put it a bit away from the warm computer they are plugged in.

My devices identify as RDing TEMPERHUM1V1.2 on the USB bus (vendor ID 0x0c45, product ID 0x7402). They register two interfaces with the host: a HID keyboard and a HID mouse. The blue circle with TXT in it is actually a button. When you press it, the sensor starts simulating someone manually typing in periodic sensor readouts. As far as I understand, you can set some settings in this mode by playing with Caps lock and Num lock LEDs. I haven't looked into it further though since I don't currently care about this feature, but it is good to know that sensors can be used with only a basic USB HID keyboard driver and a text editor.

Text editor with TEMPerHUM readings typed in.

On Linux, udev creates two hidraw devices for the sensor. To get a sensor readout from those without having to press the button, Frode Austvik wrote a nice little utility. For v1.2 sensors, you need this patched version.

The utility is written in C and is easy to compile for more exotic devices. The only real dependency is HID API. HID API is only packaged for Debian Jessie, but the 0.8.0 source package compiles on Wheezy as well without any modifications. OpenWRT has a package for HID API. The sensor however does not work on my TP-Link router because it uses USB v1.10 and the router's USB ports apparently only support USB v2.x (see OpenWRT ticket #15194).

By default, udev creates hidraw device files that only root can read. To enable any member of the temperhum group to read the sensor, I use the following in /etc/udev/rules.d/20-temperhum.rules:

Update: Previously, I made the hidraw device world-writable. That might be a security problem, although probably a very unlikely one.

SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0c45", ATTRS{idProduct}=="7402", MODE="0660", GROUP="temperhum"

Finally, what about the accuracy? I left one of the sensors (connected via an extension cable) to sit overnight in a room next to an Arduino with a DS18B20 and the old wireless weather monitor I use at home. The two spikes you see on the graphs are from when I opened the windows in the morning.

Temperature versus time for three thermometers.

The DS18B20 has a declared accuracy of ±0.5°C, while the Si7021 sensor that TEMPerHUM is supposedly using should be accurate to ±0.4°C. However, TEMPerHUM is showing between 1.5°C and 2.0°C higher reading than DS18B20. This might be because the USB fob is heating itself a little bit, or it might be some numerical error (or they might be using off-spec chips). Other people have reported that similar sensors tend to overestimate the temperature.

Humidity versus time for two hygrometers.

For relative humidity measurements I don't have a good reference. The difference between my weather monitor and TEMPerHUM is around 10% according to this graph. Si7021 should be accurate to within 3% according to its datasheet. My weather monitor is certainly worse than that. So I can't really say anything about the humidity measurement except that it isn't obviously wrong.

In conclusion, except for the incompatibility with some Atheros SoCs I mentioned above, these sensors seem to be exactly what they say they are. Not super accurate but probably good enough for some basic monitoring of the environment.

Posted by Tomaž | Categories: Life | Comments »

Pinning for gigasamples

04.10.2015 19:27

I recently stumbled upon this video back from 2013 by Shahriar Shahramian on the Signal Path blog. He demonstrated an Agilent DSA-X series oscilloscope that is capable of 160 Gsamples/s and 62 GHz of analog bandwidth. Or, as Shahriar puts it, an instrument that doubles the value of the building it is located in. It is always somewhat humbling to see how incredibly far the state-of-the-art is removed from the capabilities accessible to a typical hobbyist. Having this kind of an instrument on a bench in fact seems like science-fiction even for the telecommunications lab at our Institute that has no shortage of devices that are valued in multiples of my yearly pay.

I was intrigued by the noise level measurements that are shown in the video. At around 7:00 Shahriar says that the displayed noise level at 62.3 GHz of analog bandwidth is around 1 mV RMS. He comments that this a very low noise level for this bandwidth. Since I am mostly dealing with radio receivers these days, I'm more used to thinking in terms of noise figures than millivolts RMS.

The input of the scope has an impedance of 50Ω. Converting RMS voltage into noise power gives:

N = \frac{1\mathrm{mV}^2}{50 \Omega} = 2.0\cdot 10^{-8} \mathrm{W}
N_{dBm} = -47 \mathrm{dBm}

On the other hand, thermal noise power at this bandwidth is:

N_0 = kTB = 2.5\cdot 10^{-10} \mathrm{W}
N_{0dBm} = -66 \mathrm{dBm}

So, according to these values, noise power shown by the oscilloscope is 19 dB above thermal noise, which means that oscilloscope's front-end amplifiers have a noise figure of around 19 dB.

This kind of calculation tends to be quite inaccurate though, because it depends on knowing accurately the noise bandwidth and gain. In another part of the video Shahriar shows the noise power spectral density. You can see there that power falls sharply beyond 62 GHz, so I guess the bandwidth is more or less correct here. Another thing that may affect it is that the RMS value measured includes the DC component and hence includes any DC offset the oscilloscope might have. Finally, noise should have been measured using a 50Ω terminator, not open terminals. However Shahriar says that his measurements are comparable to the instrument's specifications so it seems this hasn't affected the measured values too much.

Of course, I have no good reference to which to compare this value of 19 dB. For example, cheap 2.4 GHz integrated receivers I see each day have a noise figure of around 10 dB. A good low-noise amplifier will have it in low single digits. A Rohde & Schwarz FSV signal analyzer that I sometimes have on my desk is somewhere around 12 dB if I remember correctly. These are all at least one order of magnitude removed from having 60 GHz of bandwidth.

I guess having a low noise figure is not exactly a priority for an oscilloscope anyway. It's not that important when measuring large signals and I'm sure nobody is connecting it to an antenna and using it as a radio receiver. Even calling Shahriar's demonstration the world's fastest software-defined radio is somewhat silly. While the capabilities of this instrument are impressive, there is no way 160 Gsamples/s could be continuously streamed to a CPU and processed in real-time, which is the basic requirement for an SDR.

Posted by Tomaž | Categories: Analog | Comments »