rtl_433
rtl_433 copied to clipboard
merbanan
Support for Ecowitt / Fineoffset WS90 (Wittboy GW2001 station)
I'm a new (and enthusiastic) user of rtl_433 that I would be happy to use with my recent Ecowitt Wittboy (aka GW2001). So far, with the latest version of rtl_433, it is not detected (using a afael Micro R820T tuner) but I discovered there seemed to be a WH24 not far away.
I have seen a mention of a forthcoming ticket to support the Wittboy but apparently it has not been created yet; hence, this one.
Is there anything I could do or provide to help supporting the GW2001? Currently it doesn't seem to be even detected by rtl_433 but I wonder whether it is possible to detect the weather station and capture raw byte streams using another tool ...
Thanks for any input.
Best regards
OK. I have found how to capture data from unknown devices from the "Contributing.md" page. I have got 3 cu8 files (see attachment). I have had a look using "od -ch ..." but I see no hint in there ... g00n_868M_1000k-cu8.zip
The files didn't capture the device. Drop on https://triq.org/pdv/ and you see just uniform noise.
Thanks. This is what I suspected (yet triq.org shows two peaks in the 868 MHz range but, agreed, from the heatmap nothing is really discernable). Are there any options I can try to capture the output of the device. Tha weather station is working (I can get measurements through the associated gateway (a separate WiFi hotspot that clearly indicates it communicates with the WS in the 868 MHz range) but I would prefer not to have this additional hotspot connected, the more so as its use is quite cumbersome ... Currently, the station is about 18 meters (and 2 brick walls) away; this should not be a big deal (as I receive another one whose location is unknown to me) but I will bring it closer to the SDR receiver, just to be sure ...
OK. I have brought my weather station much closer and run the capture for longer. Now, it seems I have go something. I join - in the archive - 4 different .cu8 files. 3 look quite similar and are probably the WS. The other one has captured a seemingly very different (shorter) signal.
Anything exploitable? I have run the following command on all 4 files:
rtl_433 -r <filename> -A
but I'm not sure what to do from their output.
Sorry if some questions sound really dumb but this is my first venture into the SDR world and I'm not acquainted yet with any of the tools. Any good tutorial to recommend?
Thanks in advance.
Forgot to mention: while capturing, just before or after the "interesting" .cu8 files, rtl_433 indicated:
*** Saving signal to file g145_868M_1000k.cu8 (243788 samples, 524288 bytes)
Signal bigger than buffer, signal = 4587520 > buffer 3145728 !!
*** Saving signal to file g146_868M_1000k.cu8 (2268917 samples, 3145728 bytes)
*** Saving signal to file g147_868M_1000k.cu8 (52027 samples, 131072 bytes)
Is there anything one can do (other/additional options, for example) when this happens? I see no obvious option nor in the man page, nor in the help (-h).
Looks like there is an FSK signal now :)
The g146 looks the same but recorded for longer ("bigger than buffer" even). You can see repeated interference as cause. Keep an eye out for that, it might disturb reception.
The files decode automatically with -A and the guess of m=FSK_PCM,s=58,l=58 is right.
We even get a pdv link to view the signal.
The signal data is:
{331} 55 55 55 55 55 55 16 ea 48 13 46 4f 00 29 3f d5 35 1d 85 20 86 00 1f ff 80 00 00 00 00 0b 00 00 7f c7 fc 00 00 3a d1 a4 80 00
{331} 55 55 55 55 55 55 16 ea 48 13 46 4f 00 42 3f d5 35 9d 04 1e 85 80 1f ff 80 00 00 00 00 0b 00 00 7f cf fb 80 00 3a b1 21 00 00
{331} 55 55 55 55 55 55 16 ea 48 13 46 4f 00 40 bf d5 35 9d 05 1b 05 80 1f ff 80 00 00 00 00 0b 00 00 7f c7 fb 80 00 3a 8b ef 80 00
Shift one bit left and we get aa aa aa aa aa aa 2d d4 90 which we expect.
Now we just need to add the subprotocol / version "90". I'll look into that.
You can get the data with
-X 'n=Ecowitt-WS90,prio=9,m=FSK_PCM,s=58,l=58,r=3000,preamble=aaaa2dd4'
Collect a number of lines and post the codes along with what you think should be in the data (e.g. temp 21, hum 80 ,wind 5,...)
Use a BitBench like this.
Oh and: the name Wittboy GW2001 refers to the package bundle of a GW2000 station plus the WS90 sensor. That's where the "90" in the protocol comes from.
Waow, Christian! I'm really impressed. I definitely need to know more about these tools. Thanks also for the better naming of the device and ticket.
I will follow your instructions and send you the requested information. (Might take a few hours)
Any idea or suggestion regarding the possible source of interference? I'm a bit concerned as, at the time, the station was about 2.5 meters from the RTL-SDR receiver (or might this, on the contrary, be the source of the problem - too close ?).
A big thanks, once again, for your efficient help.
Kind regards
Not sure about the interference. It's not data and at exactly 10ms intervals. You'll have to watch the band and try a few things (antenna position...) to locate that maybe.
Hi Stephen,
Thank you for asking (really). I have been 2 weeks on holiday, disconnected but I must admit it is tougher than I expected. I took inspiration from other Ecowitt/FineOffset protcols described on the Internet but still some sections of the datastream keep escaping me.
I have submitted the weather station to various influences to influence specific sensors. I have also captured several hours of measurements along with capture of the gateway web server at the same time but parts of the data packet remain opaque to me.
I'm just back from vacation. I will wrap up soon what I have already decoded. Maybe some among you will be able to give some clues ...
Kind regards,
Hiya,
No pressure. It might be a good idea to get in touch with the weewx guy (gjr80?) who has written a driver for the base station GW2000. He does his stuff using the network protocol, which is totally different of course, but might have some insights into the device.
On Mon, 4 Jul 2022 at 20:22, koalabi @.***> wrote:
Hi Stephen,
Thank you for asking (really). I have been 2 weeks on holiday, disconnected but I must admit it is tougher than I expected. I took inspiration from other Ecowitt/FineOffset protcols described on the Internet but still some sections of the datastream keep escaping me.
I have submitted the weather station to various influences to influence specific sensors. I have also captured several hours of measurements along with capture of the gateway web server at the same time but parts of the data packet remain opaque to me.
I'm just back from vacation. I will wrap up soon what I have already decoded. Maybe some among you will be able to give some clues ...
Kind regards,
— Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/2072#issuecomment-1173640801, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADHTQ3HVILWIFNOYAJAIHFDVSK3PFANCNFSM5V7QVQRQ . You are receiving this because you commented.Message ID: @.***>
--
"I and the public know what all schoolchildren learn Those to whom evil is done Do evil in return" W.H. Auden, "September 1, 1939"
A technique I have found useful is to add output fields for every unknown bit (in groups) and then they can be figured out over time. So it might be good to create a PR that decodes what you know and logs undecoded values that you don't, and perhaps even merge it. I found this useful in figuring out Ford TPMS and it was useful in the Acurite 6045M.
The gjr80 guy I referred to regarding the WS90 & GW2000 is @.***
On Mon, 4 Jul 2022 at 22:54, Greg Troxel @.***> wrote:
A technique I have found useful is to add output fields for every unknown bit (in groups) and then they can be figured out over time. So it might be good to create a PR that decodes what you know and logs undecoded values that you don't, and perhaps even merge it. I found this useful in figuring out Ford TPMS and it was useful in the Acurite 6045M.
— Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/2072#issuecomment-1173787231, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADHTQ3EXAKOOG3BTWGUWOLDVSLNITANCNFSM5V7QVQRQ . You are receiving this because you commented.Message ID: @.***>
--
"I and the public know what all schoolchildren learn Those to whom evil is done Do evil in return" W.H. Auden, "September 1, 1939"
As promised, I provide below the current status of my reverse-enginaering of the WS90 measurement broadcasts. So far, the results are quite meager. The WS90 protocol does not seem to share much commonality with previous ones like WS80. The captured data is compared to the WS2000's web service, queried at the same time.
Here is a sample of the data I start from. Each data record contains the data sent by radio by the WS90 (and captured via rtl_433) and the REST response of the GW2000 gateway at the same time (no absolute guarantee of course that the the 2 data sets are fully in sync.
time : 2022-05-30 07:54:28
model : Ecowitt-WS90
count : 1
num_rows : 1
rows :
len : 254
data : 90268c9e082882aa393606300b0a3fff205de500111c0500ff9ff8047d753688
codes : {254}90268c9e082882aa393606300b0a3fff205de500111c0500ff9ff8047d753688
{"common_list":[{"id":"0x02","val":"16.9","unit":"C"},{"id":"0x07","val":"54%"},{"id":"3","val":"16.9","unit":"C"},{"id":"0x03","val":"7.6","unit":"C"},{"id":"0x04","val":"16.9","unit":"C"},{"id":"0x0B","val":"0.6 m/s"},{"id":"0x0C","val":"1.1 m/s"},{"id":"0x19","val":"5.0 m/s"},{"id":"0x15","val":"164.80 w/m2"},{"id":"0x17","val":"1"},{"id":"0x0A","val":"304","battery":"2"}],"piezoRain":[{"id":"0x0D","val":"1.7 mm"},{"id":"0x0E","val":"1.2 mm/Hr"},{"id":"0x10","val":"1.7 mm"},{"id":"0x11","val":"1.8 mm"},{"id":"0x12","val":"1.8 mm"},{"id":"0x13","val":"1.8 mm","battery":"2"}],"wh25":[{"intemp":"19.2","unit":"C","inhumi":"59%","abs":"998.7 hPa","rel":"998.7 hPa"}]}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2022-05-30 07:54:45
model : Ecowitt-WS90
count : 1
num_rows : 1
rows :
len : 252
data : 90268c9e082d82aa3836051b090a3fff205de500111c0500ff9ff7047d7569a
codes : {252}90268c9e082d82aa3836051b090a3fff205de500111c0500ff9ff7047d7569a
{"common_list":[{"id":"0x02","val":"16.8","unit":"C"},{"id":"0x07","val":"54%"},{"id":"3","val":"16.8","unit":"C"},{"id":"0x03","val":"7.5","unit":"C"},{"id":"0x04","val":"16.8","unit":"C"},{"id":"0x0B","val":"0.5 m/s"},{"id":"0x0C","val":"0.9 m/s"},{"id":"0x19","val":"5.0 m/s"},{"id":"0x15","val":"165.19 w/m2"},{"id":"0x17","val":"1"},{"id":"0x0A","val":"283","battery":"2"}],"piezoRain":[{"id":"0x0D","val":"1.7 mm"},{"id":"0x0E","val":"1.2 mm/Hr"},{"id":"0x10","val":"1.7 mm"},{"id":"0x11","val":"1.8 mm"},{"id":"0x12","val":"1.8 mm"},{"id":"0x13","val":"1.8 mm","battery":"2"}],"wh25":[{"intemp":"19.2","unit":"C","inhumi":"59%","abs":"998.7 hPa","rel":"998.7 hPa"}]}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2022-05-30 12:00:55
model : Ecowitt-WS90
count : 1
num_rows : 1
rows :
len : 250
data : 90268c9e112b82aa0f3d00530a1e3fff205de50011320500ff8ff7000075ce8
codes : {250}90268c9e112b82aa0f3d00530a1e3fff205de50011320500ff8ff7000075ce8
{"common_list":[{"id":"0x02","val":"12.7","unit":"C"},{"id":"0x07","val":"61%"},{"id":"3","val":"12.
7","unit":"C"},{"id":"0x03","val":"5.4","unit":"C"},{"id":"0x04","val":"12.7","unit":"C"},{"id":"0x0
B","val":"0.0 m/s"},{"id":"0x0C","val":"1.0 m/s"},{"id":"0x19","val":"5.0 m/s"},{"id":"0x15","val":"
346.88 w/m2"},{"id":"0x17","val":"3"},{"id":"0x0A","val":"339","battery":"2"}],"piezoRain":[{"id":"0
x0D","val":"1.7 mm"},{"id":"0x0E","val":"0.0 mm/Hr"},{"id":"0x10","val":"1.7 mm"},{"id":"0x11","val"
:"1.8 mm"},{"id":"0x12","val":"1.8 mm"},{"id":"0x13","val":"1.8 mm","battery":"2"}],"wh25":[{"intemp
":"20.7","unit":"C","inhumi":"56%","abs":"999.1 hPa","rel":"999.1 hPa"}]}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2022-05-30 17:29:37
model : Ecowitt-WS90
count : 1
num_rows : 1
rows :
len : 255
data : 90268c9e08c6828a282f0623090a3fff205de50011350500ff8ff800007586b8
codes : {255}90268c9e08c6828a282f0623090a3fff205de50011350500ff8ff800007586b8
{"common_list":[{"id":"0x02","val":"15.2","unit":"C"},{"id":"0x07","val":"47%"},{"id":"3","val":"15.2","unit":"C"},{"id":"0x03","val":"4.0","unit":"C"},{"id":"0x04","val":"15.2","unit":"C"},{"id":"0x0B","val":"0.6 m/s"},{"id":"0x0C","val":"0.9 m/s"},{"id":"0x19","val":"5.0 m/s"},{"id":"0x15","val":"177.27 w/m2"},{"id":"0x17","val":"1"},{"id":"0x0A","val":"35","battery":"2"}],"piezoRain":[{"id":"0x0D","val":"1.7 mm"},{"id":"0x0E","val":"0.0 mm/Hr"},{"id":"0x10","val":"1.7 mm"},{"id":"0x11","val":"1.8 mm"},{"id":"0x12","val":"1.8 mm"},{"id":"0x13","val":"1.8 mm","battery":"2"}],"wh25":[{"intemp":"20.6","unit":"C","inhumi":"54%","abs":"998.4 hPa","rel":"998.4 hPa"}]}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2022-05-30 17:29:55
model : Ecowitt-WS90
count : 1
num_rows : 1
rows :
len : 266
data : 90268c9e089b828a282c0730090a3fff205de50011350500ff8ff8000075091c000
codes : {266}90268c9e089b828a282c0730090a3fff205de50011350500ff8ff8000075091c000
{"common_list":[{"id":"0x02","val":"15.2","unit":"C"},{"id":"0x07","val":"44%"},{"id":"3","val":"15.2","unit":"C"},{"id":"0x03","val":"3.0","unit":"C"},{"id":"0x04","val":"15.2","unit":"C"},{"id":"0x0B","val":"0.7 m/s"},{"id":"0x0C","val":"0.9 m/s"},{"id":"0x19","val":"5.0 m/s"},{"id":"0x15","val":"173.88 w/m2"},{"id":"0x17","val":"1"},{"id":"0x0A","val":"48","battery":"2"}],"piezoRain":[{"id":"0x0D","val":"1.7 mm"},{"id":"0x0E","val":"0.0 mm/Hr"},{"id":"0x10","val":"1.7 mm"},{"id":"0x11","val":"1.8 mm"},{"id":"0x12","val":"1.8 mm"},{"id":"0x13","val":"1.8 mm","battery":"2"}],"wh25":[{"intemp":"20.6","unit":"C","inhumi":"54%","abs":"998.4 hPa","rel":"998.4 hPa"}]}
NOTE: there are 3 sections in the 'codes' response. The third one is related to the GW2000's own sensors and is therefore not to be put in relation with the radio data. The second one seems to pertain only to the piezo rain sensor, probably the most "opaque" to decode.
Here is a link to bitbench with the same data.
The fields I have already identified with quasi-certainty: PROT: protocol (WS90), SID: station id, D (I'm not sure anymore - probably a false positive), HUM: humidity, WSPD: average wind speec (dm/s), WDIRL: least-significant part of the wind direction (direction modulo 256), WSPD2: wind speed 2 (gusts)
I have been unable so far to locate temperatures and pressure ... :-(
The rest keeps evading me. I'm particularly puzzled by the few variations in the data (despite variastions in the readable data) . The varying length of the message seems also a bit strange (capture artifact? variable length message?)
NOTE: the data shown here come from a long-running listening of the weather station, so variations are small and progressive. I had previously also tried to excite each sensor separately (rain, pressure, temperature, wind ...) by various means but the outcome was inconclusive ...
Any suggestion is welcome ...
Best regards,
Looks plausible so far. But I would have expected the last bytes to be addition- and CRC-checksum, then maybe some trailer bits.
If using the crc/checksum defined in fineoffset_WH51_callback (ECOWITT WH51), it is possible to find that valid payload are 32 bytes long for this device.
{330} aa aa aa aa aa aa 2d d4 90 00 31 e3 00 0e a4 aa 68 37 08 1e 08 00 3f ff 00 00 00 00 00 04 00 00 ff af fb 00 00 7e d1 07 00 00
{330} aa aa aa aa aa aa 2d d4 90 00 31 e3 00 0e a4 8a 68 37 06 07 06 00 3f ff 00 00 00 00 00 04 00 00 ff af fa 00 00 7e b5 af 00 00
{330} aa aa aa aa aa aa 2d d4 90 00 31 e3 00 0e a4 8a 68 37 00 b9 0c 00 3f ff 00 00 00 00 00 04 00 00 ff cf f9 00 00 7e 20 eb 00 00
@koalabi there is no pressure on the WS90
Indeed (you would have asked me wihout my looking at the specs, I would have said there was but no; I have chedked). Noted. Thanks.
If I summarize, has been identified so far:
- family = b[0]
- id = b[1], b[2], b[3]
- humidity = b[9]
- crc = b[30]
- checksum = b[31]
If I summarize, has been identified so far:
- family = b[0]
- id = b[1], b[2], b[3]
- humidity = b[9]
- crc = b[30]
- checksum = b[31]
checksum was not identified by me (but I trust the expert). I had also identified wind speed and wind direction. I haven't found the time to investigate, lately. It is still on my TODO list but with a medium priority ...
Best regards
Seems to match the EcoWitt-WS68: https://github.com/merbanan/rtl_433/blob/68a9c9df0fdf35af71679e5a8929ca679852c32a/src/devices/ambientweather_wh31e.c#L325-L330
(the WS68 id, could perhaps be b[1], b[2], b[3] instead of just b[2], b[3] ?)
I picked up a WS90 a bit ago and have been working on decoding the data packet, this is what I have found so far:
`Packet layout:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
YY II II II LL LL BB FF TT HH WW DD GG VV UU UU RR UU UU UU UU SS UU UU UU UU UU UU UU UU AA XX
90 00 34 2b 00 77 a4 82 62 39 00 3e 00 00 3f ff 20 00 ba 00 00 26 02 00 ff 9f f8 00 00 82 92 4f
- Y = fixed sensor type 0x90
- I = device ID, might be less than 24 bit?
- L = light value, unit of 10 Klux
- B = battery voltage, unit of 20 mV, we assume a range of 3.0V to 1.4V
- F = flags and MSBs, 0x03: temp MSB, 0x10: wind MSB, 0x20: bearing MSB, 0x40: gust MSB 0x80 or 0x08: maybe battery good? seems to be always 0x88
- T = temperature, lowest 8 bits of temperature, offset 40, scale 10
- H = humidity
- W = wind speed, lowest 8 bits of wind speed, m/s, scale 10
- D = wind bearing, lowest 8 bits of wind bearing, range 0-359 deg, 0x1ff if invalid
- G = wind gust, lowest 8 bits of wind gust, m/s, scale 10
- V = uv index, scale 10
- U = unknown
- RR = rain
- SS = super cap voltage, unit of 0.1V, lower 6 bits, mask 0x3f
- A = checksum
- X = CRC `
I am not 100% sure about the rain and super cap voltage yet. I found the the WS90 mostly agrees with the WS80, but the WS90 has a lager data packet size with more info.
@jpochmara super cool ( as I was working today on ws90 decoding and came to the same conclusions )
FF II II II LL LL BB bb TT HH WW DD GG UU ?? ?? R0 R1 R2 R3 R4 CC R5 R6 R7 R8 R9 RA RB RC XX YY
0 1 2 3 4 5 6 7 8 9 10 11 12 12 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
90 26 8c 9e 08 c6 82 8a 28 2f 06 23 09 0a 3f ff 20 5d e5 00 11 35 05 00 ff 8f f8 00 00 75 86 b8
FF = fixed 0x90 II = device ID ( 268c9e ) LL = light value BB = battery voltage ( 1=20mV ) bb = bit field D7.0 = temp.8; D7.1 = temp.9; D7.5 = bearing.8; D7.4 = wind.8; D7.6 = gust.8 TT = temperature ( temp.0-temp.7 lowest 8 bits of temperature ) HH = humidity WW = wind speed ( wind.0-wind.7 lowest 8 bits of wind speed ) 1=0.1m/s DD = wind bearing ( bearing.0-bearing.7 lowest 8 bits of wind bearing) GG = wind gust ( gust.0-gust.7 lowest 8 bits of wind gust ) 1=0.1m/s UU = uv ( 1=0.1uvi ) CC = capacitor voltage ( 1=100mV ) XX = crc YY = check
light value = ( D4 * 256 + D5 ) 1=10lux ( 0x0c8 -> 22480lux ) battery voltage = D6 * 0.02V ( 0x8a -> 2.60V ) temperature = ( temp0-9 - 400 ) / 10 ( 0x228 -> 15.2°C ) humidity = D9 wind speed = wind0-8 * 0.1m/s 1=0.1m/s ( 0x06 -> 0.6m/s ) wind bearing = bearing0-8 ( 0x6d -> 35° ) wind gust = gust0-8 * 0.1m/s 1=0.1m/s ( 0x09 -> 0.9m/s ) uv index = D12 * 0.1 1=0.1uvi( 0x0a -> 1uvi ) capacitor voltage = D21 * 0.1V 1=100mV ( 0x35 -> 5.3V ) R0-RC undecoded piezo rain values
I haven't the ws90 sensor, but I built a sensor simulator ( a transmitter that transmits the ws90 frame data, so I can change the frame at will ). Tried to change R0-RC data but received rain piezo does not change ( remains always at 0 ). I think these should contain '5 piezo rain values' that should match the '5 piezo rain gains' ( available in the vsview app settings ). But can't identify any. It could be helpful if anyone having the sensor could post a few data samples before, during and after a 'few rain ticks' ( as done before by @koalabi )
P.S. Think R7-R9 are some sort of flags
I can verify that the byte 21 is the super cap voltage. My WS90 has been out in the Sun today and reach a max voltage of 5.3V, and has been holding steady at the voltage for a few hours now.
I have played around a little bit with the rain sensor and the only byte I noticed that changed was byte 16. But there has to be more to it then that, those 8 bits can't hold the 0-9999 mm at 0.1mm units that the box spec claim.
My next plan is to bring the WS90 back inside and do some testing on the rain sensor.
I don't think the ws90 sensor calculates the 'rain amount' by itself. This should be done by the gateway/console. As only the gateway/console contains the 5 gains values ( piezo gain1, for rain rate < 4mm/h, piezo gain2, for rain rate < 10mm/h, ... ), set in wsview app. I think the ws90 sends, at least, '5 rain values' to the gateway/console
That could very well be the case, I don't have a gateway/console, I just have the WS90. I probably can't do much on the rain gauge front for the WS90.