Welcome to the Cumulus Support forum.

Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024

Cumulus MX V4 beta test release 4.0.0 (build 4019) - 03 April 2024

Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)

Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki

Ecowitt GW-1000 suggestion - added b3067

A Forum to archive Cumulus MX development suggestions that have been rejected or solved by other means.
User avatar
mcrossley
Posts: 12756
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: Ecowitt GW-1000 suggestion - added b3067

Post by mcrossley »

The default CMX conversion factor is 0.0079 which is ~126.6

Strange that they chose to supply that value especially given how inaccurate the UV reading on those stations is anyway, and I cannot see anybody having any use for it. But they don't supply the GW1000 solar W/m2 which can be calibrated in the gateway!
User avatar
galfert
Posts: 195
Joined: Tue 03 May 2016 2:57 pm
Weather Station: Ecowitt GW1000
Operating System: Mint, Raspberry Pi OS, Synology
Location: Orlando, FL

Re: Ecowitt GW-1000 suggestion - added b3067

Post by galfert »

mcrossley wrote: Tue 07 Apr 2020 12:57 pm The default CMX conversion factor is 0.0079 which is ~126.6
I would recommend dividing by 126.7 instead of multiplying by 0.0079 as then the Solar Radiation results will better match what people see on their consoles. Using 0.0079 is only an approximation and has been rounded off as the result of 1/126.7 as the real conversion factor in decimal form is an irrational number (it never ends) as it is 0.00789265982636148382004735595896......‬ when drawn out to even more decimal places and it never ends. Please consider changing your conversion to dividing by 126.7 instead of multiplying by your current decimal approximation. Similarly to explain this further with a practicable example, if you need to find out a third of something you don't multiply by .3333, instead you divide by 3 and it makes a significant difference in the results to use one method versus the other.
Strange that they chose to supply that value especially given how inaccurate the UV reading on those stations is anyway, and I cannot see anybody having any use for it. But they don't supply the GW1000 solar W/m2 which can be calibrated in the gateway!
I don't fully understand the logic either. But I tried to research this a bit and the best information I found is that their actually are different types of radiation UV-A UV-B and UV-C and they are Long, Medium, and Short wavelength radiations. I think perhaps the 0x16 data corresponds to just one of these types. It is strange that this data is there and is seemingly not utilized anywhere on the consoles nor on Ecowitt.net. What we typically refer to as Solar Radiation is perhaps just one of these other wavelengths or a combination of a couple of these...I didn't dig deep enough to fully find all the answers.
Ecowitt GW1000 | Meteobridge RPI | CumulusMX on Synology NAS
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Windy: pws-f075acbe
Tele-Pole flag pole
User avatar
mcrossley
Posts: 12756
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: Ecowitt GW-1000 suggestion - added b3067

Post by mcrossley »

Its close enough for me ;) Its only an approximation of W/m2 anyway, there is no absolutely correct conversion as lux and global solar irradiation measure different things to start with.

I don't understand the Ecowitt UV reading, they are using the same diode to measure both lux and UV - you can't do that, the solar and UV sensors need to be sensitive to different spectral bands. It looks to me like they added UV as a marketing exercise. I have seen the global irradiation drop and the UV stay the same or even increase (thin clouds can be fairly UV transparent), I don't see how their sensor could ever do that.
User avatar
galfert
Posts: 195
Joined: Tue 03 May 2016 2:57 pm
Weather Station: Ecowitt GW1000
Operating System: Mint, Raspberry Pi OS, Synology
Location: Orlando, FL

Re: Ecowitt GW-1000 suggestion - added b3067

Post by galfert »

