back to index

Thermal Sensors

An improvised temperature sensing/logging system

Also see: Environmental sensor - enhanced version with humidity sensors.

An improvised temperature sensing/logging system


Last 24 hours Last 7 days All measurements
Caveat: The sensors have to be shielded from factors that could influence their

temperature, except the ambient temperature itself; this is critical for the outside sensor. It's important to shield the sensor from direct sunlight. I omitted it, as I wanted to see what will happen, and as I haven't bothered, and the results are clearly visible on data from some days. Notice the sharp rise of temperature during some mornings, with high noise (as there were clouds and objects throwing shadows on the sensor), and a sudden drop in temperature and smoothing out of the curve at exactly 12AM - measurements at these intervals are skewed by the sensor being exposed to direct sunlight.


Two SMT160-30 thermal sensors, connected to the joystick port. One soldered to a long (8-10m?) three-wire cable and put outside the window, the other one soldered to a shorter three-wire cable and hanging in the approximate center of the room.

The sensors are calibrated, with a fully documented datasheet. They are powered from +5V, and produce a TTL-compatible signal with frequency about 4 kHz and duty cycle (1:0 ratio) dependent on the temperature of the sensor. Their power consumption is negligible. They aren't exactly cheap ($3-4, or about CZK 115 here), but you don't have to bother with calibration or the elimination of analog noise and pesky ADCs.

The power pins (2) of the sensors are connected to the +5V power available on the joystick connector. Their outputs (pin 1) are connected to the joystick button inputs, digital inputs whose values are directly available as bits of port (typically) 0x200. The F1 is a 100mA Polyswitch fuse, protecting the joystick port against short circuits. The C1 is a 100nF capacitor, connected directly to the power/GND pins of the sensor, counteracting possible voltage ripples inducted into the long cable. The internal sensor has no such measure implemented, as its cable is much shorter.

The pins 10 and 14 are the two remaining digital inputs, currently unused. They can be easily used for two more sensors. There are four more analog inputs (pins 3, 6, 11, and 13), which can be used for variable-resistivity sensors, but that's a topic for another document.

The mapping of joystick port bits (0=LSB) and connector pins is:

0   3  AX (analog)
1   6  AY (analog)
2  11  BX (analog)
3  13  BY (analog)
4   2  A1 (button, digital)
5   7  A2 (button, digital)
6  10  B1 (button, digital)
7  14  B2 (button, digital)

Caveat: In many different versions, the sensor is connected to the parallel port. The

data lines are often used as the power source. While their current rating would be satisfying, the voltage can be lower than the sensor's allowed lower limit, as happened to me when testing another sensor circuit. Then the sensor produces measurements that are way too low (eg, 15°C instead of 25°C).


For reading the sensors, a custom program was written. It samples the port for a lot of cycles in a loop (the more the cycles the better the accuracy but the longer the measurement, so depends on the speed of your machine), senses the port value, counts the ratio of 1's and 0's, calculates the duty cycle, calculates the temperature for both the sensors, and outputs it. It is called from crontab every 5 minutes. Because of the need for direct port access it needs root privileges.

It is possible to measure the sensor output duty cycle by less CPU-intensive ways, eg. catching the precise moments of rising and falling edges of the sensor outputs, but that would require an IRQ and would need a kernel module. A hightech, lowest-CPU way would be to use a microcontroller, eg. PIC12F629, to measure the values and communicate with the PC over eg. a serial port, which would allow just about any kind of autonomous and semi-autonomous registration you can imagine, but that is outside of the scope of this project.

For displaying the data as graphs, gnuplot from the plotutils package was employed, called by a custom shell script.

Caveat: Getting the joystick port working on some soundcards in Linux can be a bitch.

On my Ensoniq 5880 AudioPCI it worked nicely with "standard" kernel module, but refused to get activated with ALSA module. The solution here is to (generate (by alsactl) and) edit the /etc/asound.state file, changing the "Joystick Enable" values to "true". This can save you a night.
Nov 20, 2003: I had good results with ALSA 0.9.0rc6. Attempt to upgrade to 0.9.8 failed - the joystick subsystem decided to ignore me and silently refused to initialize. Reverting to the old version solved the problem immediately.


makegraph - the shell script for making the pretty graphs
therm.c - the source code for the sensor reading software
cron-logtemp - the cron-called script for reading and logging data
therm.log - the logged data

If you have any comments or questions about the topic, please let me know here:
Your name:
Your email:
Leave this empty!
Only spambots enter stuff here.