UV Index - Integer or not

[Lloyd Adams]

Should a UV Index always be an integer?  The sensor produces an integer value, about once per minute, but this is being averaged for each archive packet, resulting in non-integer values.  Is this correct?

Thanks

Lloyd

[Thomas Keffer]

Hello, Lloyd

Both LOOP and archive records on the VP2 use non-integer values for UV. Take a look at your console, and you're likely to see a non-integer value. 

-tk

--
You received this message because you are subscribed to the Google Groups "Weewx user's group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Milner]

Tom

From what I can glean off the web a UV index should be rounded to an integer, but I guess a UV reading may not be.

See the end of this calculation:

http://www.epa.gov/sunwise/uvicalc.html

Andrew

[Lloyd Adams]

Tom, my console (OS WMR88) only displays integers, and the sensor (OS UVN800) only transmits integers.

Lloyd

[Andrew Milner]

...... and from the davis document:

http://www.davisnet.com/product_documents/weather/app_notes/93004_306-AN_06-interpret-uv-readings.pdf there is this link:

http://www.cpc.ncep.noaa.gov/products/stratosphere/uv_index/bulletin.txt where all the UVIs for major US cities would appear to be integer values, so perhaps the archived average should be rounded to nearest integer rather than just being a sum and division otherwise everything that uses the value needs to do a reformatting exercise to force the float value to a rounded one - I think.

As I do not have a UV sensor of any kind myself I'll just leave this subject with those to whom it matters more, having said my 2 centsworth ...

[Shaggy]

Having checked my database (I also use the WMR88 and the same sensor), only integer values are stored there.  I too see non-integer values reported in Weewx, and assumed that averaging was the reason for it.

On a related note (not wishing to hijack the thread though), I recently implemented the colour-coded background for UV value on the default Weewx web page as per the documented instructions.  However, when I modify the same HTML code to try and achieve the same for the $day.UV.max, the if-statement for comparing the max value fails (either drops off the end of the else-if statement and displays nothing, or if I put a final else statement, this is always the end result).  Is there a difference between the $current.UV and $day.UV.max formats, which would cause a numerical comparison of the latter in HTML to fail?

[gjr80]

Is this a case of forecast vs measured? From what I could see the EPA and NOAA links are dealing with predicted or forecast values and I would expect that an integer would suffice. On the other hand, it would not surprise me to see observations to 1 decimal place (à la temperatures where forecasts are integers but obs are often to 1 decimal place). I did look at the BoM and ARPANSA sites here in Aus which seem to support this, but unfortunately since the sun is now down I could not confirm this against a current reading (0.0 seemed to be an indicator though). Of course if a station outputs integers only .... then that is what is outputs... Completely coincidental but I did order my UV sensor this arvo, so I guess we will see what I get in a week or so.

Now that I can say I have not hijacked the thread, re the colour coded backgrounds, you are using .raw in your if statements aren't you? My understanding is that a string is normally returned from a dot code and .raw needs to be added if you want to return a numerical value for use in calculations or numerical comparisons.

Gary

[Andrew Milner]

Looking around further .... Hong Kong rounds UV index observations to nearest integer if > 1, but uses 1 decimal place if < 1.

[Lloyd Adams]

Shaggy - are you saying that you have only integers in your archive table?   I'm not using the WMR88 console to feed weewx (too unreliable), but instead grab the raw transmissions from the sensors.  If you only have integers, perhaps I should take a look at the WMR88 driver and check what that does.

Lloyd

[Thomas Keffer]

My apologies. I had assumed that you had a VantagePro, which does report non-integer values.

Frankly, I don't know what the WMR88 emits. In any case, weewx will average the values over an archive interval and store that, so it's unlikely to be an integer.

If you want to report an integer in your generated files, you should be able to format it that way (NOT TESTED):

$day.UV.format("%d")

-tk

--

[Shaggy]

Yes - I definitely only have integers in the Weewx database.  I originally found the WMR88 quite unreliable, but modified the antenna to improve reception.  Now the only problems I get are when one of the sensors' batteries start to fade, apart from that it's pretty robust now (ignoring the fact that it's a cheap station, so accuracy from the sensors won't be as good as from a higher quality one).

Over this weekend, I'm planning to upgrade from 2.6.1 to 2.6.3 because I have been getting more frequent Weewx crashes over the last several weeks, and I know Tom has made improvements to the WMR100 driver.

[Bob Geddes]

I am getting UV readings at last in the UK and get decimal readings in the database. Have just started logging the raw values from the WMR100/wmr88 drivers and getting integers so far. Guess I must wait for a few clouds to catch the averaging.

[Bob Geddes]

The WMR88 continues to log integer numbers. As the values slowly declined this afternoon weewx reported a decimal value for the period that covered the value going down from 3 to 2 etc.