mcrossley wrote: Tue 07 Apr 2020 4:00 pm Its close enough for me ;) Its only an approximation of W/m2 anyway, there is no absolutely correct conversion as lux and global solar irradiation measure different things to start with.
Yes I understand close enough. If the station was only using CMX it wouldn't matter. But the point though is to be able to have the data match what the console shows and what gets uploaded to Ecowitt.net...etc. Seems like a simple enough request to change for that sake. You are just changing a multiplication for a division in one place.
I don't understand the Ecowitt UV reading, they are using the same diode to measure both lux and UV - you can't do that, the solar and UV sensors need to be sensitive to different spectral bands. It looks to me like they added UV as a marketing exercise. I have seen the global irradiation drop and the UV stay the same or even increase (thin clouds can be fairly UV transparent), I don't see how their sensor could ever do that.
Agreed
Ecowitt GW1000 | Meteobridge RPI | CumulusMX on Synology NAS
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Windy: pws-f075acbe
Tele-Pole flag pole
AllyCat
Posts: 1124
Joined: Sat 26 Feb 2011 1:58 pm
Weather Station: Fine Offset 1080/1 & 3080
Operating System: Windows XP SP3
Location: SE London

Re: Ecowitt GW-1000 suggestion - added b3067

Post by AllyCat »

Hi,

IMHO some data is basically "garbage" and should carry a "health warning" (in this case almost literally) before being posted to the internet (or anywhere). It's unfortunate because the Davis solar sensors (and documentation) are highly professional, albeit at a rather high price. I don't have any experience of the "Ecowitt" solar sensors, but they appear to bear a considerable similarity to the Fine Offset "Solar Pod" which was supplied with the WH-308x stations. I do have some experience with those, partly because they had such poor reliability, so here is my "take" on these discussions.

First, the FO engineer seems correct that the data format transmitted is 3 bytes (24 bits) in units of a tenth of a Lux. That gives a full-scale of 1.68 million Lux; F O claimed a full-scale of 400k, so presumably 22 bits and in practice the normal solar maximum might be just into the 21st bit. In my experience the "resolution" was nowhere near 0.1 Lux, typically in steps of about 12.5 Lux from darkness and some of the "faults" suggested that it used two coarse ranges. The "Pod" appeared to use a silicon diode, so reporting the level in Lux is "strange" (see below). Some of the Consoles did calculate watts/m2 in addition to the Lux value, but unfortunately used an incorrect conversion factor to give a result almost an order of magnitude in error! The Pod did have a separate UV sensor (a SMD chip impossible to identify), probably sensitive to (just) UVA, but it only reported 14 "UV Index" steps, often demonstrably wrong.

Lux is a measurement of the VISIBLE light level, normally measured with a PhotoResistor. But (approximately) half of all the measured solar radiation (in Watts/square metre) is INFRA RED (heat), however the ratio is not constant so there is NO exact conversion between Lux and watts/m2. This "insolation" is accurately measured with a Pyrometer, but it happens that normal Silicon (photo) Diodes peak just into the IR region and give an "acceptable" (i.e. cheap) indication of the overall Visible + IR energy. Due to the intrinsic emphasis towards the red end of the spectrum, some diodes are available with an extended or enhanced blue sensitivity. But measuring solar radiation (particularly in UK) is exceptionally difficult, with an absolute value unlikely to be better than around 5%, so discussing conversion factors to more than two significant digits is pointless.

Yes, there are UVA, UVB and UVC frequency bands but UVC doesn't pass through the Earth's atmosphere and can be ignored. The "dangerous" band (skin cancer, etc.) is UVB, but nearly all low-cost "UV" sensors measure UVA, or at best UVA + UVB. Davis use an expensive optical filter to remove most of the UVA to give a genuine "UV Index" (which has a very specific definition). But inferring the UVB level from UVA is "questionable" and it seems nonsense if Ecowitt really are calculating it from a Visible / IR measurement.

Cheers, Alan.
zoomx
Posts: 65
Joined: Sat 15 Mar 2014 4:50 pm
Weather Station: Froggit GW1000
Operating System: Windows-Linux
Location: Italy

Re: Ecowitt GW-1000 suggestion - added b3067

Post by zoomx »

In this thread from Meteonetwork forum (in italian) there are images taken from Ecowitt.net that shows UV index. They are talking about this index in Italy seems to overestimate.
https://forum.meteonetwork.it/stazioni- ... ex-uv.html
I don't know wich sensor is inside the new Ecowitt-FineOffsett stations but it seems that all firmwares are done by Ecowitt and maybe some device projects.
Post Reply