ts

1. Quozl's Temperature Sensor Project
2. History
3. Prototype Picture
4. Problem: reading limit 100 in Fahrenheit
5. Problem: reading error increases as cable length increases
6. Question: use only two wires for each sensor
7. Feature: Digital Inputs
8. Logging and Graphing with MRTG and Rrdtool
9. Question: a redirect log has too many samples, how to reduce?
10. Comments

Quozl's Temperature Sensor Project

This is a project community page for Quozl's Temperature Sensor, here you can read comments made by others, make comments yourself, or help other people solve their problems.

Create yourself an account on this Wiki first, using UserPreferences, then you can edit this page. You can also subscribe to the page so that changes will be mailed to you. The RecentChanges page has an RSS feed if you know how to use it.

History

It is hard to remember exactly how this kit came about, but basically it was something I wanted, and I couldn't find anything similar for a suitable price.

The project was inspired by a kit published in an Australian electronics magazine some time between 1996 and 1999. This kit was driven by a Zilog microcontroller, and had an LED display and serial port. It was called a Digitemp, probably by Mantis Micro Products. It is unrelated to the Digitemp product by Brian C. Lane.

The Digitemp was very interesting. It supported up to eight sensors on a single bus, so naturally I got myself eight sensors to play with. It displayed Celcius degrees to one decimal place. It also checked the DS1820 CRC and used a CRC itself on transmissions to the host computer.

When I read up further on the DS1820 sensor, I found it could do a bit more resolution, and it could do it faster than the Digitemp drove it.

I'd just got into PIC microcontrollers as a result of some Technical Aid to the Disabled Projects, so I had a play with DS1820 sensors attached to a PIC.

What I wanted was a unit that would be powered from the serial port, would talk straight ASCII, and without any display. My prototype was on a PIC 16F84, but I felt that chip was too large ... I was using only two of the I/O pins. So I asked on the PIClist and a few guys suggested the PIC 12C508 or 12C509.

Then a technical challenge ensued ... porting the code from PIC 16F84 to the simpler and more limited PIC 12C50x chip. With a lot of assistance from the PIClist community I built a porting checklist, to remove all the PIC 16F84 stuff.

