Table of Contents
Welcome to DS025: Weather monitoring with Dallas 1-Wire

Table of Contents

Help file version: adapted from 21 May 04, 19 Nov 2009

(Note to self: Do much more bringing of material from DS025manual.txt into this hlp file.)

This file is rather Out Of Date.... especially in respect of what you put in the second ini file, DS025ini2.txt

But fear not!!! Additional notes are available to you: Just go to....

http://sheepdogsoftware.co.uk/ssds025.htm, and you can access (and store on your

computer, if you wish) a text file with more recent, more currently-correct notes!

What is in the help file you are reading is, for the most part, right... but the help file

is incomplete in some ways. Sorry. Would you rather I polished the help file,

or spent time adding features to the monitoring system??

Go here if you don't have a 1-Wire MicroLan

Go here if you want to start program for first time

Go here once you are able to start the program running

Some menu items

Details of what you can change with DS025ini.txt, the main ini file

Details of what you can change with DS025ini2.txt, the optional, secondary ini file

How to read the file which records readings, DS025DtLg.txt

How to read the file which, while the program runs, records errors.

The coding of the date/time stamps

Supported 1-Wire devices

Wiring your MicroLan

Some finer points: Interesting, I hope. Not essential to getting it working

Glossary, trademarks, etc: Have a look at this, just to be sure we use terms the same way.

Contact the author: See bottom of this page.

This help file is not finished! I hope you find it useful; I apologize for gaps in it. Email me with suggestions if you are feeling kind!

There are many pages of information about 1-Wire issues on my internet site at

  sheepdogsoftware.co.uk

If you go to .......

  sheepdogsoftware.co.uk/sc3swd.htm

......you will go straight to matters 1-Wire. The site also has information about how to build sensors for weather and other phenomena, and information on programming 1-Wire chips with Delphi. Of course, Dallas / Maxim's site, www.ibutton.com also has extensive help for you online.

The version of the program current at the end of Jan 2004 was set running, unattended, in a machine that cost $40, excluding the monitor. It ran for about ten weeks without incident, completing 7 million cycles, with only twelve (non-fatal, obviously) error reports during that time. It was still running okay when I interrupted it to upgrade the software. A "cycle" now has 60 steps. (At that time it had 30.) One "step" consists of making one reading. Some are sensors are read frequently (e.g. wind direction). Others, especially those where the 1-Wire chip can accumulate readings, e.g. the rainfall counter, or those monitoring slowly changing things (barometric pressure) are not assigned to as many of the 60 steps in a cycle.

Tom Boyd

To contact me, go to...

sheepdogsoftware.co.uk/ctact.htm

... for an eddress and an online "send a comment" form. If sheepdogsoftware.co.uk gives you "not found", have a look with Google for Boyd Sheepdog Software. (Sheepdog Software is a registered trademark.)


Wiring the MicroLan

All you must have to have a MicroLan is two wires: One as ground, and one which both powers the chips on the line and carries data between the chips and the adapter connecting the MicroLan to the controlling pc.

Many (all?) of the chips in the 1-Wire / MicroLan family will operate with no other source of power. How can this work? The 1-Wire chips have internal switches which can connect the two wires of the LAN together. Because of the way power is fed into the data/power line, the voltage in it will drop significantly if one of those shorting switches is closed. No damaging current surges occur. Most of the chips, most of the time, are monitoring the voltage in the data/power line. When one pulls it low, it does it intermittently, and the pattern of "offs" seen by the other chips is the code that tells them things. While most (all?) 1-Wire chips can operate with no other power source, sometimes it is better to provide power separately. In addtion, sometimes the electronics "feeding" the 1-Wire chips need separate power.

Don't be daunted by the next paragraph. You can get started with DS025.exe with just two wires with a temperature sensor at the end of them. What is addressed in the next paragraph isn't rocket science, but you need to take a little care if you are new to such things, that's all.

Anyway... as I said: Two wires sufficient.. but of course, people always embellish. Be careful when attaching modules to your MicroLan. You may find that they make unsafe assumptions. While two wires are enough, Cat5 cable is frequently used. It has 8 wires. Sometimes it is connected to modules with telephone type plugs (4 contacts.. RJ-11?) or ethernet RJ-45s (8) The extra contacts are often used to distribute power around the MicroLan... but which conductors carry which voltages, and whether there is a conductor through a module from one connector o the other is not at all standardised. Then you also find at least one case (The Dallas / AAG wind direction/speed sensor) where you are expected to use one of the RJ-11 (hope I have that number right... a "phone-type") sockets to hold a small plug which shorts two connections in order to select an option of the sensor's pcb.

Cat5 cable seems to be the preferred option for MicroLans because it seems to be realtively easy to obtain, have suitable electrical characteristics, is available in "outdoor" grades, and the extra conductors are useful and not overly expensive.

