Figuring out units for Ecowitt WS68 in ambientweather_wh31e.c

[nitrogen76]

I have two wind reporting instruments. (I am writing a set of scripts to automate setup and ingestion of weather data mostly for my own use)
I have an acurite 5-n-1 and a Ecowitt WS68

the acuirite reports to influx as "wind_avg_km_h/wind_gust_hm_h" while the EcoWitt reports as "wind_avg_raw/wind_gust_raw"

What do i need to do to get the Ecowitt reporting with the same tags?
I'm not very good in C, but i see code in that module that would report this way, with tags about "clang-format on/off" and i'm not sure what that means.

My commandline:

rtl_433 -s 1024k -d:00000915 -M time:unix:usec:utc -f 915M -R 142 -R 40 -R 73 -R 113 -R 42 -M protocol -M level -C si -Y autolevel -F "influx://${influx-db-url}"

Thanks for your help.

[zuckschwerdt]

I added the WS68 in 2020 as preliminary for #1283. We still need a user to figure out units and scaling of

• battery_raw
• lux_raw
• wind_avg_raw
• wind_max_raw
• wind_dir_deg_raw

There was new interest in the WS68 / that issue in 2022 but it didn't conclude anything iirc.

It would be great if you can figure out things. Maybe by comparing both your units?

[nitrogen76]

Ok, that's a GREAT reason!

I will try and do this. Is placing my findings in this thread okay, or is there a way that's better for you?

[zuckschwerdt]

Perfectly fine. Report anything you find. Thanks!

[nitrogen76]

Ok, so the 5n1 doesnt report wind speed exactly like the WS68 does, but it APPEARS it's reporting in km/h, as any other
measurement for my wind instrument doesn't make sense for the weather conditions. They match close enough.

• Wind speed: km/h (avg and max) (max is gust)
• wind_dir_deg is degrees, with 0 being north
• battery_raw appears to be a arbitrarily figured percentage of battery used, but i'm not sure how accurate i am in that.

a brand new battery last night was at 90%. A battery with 1.485 volts came in at 75%, and a completely used battery came up at 0%.

The funny thing is, ZERO battery just uses the last reported value (this thing as a solar cell in it.)

• lux_raw i don't know what it is. It reports "5393" lux at about 2:15 PM near Dallas, TX. My android phone lux meter reported it was closer to 99796 lux

The WS68 also has a UV report range, which is between 0-15. the "extra data" section doesn't match up, so i am wondering if some bits are sliding

I've attached some g* signal save files, as well as output from my WS68 to see if it helps you decode stuff at all.
ws68.tar.gz

Lux reading from my cellphone during these measurements was approx 109000 lux.

[ProfBoc75]

Hi @nitrogen76 @zuckschwerdt : I was looking into the previous issue regarding the WS68, and I'm pretty sure that the byte 14 th (b[13]) is the UV x 10 value, and each time it's a whole number matching an UV Index number and value increasing with LUX_raw value too.

The first byte of the 'Extra data' is = b[13] = 14th byte and we have Here:
0x14 = 20 => UV Index 2 ( LUX_raw = 2907, 3267)
0x32 = 50 => UV Index 5 ( LUX_raw = 6867)
0x3c = 60 => UV Index 6 ( LUX_raw = 9284)

In another extract, I saw also 0x28 = 40 , UVI = 4 ( LUX_raw = 5663)
and UVI = 0 (LUX_raw = 1077 ) here

Edit : from your samples
0x14 = 20 = UVI =2 and LUX_raw = 3647 (g003_915M_1024k.cu8)
0x14 = 20 = UVI =2 and LUX_raw = 3629 (g007_915M_1024k.cu8)

I will try to get the LUX information, but from the WS68 user guide, the limit is 120KLux = so more than 2 Bytes, as @zuckschwerdt said, it could use some exponent to get the figures.

From my weather stations (not WS68), I have history with Lux and UVI.

