Closed koalabi closed 1 year ago
koalabi
commented
2 years ago 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
zuckschwerdt
commented
2 years ago The files didn't capture the device. Drop on https://triq.org/pdv/ and you see just uniform noise.
koalabi
commented
2 years ago 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 ...
koalabi
commented
2 years ago 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.
koalabi
commented
2 years ago 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).
zuckschwerdt
commented
2 years ago 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.
zuckschwerdt
commented
2 years ago 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.
zuckschwerdt
commented
2 years ago 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.
zuckschwerdt
commented
2 years ago 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.
koalabi
commented
2 years ago 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
zuckschwerdt
commented
2 years ago 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.
koalabi
commented
2 years ago Still busy decoding. Will come back soon. Please don't close ticket.
stephen-hocking
commented
2 years ago How's it going?
koalabi
commented
2 years ago 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,
stephen-hocking
commented
2 years ago 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"
gdt
commented
2 years ago 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.
stephen-hocking
commented
2 years ago 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"
koalabi
commented
2 years ago 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,
zuckschwerdt
commented
2 years ago Looks plausible so far. But I would have expected the last bytes to be addition- and CRC-checksum, then maybe some trailer bits.
ruolfa
commented
1 year ago 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 
sdalu
commented
1 year ago @koalabi there is no pressure on the WS90
koalabi
commented
1 year ago @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.
sdalu
commented
1 year ago If I summarize, has been identified so far:
koalabi
commented
1 year ago 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
ruolfa
commented
1 year ago 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] ?)
jpochmara
commented
1 year ago 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 4fI 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.
davidefa
commented
1 year ago @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 b8FF = 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
jpochmara
commented
1 year ago 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.
davidefa
commented
1 year ago 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
jpochmara
commented
1 year ago 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.
ruolfa
commented
1 year ago Total rain would be: (R3 << 8 | R4) * 0.1 mm
davidefa
commented
1 year ago Sorry, but this is too simple, it does not take in consideration the 5 gains set via the vsview app. The sensor should send, at least, 5 different values to the gateway/console, that should somehow 'compose them' ( maybe simply sum them after multiplying by the respective gain )
ruolfa
commented
1 year ago Perhaps simple, but working fine and giving consistent reading over time
davidefa
commented
1 year ago Ok. Could you post some data 'before, during and after' some rain recorded?
ruolfa
commented
1 year ago Sorry, but this is too simple, it does not take in consideration the 5 gains set via the vsview app. The sensor should send, at least, 5 different values to the gateway/console, that should somehow 'compose them' ( maybe simply sum them after multiplying by the respective gain )
Gateway can't sum the total rain value. The total sum need to be calculated in the ws90 itself otherwise packet lost would mean loosing some rain.
davidefa
commented
1 year ago The other rain sensors ( ws65, ws40 ) transmit a 16 bit 'rain tick count' which always increments. In this way even if a few packets are lost the correct rain amount will be calculated at the next packet received. The ws90 should do the same, but should send, at least, 5 different 'rain tick counts' ( one for each 'rain rate range' ), as the sensor is a little bit more complex.
jpochmara
commented
1 year ago I have been running a test today comparing the rain fall as measured by a Stratus rain gauge and read from the WS90 with (R3 << 8 | R4) * 0.1 mm . And for me the two measurements are tracking pretty well. The last reading I took has the Stratus at 0.46in and the WS90 is reporting 0.44in. The two units are about 10 feet apart.
It looks like to me like the (R3 << 8 | R4) * 0.1 mm is correct.
davidefa
commented
1 year ago Good
P.S. Does this counter always increment or does it reset to zero after some time?
ruolfa
commented
1 year ago P.S. Does this counter always increment or does it reset to zero after some time?
I would say it wraps at 9999 , as measurement specification on ecowitt website give a range of 0-9999. Sadly there is no unit so I don't know if it is 9999 mm or 1/10 mm
godric
commented
1 year ago 👋 Gave a try to the implementation that was recently merged by @koalabi from #2448.
I have the Ecowitt WS90 (433MHz variant) and it doesn't seem to register at all with the new protocol (ie: rtl_433 -R 244)
I can however see the messages using generic decoder, ie:
$> rtl_433 -R 0 -X 'n=Ecowitt-WS90,prio=9,m=FSK_PCM,s=58,l=58,r=3000,preamble=aaaa2dd4'
time : 2023-05-11 14:49:13
model : Ecowitt-WS90 count : 1 num_rows : 1 rows :
len : 268 data : 9000354800069a826a34008b05003fff0000000000080000ffbffb0000850eef001
codes : {268}9000354800069a826a34008b05003fff0000000000080000ffbffb0000850eef001Which seems to match the reverse engineered format, so I'm not sure why it's not being decoded. I'm posting here in case it's something of interest. I'll try to dig into it on my own whenever I have time, let me know if I can help in any way.
zuckschwerdt
commented
1 year ago You can get some debug info with rtl_433 -R 244:v or rtl_433 -R 244:vv but in any case you will need the -Y minmax demod, which is only automatically selected at 868M.
godric
commented
1 year ago Thanks @zuckschwerdt, -Y minmax did indeed do the trick.
After about ~24h of decoding, I can confirm that the implementation (244) works like a charm.
Even got a bit of rain today and the precipitation data looks correct to me.
Thanks to everyone involved in both rtl_433 and the WS90 implementation, you guys are awesome 🥇
buelowp
commented
1 year ago I just got this yesterday, and am up and running today. Question though for those that use it, is the rain accurate? I got a count that makes sense in centimeters (.4371 recorded this morning) when I compare it to local recordings. I live right next to O'Hare airport so I can count on that reporting station from the NOAA to pretty closely match my own. O'Hare this morning reported .2 inches, and my tip gauge in the backyard reported .25. If I convert .4371 to inches, it's .17. I don't trust my tip gauge as much anymore which is one reason I wanted a new solution. But I don't think I got a third of an inch more rain that something 3 miles away.
I see @godric thought it was accurate, but which unit is that in? I see temp in farenheit in my results.
I have the 1.3.3 firmware from Ecowitt installed.
godric
commented
1 year ago 👋 My comment was about the data being correctly decoded from the protocol, I really can't speak for the accuracy of the WS90.
Regardless, you should be able to tell using the metric name:
rain_mm.-C customary) in which case the metric name will be rain_in.buelowp
commented
1 year ago It's using customary and everything else seems to be in inches (it's reporting rain_in). But it's just too far off. There isn't any rain predicted for the next 7 days, so I don't have a way to test this for a bit. It was in a test location, so it's possible the nearby items impacted the measurement. It's in the correct unobstructed location now. Everything else works as expected. I'll test it again next time it rains I suppose.
Grisen80
commented
1 year ago First, many thanks for all the time and effort you all put into this. Great work!
I just received my WS90 (868MHz) yesterday but my rtl_433 HA addon does not seem to pick up the signal. I use the "next"-version of the addon that should use the most recent build of rtl_433. I have set my config file to frequency 868M and protocol to 244. Is there anything that I am missing in my config? Any other ideas on how to get this working?
Worth to mention is that I actually got one reading from the WS90 with the above config yesterday but since then - nothing
Starting rtl_433 with rtl_433.conf... [rtl_433] rtl_433 version nightly-3-g70d84d01 branch master at 202308211241 inputs file rtl_tcp RTL-SDR [rtl_433] Use -h for usage help and see https://triq.org/ for documentation. [rtl_433] [rtl_433] New defaults active, use "-Y classic -s 250k" if you need the old defaults [rtl_433] [rtl_433] [Protocols] Registered 1 out of 246 device decoding protocols [ 244 ] [rtl_433] Found Fitipower FC0012 tuner [rtl_433] Exact sample rate is: 1000000.026491 Hz [rtl_433] [SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM" [rtl_433] Allocating 15 zero-copy buffers
zuckschwerdt
commented
1 year ago Try to follow https://triq.org/rtl_433/ANALYZE.html to find the signal.
Grisen80
commented
1 year ago Success. I started reading and decided to first try follow the advice:
"To get a clean signal remove the receiver antenna and place the device at 10cm to the receiver, that mostly isolates the transmissions."
With the external antenna removed I now get readings every 10s (I have the standard dongle you can get for cheap from Ali https://www.aliexpress.com/item/1005003840126962.html).
However, w/o the external antenna none of my 433-sensors are being picked up. I was hoping I could get away with only one radio and hop between the two frequencies.
Perhaps not the right topic for this issue, but is there anyway to get around this?
zuckschwerdt
commented
1 year ago Are all your devices, esp. the new one, close to 433.92 M? Or is there a wider spread? You might need to pick a frequency slightly offset (e.g. 433.85 M) to capture all. What was the distance before taking the antenna off? Is the sender too strong?
Grisen80
commented
1 year ago The WS90 is my only 868 MHz device. Currently it is positioned approx 15 cm from the dongle w the antenna removed. I use a 50cm USB extension cord between the PC and the dongle. Perhaps noteworthy that a zigbee and a zwave dongle also are plugged into the same PC. Zwave is around 868 if I remember correctly.
The 433 devices are on protocol 153, 205, 18, 18, 54. Some belonging to my neighbors 50m away outside my house, others two floors up, I placed one 10cm away from the dongle just for testing purposes. None of these are being picked up with the external antenna removed, but all work fine w the antenna attached. I checked one of my Oregon temp sensors THGR800 and it just says 433MHz.
I have tried moving the WS90 around from 1 to 10m indoors (antenna attached) but doesn't seem to make a difference.
Could it be that the antenna is 433MHz range only and that it prevents any higher frequencies from being picked up? Zwave interference?
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