Ecowitt WH51 at 915MHz decoded by Classic but not Minmax

[loopy321]

Anyone have any suggestions about getting this device (labelled "ecowitt wireless multi-channel soil moisture sensor model no: WH51" to decode? I saw that the device might decode with the following https://github.com/merbanan/rtl_433/blob/master/src/devices/fineoffset.c

But, the one I have does not. I have sampled what I believe are the "unknown" signals (6) as attached here:

wh51decode.out.txt

If you have any suggestions for how to decode, please let me know.
Thanks!

[gdt]

I got 2 of these (same part number) in late September, and they worked fine with rtl_433, the same as one that I got in probably June 2020. They report every minute and the values make sense. (I will not say they are calibrated.)

Beware that the frequency offset of lesser dongles is significant. I found that to get reliable decodes (of this or something else from ecowitt, perhaps outdoor PM2.5?), I had to adjust the frequency offset, as in -p -73. This is not a complaint about ecowitt; with a Blog v3 or a Smart v5 dongle, I didn't need an offset. The frequencies look perhaps near the edge of the passband; it's hard to tell.

My advice is look at output of everything else, and see what the freq or freq1/freq2 is, compared to nominal, even if it's at 433.92. Then figure out the -p to make it right, and then listen at 915. Also get closer if you can. My other advice is, if you can, get a Blog v3 with the dipole kit. The Blog v3 and Smart v5 are pretty much equal but the dipole kit vs the mini mag mount is way better. I don't remember where the edges were, but this process took me from missing a lot of decodes to reliable.

[gdt]

also your rtl_433 version is strange; I can't find the SHA1 in the commit history, but it looks like 9 commits before current master. This worked in 2020, so you shouldn't need super recent, but always better to be up to date.

[loopy321]

@gdt thanks for the suggestions. I am getting good SN ratios with lots of devices at ~ 914MHz and scanned up and down with -f 910-920MHz without little improvement. So it makes me think I have a good center freq. How did you arrive at your -p -73 ? Was it comparing expected vs. max rtl_433 SN?

Maybe there is a good external calibration standard?

[gdt]

Proper calibratiion is hard; you'd need real test equipment and need to know how to use it. No, I didn't pay attention to SNR when doing frequency. What I did was write a python program that would graph the freq1/freq2 or just freq vs time and plot it in xplot, and then capture a bunch of sources. I found that with high-quality dongles (SmarTEE v2, Smart v5, Blog v3), that most sources were very close to nominal frequencies. And the good dongles were 1-2 ppm different from each other. I then looked at the same sources with two older NooElec dongles, and they were -73 and -51 for the -p argument to move the frequency output to match. Doing this right requires a calibrated signal generator to make something at 915 MHz exactly and then measure that. But things like that are expensive, and no I don't have one either. It should be possible with ham-type equipment to figure out a cal scheme, but I don't think it's easy, even for someone with a formal background in RF.

SNR and frequency are separate. If you are getting one tone and not the other, the one you are getting could be poor SNR but no decodes. And -8 is ok, but I tend to see signals at -0.5 and noise at -28. Hard to tell until you figure it out.

[gdt]

See the mailinglist archives. I sent a long note on October 2, 2022.

[loopy321]

Thanks for the reply! I might need to upgrade my dongle... Mine is a "TerraTec Cinergy T Stick+" that I picked up ~10 years ago. It works amazingly well for picking up most things, so could also be a problem with the transmitting device. I'll take a look at your Oct 22 post.

[gdt]

Link to calibration post: https://groups.google.com/g/rtl_433/c/xg7f7haSE8I

[loopy321]

I tried following the decoding in the fineoffset.c using: rtl_433 -f 915000155 -X "n=soil_sensor,m=FSK_PCM,s=58,l=58,t=5,r=5000,g=4000,preamble=aa2dd4" and was able to get some data which looked a little strange. I get the FAM=51, but not consistently. and the ID does not line up. Any ideas if I am looking at noise or is there a different decoding structure here?

According to the source file it should look like:

Data format:
                   00 01 02 03 04 05 06 07 08 09 10 11 12 13
    aa aa aa 2d d4 51 00 6b 58 6e 7f 24 f8 d2 ff ff ff 3c 28 8
                   FF II II II TB YY MM ZA AA XX XX XX CC SS
- Sync:     aa aa aa ...
- Preamble: 2d d4
- FF:       Family code 0x51 (ECOWITT/FineOffset WH51)
- IIIIII:   ID (3 bytes)
- T:        Transmission period boost: highest 3 bits set to 111 on moisture change and decremented each transmission;
-           if T = 0 period is 70 sec, if T > 0 period is 10 sec
- B:        Battery voltage: lowest 5 bits are battery voltage * 10 (e.g. 0x0c = 12 = 1.2V). Transmitter works down to 0.7V (0x07)
- YY:       ? Fixed: 0x7f
- MM:       Moisture percentage 0%-100% (0x00-0x64) MM = (AD - 70) / (450 - 70)
- Z:        ? Fixed: leftmost 7 bit 1111 100
- AAA:      9 bit AD value MSB byte[07] & 0x01, LSB byte[08]
- XXXXXX:   ? Fixed: 0xff 0xff 0xff
- CC:       CRC of the preceding 12 bytes (Polynomial 0x31, Initial value 0x00, Input not reflected, Result not reflected)
- SS:       Sum of the preceding 13 bytes % 256

[gdt]

Can you bring the sensor and the dongle to be only 2m apart? I still think you may be having weak signals and It's good to exclude that. Nobody else has reported that ecowitt has a new format -- but they could. Also calibrate first before proceeding.

[loopy321]

They are about <2m apart. I tried doing calibration with kalibrate-rtl and rtl_test -p but didn’t get a sensible result.

On Sun, Nov 13, 2022 at 10:09 AM Greg Troxel @.***> wrote:

Can you bring the sensor and the dongle to be only 2m apart? I still think you may be having weak signals and It's good to exclude that. Nobody else has reported that ecowitt has a new format -- but they could. Also calibrate first before proceeding.

— Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/2235#issuecomment-1312765753, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2SKKQXFPKFDADGN6DDS3WIEHB7ANCNFSM6AAAAAAR6P2US4 . You are receiving this because you authored the thread.Message ID: @.***>

[gdt]

Ah, well then I don't really know what to say. You might try to calibrate with other sources that work.

[loopy321]

Of the 10 different devices I am decoding properly, all of them are ASK. This will be my first FSK device. Perhaps FSK requires a more stable frequency in the receiver?

[zuckschwerdt]

Can you grab sample and post as zip here? Noise, errors and position in the band will be visible there. https://triq.org/rtl_433/ANALYZE.html

[loopy321]

I have discovered that the decoding does work when I do analysis on the .cu8 files. i.e. :

model     : Fineoffset-WH51                        ID        : 0d1147
Battery level: 1.000     Battery   : 1600 mV       Moisture  : 0 %           Transmission boost: 0     AD raw    : 45            Integrity : CRC

But when running rtl_433 -S all -f 915000155 -X "n=soil_sensor,m=FSK_PCM,s=58,l=58,t=5,r=5000,g=4000,preamble=aa2dd4" , all I see is:

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2022-11-13 11:33:38
model     : soil_sensor  count     : 1             num_rows  : 1             rows      :
len       : 113          data      : 2030147107f00f05bfffff89bd010
codes     : {113}2030147107f00f05bfffff89bd010

See zip file with two samples: WH51_analysis.zip

[zuckschwerdt]

For some reason the minmax demod, default for 868M and above, does not work well here. The reason analysis works is the different default of classic there. E.g. try: rtl_433 -f 915M g178_915M_1000k.cu8 vs. rtl_433 g178_915M_1000k.cu8 To use the older demod with -f 915M add -Y classic

[loopy321]

Awesome, Thanks! That did it. Get reasonable decoding with rtl_433 -f 915000155 -Y classic :

time      : 2022-11-13 12:35:28
model     : Fineoffset-WH51                        ID        : 0d1147
Battery level: 1.000     Battery   : 1600 mV       Moisture  : 0 %           Transmission boost: 0     AD raw    : 46            Integrity : CRC
...
time      : 2022-11-13 12:37:48
model     : Fineoffset-WH51                        ID        : 0d1147
Battery level: 1.000     Battery   : 1600 mV       Moisture  : 0 %           Transmission boost: 0     AD raw    : 46            Integrity : CRC

and wet:

time      : 2022-11-13 12:41:18
model     : Fineoffset-WH51                        ID        : 0d1147
Battery level: 1.000     Battery   : 1600 mV       Moisture  : 97 %          Transmission boost: 7     AD raw    : 426           Integrity : CRC

Is there an easy way to incorporate this into the decoder? Or just run w classic?

[zuckschwerdt]

The demod (technically a discriminator -- decides 0/1 state in the signal) is global. There are ideas to run both parallel and use the "better" output or let decoders choose, but that won't happen soon.

[loopy321]

Thanks for helping figure this out. Made a pull: https://github.com/merbanan/rtl_433/pull/2236 in case that helps.

[gdt]

I looked at my invocations, and found

# units
UNITS="-C si"

# RF stats
STAT_RF="-M level -M noise -M stats"

# proto stats
STAT_PROTO="-M protocol -M bits"

# low levels
LEVEL="-Y autolevel -Y minlevel=-30 -Y magest"

OPTS="$UNITS $STAT_RF $STAT_PROTO $LEVEL"

but, I am getting extremely clean signals.

[loopy321]

@gdt thanks! I tried your invocations and found many more decoded signals than I usually do, however, without the -Y classic I do not see the WH51. I have ordered a new dongle, the Blog V3, and will test with that too to see if there is any difference.

[zuckschwerdt]

I wouldn't necessarily say that classic works better with this sensor, I think it's distortion in the signal that breaks minmax. We should look into that, maybe @merbanan can figure it out.

[loopy321]

Please let me know if there is any more distorted data I can provide :)