So if UVI = 2 , LUX range is from ww to xx LUX , UVI = 4 , LUX range is from yy to zz then I may found the formula for the WS68 based on the LUX_raw information. It's complex because it's related to the date and solar elevation angle, but I will try to build a table with the figures and may be a simple formula could be guess.

[nitrogen76]

If having more samples is helpful, let me know what kind of samples you need with extra info (time of day, weather, lux values from my phone, my general location so you can check other historical weather info, etc) and i'll see about getting them for you.

Even a formula that I can feed to something like grafana, or some other program would be absolutely awesome.

[ProfBoc75]

If having more samples is helpful, let me know what kind of samples you need with extra info (time of day, weather, lux values from my phone, my general location so you can check other historical weather info, etc) and i'll see about getting them for you.

Even a formula that I can feed to something like grafana, or some other program would be absolutely awesome.

Yes, would be nice to get more samples like you did with : Date / Time / LUX_raw / the "Extra Data" which contains the UV_raw (my assumption) + LUX from your phone too.

With the -R 113:v option to get the full data code could help too (useful for bitbench).

[ProfBoc75]

So, in the meantime I looked at :

• My history of UVI and LUX, and play with excel and pivot table and compare to the ws68 LUX_raw and UVI
• Into the fineoffset_ws80 & ws90 drivers, very similar sensors to ws68, more or less the same protocol approach. just not same metrics (with temp / hum , rain gauge ) , the lux = lux_raw * 10 and uvi = uvi_raw * 0.1f (for ws80, at same byte position too ! )

So for me, it's probably the same with the ws68 : LUX = 10 x LUX_raw , and it's in the same kind of range vs UVI (see my EMAX graph below)

for ws68 : (multiple sources / locations)

From my Emax history: ( near Paris / France , 48.8 North, where Dallas is 32.6 North so your sun light is stronger )

To summarize my assumptions for ws68 :

LUX = LUX_raw * 10
UVI = b[13] * 0.1f

[nitrogen76]

Ok, i figured out why my initial lux value was so high, this weather station has a sensor separate from the solar panel, so it's not looking directly at the sun, but just the top of the sky.

At 12:33 CST (local time) it was lux 55000 just pointing at the sky via my phone, which is much closer to the value reported (6304).
Clear skies, zero clouds right now.
20240113-1331.ws68.log

[nitrogen76]

at 2:49pm CST (local time) my phone reported lux 33,000, while the device reported 3109 so i am sure you're right on about the value being lux_raw*10

20240113-1449.ws68.log

EDIT: the National Weather Service says the UV index for where I am right now is "3" but i have no idea how they calculate that, for whatever that is worth. If I run the calculation you provided, it gives me 2.4 if I did the math in my head right, so again, I think you are on track.

[ProfBoc75]

at 2:49pm CST (local time) my phone reported lux 33,000, while the device reported 3109 so i am sure you're right on about the value being lux_raw*10

20240113-1449.ws68.log

EDIT: the National Weather Service says the UV index for where I am right now is "3" but i have no idea how they calculate that, for whatever that is worth. If I run the calculation you provided, it gives me 2.4 if I did the math in my head right, so again, I think you are on track.

I think so, we are on track, from your log file the 'extra data' = 14 xxx (don't care about the xxx value, we just need the first byte, here 14) , where 0x14 (hexa) = 20 (decimal) = UV Index 2 and for LUX around 30KLux sounds good too.

From the previous log file, the LUX around 64KLux and extra data = 0x28 = 40 = UV Index 4 , same, sounds good value too.

For me, I guess we have enough confirmation to update the device driver, I will try a PR very soon.

[ProfBoc75]

@zuckschwerdt thanks for the quick merge ! @nitrogen76 : please download and try the last version of rtl_433 and let us know. Enjoy !

[zuckschwerdt]

@ProfBoc75 well, thank you for taking care of the analysis and PR, with the always superb quality of your contributions!

[nitrogen76]

Looks good! Thanks so much, its awesome.