The PIC 12C508 was obviously too small for my code, so I went for the PIC 12C509. Bought a couple of -JW suffix parts which have the quartz window allowing them to be erased. Borrowed an ultravoilet eraser from a friend, and set to. (The actual order of these events may have been different, 'cause my TAD projects may have used the -JW parts earlier).

Once I'd built it, the owner of Kitsrus contacted me, or I contacted him, can't exactly remember ... to sell it as a kit. I didn't have a PCB, nor any way to make PCBs, so he built one from a couple of prototypes that I sent up to him. The big discussion points in this process (from memory) were:

• provide Fahrenheit output as an option,

• the method of termination of the sensors,

• the Windows software for logging the output.

That last bit was terrible for me. I don't use Windows, so I had to learn a little bit about it. I obtained an open source compiler (djgpp or Cygwin) and ported my UNIX software across to it. I'm glad that since then others with more experience have built on my work.

Prototype Picture

This picture is of the prototype built before Kitsrus got involved. No chip is present. Unkeyed connectors were used. A serial cable was made to convert DE9F to four pin header plug.

Problem: reading limit 100 in Fahrenheit

Known behaviour. Change to Centigrade/Celcius mode to fix this.

The web page says A larger range and accuracy is obtained from running in Centigrade mode; users are advised to make their conversions within the attached computer.

Celcius is the international standard, and maps directly to degrees Kelvin, used by physicists. The DS1820 sensor itself uses Celcius.

In Celcius,

The actual cause of the behaviour seen is an overflow of the intermediate result during conversion to Fahrenheit. This conversion is done by the microcontroller, and has a range limit near 95 F.

The conversion is a multiplication by nine, then a division by five. The intermediate result is in hundredths of a degree, and is only 16 bits wide. This places the upper bound on the possible readings in Fahrenheit mode.

Problem: reading error increases as cable length increases

Well known problem, usually caused by RF interference or depleted power supply at the sensor at time of measurement. Measure the voltage at millisecond intervals during the time that the sensor is performing a conversion, using a CRO or other sampler. You may find the voltage is going below specification for the sensor. We've certainly seen this behaviour before.

You may also try one or more of these solutions:

1. add a local power supply for the sensor, using a regulated 5V source ... this has been done by passing 12V over the long cable and placing a regulator near the sensor,

2. add a 10uF tantalum capacitor across the power supply pins of the sensor (as per the web page), which should act as a local storage for the energy needed to run the sensor during the conversion,

3. add a 0.1uF ceramic capacitor across the power supply pins, to filter our any other spurious noise,

4. place the microcontroller near the sensors, using a long cable to the computer, thus allowing the onboard capacitor and regulator to provide energy for conversion.

Question: use only two wires for each sensor

Scott Aitken asked if there is any way to use only two pins from the DS1820 to the circuit board?

Yes, the data sheet allows it, but the code on the microcontroller hasn't been written with this in mind. So your choices are:

1. provide 5V to the DS1820 from another source, and therefore use only two wires to the circuit board, or,

2. modify the source code of the program in the microcontroller to obey the data sheet recommendations for parasitic power, and program it into another microcontroller.

It may work now, but it may not be accurate.

Feature: Digital Inputs

The project page mentions a special version that had digital input capability, to report if a switch or other single digital input is at high or low logic level.

One reader asked:

• I'm trying to interface your board with a mercury tilt switch.  I'm
  reading your directions on how to wire in a digital input if you have
  a special board, but not quite following.
  
  I'm going to buy the board from a USA dealer, any
  idea if it's "special"?
  
  Do you happen to have a diagram around on how I could use a digital
  input like the above with your board?
  

It isn't up to Quozl what the dealers do with the chips, as long as they provide the source code in agreement with the license. They don't pay him anything. Since Quozl never gave them the special version, it is unlikely that they would ship it, as it reduces the number of sensor channels available.

You can either build the special code yourself, and program it into a blank 12C509 chip, or you can find another way.

Other ways to interface the switch ...

1. place it in series with the serial data line to the microcontroller, so that when the switch is open no data flows at all,

2. place it in series with one sensor's data line, so that when the switch is open one (of the four) sensors no longer shows any data ... the microcontroller skips it.

Logging and Graphing with MRTG and Rrdtool

I've recently built the temperature sensor and have it connected to a Linux server at home. I wanted to be be able to put up a graph of the temperature on my web server, and since I already use mrtg for graphing things like CPU load, Internet traffic and disk space it seemed sensible to use the same for the temperature sensor.

Firstly, I use Asgeir Nilsen'd Python script to pull the data from the temperature sensor. It saves this to a temporary file. I added the following to my mrtg.cfg file:

 #       Outside Temperature

 Target[outside-temp]: `/share/scripts/tsl-temp.sh`
 Options[outside-temp]: gauge
 Title[outside-temp]: <h2>Outside Temperature</h2>
 MaxBytes[outside-temp]: 100
 YLegend[outside-temp]: Degrees
 ShortLegend[outside-temp]: Deg
 LegendO[outside-temp]: &nbsp;Outside Temp:
 LogFormat: rrdtool

The script /share/scripts/tsl-temp.sh is very simple - it just reads the temperature from the temporary file created by the Python script:

 #!/bin/sh

 ds1=`cat /var/tmp/tsl.1`

 echo $ds1
 echo 0
 echo 0
 echo "Outside temperature"

That's all that's needed for mrtg to poll and log the temperature in an rrd file.

Finally, I run this script every 15 minutes to produce/update the graph:

 $RRDTOOL graph $OUTDIR/outside-temp.png \
       -a PNG \
       -h 160 -w 600 \
       -s -1week \
       -u 40 \
       -l 10 \
       -Y \
        -E \
       -v "Deg C" \
       -t "Outside Temperature" \
        -x HOUR:6:DAY:1:DAY:1:86400:'%b %d' \
 DEF:ts1=/var/db/mrtg/outside-temp.rrd:ds0:AVERAGE \
 VDEF:now=ts1,LAST \
 VDEF:min=ts1,MINIMUM \
 VDEF:max=ts1,MAXIMUM \
 LINE1:ts1#001FFF:"Temperature" \
 COMMENT:"Now\:" \
 GPRINT:now:"%3.1lf" \
 COMMENT:"Minimum\:" \
 GPRINT:min:"%3.1lf" \
 COMMENT:"Maximum\:" \
 GPRINT:max:"%3.1lf" > /dev/null

You can see what this looks like here

If you have any questions send me an email

Question: a redirect log has too many samples, how to reduce?

I use the TSL data logging program to capture data and Excel for analysis. I use the dos redirect command to send the data to a file and parse it into Excel as a csv file. My question is, how can I modify the raw data sample rate.

The sample rate used by the microcontroller is one sample every second, in rotation over the available sensors. So if you have four sensors, the sample rate is 0.25Hz.

You can modify the sample rate in several ways. Understand what happens and you'll see how the sample rate can be changed.

1. the microcontroller reads one sensor, and sends the sensor number and the reading to the computer over the serial port, then waits enough time to make about one second,

2. the TSL program reads the sensor number and the reading, stores it in memory, and updates the display,

3. every 30 seconds the TSL program saves the displayed values to the recording file,

Your use of redirect may be the source of your problem. The display output of TSL was never intended for further processing. TSL writes to an output file instead.

TSL.EXE was designed to accept a sample rate parameter, in seconds, as the second command line option. By default this is 30 seconds. The first command line option is the serial port. The default is COM1 on DOS. The last command line option is the file name to record into. It defaults to %4.4d%3.3d.log which means to use four digits for the year and three digits for the day in the year.

So run the program like this:

        TSL COM1 60 BATCH.CSV

and you will record samples in the output file BATCH.CSV on every whole minute.

But your use of redirect captures the display output, which is at the sample rate of the microcontroller. The TSL program buffers the previous three samples from the three other sensors. It reprints the display line using these buffered samples. So you have mistakenly thought that there is one sample per second. The results would be distorted.

To put it another way, if the microcontroller generated samples and we tag them A through to Z, then your redirect file contains the samples like this:

A,
A B,
A B C,
A B C D,
E B C D,
E F C D,
E F G D,
E F G H,
I F G H,
I J G H,
I J K H,
I J K L, and so on.

Your options are:

1. avoid using redirect, instead use the log file created by TSL, and choose a sample rate using TSL's second command line option,

2. adjust the source code for TSL and recompile it, (the source code is on my web site, you will need to obtain a compiler),

3. write an additional program or macro to process the large log file you have, and live with the inaccuracy caused by oversampling,

4. tool up and then rewrite the microcontroller program so that it takes a sample every minute. (the source code is on my web site, you will need to obtain a blank chip and a chip programming unit),

Comments

(edit the page and put stuff here)