Avoid star toplogies. As far as possible, make your network like a ladder, with the two wires the "rails" of the ladder, and your 1-Wire chips and modules connected (right way 'round: it does matter) across it, as the "rungs". Keep the "rung" wires short.

A star topology arises when you have several "ladders" joining at their "feet". This MAY work, but avoid it as far as you can. While the program this help file was written for does not (yet! Nor likely soon) support them, devices called hubs are available which allow stars to work well by connecting only one of the "ladders" at a time. The hub goes in where the ladder "feet" join. And you can have hubs on dependent brances of a hub, if you really crave confusion.

The RJ (or other) plugs do make it easy to re-configure your MicroLan, swap things in and out, etc. However, they do add expense, and, especially with any exposed to the weather or dampness, they can give rise to poor connections, with predictably unpredictable results. I prefer to use soldered joints on any outdoor connections, or screw terminals.

In a similar vein, and with more hassle and, fewer fellow advocates, I prefer to have as little as possible at the distal ends of wires. An example: A windspeed sensor consists of a reed switch which is opened and closed by a rotating magnet attached to the shaft of a little "windmill'. Typically, that reed switch is mounted on a circuit board with a DS2423 which counts the closings, and makes that count available via the MircoLan any time the controlling PC asks for it. In this design, if you are having problems with your system, the problems may be on top of your roof, up on the pcb inside the anemometer. What I prefer to do is to run wires from the reed switch in the anemometer to a DS2423 mounted where a) it is out of the weather, and b) where I can get at it more easily. The price of this approach is more wires from the rooftop down to the chips, but only a few of my sensors are up on the roof, anyway: Wind speed and direction. They require 6 wires between them. Other sensors (temperature, rainfall, humidity) can reside closer to the ground in most cases, so accessing their pcbs isn't such a problem. My barometer module lives inside.

There are many other considerations explored on the internet.

Help file table of contents


Supported 1-Wire devices

First, the bad news: This software cannot "see" anything downstream of a 1-Wire hub. The presence of the hub in the LAN will not interfere with DS025. You will even be able to "see" anything that is on the currently selected branch downstream of the hub. However, the program cannot change the hub's switches for you as it runs.

So much for the bad news.

The good news is that the following are supported. Each entry starts with the chip's Dallas family code, i.e. the right hand two hex characters in the chip's id as returned by Dallas's iButtonViewer program. If you find other chips within the families mentioned, and know they work well with DS025.exe, please let me know? Also let me know if there are chips not on the list you would like to read.

$10, DS1820, DS18S20, temperature sensors

$1D, DS2423, dual counter. Used for windspeed, rainfall, lightning monitoring.

$26, DS2438. Dallas calls this a battery monitor chip. Weather enthusiasts have harnessed it for various uses. DS025.exe can read temperatures and analog voltages from it. For temperatures, no further electonics are necessary. With extra electronics, the DS2438 can report barometric pressure, humidity, and things as yet undeveloped!

$28, DS18B20, temperature sensor

Next: A list of devices known to work with DS025.exe, and their core chip. Apologies to developers if I have mis-identified your work... just let me know!

Bray/ Atkins barometer, DS2438

Jennings lightning detector, DS2423

Buffalo Run (Jennings?) Humidity, DS2438

Dallas and AAG windspeed, wind direction sensors, DS2423 and DS2450 respectively.

(DS025.exe cannot read the first version of the Dallas wind direction sensor. I think AAG does a replacement pcb which will allow you to convert on for DS2450 operation.

Dallas, AAG and other rainfall sensors, DS2423

Help file table of contents


FP The three windows
The three windows

When the program is run, you should see a "Welcome, please wait while..." message almost immediately.

Once you have been running the program for a while at this point there will be quite a delay... as much as two minutes on an old machine with a slow disk... while the program works it's way back through old data, preparing a display of that data for you.

The program eventualy creates three windows, which are put on the screen, overlapped.

The main window has a graph showing the sensor readings. Click here for details of the graphs

A second window has a memo component in it, and error messages from the system are displayed here. They are also recorded in C:\DS025ErLg.txt) The errors are usually not fatal; the program can continue to run. In general, they report cases of failed reads.

The final window shows the most recent readings from each sensor, plus the "most prevalent recently" wind direction. The readings are shown in the same color as is used for the sensor's line on the graph.

The windows' sizes and positions may not perfectly suit you. They were chosen to give optimal results on an old laptop I have monitoring sensors. Sadly, it's screen offers only low resolution. In the menu, there is an item called "Restack". It has two options: Scheme A and Scheme B. Scheme A is what the program starts in. Scheme B is, but default, suited to a better pc with better graphics. Both schemes can be customised via the secondary ini file. If you resize or move a window "by hand", invoking Restack will discard your adjustments. There is (currently) no way to save your preferences except by editing the secondary ini file. Unfortunately, unless I underestimate the inter$t this program is likely to provoke, I suspect there's not much reason to spend too many more hours on it. The first draft of this help file has took over three hours to bash together. Merely adding Restack, tidying some loose ends, and revising this help file took large chunks of two days.

A large part of the final window is usually not visible. There is information on it which can help with various things, though, including the setting up of a wind direction sensor. Click here for more on this.

"Finer Points" menu

Help file table of contents


FPFP Wind dir setup
Setting up the wind direction sensor and it's software.

THE APPLICATION DOES NOT, AT 11/09, HAVE WIND DIRECTION LOGGING CAPABILITIES.

(I'vbe tried, and tried... but still can't get that feature working reliably! The new (about 1/09- ish) wind direction sensor from AAG may be "the answer"... when I get time to try it!)

The first wind direction sensor produced by Dallas used eight 1-Wire chips. There were fundamental problems with that design, and I am not going to provide for it in DS025.exe. I believe you can convert it to their second design just by replacing the pcb.

At 11/09, AAG had a third design in the marketplace. What follows is all about the old, second, design... the one using 1-Wire between the ground and the sensor, and a DS2450 ADC chip.

The program can cope with any sensor which reduces the wind direction to 4 analog values which cluster around limited possible values. In the case of the Dallas / AAG sensor, there are three clusters of values.

If you are using the Dallas / AGG sensor, you should not need much of what follows. You will need to work out what offset is needed to "translate" the data from your sensor to traditional directions. The offset allows you to mount the sensor rotated however much seems best, and then to compensate for that rotation though one of the letters in line "u" of your ini file. See "What you can change in the ini file" for the details.

If you want the program enabled to read a sensor of a different design, study the following:

On the window with the numerical reports of current sensor readings, on the bit ordinarily under the graph window, you should see 4 numbers coming from the wind direction sensor. For a design providing three analogue levels, they will each either be "low" (around zero) or "medium" or "high". (Similar schemes can be created if your sensor produces more... up to 9.. levels)  In my case, "high" tends to be about 10,000. The program has two critical constants which set the boundaries between "low" and "medium", and between "medium" and "high". I've got them at 300 and 5500. Using the information on the window with the numerical reports of current sensor readings will allow you to see if these are okay for your sensor. If not, let me know what numbers you need, and I can provide a special edition of the program for you. The boundary numbers should be well away from a "high low" and a "medium high" and a "high medium" and a "low high".

If that much is working, look and see what values you're getting for "Wind direction in 4". These will be four digit strings, using only 0,1 and 2. If you have a non-standard sensor, if you can give me a list of the "Direction in 4" values as the weather vane is turned clockwise around the compass, starting at North, I can make provision for your sensor within DS025.exe

"Finer Points" menu

Help file table of contents


How to read the file which records the data collected by the program
How to read the file which records the data collected by the program- DS025DtLg.txt

In general:

The lines are recoded in chronological order.

Each line starts with a two letter code to say what is recorded on that line.

Then there are 8 characters to give a date/time stamp specific to the minute.

After that....

In lines beginning t0, t1, t2, t3, t4: Next a sign (+ or -), then 4 digits for a Celsius temperature in hundreths of degrees, e.g. +1234 indicates a time when the temperature was 12.34 degrees Celsius.

In lines beginning  ws: Windspeed: Count of rotations of anemometer since counter was last reset, NOT since last record in DS025DtLg.txt.

rf: Rainfall: Count of tips of tipper since counter was last reset, NOT since last record in DS025DtLg.txt.

lt: Lightning Counts of tipper since counter was last reset, NOT since last record in DS025DtLg.txt

bp: Barometric pressure. Raw value from sensor, not millibars or inches of mercury.

hm: Humidity: Raw value from sensor, not percent.

ss: System started: Indicates the program was started at the time shown

cm: These are comment lines. Some are machine generated, others are the result of input from a human.

In the lines beginning "wd" there are 17 pairs of characters, each a hex number. They report the counts over the just-concluded sample period for wind from each of the 16 directions, plus a count of the "invalid" readings. The directions, I believe, are in the program's internal terms. If the lookup table is right, they will be in sequence around the compass, but the first reading will not necessarily be for wind from the north. When the program is run, an entry is made in the data log to say what direction offset is in effect, and with this, which datum reports wind from the north can be determined.

Help file table of contents


FPFP Graphs
The Graphs

The faint vertical lines mark midnights. "Now" is at the right hand edge of the screen.

The green line from upper left to lower right marks the portion of the display drawn from data in C:\DS025DtLg.txt. The green line gradually disappears to the left as the program runs.

The different phenomena monitored by the program are plotted in different colors. What color goes with what phenomenon is usually pretty obvious from the pattern of the line, but the window giving current readings in text form uses the same colors as the graph, so confusion can be resolved by refernece to that.

A word about the windspeed and rainfall reports: Each produces some short vertical lines rising from the bottom edge of the plotting area. These are not working at the moment! Each also produces a line. When that line is flat, there is no wind or rainfall. The steeper that lines becomes, the more wind or rainfall there is at the time in question. When either line reaches the top edge of the plotting area, it wraps around and re-emerges at the bottom edge of the plotting area.

"Finer Points" menu

Help file table of contents


Some menu items

There is a "Restack" item in the menu. If you click it, you are offered "Scheme A" and "Scheme B".

If you click either, unless they are already in the relevant positions, the program's three windows will be rearranged, resized, and/or re-ordered.

You can change the apprearance of the windows (position and size) under either scheme by making entries in the optional secondary ini file. (Click here for information on secondary ini file.)

Help file table of contents


Go here if you want to start program for first time
To start the program for the first time...

If you are reading this, you have probably successfully acquired the software. If you are looking at this without unzipping or installing the setup file, do proceed with the setup without undue concern: I don't "do things" to your system when installing things. You get to choose what folder things go in. I leave your system folder alone. I don't mess with your registry, or inflict dlls. If the package came to you in an InstallShield wrapper, InstallShield may have put a dll in the folder, and/or an entry in the registry. I believe these are connected with setting up "Uninstall" for you. you can have the zip or UnstallShield package anywhere you like. Early in the unzip process you are given the chance to specify where you want the program and its support files.

To run the program this help file was written for, DS025.exe, first catch and set up your MicroLan. See "If you don't have a MicroLan" if necessary. (If you don't seem to have a program called DS025.exe, then your computer has "known extensions suppressed." See Glossary.)

When you run DS025.exe, it will write two files to your disk. The first is DS025DtLg.txt, which contains the data that the program has harvested from your sensors. The second is DS025ErLg.txt which is a log of error messages. Both files (at the moment) are written to the root folder of your C: drive. I know. Messy. Sorry. Both will be created by the program if necessary. If either is already present, the program will append new data to the end of the pre-exisiting file.

You only need five things to start recording data:

The Dallas program OneWireViewer or iButtonViewer (both free).

A 1-Wire (aka MircoLan) adapter to connect the MicroLan to your computer. E.g. a DS9097.

A Dallas 1-Wire temperature sensing chip.

My program (DS025.exe).

An initialization file. It is called DS025ini.txt and must be in the same folder as DS025.exe.

The chip can be a  DS1820, DS18s20, DS18B20, or a DS2438 (Dallas family codes $10, $26 and $28). If you have several, chosing one you will be willing to "tie up" in the machine running my software will save you minor chores later.

On DS025ini.txt, you will certainly have to do one edit, and probably several. You can use Notepad, the little editor that comes with Windows. Don't use a big wordprocessor, unless you know how to make to save the result as plain Ascii.

Each line of the ini file begins with one letter and a space. After the space on line k , put an e, and then the id of your temperature sensing chip, with the family code at the right hand end. Following that (same line) put three z's. That is to say, make line it something like....

k eFE0001235B20C26zzz

... but change the "FE0001235B20C26" to the id of yYOUR temperature sensing chip..

If it isn't like this already, make line l (that's "ell", not "one")...

l e0000000000000026zzz

This will cause the program to start up in demo mode. The demo mode will plot and record one channel of temperature.

Next look at lines h and i:

Line h: The third character should be a digit. The digit will determine which COM port the computer goes to in attempting to communicate with the MicroLan. In the skeleton DS025ini.txt supplied with DS025.exe, I have illustrated a convention which I've used in DS025ini.txt. On some lines, the program only looks at a limited part of the line. When this is the case, I will sometimes put extra stuff on the line, just for the humans who look at the file. In such cases, I usually start the "for humans" part of the line with an exclamation mark ("!"), thus, line h might be....

h 5 !port which adapter is on, usual 1 or 2 for COM1 or COM2

Line i: The third character will determine what sort of adapter the program will assume is being used. If that character is.....

1: Program assumes a suffix-less-DS9097, or a DS9097-E

5: Program assumes DS9097-U, or DS9097-U9

The adapter from iButtonLink.. a good "USB" adapter... uses a virtual serial port to connect, so use a 5 on line i. A "real" USB adapter needs 6 on line i..... I think! (Write and complain if you find otherwise. Please mention the exact brand and model of your adapter if you write.)

Speaking of the adapter from iButtonLink: Beware: It gives you a 5v supply on one of the "unused" (by 1-Wire) pins of the connector. Useful if you know. Potentially problematic, if you don't!

I haven't worked with other sorts of adapters, but would be happy to try to provide for them if there is a demand.

Save the file. Run DS025.exe

During initial tests, if you are as impatient as I am, you'll find waiting to see if it worked frustrating, but remember: the program is meant for long term monitoring of the weather. If it is "falling over", you should get explicit error messages. Be a little patient... once it is running, I think you'll like it.

Help file table of contents


Go here when you are able to start the program running
Read this when you are able to start the program running...

Once you've overcome the challenges of getting the program running in demo mode, you will probably want to go further.

To do that, send me the id of a temperature sensing chip (DS1820, DS18s20, DS18B20, or DS2438. The Dallas family codes are $10, $26 and $28)). You will need to make that chip available for channel t0 (you do it with line k of the ini file) whenever you are using DS025 to monitor the sensors on your Microlan.

