Rain decimals

[Piero]

Hi Steve,
on my Davis station I use the weight for the measurement in inches, but the software is set to display the measurement in mm.
This fact, however, causes problems of conversion and rounding of numbers.
Can I wiew the rain with two decimal places instead of one?

Thanks and best regards

[steve]

Not currently, no. Note that displaying two decimals for rain implies that your rain gauge is accurate to 0.01 mm, which it is not.

But at some point I do plan to make the number of decimals for everything configurable by the user, and then it will no longer be my responsibility

[Piero]

Not currently, no. Note that displaying two decimals for rain implies that your rain gauge is accurate to 0.01 mm, which it is not.

It 's true, but my rain gauge is set to 0.01 inches and the display is in mm. So the problem is the conversion from inches to mm: WeatherLink uses two decimal places, so the values ​​on my site many times do not match.
It seems to me that Cumulus does not make the rounding of numbers, but consider only the first decimal place: when I see on WeatherLink "2.56 mm", on cumulus I see "2.5", and this causes even more differences between the two values on the pages​​.

Extremely serious problem for an engineer ....

[steve]

when I see on WeatherLink "2.56 mm", on cumulus I see "2.5", and this causes even more differences between the two values on the pages​​.

How do you get a value of 2.56 mm from multiples of 0.01" (= 0.254 mm)? 10 tips would be 2.54 mm, which rounds to 2.5 mm.

[Piero]

Are you an engineer too? I did a random sample.

Yesterday, WeatherLink showed 0.25 (0,3 in the bulletin) and Cumulus 0.2. WeatherLink 0.76 and Cumulus 0.7.
That's why I thought Cumulus would show only the first decimal place without rounding.

Today, however, WeatherLink shows 8.89 and Cumulus 8.9.

Is there something I'm missing in the management of these numbers...

[steve]

As far as Cumulus is concerned, the Davis DLL does the conversion of data into the required units, and Cumulus rounds using system routines. I'm not aware of any issues with the rounding. It may be relevant that Cumulus calculates today's rain by taking the difference between the annual rain total now and the value at the start of day. The calculation is done before rounding.

But it's because of all of this that Davis supply metric adapters for their rain gauges...

[Piero]

It may be relevant that Cumulus calculates today's rain by taking the difference between the annual rain total now and the value at the start of day. The calculation is done before rounding.

But the annual rain total is downloaded every time from the datalogger?
The calculation is done using the same decimals of the data logger?

It could be a problem due to multiple successive rounds..

But it's because of all of this that Davis supply metric adapters for their rain gauges...

In fact, I've always used the metric adapter. Now, however, I'm trying the other because it seems to allow more precise measurements. That's why I found this problem.

[steve]

But the annual rain total is downloaded every time from the datalogger?

Yes.

The calculation is done using the same decimals of the data logger?

It's done with whatever value it gets from the Davis DLL. The start of day figure is logged in today.ini without rounding. Rounding only occurs when the figure is displayed or written to the log file.

In fact, I've always used the metric adapter. Now, however, I'm trying the other because it seems to allow more precise measurements.

I don't understand how that can be. A metric tip is smaller than an imperial tip.

[steve]

Actually, it occurs to me that the start of day counter and the current counter are logged to the diags file periodically, so you could look in there to see the 'raw' figures before the calculation of today's rain is done.

[Piero]

It's done with whatever value it gets from the Davis DLL. The start of day figure is logged in today.ini without rounding. Rounding only occurs when the figure is displayed or written to the log file.

In this case, the problem should not exist.
I'm beginning to think that it was a problem due to the start of Cumulus with Vitual VP: sometimes it happens that it reads from VVP wrong values of the rain and I have to restart it using the backup files.
I think this because even today, which is the second day by the change of tip, the values ​​are correct.
In case of repeating the mistake, I will check the file today.ini.

In my opinion it would be nice, in any case, be able to set the number of decimal places.

I don't understand how that can be. A metric tip is smaller than an imperial tip.

I too am skeptical, but the frictions could prevail. However my pluviometer still providing wrong values ​​and I can not seem to adjust it properly. So I decided to try.

[steve]

I'm beginning to think that it was a problem due to the start of Cumulus with Vitual VP: sometimes it happens that it reads from VVP wrong values of the rain and I have to restart it using the backup files.

There are definitely issues between VVP and the Davis DLL, which cause a number of problems.

It could also be that the Davis DLL rounds the figures to the correct number of places for the units that Cumulus has told it to use (i.e. 1 decimal place for mm). I think this then has the potential for differences of +/- 0.1 mm in the calculation of today's rain. It also means (I think) that allowing more dp in Cumulus wouldn't make any difference.

[Piero]

In the rain database of WeatherLink I have always found two decimal places, even when I used the metric tip. So it is likely that the DLL Davis always use two decimal places, in fact even VWS for default always show two decimal places.
It would be interesting to see the Cumulus calculation without rounding, but I think you're right, it probably would not change anything.
If you did this test, I would like to know the result.
Anyway, I'll let you know in the coming days if the problem persists.

Thanks, as always, for your timely and valuable assistance

[steve]

Weatherlink doesn't use the DLL, but VWS does, I believe. So perhaps the DLL doesn't do any rounding. But then again, the author of VWS has managed to get the DLL to do things that I haven't been able to do - like getting the USB mode working. I guess one approach might be to tell the DLL to work in inches (i.e. the units that the gauge is set to) and then do the conversion in software. I have to admit that it never crossed my mind that anyone would want to do what you are doing, when Davis provide the facility to set the rain gauge to work natively in the correct units.

The new version of Cumulus that I'm working on doesn't use the DLL, and it's in that version I'll be allowing the user to specify the number of decimal places they want to use.

[Piero]

Sorry Steve, you've intrigued me and, if I can, I take this opportunity.
I had a doubt. What you mean by DLL? The data logger?
I ask because now I do not understand how WeatherLink works.
The data logger stores only the number of "ticks" of the pluviometer and then WeatherLink associate 0.01 inches or 0.2 mm depending on the setting?
Or the datalogger stores directly 0.01 or 0.2 mm and then WeatherLink converts?

[steve]

"The DLL" is a Windows Dynamic Link Library supplied by Davis for third parties to use when writing software for Davis stations. It handles fetching data from the console, and does all kinds of useful things like converting the data into the units you require. It means that fetching data from Davis stations is much easier that driving them 'directly' using the serial protocol. The DLL does have a number of disadvantages, however, and a few bugs.

So for rain, you're correct that the logger stores the number of ticks. What the DLL does is convert the number of ticks into whatever units Cumulus asks for, using the rain collector setting in the console. Weatherlink does not use the DLL, it uses the serial protocol directly and does the conversion itself.