Topic: Wind Gust Problem SDR vs. Ecowitt on WS2902/Ventus W830

[fankyy]

Hello everyone, I have a Ventus W830, which I assume should have the same WH65 sensor array as the WS2902 Models accordingly to the must read thread. But:

With rtl_433 it is being recognized as a WH24B, and weewx-sdr only works if i use this instead of WH65B in the sensor map. And: The reported wind gusts on SDR with rtl_433 are around 2 to 2.4 times as high as the console reports to Ecowitt.

And problem #2: The wind gust measurements on Ecowitt are around 0.75 times as low, compared to an old WH2310/WH1080 sensor (mounted on the same pole at nearly the same height). According to Ecowitt Support, both sensors have a sampling rate of 1 second. Thus the WH2310 (WS-1?) sensor measures gust peaks just fine, comparable to a Windmaster2/Windtronic2 hand anemometer (which has around 0.8s sampling). A Davis VP2 will often measure gust peaks up to 20% too low because of the slower 2.5s sampling rate, so factor 0.8 compared to WH2310/WH1080 sensors and the Windmaster2 anemometer. (Depending on gust duration, which gets usually shorter/more turbulent at lower measuring heights above ground).

Now why does the WH65 sensor array output on ecowitt (and probably also on the console display, couldn't compare so far as it's kind of a remote station) is that much lower, compared to a WH2310 station? And over SDR just too high, on the other hand. I really expected the WS2902/Ventus W830 to measure gusts the same way as the WH2310 I have, just with a faster 16s signal instead of 48s.

Does Ventus maybe use an old WH24 chip for tx and they might have just implemented the anemometer sampling wrong?

Another question: Does the WS2902 console upload the best cumulated gust number out of the 3 or 4 16s signals, or just the one that is currently on the display as it uploads (so from the last 16s instead from the last 48-64s?)

And am I the only one getting such different readings over SDR?

[fankyy]

Update: The reply i got from the ecowitt support already clears a lot of things:

The sensor works as you described.

However on wh2910 side, it sends data once a minute, so it will send the latest packet data received, not from the previously data packets stored, to the server.

Please note that our old wh24 sensor has a different wind speed factor as it rotates almost half the speed of a wh65 sensor.  So their wind speed is handled diffently: our wh65 wind speed factor is 0.49m/s/hz, and our wh24 sensor is 1.1m/s/hz.

So, the wrong readings over SDR seems just have to do with my sensor array from the Ventus W830 being wrongly identified as a WH24 from rtl_433, but why?

And the ecowitt network seems to be basically useless for wind gust reports, if nearly 3 out of 4 gusts are being lost in a minute. Will setup WU and weewx-interceptor driver now and compare them again. The gusts on the console still seemed to be lower during initial setup of this station though..

[davidefa]

rtl_433 try to detect if a sensor is a wh24 or wh65 ( but it may fail as it is based only on an undocumented feature: the preamble/postamble bit numbers ).
The only things that change are 2 scale factors for wind and rain.

Code: [Select]

MODEL_WH24
        wind_speed_factor = 1.12f;
        rain_cup_count = 0.3f;
MODEL_WH65B
        wind_speed_factor = 0.51f;
        rain_cup_count = 0.254f;

In case a wh65 is mistakenly recognized as wh24 you have to correct ( hope this can be done in weewx ) the wind_speed/gust and rain results:

Code: [Select]

       wind_correction = 0.51 / 1.12
       rain_correction = 0.254 / 0.3

P.S.
For 'undocumented feature' I mean that even ecowitt does not differentiate wh24 and wh65 sensors basing on this 'feature' ( wsview app has a simple check box you have to enable to select wh24 ).
So no wonder this automatic sensor recognition may work correctly/fail in different cases

[fankyy]

rtl_433 try to detect if a sensor is a wh24 or wh65 ( but it may fail as it is based only on an undocumented feature: the preamble/postamble bit numbers ).
The only things that change are 2 scale factors for wind and rain.

Code: [Select]

MODEL_WH24
        wind_speed_factor = 1.12f;
        rain_cup_count = 0.3f;
MODEL_WH65B
        wind_speed_factor = 0.51f;
        rain_cup_count = 0.254f;

In case a wh65 is mistakenly recognized as wh24 you have to correct ( hope this can be done in weewx ) the wind_speed/gust and rain results:

