EcoWitt WH40 rain gauge not recognized by rtl_433 - anyone working on it?

[Helmut Bachmann]

Hi, I just received a new WH40 rain gauge from EcoWitt and expected to have it added to my Weather station based on rtl-sdr and weewx.

I have already tried different things, but couldn´t get any reading after running the driver alone, neither with "-S all" option, where it just writes a file in the form of  "g037_433.92M_250k.cu8" but nothing of value is displayed.

While reading the file with the suggested -a and -A paramters, som info is dislpayed but surely only for experts and not for me as newbie.

I'd appreciate your help on what steps would be necessary to have this sensor added to rtl_433 driver.

Thanks and regards   

[Helmut Bachmann]

Adding rtl_433 -S all files for the sensor...

[Tolip Wen]

Hello,

Based on your post I discovered the ecowitt WS68 (wind direction, wind speed, gusts???, UV, and "Light")

My shiney new annemometer is now here with the battery installed!

Luckily I read your post first and adjusted my expectations before  purchasing.

I already have a working anemometer but I want one on the ground to compare/pseudo-calibrate one that I am constructing.

I partially based my purchasing decision on the fact that one of the things readable by the WS1000 is a WH51 that is known by rtl_433. I was looking for one to take apart and hardwire for regression testing and with this one I may not ever need to void the warranty.

I took a crack at the files you posted and made progress of a sort. I don't have your rain gauge so I have no idea what to expect from the output so I guessed. If you are asked for more samples the rest of this post may interest you.

I would not have posted what I found to date in your files EXCEPT that you started a different thread about a different rain gauge.

You may have already provided enough for 'them' to proceed to a solution. It may just take a few more files under known conditions. If you are asked to provide more data the rest of this post may interest you in understanding it a bit more.

Even if you bail and get a different product please describe the conditions when you took samples. What did you change between samples?

For your situation if you/they need more data you can add "-T 195" to the command you call with "-S all" that creates the .cu8 files. Then you will have exactly 3 messages from the rain guage. It reports every 49 seconds. 49*4=196. Subtract one second and you'll never capture 4 packets.

rtl_433 might create more than 3 files but only 3 or 6 or 9 etc will be related to the rain guage. Look at the time stamp that the .cu8 files were created and find the ones that are 49 seconds apart. This will help determine what files to expect to contain useful information.

Once you have the .cu8 files the fun begins! If this is not your kind of fun just post the files and describe exactly what you changed and what you did not change for each file or file group. Else read on and dig in.

run rtl_433 with the following command if on a Linux machine.

rtl_433 -r *.cu8  -R 0 -X "n=WAS_WH51_soil_sensor,m=FSK_PCM,s=58,l=58,t=5,r=5000,g=4000,preamble=aa2dd4" | grep len | sort

I just copied -X portion from the WH51 section of fineoffset.c in the rtl_433/src/devices folder and modified the 'name'.

I never would have guessed or figured out that -X line on my own. I only partially understand it.

It may or may not work 'correctly' for your rain guage. I don't have one to play with but it seemed like a good place to start.

With the files you provided here, that command produces the following lines of interest.

Test mode active. Reading samples from file: WH31_433.92M_250k.cu8
Test mode active. Reading samples from file: g003_433.92M_250k.cu8
Test mode active. Reading samples from file: g022_433.92M_250k.cu8
Test mode active. Reading samples from file: g026_433.92M_250k.cu8
Test mode active. Reading samples from file: g037_433.92M_250k.cu8
len       : 115
len       : 115          data      : 4000cd6f10000064f00001de00b00
len       : 115          data      : 4000cd6f10000064f00002bd00000
len       : 116          data      : 4000cd6f10000064f000027b00000
len       : 116          data      : 4000cd6f10000064f00002de00b01
len       : 116          data      : 4000cd6f1000296a1f0002f600000
len       : 144
len       : 144          data      : 30d082ce3294160000000000000000000000

We notice that there are 5 files and 5 groups of data that are similar.

Of those 5 we notice 3 columns of numbers that change every time.

Is this what we expect??? If it is we translate the 3 hex digits into binary.

1de : 0001 1101 1110
2bd : 0010 1011 1101
27b : 0010 0111 1011
2de : 0010 1101 1110
2f6 : 0010 1111 0110

I always find it useful to work in binary when working with arbitrary bit length variables, fixed width font needed though :-)

We make note that 11 out of the 12 bits changed. We consult the manual and notice manufacturer claims Rainfall measuring range: 0--6000mm.

12 bits gives us 4096 possibilities and manufacturer claims 6000. If we divide 6000 by 4096 we get ~1.46 mm(~0.06 inches) of rain for each bucket tip. I'm in the USA and 0.1 inches is how they report measureable rainfall so this might work.

To verify if our guess it correct we measure the inside diameter of the rain guage and calculate the volume of a cylinder 1.46mm tall.  3.14159 * (diameter in mm/2)^2 * 1.46 to get mm^3. Divide that by 1000 to get cm^3. cm=ml, so take that amount of water and pour it in slowly and see if you get exactly one bucket tip.

It may not be this simple. If you can listen or look for bucket tips and measure bucket size you can work it in the other direction.

The 12 bits I isolated here may be something else but they were an easy target for investigation with only 5 files.

At this point it's into fineoffset.c to look at how this other working thingy slices the bits (starting at line 514 in my copy of the file)

Hope this helps! :-)

To anyone else possibly still reading, what if anything did I do that is incorrect or needs improvement? Thx in advance.

[Christian Zuckschwerdt]

Tolip, that's nicely written information. Perhaps you could add that to https://github.com/merbanan/rtl_433/issues/1275 so it won't get lost here.

Nice find on the (bucket tip) counter field. But doesn't it go down in the third code you list? Can one of you observe the field for longer and see if it's really the bucket tip counter?

[Christian Zuckschwerdt]

For long runs of 0 (or 1) bits the PCM demod needs an accurate short/long value. Thus giving 60 instead of 58 there might result in a broken code.

I just made a major improvement to the PCM demod though, now if there is a preamble (almost mandatory for PCM) the demod will lock-on to the actual bit-width. Now you can get away with just a ball-park width.

But for good documentation the value should reflect the nominal width well. The acutal value is just the length of a bit as seen (and measured) e.g. in the sigrok-pulseview display.