[loopy321]

Tested with a new Blog V3 receiver and can confirm that the WH51 is decoded without the -Y classic option.

As a side note, I was disappointed that the SNR and reception was not better @433.92MHz with the new Blog V3 device: Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T with the Rafael Micro R820T tuner reports: SNR : 24.1 dB Noise : -24.2 dB vs. the older Bus 001 Device 004: ID 0ccd:00d7 TerraTec Electronic GmbH with the Elonics E4000 tuner reports receiving the same signal: SNR : 40.8 dB Noise : -42.1 dB

Antennae are same length and right next to each other (~20cm apart).

[gdt]

My opinion is that the noise measurements and AGC behavior are complicated, and I don't at the moment really believe them. The real test is decodes. I would suggest that you run with each for a while and look at decode rates of distant, near-the-edge emitters. For me, the Blog v3 and Smart v5 were about the same, vastly better than the mini/mini2. Your older one might be great - I have no idea of course. But super high SNR values for strong signals does not mean that much IMHO.

I will try to clean up my analysis code enough to check it in. It takes a json output stream and turns it into xplot format, and that made the differences among receivers and antennas really clear.

[gdt]

I think this PR has run its course and can be closed.

[gdt]

I'm calling this a dup of #2645 and #1264 Thanks for the discussion; this has crystallized out two specific things to work on.