Page 1 of 1

Wind data HTTP (Ecowitt) vs. Ecowitt GW1000

Posted: Sat 08 Jan 2022 12:33 am
by KarlS
It's winter: light snow at -26°C, not much incentive to go outside. Rummaging through my spare parts bin I find an unused Raspberry Pi and an Ecowitt GW1000 gateway. Whoa, why don't I create a backup CumulusMX system? Ready ... set ... go

Here is what I did:
• Clone (!) the SD card of my main system
• Edit the Cumulus.ini file so the backup system doesn't upload to my website(s)
• Update the IP/MAC address of the second GW1000 in the Cumulus.ini file
• Change the port address for the web interface to 8888

After booting up the second Pi and logging into the interface, I changed the station type from "HTTP (Ecowitt)" to "Ecowitt GW1000". (It's winter, I've got nothing better to do ...) After running the two systems for a few days I noticed some differences in the monthly log files, namely the wind values. This Excel table highlights the differences (I have deleted the rows with matching values).

wind1.jpg

OK, right now it's not very windy, but still it's interesting to see that the HTTP values for windspeed and windgust are always higher than the GW1000 values. I'm not really concerned about the differences in the windbearing, that's maybe for another day. But what's the reason for the windspeed/gust differences? Is it that I use two different GW1000 gateways?? To find out, I change the IP address of the backup system to the same one used in the main system and let it run for a few hours:

wind2.jpg

Again the HTTP values are higher than the ones reported by the GW1000 protocol. Is this another case of Segal's law, or maybe the two protocolls don't provide the same data precision (integer, floating) ... or ... or am I missing something?

Re: Wind data HTTP (Ecowitt) vs. Ecowitt GW1000

Posted: Sat 08 Jan 2022 9:17 am
by Gyvate
Are your posting interval (customer server) and your polling interval (CMX from GW1000) the same ? And do they happen for both in the exactly same time window ?
If not, differences are to be expected.
By the way, I have 4 CMX instances running in parallel, on different RPis (backup,test,prod, Win11 PoC), 2 x GW1000, 1 x WH2650 (technically a GW1000 without indoor sensors), 1 x HP2551 via http.
The deviations (as the all have the same outdoor sensors to read) are zero for the max and actual gust values, wind the same.
Wind sensor is the ultrasonic WS80.

Re: Wind data HTTP (Ecowitt) vs. Ecowitt GW1000

Posted: Sat 08 Jan 2022 9:50 am
by HansR
@KarlS: interesting experiment. So the WS80 delivers the same data to both and the registration is different. Did you see my issue with the WS80 and two GW1100 and the solution Ecowitt suggested?

Good question by @Gyvate, curious to your settings.

For me, I have had several problems with the WS80 and I think - from what they tell me which is not much - Ecowitt still has a problem with the WS80, apparently still working on it (too soon released?). All issues for me seem to be related to the firmware of the gw1100 so the switch off the not used sensor WS90 (and maybe all not used sensors) may be a good idea. At least to try: if it does not work, it does not harm either.

Re: Wind data HTTP (Ecowitt) vs. Ecowitt GW1000

Posted: Sat 08 Jan 2022 12:25 pm
by mcrossley
I can see that CMX handles the average wind speeds slightly differently for the two station types. This based on the sparse documentation for the GW1000 protocol and no documentation for the Ecowitt protocol. I've started an investigation into comparing the data across the two protocols from the same station to try and figure out what they are sending.

The other difference is that the GW1000 sends the values as metres/sec and the Ecowitt as mph. CMX handles all conversions with double precision values, but maybe there are rounding errors in the GW1000 firmware - the data comparison may shed some light. TBC...

Re: Wind data HTTP (Ecowitt) vs. Ecowitt GW1000

Posted: Fri 21 Jan 2022 2:06 pm
by mcrossley
The latest release (3.14.2) fixes an issue with the HTTP Ecowitt handling of wind data.

You should find that they are now much more comparable. There will however still be small differences due to timing of the data arrival, and different polling/transmit intervals used.