Cumulus Support

Hi Steve,
I presume you have a wish list somewhere, but I can't find it.

I wonder if it would be possible to include a second order multiplier for temperature. I don't know if that is the correct mathematical term for it or not so an example:

If a calibration determines that the error to be corrected is a curve of the equation y=0.0007t^2 + 0.0025t +0.0119 then the program can accept the last two terms as it is now (although see below ref decimal places) but can't accept the first as stands now.

If you could introduce a new multiplier field that, defaults to 0 (I think) that adds the temperature squared * the value entered to the existing correction, I think this would satisfy this request.

As a secondary request, please would you increase the number of decimal places on the existing multiplier to 4, and if you implement the above request, the new field would need 5 decimal places, I believe.

I'm not a mathematician, so feel free to pick holes in my request!

See the link(s) near the top of the forum for enhancement requests. You'll see that there are quite a lot of them already, and I'm also in the middle of writing a new cross-platform version of Cumulus. Your request is rather 'esoteric', if you don't mind me saying, so it's not likely I'll be doing it as a priority

Thanks for your comment Steve.

I have been calibrating my temperature sensor as per recommendations in Stephen Burt's book "Measuring the Weather" ( http://measuringtheweather.com/ I highly recommend it to anyone serious about running any kind of weather site). After a number of months data collection I have produced - what I believe to be - pretty accurate calibration data. Unfortunately the Davis SHT11 sensor has turned out not to be linear - i.e. not just a slope (multiplier) and offset. It has turned out to be a curve. As Cumulus stands people who might like to produce truly meteorologically useful data can't. At least they can't other than manually putting dayfile.txt into a spreadsheet and applying the relevant formula to correct their data.

The addition of this extra field, which, forgive me for being presumptuous (being a programmer myself), I wouldn't think would be a hugely difficult task, would fix this.

I don't really think it is *that* esoteric so I will add the request to your list if you don't mind.

Out of interest, what factors do you have to apply to your sensor to correct it?

Adrian Hudson wrote:The addition of this extra field, which, forgive me for being presumptuous (being a programmer myself), I wouldn't think would be a hugely difficult task, would fix this.

Apologies if you got the impression from my reply that I thought it would be difficult; many of the several hundred outstanding enhancement requests won't be difficult to do when/if I eventually get around to them

It's not a difficult task, but it affects a lot of different places in the code due to the fact that the temperature value is a component of several other values calculated by Cumulus, and unlike most of the code that processes the data once read from the station, a lot of that code isn't in the 'common' code due to the different way each station type works.

As Cumulus stands people who might like to produce truly meteorologically useful data can't.

It's odd that Davis didn't think to include this as an option in the console, or the software that they supply.

I don't really think it is *that* esoteric so I will add the request to your list if you don't mind.

Again, apologies if I gave the impression that you shouldn't add it to the list. Please do; it's nowhere near as outlandish as some of the requests I've had in the past

And if Stephen Burt says that this is an important thing to do, then who am I to argue, he certainly knows his stuff. I still haven't got around to getting a copy of his book (It's actually called "The Weather Observer's Handbook"). Would this additional parameter be specific to the sensor used in Davis stations?

@steve

(It's actually called "The Weather Observer's Handbook")

Err, yes. So it is! Sorry Mr Burt!

It's odd that Davis didn't think to include this as an option in the console, or the software that they supply.

Well, Davis kit is good, but it isn't THAT good. A lot of its high price is due to the fact that its made in America and suffers from high labour costs etc that other kit doesn't as most other kit is made in the far east. Davis allow for an offset, that's all, as you will know. Your program adds to this by adding a multiplier, which in effect, together with the offset describes a straight line correction which is an order better than Davis already. Davis certainly don't expect anyone to - given Mr Burt's book etc - go to the trouble of logging, with a platinum probe datalogger, several month's worth of data, which [more] accurately describes the temperature sensor's response.

Would this additional parameter be specific to the sensor used in Davis stations?

No. Most sensors errors are described as a offset, an offset and a slope or a curve. Happily the curves are usually no more complex than a simple second order curve (a U or n shape - usually tilted slightly). This new parameter would allow for errors described 1) simply as an offset; 2) errors described as a line with a slope or 3) errors described as a curve all to be corrected by Cumulus. It can do the first two already, this would add the third.

@mcrossley
The equation that describes the error in the my particular (see last para below) Davis sensor is y=0.0012x^2 - 0.021x - 0.0398 where y= is the error (degC) and x is the temperature from the Davis.

To correct the Davis this needs to be calculated and then subtracted from the Davis temperature.

Obviously I can't enter this in Cumulus (hence this request) so I use the nearest straight line equivalent (as per my excel spreadsheet!) which is y=-0.0051x - 0.0771, where the variables are as above. This still needs to be calculated using the Davis temperature and then subtracted from it which can't be done directly in Cumulus - so - jiggling it about a bit you can enter 1 - (-0.0051) or 1.0051 as the multiplier and -(-0.0071) or +0.0771 as the offset. Actually, you still cant quite enter that as there are not enough decimal places so I have entered 1.005 as the multiplier and 0.077 as the offset.