Code: [Select]

       wind_correction = 0.51 / 1.12
       rain_correction = 0.254 / 0.3

P.S.
For 'undocumented feature' I mean that even ecowitt does not differentiate wh24 and wh65 sensors basing on this 'feature' ( wsview app has a simple check box you have to enable to select wh24 ).
So no wonder this automatic sensor recognition may work correctly/fail in different cases

Now that makes sense, so it was just bad luck. Yeah weewx should do corrections under StdCalibrate in the config file, i will try it. But it would be somehow more 'clean' without this additional correction step. Could switching the identifier in sdr.py work too? Like in this:https://www.wxforum.net/index.php?topic=39278.msg404185#msg404185 thread?

[mcrossley]

A Davis VP2 will often measure gust peaks up to 20% too low because of the slower 2.5s sampling rate

I would argue that the VP2 value is "more correct" and the Ecowitt value is being overstated. The normally accepted definition of a gust in meteorology is the average speed over 3 seconds. If the Ecowitt is only averaging over 1 second or sending the peak in 1 second (I have not seen anywhere a statement on how they calculate their wind speeds) then it will tend to over-read the higher gusts.

[fankyy]

A Davis VP2 will often measure gust peaks up to 20% too low because of the slower 2.5s sampling rate

I would argue that the VP2 value is "more correct" and the Ecowitt value is being overstated. The normally accepted definition of a gust in meteorology is the average speed over 3 seconds. If the Ecowitt is only averaging over 1 second or sending the peak in 1 second (I have not seen anywhere a statement on how they calculate their wind speeds) then it will tend to over-read the higher gusts.

Not quite: If the 3 second gust falls right in between two 2.5 samples, you're averaging the gust over 5 seconds. So no, a VP2 really isn't suited the best for measuring gusts WMO conformly. You just can't generate a floating 3 second value with that, as professional weather stations from official meteorological institutions often do. The Federal Office of Meteorology and Climatology in Switzerland (Meteoswiss) even measures gusts as a floating 1 second (so let's say the fastest continuous 4x0.25s in a row, for example). And if any, i want to compare my measuerments with their stations, so the same sampling rate is likely the most important starting point equipment wise (apart of recording stability / sensor stability and so on). Not even talking about the measuring field/height/obstacles and so on.

It isn't really about over-reading, rather about which proportions of a gust peak one wants to measure. And since sensors and seemingly even meteorological organisations seem to lack of a coherent standard, the measuring of gusts is a real mess imo. But still, you wouldn't accept a car speedometer which averages acceleration to let's say 10 seconds. The faster the sampling interval, the more accurate peak measurements, you could still generate WMO conform 3 second floating averages of that.

That being said, gust duration tends to be longer, the higher the sensor is placed. But if someone doesn't have the possibility to put the sensor acccordingly 10m above ground, the slower sampling of the VP2 can have quite an impact, compared to faster sensors.

Regarding the Ecowitt/FO sensors: Somewhere in the documentation for WS80 or WS90 they stated a windspeed depending sampling of 1hz or lower above 8m/s, if i recall that correctly. They don't send the peak every second, the outdoor sensor array collects the 16 seconds (or 4.75 for the WS80 and 9 for the WS90 respectively) and reports the fastest second as a gust, sending the gust value, as well as an average 16s (5s, 9s respectively) wind value. Unlike the VP2 which sends every 2.5s the current wind value, but slower sampling therefore.

Edit: For the WS80 (and probably WS90) it's 1s for windspeeds above 5 m/s, according to the Ecowitt WS80 manual on page 18:
https://www.manualslib.com/manual/2298031/Ecowitt-Ws80.html?page=18#manual

[mcrossley]

To be fair, we do not really know how either system does the sampling - or do we? They both *could* be using a sliding window for the gust speed and transmitting that every 1 or 2.5 seconds. However I doubt it.

So, with the one second sampling of the Ecowitt, are you taking a sliding average of the last three readings for the gust, or just using the peak? To be comparable with "standard" met data should it be the former? Is it still 20% higher than the Davis then?

[fankyy]

To be fair, we do not really know how either system does the sampling - or do we? They both *could* be using a sliding window for the gust speed and transmitting that every 1 or 2.5 seconds. However I doubt it.

So, with the one second sampling of the Ecowitt, are you taking a sliding average of the last three readings for the gust, or just using the peak? To be comparable with "standard" met data should it be the former? Is it still 20% higher than the Davis then?