I will send you a line of "gibberish", a registration key string, which you will need to put in your ini file. That, combined with the temperature sensing chip, will "turn on" your software!

As I write this, the program and registration key are free. I reserve the right to begin charging for the program without making changes to this help file. Use of the program in demo mode is likely to remain free. Any charges are most likely to be announced on the web page where this program is made available.

Help file table of contents


How to read the file which records errors while the program runs
How to read the data in the file the program uses to record run time errors

The 1-Wire system can work extremely well. Messages do not always survive their journey, though. The protocol has advanced checksum protection which is not yet fully utilised by the program I'm sorry to say. However, even in its present state, the program will detect some non-fatal errors. How many errors you get will depend on many things. I had a simple weather monitor which ran in early 2004 for 7million cycles with only 12 error reprots.

The errors are recorded in C:\DS025ErLg.txt. If there is a file of that name when the program is started, new error reports are appended to the end of the existing file. If the file is not present, it is created. I will try to make the file's location user definable in due course.

The file is simple Ascii, readable by Notepad until it becomes too large, and by word processors thereafter. If you edit the file, you should re-save it as plain Ascii. One of the reasons I like Textpad (www.textpad.com) is that it will open huge files. You can read more about why I like Textpad in this entry on the internet at my recommended software page.

The program does not log all errors. Most of the errors which give rise to a message on the screen with an "Okay" button to click are nt recorded in the machine readable error log file.

