Heh, good luck mate!
The cockatoos nibbled off the auxiliary power cable to my WH-90 within 24 hours of installation. Fortunately I’ve found no need for it as frost isn’t a common issue in my corner of Queensland, but it was illuminating to see how quickly they identified that cable as a somewhat expensive bird enrichment toy. They’ve started work on chewing the silicon band around the top of the WH-90, unsure if this is likely to cause me problems or not. 
They regularly but infrequently land inside the WH-40, casually ignoring the 2nd-generation spikes I have artfully arranged, and the buggers carefully pick out the anti-bird spikes one by one, thoughtfully throwing them on the ground nearby in what can only be described as gleeful chaotic neutral behaviour with an added touch of irony. Zero bird poo issues so far though.
I’ve decided to see the whole thing as a mildly amusing battle of wits where the birds are winning, most of the time.
Our local magpie family? Not interested in either piece of weather kit, no food involved, although keeping them out of the house is as futile as keeping the cockatoos out of the rain sensor
 

From our observations, we found that above 30-40 km/h the stability of readings on WS80 and derivatives can drop. Performance is not as good as the low speed range.

Besides, many previous software versions even at speeds of 1-3 km/h showed unnatural drift of wind direction and strangely unstable speed readings. I don't know if new versions of WS80 and derivatives have fixed this.

One can also perceive that a copy is unequal to a copy on the same software. It becomes more pronounced especially above 30-40 km/h on WS80 and derivatives. The WS68 behaves more stably in such scenarios and is a good value for money, although it is obviously inferior to more expensive designs like the Davis VP2 and other reputable brands.

Perhaps at Fine Offset they will understand at some point that to make progress you need to invest more in the hardware layer, even if it involves slightly higher prices. Customers will be there for that anyway, when higher accuracy product lines emerge to complement the existing portfolio in the low-end segment. There is potential in their iOt services, while the hardware layer has room for clear improvement in many aspects.

The problem turns out that not everyone can spend more money on measuring sensors. Hence, for those who own the WS80 and WS90 Wittboy, I recommended buying the Ecowitt WS68, which turns out to be more stable when I tested it with a professional-grade wind gauge in the field for a longer period of time. I had a few reservations about the equipment, but it was generally closer to the truth than the WS80 and derivatives when it came to measuring wind speed.

The release of more firmware versions by Ecowitt for the WS80 and derivatives is due to, among other things, what I detected with the reference equipment and gave the information to Ecowitt with the evidence. Hence, they have been trying to fix the accuracy and stability of the Ecowitt hardware for many months. However, I doubt that with such a hardware layer, subsequent software versions will yield the expected results and it is not a waste of engineers' time and hardware resources. 40Khz transcoders are not very stable relative to 200Khz and are about 20-40 times cheaper than 200Khz transcoders used by reputable companies in the professional segment.

Personally, I think that going into ultrasonic technology was a mistake by Ecowitt, instead of focusing on improving the flaws in their rotary wind meters. It would have made sense if the hardware layer wasn't so cheap with sonic technology, it would have saved us time and wouldn't have required so many software updates, as not everyone has the time to do that and get on masts.

In some time we will check with the reference equipment what Ecowitt has improved in the WS80 and derivatives, but do not expect a breakthrough as long as such large savings on components are made. So we will most likely point out further flaws of Fine Offset in newer software versions for Ecowitt WS80 and derivatives. Perhaps someone will realize that this makes no sense, since Ecowitt doesn't even use professional ultrasonic anemometers in testing, to understand where they are making a mistake and wasting their human resources on fine-tuning a product of questionable accuracy. Not everything can be caught up with software when cheap components fail.

I think that's the WS85 sensor:
{ "img": "wh85", "type": "49", "name": "Wind & Rain", "id": "FFFFFFFE", "batt": "9", "signal": "0", "idst": "0" },
sensorID 0x31 = dec 49 (type is the sensor #) - including the WS85 there are 49 sensors possible assuming the max number of each is registered
result of http://IP-address/get_sensors_info?page=1 on a GW1200 1.3.0 resp. a WS3910 on 1.2.9

Yes, that makes sense - thank you.. I have now added this to my ecowitt.h, along with supporting code to the application:
        eWH85_SENSOR = 49,      // 49   0x31

But it still doesn't explain the loss of the WH46 in the v1.3.0 firmware.  I dug around some more, and the firmware does indeed still have the pm1, pm4, and wh46 strings embedded inside.  (There are also quite a few ws85 strings in there - lots of debugging.)

   ---Jonathan

I think I've found a regression here:

1.2.2 - shows WH46 additional information (pm1, pm4) on its web page (liveData.html) and sends via the Ecowitt protocol to EAR, but does not send via the telnet API.

1.2.8 - continues to show WH46 on its web page, continues to send via Ecowitt protocol to EAR, and ADDS that it sends the data via the telnet API.

1.3.0 - does not show anything at all for the WH46 - not on the local web page, not on the EAR submission, and not in the telnet API.  It *does* report the hardware ID in the WH45 slot, as it had been doing previously.

1.3.0 is also the first time that the value "eMAX_SENSOR" (0x31) has appeared at the end of the reply to CMD_READ_SENSOR_ID_NEW - the sensor type of 0x31 is accompanied by by a hardware ID of ff:ff:ff:ff, a battery value of ff, and signal value of 0, as might be expected.  The data ends there. This sentinel value is really only surprising in that it's the first version of the firmware to exhibit this particular behaviour - all previous versions simply used the length to indicate the end of the sensor list.

Interesting...  I have down-revved to 1.2.8 for now, and things are back to normal.

   ---Jonathan