The transmit intervalls to the console are stated in the specs: 2.5s on the VP2 and 16s on the WH65 (4.75s on the WS80). But the VP2 only sends one value and that is just the 2.5s wind value, no additional gust value unfortunately (at that price they could well equip their ISS with some cache/memory for faster gust sampling, just like the FO sensor array does).

And for the FO/Ecowitt Stations, as you can read in an earlier post, the Ecowitt Support confirmed the 1s sampling window. In their previous message i got they also statet it, as i asked them about the WH2310 vs WH65 readings:

 
 The sensing timing is same: once per second it count up the wind pulses.

Well there is no possibility to generate a 3 second-in-a-row sliding average with the FO setup, as it dismisses the other values apart of 16s average wind and fastest 1s gust per 16second. To be comparable with standard met data it really depends how the met offices configured their sensor/measuring equpment too. In my country at least it is not 3 second but 1 second, so..

As i said: It depends on the gust duration, a long gust >5s will be accurately recorded with the VP2 in any case, a shorter than 2.5 second gust not, that's plain maths. But the difference wouldn't be 20% anymore. The - on average - 19% difference i observed at a measuring height of 2m above ground, where gusts can be especially shorter. But it still will be a few % sometimes, if you'd compare to a 3s floating average, because a 3s gust could be averaged to 5s if it falls in between two 2.5s samples. What I also compared is a 0.8s sampling 2m above ground (Windmaster2 hand anemometer) vs. the VP2 2.5s sampling 6m above ground, where the difference still is around 10 to 12% on average, even with the height advantage for the VP2.

But the WH65 tri-wing results seem to be a bit lower than the WH2310 and the Windmaster2, in my first comparison so far. Still figuring out why, could also be the rain cup being in the way or too close, depending on wind direction. In this forum someone compared the WS80 with the WS68 and got higher gust readings on the WS68, even though the WS80 already measures peaks better than the WH65. If only the WS68 would support the battery extension cord...

[fankyy]

Update: With the right commands in rtl_433 it gets recognized correctly as WH65B now. I had to add "-Y classic"

Code: [Select]

rtl_433 -f 868.3M -M time:utc -F json -Y classic
But i had to change the sensor map accordingly, for this identifier it is "FOWH65BAltPacket" (found in sdr.py) so for example:

Code: [Select]

windSpeed = wind_speed.254.FOWH65BAltPacket
Also, i compared them a bit further and the wind gust peak readings are now quite in line with the WH2310, if we take mounting heights into account, both with the usual differences to the VP2 as a result of its slower sampling rate. The WH2310 was at 1.8m above ground, while the VP2 was at 2.2m and the WH65 at around 2.6m on the same mounting pole, so they didn't get each other in the way. The effects do vary a bit, depending on wind direction, (which was also the case when there was just the WH2310 and VP2), probably the mounting pole at play. But in general it fits my Windmaster2-VP2 observations from other measuring locations, where other dominating wind directions occur.

WH65 (is one hour off because i forgot time:utc in rtl_433 before)  :
 [ You are not allowed to view attachments ]
WH2310:
 [ You are not allowed to view attachments ]
VP2:
 [ You are not allowed to view attachments ]

WH65 ecowitt for comparison, some gusts are definitely missing, one of the highest gusts on this particular day was not, but i think that is rather the exception, with a dismissing rate of 3 out of 4 16s packets on that upload protocol/service:
 [ You are not allowed to view attachments ]

[fankyy]

And just the day after i've written my previous entry, i could observe the WH65 Anemometer getting stuck for a short moment and even rotate in the opposite direction by turbulences and lee effects from the raincup and the broad plastic "wings" of the "Y"-type sensor array, as the hill i'm testing it on can cause quite an upwind situation, at least at this low measuring heights and at northeast wind direction. The max gust of that day then was lower on the WH65 than on both the WH2310 and VP2... It is what it is i guess. Will probably take a look into the WS80 or WS68 next, at least for this measuring location. Or maybe i'll just keep the WH2310 alive a little longer.

The other values like temperature seem to be quite in line with the (unventilated on that particular location) VP2, which is still my reference for every other measuring value apart of wind. I wonder if it will change when it gets summer, as the shield for the temperature sensor is still smaller than on the VP2. There, the WH2310 with its small diameter shield was quite bad, often more than 3°C too high readings compared to the VP2.