If you are getting too many errors, the first thing to do is to look at your MicroLan using the excellent iButtonViewer which comes with the 1-Wire run time environment. It is an excellent tool for testing how well the MicroLan is running.

Once things are running as well as you can make them run, re-start DS025. Errors that arise will be recorded in the log file. If you will quote the messages accurately when you send reports, it will help me help you. I do NOT need the date/time stamp which will be at the right hand end of each error message.

Help file table of contents


If you don't have a MicroLan

The program this help file supports (DS025.exe) requires a little hardware and software in addition to a basic Windows PC.

You'll need at least an pc-to-Microlan adapter. I like the USB adapter from www.ibuttonlink.com. If you use it, you need to be aware of the fact that it puts 5v on an "unused" pin. Useful! But you need to know it is going to do it. Also, be advised that it will, to your PC, appear to be connected via a serial port, even though you have it plugged into a USB socket. It creates a virtual serial port when you plug it in.

Alternatively, a DS9097-U is a good choice. Supplied by Dallas/Maxim: www.ibutton.com. Plugs into a serial port.

"True" USB adapters are also available. Adapters run through the parallel port used to be available, but are today deprecated.

Once you have the adapter, you attach two wires to it, and along those wires, in parallel, 1-Wire chips. ("In parallel" means "like a ladder" The ladder rails are the wires, the chips are the rungs. The chips must be attached the right way 'round.) You can, (with geater or lesser degrees of success) implement a star topology... but the more you avoid that, the better.

Last time I bought them, an adapter cost about $40 and a DS18B20 to read temperature about $5. (Ask Dallas nicely, and you might get one or two 1820s free as samples. You'll have to pay for an adapter, though!)

Then you'll need some software. Go to the Dallas website (www.ibutton.com), and find the TMEX support and drivers package. I've installed it on a number of machines without incident. It does put some .dlls in your Windows\System folder, but doesn't add things to Program|Startup, nor to what is reported as running when you do Ctrl/Alt/Delete.

Once you have done the above, in addition to the essential .dlls, you'll have the OneWireViewer from Dallas, a nice modest support tool for troubleshooting your 1-Wire installation. Once you've "seen" your sensor chip(s) using the OneWireViewer, little else is needed to run DS025, the application that this help file is for. While you have OneWireViewer runnning, make a note of the IDs of your chips. You'll need them to put into DS025's ini file. See "Go here to start program for the first time" for more details.

Before the Java driven, free, OneWireViewer, Dallas distributed a simpler alternative called iButtonViewer. I liked it... but it doesn't give access to some 1-Wire chips, e.g. the DS2408 (not used by DS025). OneWireViewer imposes the need for a Java RTE upon you, but that (the RTE) is probably worth having. You'd need it for the excellent OpenOffice, for instance. The RTE will install along with your 1-Wire stuff, if you need it.

Help file table of contents


Details of what you can change in DS025ini.txt, the primary ini file
Details of what you can change with DS025ini.txt, the primary ini file

The main program (DS025.exe) will not run unless there is an initialization file in the same folder as the .exe file. The ini file must be named DS025ini.txt.

The first 26 lines of the ini file begin with a letter and a space. The letters are in alphabetical order. You cannont, by the way "rem out" a line.

In the examples that follow, a "line" may have been wrapped, and be showing on one or more lines of the window you are reading it in. Let the "letter/space" at the beginning of the ini file "lines" be your guide.

The ini file consists only of simple Ascii text. You can edit the file file with Notepad, which is supplied with Windows. I prefer to use Textpad. There's a free demo version available from www.textpad.com. You can read about why I like Textpad in this entry on the internet at www.arunet.co.uk/tkboyd/prgmr1.htm, my page for programmers. Don't try to use a wordprocessor to change what's in the ini file unless you know how to make the wordprocessor save the result as plain Ascii text.

The first line of the ini file will look something like...

a aa DS025ini.txt file

... although the "aa" may have changed. (It indicates the format of the ini file.)

Line b can be used however the user wishes, provided it starts with a d and a space, and contains only Ascii characters, and no more than 253 of them.

Lines c and d are reserved for enhancements to DS025. While they are at present empty (apart from their letters), they none-the-less must be present.

Line e will either be just an "e" and a space, or contain "gibberish". The gibberish is called the registration key string. The program will run in a limited demo mode (Click here for how to make it do that). If you email me, sending the Dallas ID of one of your temperature sensing chips, (1820, 18B20, 18S20, 2438, or others with family codes $10, $26 or $28), I will send you a registration key string. It will allow you to use the program for things beyond the simple demo use.... as long as the chip you mentioned is connected to your MicroLan. Both to discover the Dallas ID of your chip, and for basic (but often necessary) troubleshooting, I strongly recommend that you have Dallas's iButtonViewer installed on your system. It comes with the drivers.

Line f will either be just an "f" and a space, or it will hold 4 characters of "gibberish", followed by the Dallas serial number of the temperature sensor you have put on the first channel, channel "zero".

Line g is reserved for enhancements to DS025. While it is at present empty, it none-the-less must be present. Line g currently may hold a warning about h and i, but DS025 doesn't look at it.

Line h: The third character should be a digit. The digit will determine which COM port the computer goes to in attempting to communicate with the MicroLan. On some lines, the program only looks at a limited part of the line. When this is the case, I will sometimes put extra stuff on the line, just for the humans who look at the file. In such cases, I usually start the "for humans" part of the line with an exclamation mark ("!"), thus, line h might be....

h 5 !port which adapter is on, usual 1 or 2 for COM1 or COM2

Line i: The third character will determine what sort of adapter the program will assume is being used. If that character is.....

1: Program assumes a suffix-less-DS9097, or a DS9097-E

5: Program assumes DS9097-U, or DS9097-U9

I haven't worked with other sorts of adapters, but would be happy to try to provide for them if there is a demand, and you can loan me one for deveolpment work.

Line j: Reserved. Currently not processd by the program, but used for advice to the user regarding the format of lines k through u.

Lines k-u: General points:

The third character of each is an "e" or a "d", for Enabled, or Disabled. Making the third character a "D" turns off the monitoring of that parameter. Turning off, say, half of the parameters will not always have much effect on how many times the other parameters are measured by the program, but turning parameters off can  make a difference. It is as well not to worry too much about trying to alter the cycle time. When using the program in demo mode, you can have these as d's or e's... the program won't care... except that the ones on line k and l should be e's. (You can use upper or lower case e's or d's. Everything in the program is (meant to be) case insensitive.)

Then, each line either has 14 zeros followed by 26, or the digits and letters of a device's Dallas ID code. he letters can be in upper or lower case. The family ID code (in hex, as is the rest of the number, goes at the right hand end. This is consisent with the way the iButtonViewer reprots the chip IDs.

Each line then has 3 more characters, sometimes referred to as the "parameters" for the way the program interacts with that chip. In most cases, the parameters are ignored, in which case, I've usually entered them as "zzz". Line p affords an example of the parameter characters being in use, though. Line p is for a DS2423 dual counter chip to be used to monitor rainfall. If the inputs to the chip relating to rainfall are connected such that rainfall registers int the chip's page 14, the final character of the parameters should be "y". Alternatively, if the inputs to the chip relating to rainfall are connected such that rainfall registers int the chip's page 15, the final character of the parameters should be "z".

Line-specific comments:

Line k: Determines the id of the temperature sensor which will be assigned to "t0", the first temperature channel. The chip for which your registration key was generated should be assigned to channel "t0"

If you do not yet have a registration key, you can invoke the demo mode by making line l ("ell", not "one"...

l e0000000000000026zzz

... and putting a valid Dallas temperature chip id in line in k, e.g....

k e0A0008001DD4ED10zzz

... but! N.B.! You have to change that id (0A0008001DD4ED10) to the id of the chip you are attaching to the computer running the program.

Demo mode will plot and record one channel of temperature. If you have more than one temperature chip available, you'll save yourself minor chores if you make your investigations in demo mode using the chip to be the one that you will give me the ID code from to obtain our registratoin key string. Temperatures can be sensed be sensed with DS1820, DS18s20, DS18B20, or DS2438, or mixtures of these chips. (Dallas family codes $10, $26 and $28)

Lines l, m, n, o: Temperature channels t1, t2, t3, and t4. (See also the role of line l ("ell") for invoking the demo mode, explained above.)

Line p-r: Should all specify DS2423 Dual Counter chips, family code $1D. The parameters will determine which page is read within the chip, as explained above. It is quite possible (and sensible) to have the same chip id in two of the lines. while you can attache almost any input to the counter chips, DS025's screen will describe whatever is sensed via the chip and page specified by line....

p as rainfall

q as windspeed

r as lightning

s as barometric pressure

t as humidity

Lines s and t: These must specify the id for a DS2438, family code $26, and the Vad will be read from it. (See also material in previous section)

Line u: This must specify the id fr a DS2450 ADC, family code $20. It is for reading wind direction. The second letter affects the display. If it is "a", the the reading of the wind direction sensor that produces "0" inside the program is reported and displayed as "North". If the second letter is "M", then when the vane is in the same position as before, the direction will now be reported as "West". The maximum valid letter is "p". Changing by one letter changes the direction report by an eighth turn, e.g. N becomes NNE. This offset letter does not affect the record made in DS025DtLg.txt. The offset letter in effect is recorded in DS025DtLg.txt every time the program is started.

Line u parameters continued: The third letter of the parameter determines which lookup table to use. a/A for 0, etc. (Contact me for help in setting up your ini file for the wind direction sensor. Tell me what sort of wind direction sensor you are using. The Dallas / AAG one using a DS2450? Good! The first Dallas one which used 8 separate chips? Not good... but please tell me what the chips were, and their family code, and remind me that I wanted to edit this part of the hlp file? Thanks. Sorry: I'm not going to make my program capable of reading the early Dallas sensor. Other sensor that "boils the data down" to no more than four analogue values, fet to the MicroLan with a DS2450? Get in touch... I suspect we could get my software enabled for your hardware.)

Lines v to z are reserved for enhancements to DS025. While they are at present empty, they must be present none-the-less.

(Before May 04, lines aa (first line after line z), ab, etc were defined to do a job. They no longer have any effect, though they will do no harm. The job they did is now done by lines in DS025ini2.txt.)

After line z: You can put what you like in the ini file... it will be ignored by DS025. I tend to keep the IDs of various Dallas 1-Wire based devices there... it is sort of a "parts bin". (Of course, the devices listed on the lines after line z would mostly be devices not currently connected to the MicroLan the application is currently monitoring.)

Help file table of contents


Details of what you can change with DS025ini2.txt
Details of what you can change with DS025ini2.txt, the secondary ini file

In addition to DS025ini.txt (see here for details of its functions), there can be a file called DS025ini2.txt. It is optional, you do not have to have it, but if you do, it must... at the moment... be in a folder called C:\DS025. (Sorry... a bit crude, isn't it? I'm trying to get around to fixing that!) (DS025ini.txt, the main ini file, the one without the "2" in its name, goes in the same folder as DS025.exe... which can be where YOU want it!)

DS025ini2.txt, like DS025ini.txt, is a simple text file. The first line must start...

abDS025ini2

After that, you can put almost whatever you like in it. DS025.exe.

Before November 2009, the file had some things which were done a very old fashioned way. For DS025 version 17 Noivember 2009 and later, you don't use those mechanisms. Now you use something that is merely quite old fashioned.... Ini file Sections and Keys. (The "modern" "answer" is The Registry. Why should my little program, un-necessarily, presume to worm its way into the heart of something critical to your whole computer's operation? Registry for apps? Bah!)

What things can you do with DS025ini2.txt? (Which I will just call "ini2" in much of what follows.)

Please read the next few paragraphs Carefully. They set up some definitions that you'll need for the rest of this. I'll tell you when you can safely start skimming.

The colors used for the different channels are set to colors I found pleasing. You may want a different color scheme. Nothing could be easier! Just put something like the following in ini2....

[ChannelColors]

p5c=0000FF

p6c=6600FF

;p7c=666666

... and your rainfall line (assuming your rain detector is on channel 5, which is where it should be) will be a bold blue (blue- rain? Seems appropriate!), your windspeed line (channel 6) will be a muddy blue... blue with a heafty dose of red), and your channel 7 line will be displayed in the default color for channel 7, as if the ...

;p7c=666666

.... weren't there. If there is noting else under the [ChannelColors] section, then all the other channels will be displayed in their default colors. (Give the default colors for the temperature channels... channels 0 through 4... They are set up in a graduated set of reds, moving to yellow.)

Why is all the above true?

Let's start with the "channel 7 will be displayed in its default color. See the semicolon (;) in front of the p7c=666666? That "hides" the rest of the line. Using semi colons is a great way to "cross something off", without completely removing it. Leaving at least one example in each section, even if it is "hidden" (usually called "remmed out", because the semicolon makes the line "a remark"), is a good way to remind yourself of the allowed format for keys in the section. ("p7c=" is the key, "666666" is the value I would be setting the key to, if the semicolon were absent, and [ChannelColors] is "the section".

The system doesn't care about the case of letters in section names or keys, so the following would work, despite looking a little Monty Python....

[chaNNeLcoloRs]

p5C=0000fF

P6c=6600FF

;P7C=666666

End of stuff you need to Read Carefully. (There was an imprecation above.)

"666666", by the way is a gray. The "numbers" after the equals signs should consist of 6 characters. The first pair says how much red to put in the color, the second how much green, and the last how much blue.

Besides the normal digits, you have A, B, C, D, E and F available. (The number is "in hex", is why.)

00 means "none of this color", FF means "as much as possible." 33 is "a little", 66 is "more", 99 is "lots", CC is "nearly max", and as I said, FF is "as much as possible." (If you know hex, you can use intermediate values, but numbers made by combining those elements are "web safe", apart from other things.

So! That's why 0000FF yields a bold blue, and 6600FF gives a blue with some red in it. (It still looks "blue", but it isn't the nice saturated blue that 0000FF gives.)

Magenta is FF00FF, yellow is FFFF00. Black is 000000. Don't use white: The graphs are drawn on a white panel, so white "ink" doesn't make a lot of sense! For greys, make all the characters in the number the same, e.g. 333333 (dark gray), CCCCCC (light gray).

=======================================================

Now we will look at different possible sections in turn. Remember that....

http://sheepdogsoftware.co.uk/ssds025.htm,

... has some things not covered (yet) here.

__________________

Section: [FieldLabels]

;Do not put spaces after tture channel names to create gap

;    before (F) or (C) units designator...

;    Delphi will remove them.

;By the way: The keys have "f-ell" in them, not "f-one". You can

;    use FL, if you are worried that you might slip and use

;    "f-one" if the ell is in lower case, the way I have it

;    in most of the examples below.

p0FL=T0

p1fl=T1

p2fl=T2

p3fl=T3

p4fl=T4

p5fl=RF

p6fl=WS

p7fl=LT

p8fl=BP

p9fl=HM

;;;p10- wind direction- not settable by ini file

p11fl=OnOff1

p12fl=OnOff2

... then the labels in the "Numeric display" window on the screen when DS025 runs will be "T0", "T2", etc. These abbreviations are for...

Temperatures "0", 1,2,3 and 4,

Rainfall

Windspeed

Lightning

Barometric Pressure

and...

Humidity.

You can, of course, subject your sensors to different phenomenon... but if you consult these assignments, you will get a sense of the sort of software behind each channel. Rainfall, windspeed and lightning are monitored by counters, barometric pressure and humidity are monitored by a ADC inside a DS2438. The temperature channels are dedicated to chips dedicated to temperature sensing, like the DS1820, but they can also be attached to a DS2438... but boards carrying DS2438's often produce a little heat of their own, introducing errors into the temperature readings. However, for some purposes, the errors are not significant... usually, the board heating just introduces a small and regular offset from the "true" ambient temperature.

_____________________________

Section: [WindowPosnsAndSizes]

The applicaton uses three windows. They are...

1: The main graph and menu window.

2: The window displaying recent error messages.

3: The window displaying the sensors' most recent readings, as numbers.

The [WindowPosnsAndSizes] section of ini2 allows you to change the size and position of the windows on your screen. (The application doesn't "remember" changes you make by dragging things around, by the way.)

The application remembers two stacking schemes, "A" and "B". (It displays the windows stacked by scheme A when it boots.)

Normally, the three windows overlap, and must do so in the right order to give a good result. Happily, you only need to click on the "Restack" menu-item to get things back to the layout defined within the application, or (if the relevant lines are present) defined within DS025ini2.txt.

Sample from working DS025ini2.txt file. The numbers mean what they did before... aren't you glad you struggled through the above? The information is just "fed" to the application slightly differently.

Here is a sample of a complete set of keys for the [WindowPosnsAndSizes] section

SchemeAW1=0,0,799,370

SchemeAW2=0,342,799,83

SchemeAW3=0,249,799,270

SchemeBW1=100,0,799,370

SchemeBW2=100,342,799,83

SchemeBW3=100,249,799,270

The key name derives from (stacking) SCHEME (alternate "A" or "B") Window number ("1" or "2" or "3")

The four numbers, separated by commas, after the equals sign determine the windows'

   left side (x-coordiante),

   top edge (y-coord, measured from top of screen as zero, bottom a larger number),

   width, and

   height.

All are expressed in pixels, the first two measured from the upper left of your screen, with the numbers rising as you go across the screen for x coordinate, and rising as you go DOWN the screen for the y-coordinate. All of the arguements of these keys must be whole numbers.

There are futher notes on the Restack Schemes (See "Some menu Items") in the page about the application's menus.

The keys in the [] section affect the plotting of the temperature data collected by the program. (It will NOT affect what is recorded in the datafile, by the way.)

You'll have to consult the text file at...

http://sheepdogsoftware.co.uk/DS025manual.txt

... for full details, for now.

In the post 17Nov09 version, Offsets and Scaling is done with keys in the [LineOffsetScale] section like...

p2m=10000

p2a=10

... which, in a nutshell, cause the channel 2 line to be "squashed" or "stretched" (vertically) NOT AT ALL, and shifted up the page 10 pixels. (Use, for example, p2m= 500 to squash the line considerably, or p2m=20000 to strech it a bit. Ten thousand is the value that makes the line not squash or strech.

But... as I said.. that's "it" only in a hasty nutshell.

The following down to "End Edit" What is in green is SCRAPS OF AN OLD VERSION'S DOCUMENTATION.. Stuff in BLUE is comment from 11/09 on the the scraps.

The old stretching and squashing was done with commands like...

[p0OffS] 100, 1.5.

Each of these will be followed by an integer, a comma, and a real number. For example, the following is valid....

[p0OffS] 100, 1.5

The effect of the p0OffS command is to change the appearance of the graph line drawn to show the readings from the first temperature sensor.

The integer determines an offset. If you change the 100 in the example above to, say, 150, you will move the whole line up 50 units. If you position a line so that parts "fall" off the top or the bottom of the graph, don't worry: The "lost" part will appear at the other edge of the screen, i.e. the plots wrap around the graph in the vertical dimension. The offset must be an integer, but it can be positive or negative.

The real number is a "squash factor". If you change the 1.5 to, say, 2.5, you will "squash" the line even more, making it closer to flat when displaying the same series of temperature readings. A "squash factor" of 1 means that the line is not squashed, a "squash factor" below 1 will make a graph swing up and down more. The "squash factor" should always be more than 0. The old system had a different "don't squash or strech" value, 1, vs the 10,000 that is not the "don't" value.

The squash factor and the offset number interact. Lets say you have temperatures that swing back and forth around 10 (degrees Celcius), never going above 20 nor below 0. With an offset of 110 and a squash factor of 0.4, which are, I think, the default values, I think you'll get a reasonable line. Lets say that the graph area runs from "zero" (bottom edge) to about 240 (top edge). For the conditions just described, the plot line would bounce around between about 60 and 80.

If you simply changed the offset, increasing it by 10 to 120, the graph would swing from about 70 to 90.

If you wanted a bigger swing, but centered on the same band of graph space, you would decrease the "squash factor", but you would also have to decrease the offset. To see why, consider the following....

If you were dealing with temperatures between plus and minus 10 degrees, averaging zero, then to move the whole line, as before, you would change the offset. However: if you wanted to increase the amount of swing, you would again decrease the sqash factor, but this time, as you have positive and negative numbers, you don't need to change the offset.

Bottom line: Use a little intelligent trial and error. Remember that the plotting routines will "wrap" plots overspilling the top to come back on at the bottom and vice versa.

Don't do too much offset/squash fine tuning until you have collected at least several days' worth of data.

Start with a high "squash factor"... (100?) enough to squash the line flat.

Gradually, make it bigger,until line swings enough.

Then set the offset. It can be negative if 0 doesn't move the line far enough down the graph area.

"Squash factor" behaviour... numbers changed to reflect 11/09 system

      10000= no scaling

        9000= squash graph a little

         100= squash a lot

      20000=stretch graph a little

      50000= stetch a lot ... I believe the "strech factor" must be less than 65,000

All of the temperature graphs ... and, at 11/09, everything else, I believe, exept the not- working- anyway wind DIRECTION channel will respond properly to [pXoffs] type commands.

Whether or not a parameter will respond to a [pXoffs] command, it will have default values for offset and scaling which may differ from parameter to parameter...

END OF SCRAPS OF OLD!!! AT LAST!!!.

Concerning the multiple temperature channels. An arguement can be made for setting the same offset and squash factor for all of the channels. I think keeping the squash factor the same will always make sense. On the other hand, you may want to use different offsets, to spread the plots across the graphing area, to keep them from being all piled up on top of one another, and thus confusing, if they are in similar environments.

Click here for information on the main ini file.

Help file table of contents


The code used for the date/time stamps

In several places, data is stamped with a string of characters which indicates the date and time of the datum. The time is to the minute.

If the date/time stamp were....

04a30b59

... then the date would be 30 January, 2004, and the time 1:59 am

The code works as follows:

The first two digits give the year. All dates are assumed to be in the 2000's

Then follows a letter: "a" for January, "b" for February, "c" for March, etc.

Then the day of the month, always two digits, so sometimes a leading zero is involved.

Next a letter for the hour of the day. "a" for the hour following midnight, "b" for 1am, etc

Lastly two digits for the minute. Again, a leading zero is used for zero to nine minutes past the hour. The minutes figure is truncated, not rounded. E.g. if a datum were recorded at 1:23:59 (59 seconds past 23 minutes past 1 am), the time would be given as "a23".

Two more examples:

00b01a02: 0:02am, February 1st, 2000

99l31x59: 12:59pm, December 31st, 2099 (The last date/time the program can handle. Y2.1k anyone?)

To save our fingers from excessive counting chores:

J  F  M  A  M  J  J  A  S  O  N  D    <- Month

a  e  a  p  a  u  l  u  e  c  o  e

n  b  r  r  y  n  y  g  p  t  v  c

a  b  c  d  e  f  g  h  i  j  k  l  m  n  <- Code

0  0  0  0  0  0  0  0  0  0  1  1  1  <- Hour

0  1  2  3  4  5  6  7  8  9  0  1  2

-  -  -  -  -  -  -  -  -  -  -  -  -

o  p  q  r  s  t  u  v  w   <- Code

1  1  1  1  1  1  1  2  2  2  2  <- Hour (1pm=13:00)

3  4  5  6  7  8  9  0  1  2  3

Help file table of contents


Glossary, trademark information, etc
Glossary, Etc.

In this helpfile, I have assumed that you have not told Windows to hide the extensions of files. The helpfile itself, for instance is called DS025.hlp. The ".hlp" part of that may not be showing if your computer has Windows set that way. In that case, you will probably also not see .exe or .txt at the right hand end of filenames. if you don't want to have your computer show extensions, then you'll have to rely on its descriptions of files. DS025.exe is likely to be reported as "DS025.. Application."

Trademarks: "1-Wire" and "Microlan" are registered trademarks of Maxim/Dalsemi. ('Dalsemi" being a trendy alternative to "Dallas Semiconductor", the original incubator of the 1-Wire product line. 1-wire and MicroLan seem to be used interchangably.

"Sheepdog Software" is also a registered trademark.

Glossary

DS025: The name of the weather monitoring program that this help file supports. The program itself is supplied with the name "DS025.exe". Most (all?) related files have "DS025" as a part of their name.

Extension: The files on a computer have names. On a Windows computer, the name of a program will usually end ".exe" This is called the file's extension. Files of other types should have other extensions.... though you can make a file have the "wrong" extension... which is not a good idea. A frequently chosed option of the Windows system will hide common extensions such as .exe, .txt, .htm.

Folder: Another term for what we once called a directory. A subdivision of a filing system.

iButtonViewer: The excellent and useful bit of free software supplied by Dallas to help users troubleshoot MicroLan installations. It is sort of a "MircoLan Explorer": You fire it up, and it gives a list of the connected MicroLan chips. If you click on the entry for a specific chip, a window opens to allow you to communicate with that chip. An up-to-date copy of the iButtonViewer will access all of the chips DS025 can handle. (It will not, I believe, access the DS2408, if you are trying to explore that chip. It is not supported by DS025.exe either. Dallas have a new tool, written in Java. I found it not as good as iButtonViewer, and a pain to download, install... More Is Not Always Better! Once it is refined, it will probably be good.)

ini File: "Ini" is just an abbreviation for "initialization". An ini file holds information about how an application should behave. DS025 requires a main ini file and allows the user sundry extra choices by means of a secondary, optional ini file. They are called DS025ini.txt and DS025ini2.txt respectively, though the extension may not show, depending on your computer's Windows customization. Ini files are often saved with .ini as their extension, but this is not the practice of DS025.

MicroLan: Another term for 1-Wire. The are both essentially adjectives, as in "The DS1820 is a 1-Wire chip for reading temperature". I have extended "MircoLan" to a second use as a noun, by which I mean "a collection of 1-Wire chips connected to a computer through a 1-Wire adapter, e.g. a DS9097-U".

Help file table of contents


Some finer points

I hope this material is interesting. You don't need to know it to get the program running.

Cycles

Offsets and scaling

Units

A Display issue

Two small points, not needing their own pages:

The program is protected against multiple executions. (Sounds grim! What it means is that if the program is already running, trying to run a second instance of the program will result in nothing happening.) The reason for this? The computer you are running it in may be used for other things. Ordinarily, this will be fine. There's no need to shut down the weather monitor (DS025) while those "other things" are done. However, suppose someone does shut down DS025? If you want to set up the Windows task scheduler, or some third party utility, to start DS025, say, every night at 8pm, then you can do so without worrying about what will happen on the occasions when DS025 is already running then.

Even though the program's windows have "maximise" buttons, those buttons won't do anything.. Well... the window will maximise for a moment, and then return to the "restored" state.

Help file table of contents


FP Cycles
Cycles

Once the program has finished initializing, and settles down to reading and recording data, it enters a big loop with 60 steps. A "cycle" is one trip through that loop. the number of cycles completed by the program to date, since the last time it was run, is displayed on the graph page. Every so often, a record is made in DS025DtLg.txt noting the time, and number of cycles completed.

One step within a cycle will consist of the sorts of things listed below:

Wind direction is checked quite frequently. The WD(i) (Wind direction at this instant") text on the display is updated, and the circular wind direction indicator is updated. (The thick end of the "vane", by the way, points into the wind.)

Less often, a step is executed with looks to see how many instantaneous wind direction readings have been made and tallied. When enough have been, the prevalent direction is reported in the WD(a) text, and an entry is made in DS025DtLg.txt recording how many times the wind was seen to be coming from each direction in the just-past period.

Temperatures are checked fairly frequently. The temperature on channel t0 is checked twice as often as the other temperatures.

Some things are measured with sensors with some intelligence. The rainfall sensor, for instance, keeps track of rainfall-so-far internally, so it doesn't need to be read very often.

Barometric pressure changes slowly, so it isn't checked very often.

In every case except "wind direction, average", a reading of a sensor does not automatically result in an entry in DS025DtLg.txt. A compromise is made between the number of readings recorded and the detail being lost. If, say, the barometric pressure hasn't changed since the last time your read it, there is little point in re-recording it in the data file. If, even though it hasn't changed, it has been a while since the value was recorded, it is recorded again just in case the program is stopped, and to facilitiate replotting recent data when the program is restarted.

"Finer Points" menu

Help file table of contents


FP Display issue
A Display Issue

On many computers, the program will run quite acceptably without much effort by the user. However, with so many customization features available for the underlying Windows environment, you may find that on your computer the windows are not arranged nicely.

The first thing to try is the Restack menu item. Chose Scheme B. (The program boots up in Scheme A.) You can redefine Scheme A and/ or Scheme B using commands in the secondary ini file.

The program may be used on an old machine with limited graphics capabilities. I think you'll find the default Scheme A works okay down to 640x480. You may have to scroll the main window to see the most recent parts of the graphs, but this was the price to get just over a week on display for most users.

If your machine's Windows has been customized as follows, you may have to use the secondary ini file to get sensibly sized windows. The tweak that defeats me is: Display Properties | Settings | Advanced | Font Size. If your computer scales the fonts, buttons and labels seem to be re-sized and(?) moved about... but the underlying window seems to stay the same size... a size which no longer accomodates my carefully laid out controls. If anyone can point me to a discussion for programmers about accomodating these possibilities, I'd be very grateful.

"Finer Points" menu

Help file table of contents


FP Units
Units

I'm afraid I am most interested in the patterns of the various parameter's changes. The barometric pressure dropping twice as fast or twice as far today than it did three days ago is interesting. The fact that rain usually comes hwile the barometer is falling is interesting. What that pressure is or was, in millibars, Pascals, mm of Hg, or the unit of your choice I don't find very interesting, and I'm afraid that refinement to the program may take a while to arrive.

Because the chips return temperatures in degrees Celsius, it is fairly easy to display temperatures in conventional units, so I have done. I even provide for displaying them in Celsius or Fahrenheit, you lucky people!

Sorry! At April 04, the program runs to 6500 lines of code. Your glass is at least half full.

The temperature chips, by the way, while they have astonishing resolution and repeatablility, are not enormously accurate. You may want to do calibration tests and keep a note that, say, chip "4123B2E124..." consistently reads 1.3 degrees high, while chip "D100042F3.." consistently reads 0.4 degrees low. Note that "consistently". I haven't done my own tests, but I believe the chips do turn in consistent results. For the precision enthusiasts among you: Do remember that the chip may not mis-read by the same amount at all points over it's range.

And while I'm being a wet blanket: Also consider the following: If you are using the DS2438 on your barometer module to read the temperature, remember that the module has two voltage regulators. They generate heat in the course of their operation.

"Finer Points" menu

Help file table of contents


FP Offsets and scaling
Offsets and Scaling

At April 2004, the program had little flexibility in the way it graphed the data it collected. Humidity was drawn in the top part of the graph pane, extending down to about 20% of the pane's height when the humidity was zero, for example.

Happily, some work had already been done by then allowing you to move the temperature plots up and down the graphing pane to suit your needs.

In May, 2004 however, the program was extended. If your version is older than May 2004, get the update. You can simply replace your old DS025.exe, and add, in that directory, the DS025ini2.txt that comes with it. Also replace the old help file with the one this is in. Temperature lines can be moved up and down in the graph plotting area, and the amount of "swing" in each line can be altered. See What you can change in the secondary ini file for details.

"Finer Points" menu

Help file table of contents


PUReal
Real number: One with or without a fractional part, e.g. 5, 5.8, 200, -27


PUInteger
Integer: A "whole number". Negative numbers allowed, but nothing with a fractional part.


PUVersion
Version:

To ascertain what version of the application you are using, look in the title bar. The version ID will be a date. Be sure to read the first date in the title bar. Other dates are given after the word "Incorp", to identify the versions of modules incorporated into the application.