I would LIKE to be able to enter the curve equation. I believe (remember, I am not a mathematician!), given a new "2nd order multiplier" field (which most people would leave as 0.0000) I would enter the correction as: 2nd Order Multiplier=0.0012, Multiplier=1.021, Offset=0.0398. At least, in my test spreadsheet, that's the way it seems to work if I plug it into the formula: correctedTemp = - 2ndOrderMult*DavisTemp^2 + Multiplier*DavisTemp + Offset

By the way, I have replaced the supplied temperature sensor on the Davis (the SHT11) with a SHT15. The I also calibrated the SHT11 and found that it was considerably less accurate than the SHT15. Calibration, together with this requested field (and extra precision) would have meant that replacing it would not have been necessary.

Adrian Hudson wrote: @mcrossley
The equation that describes the error in the my particular (see last para below) Davis sensor is y=0.0012x^2 - 0.021x - 0.0398 where y= is the error (degC) and x is the temperature from the Davis.

To correct the Davis this needs to be calculated and then subtracted from the Davis temperature.

Thanks, I'll plug that into a spread sheet later and see what sort of errors your example has. I have also replaced my SHT11 with an SHT75 (SHT15 on a modular board).

I didn't learn about the existence of the SHT75 until after I bought the 15. I nearly went blind soldering the flippin thing!

Hi,

Adrian Hudson wrote:... go to the trouble of logging, with a platinum probe datalogger, several month's worth of data, which [more] accurately describes the temperature sensor's response...... The equation that describes the error in the my particular Davis sensor is y=0.0012x^2 - 0.021x - 0.0398 where y= is the error (degC) and x is the temperature from the Davis.

I haven't read Mr Burt's book, but presumably you're working in degrees C (don't forget all our American cousins who use degrees F). What accuracy and range of temperatures are you trying to achieve?

0.0012x^2 seems too large, it represents an "error" of over one degree at 35 degrees C. Unless you calibrate the sensor over the complete range of "potential" temperatures then you might make your "extremes" less accurate than before.

As for your request to extend the scale factor to 4 Decimal Places, that suggests you're trying to work to less than 0.1 degree C, and, if so, the second order factor might need six DPs. Is the location of your sensor really suitable for that degree of "accuracy"?

Cheers, Alan.

Hi Allycat,

Thanks for your reply.

I am working in deg C, yes. If you feed 35C into the full formula you get an error of 0.6952, which I agree is probably a bit large**. However, I haven't finished calibrating the sensor yet, I need a period of warm weather to complete the process. I believe the curve will flatten out to give less error at the extremes. Remember, I am not actually using this formula at the moment, rather I am using a straight line through the scatter plot which currently is giving me the following very reasonable figures:

Davis -10 0 +10 +20 +30
Error -0.0261 -0.0771 -0.1281 -0.1791 -0.2301
Corrected -9.9739 0.0771 10.1281 20.1791 30.2301

After the calculations Cumulus will round everything to 1dp anyway but that's not the point, when dealing with slight slopes as you say, 5 or 6dp may be needed to avoid losing data.

As for the location of the sensor, its actually quite well placed, and anyway, I am making this request for the benefit of everyone not just me

** With the SHT11 sensor, 0.7degC degree of error is actually within spec (just). My SHT11 was slightly worse than this. It had a reverse slope, the colder it got, the worse it was. By -10 it was reading a little over 0.9deg warm (although still in spec).

Edit: *sigh* that table didn't come out at all well. No idea how to get the forum to format with fixed font like courier

You can get fixed font by using the code tags, but of course you don't see fixed font as you're typing it so have to format it elsewhere and paste it in. Not ideal.

Thanks Steve!

steve wrote:Again, apologies if I gave the impression that you shouldn't add it to the list. Please do; it's nowhere near as outlandish as some of the requests I've had in the past

There is already a request for this feature: https://cumulus.hosiene.co.uk/tracker.php?p=1&t=224

So there is, and now I actually understand the original request (i.e. how it relates to the existing options)!

Hi Steve,

I have confirmed my Vp2 temperature sensor errors and confirm they are indeed a curve, like - I have learned -most temperature sensors.

I have added a comment to the change request mentioned above:

can I second this request.

I have made a careful study of my VP2 sensor and determined it has a curved response. It reads 0.1C too high around zero, it reads 0.1C to low around 15C and back to 0.1C too high around 25C and traces a smoth curve at all point in between

an equation of the form y = ax^2 + bx + c as requested would allow correction of this.

It need not be implemented as an equation but simply as a further multiplier field where the current reading is squared and multiplied by the new field before being added to the existing calculations.

The program already implements the "bx + c" part, you just need to add the ax^2 bit!