Open kami83 opened 3 months ago
zuckschwerdt
commented
3 months ago Do you already own the sensor? Otherwise if you are deciding to buy or not: Newer Bresser protocols all show roughly the same structure and it shouldn't be a problem to analyze and add more.
kami83
commented
3 months ago Yes i bought it.do you think it is 868 or 433?
zuckschwerdt
commented
3 months ago Newer sensors are FSK, and FSK is likely to be on 868. I only have older 433 (OOK) sensors.
ProfBoc75
commented
3 months ago Hi, it's 433.92 Mhz, page 24 : User Guide
kami83
commented
3 months ago Ohh thats good. I should be nearly the same sensor then this:
https://github.com/merbanan/rtl_433/issues/1781
Can someone help me to write a decoder for this?
Thx a lot.
BR kami
zuckschwerdt
commented
3 months ago Get a good sample to find and verify timings. https://triq.org/rtl_433/ANALYZE.html Then we'll need to get a number of codes and check those. Writing (or modifying) a decoder is easy then ;)
kami83
commented
3 months ago Hmm okay i will try. But it is not so easy to get a sample. There are just to much other different messages.
i will try.
BR kami
zuckschwerdt
commented
3 months ago It usually helps to remove the antenna and place the device and receiver at maybe 20cm to each other.
ProfBoc75
commented
3 months ago May I propose to run rtl_433 in verbose mode for only the existing Bresser decoders to speed up the analysis.
rtl_433 -R 52:vv -R 119:vv -R 172:vv -R 173:vv -R 247:vv -R 249:vv -M protocol -M levelIf we are lucky, you may have some message that could help us to focus on a specific decoder.
Notice that, except model 52, all are based on FSK PCM with s = l = 124 µs , preamble=0xaa2dd4, so a flex decoder like this one could help also (my assumption that this soil sensor uses the same rf coding) :
rtl_433 -X "n=Bresser_soil,m=FSK_PCM,s=124,l=124,r=25000,preamble=aa2dd4"Hi, first of all, thanks a lot for the good and fast help. But i think my sensor is broken and i think i will get a new one next week. So until i recieved the new one i have to wait.
BR kami
kami83
commented
2 months ago Hi, so i know find out that the sensor is working fine. If i make a reset i can get new values and can see the new values on my weather station. If i remove the antenna from my rtl-sdr i am not recieving anything. So it could be that i recieve more then only the Bresser. But i now made 5 examples with : rtl_433 -f 433.92M -S unknown (The other commands are not working).
Here is the list of values, which should be in the files.
g026_433.92M_250k - Humidity 0% - Temp 28,7°C g035_433.92M_250k - Humidity 100% - Temp 31,1°C g040_433.92M_250k - Humidity 98% - Temp 33,0°C g043_433.92M_250k - Humidity 0% - Temp 32,7°C g046_433.92M_250k - Humidity 91% - Temp 32,7°C
It would be really great if you can help me to decode the messages. If i can give you more information if you need them. I also got no a second Bresser soil moisture sensor.
Thanks a lot.
BR kami Samples.zip
zuckschwerdt
commented
2 months ago Here is what I got, the transmission looks like this: 3 OOK packets of each PPM with (nominal) 1000 µs pulses, 13x 4000 µs sync gaps, then 88x 2000 µs / 1000 µs data gaps. And then 734 ms trailing pulse.
This will read the data rtl_433 -R 0 -X 'n=name,m=OOK_PPM,s=1000,l=2000,y=4000,r=5000'
but note that the long pulse between packets isn't processed and thus all three packets are joined into one long code.
Also the sync preamble seems to be included in the codes?
E.g. here the codes are:
{303}fffd2b610168a0405838c7ffe7ffe95b080b850202c1c60021ffff4ad8405e2810160e30035c
{303}fffd2b610160b8405838c00b9fffe95b080b45c202c1c60096bfff4ad8405c2e10160e300642
{303}fffd2b61015148406038c094bfffe95b080aca420301c604efbfff4ad840585210180e3028c2
{303}fffd2b61015150406038c0998fffe95b080aca820301c605063fff4ad840585410180e302b8e
{303}fffd2b61015960406038c0b29fffe95b080b0b020301c605e33fff4ad8405a5810180e30314awhich broken apart (roughly at the fff) is
ffd2b610168a0405838c70
ffd2b610170a0405838c0042
ffd2b610178a0405838c00d700
ffd2b610160b8405838c00b9
ffd2b610168b8405838c012d60
ffd2b610170b8405838c019080
ffd2b61015148406038c094b
ffd2b61015948406038c09df60
ffd2b61016148406038c0a3080
ffd2b61015150406038c0998
ffd2b61015950406038c0a0c60
ffd2b61016150406038c0ae380
ffd2b61015960406038c0b29
ffd2b61016160406038c0bc660
ffd2b61016960406038c0c5280Hi , I reduced the reset and I got this:
rtl_433 -X "n=Bresser_soil,m=OOK_PPM,s=1000,l=2000,r=3000" *.cu8 2>&1 | grep codes
codes : {88}a56c202d14080b0718fffc
codes : {88}a56c202e14080b07180087
codes : {88}a56c202f14080b071801ae
codes : {88}a56c202c17080b07180173
codes : {88}a56c202d17080b0718025a
codes : {88}a56c202e17080b07180321
codes : {88}a56c202a29080c07181297
codes : {88}a56c202b29080c071813be
codes : {88}a56c202c29080c07181461
codes : {88}a56c202a2a080c07181331
codes : {88}a56c202b2a080c07181418
codes : {88}a56c202c2a080c071815c7
codes : {88}a56c202b2c080c07181653
codes : {88}a56c202c2c080c0718178c
codes : {88}a56c202d2c080c071818a5We have 3 messages into a frame. Not yet found CRC formula, last byte look like the CRC or CHECKSUM and the byte just before is an incremental counter.
zuckschwerdt
commented
2 months ago Oh, very good! revdgst shows that there is addition with carry excluding the first and last byte. I.e.
add_bytes(&b[1], 8) - b[9] == 0;
Not sure what the last byte is, should be something like a CRC, yes.
ProfBoc75
commented
2 months ago incremental counter in the middle also , 2d 2e 2f , 2c 2d 2e ,
CHECKSUM is:
Done with g 83 k 34 final XOR a3 using xor xor (100 %) Time elapsed in s: 0.06 for: Galois BIT_REFLECT
zuckschwerdt
commented
2 months ago Yes! Or again skipping the a5 we get a clean Done with g 83 k bf final XOR 00 using xor xor (100 %)
zuckschwerdt
commented
2 months ago With your data in a BitBench it's just strange that the transmissions all look nearly the same, no clear indication where temp or moisture are.
You might need a longer run with @ProfBoc75 's decoder (rtl_433 -X "n=Bresser_soil,m=OOK_PPM,s=1000,l=2000,r=3000") and collect a day of codes to see a progression somewhere in the data.
kami83
commented
2 months ago Hi, okay i just started it now for some hours. I will send the logfile later. BR kami
kami83
commented
2 months ago Hi, first of all thanks a lot to you both for the fast and good help. So here is a sample file from the last 5 hours. Hope this helps. Otherwise tell me, what i can do.
BR kami Bresser.zip
ProfBoc75
commented
2 months ago Hi @kami83 , unfortunately it did not contain expected information, may be too far from the sensor ? Check your antenna. Notice that such sensor inserted into the ground in the garden for example, have a shorter transmission distance, you must be less 30 or 20 m (free air).
Try this:
rtl_433 -X "n=Bresser_soil,m=OOK_PPM,s=1000,l=2000,r=3500,bits>=88" -F json -s 1024kTry also to capture some samples as you did , and you can replay them with the flex decoder to check which ones give answers
As you did to capture (by default it's 433.92M, you don't need to provide the frequency) -s 1024k to get larger a sample rate:
rtl_433 -S unknown -s 1024kTo replay (one or all):
rtl_433 -X "n=Bresser_soil,m=OOK_PPM,s=1000,l=2000,r=3500,bits>=88" -r g001_433.92M_1024k.cu8
rtl_433 -X "n=Bresser_soil,m=OOK_PPM,s=1000,l=2000,r=3500,bits>=88" -r *.cu8Hi @kami83 , unfortunately it did not contain expected information, may be too far from the sensor ? Check your antenna. Notice that such sensor inserted into the ground in the garden for example, have a shorter transmission distance, you must be less 30 or 20 m (free air).
Try this:
rtl_433 -X "n=Bresser_soil,m=OOK_PPM,s=1000,l=2000,r=3500,bits>=88" -F json -s 1024kTry also to capture some samples as you did , and you can replay them with the flex decoder to check which ones give answers
As you did to capture (by default it's 433.92M, you don't need to provide the frequency) -s 1024k to get larger a sample rate:
rtl_433 -S unknown -s 1024kTo replay (one or all):
rtl_433 -X "n=Bresser_soil,m=OOK_PPM,s=1000,l=2000,r=3500,bits>=88" -r g001_433.92M_1024k.cu8 rtl_433 -X "n=Bresser_soil,m=OOK_PPM,s=1000,l=2000,r=3500,bits>=88" -r *.cu8
Hi @ProfBoc75 thanks a lot for the good help. Here are some more informations from me. First of all my rtl-sdr, the soil sensor and the station are on the same table. I think there is no distance problem. I also got a Bresser 3channel Temp/Hum outdoor Sensor for the same base. (https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_3ch.c) I am recieving this values with the bresser station and with the rtl-sdr device. Is it possible that the soil sensor using nearly the same (s,l,r values).
I started this morning now with collecting samples with the first command and then will go on with the other tests.
Temporaly i think the sensor is sending not in the area we are looking at?
Thx a lot.
BR kami
ProfBoc75
commented
2 months ago hi @kami83: I think so, if you have other sensors using the same base station, then the protocol should be very close or the same, and your previous captures were related to another sensor which could explain why we can't figure the temp and moisture values.
bitbench from rtl_433_test Bresser 3 CH samples:
ID ~8d BAT_OK 1b TEST ~1b CH ~2h TEMP_F_OFFSET_NINE_HUNDRED ~12d HUM ~8d CHECKSUM ~8h 1xAnd from Bresser 3 CH decoder, we can build this flex decoder:
rtl_433 -X "n=Bresser_3CH,m=OOK_PWM,s=250,l=500,r=1250,sync=750,g=625,bits>=40,invert"Because there is sanity checks into the decoder, the moisture values may be dropped, the flex decoder could help us to figure where.
kami83
commented
2 months ago Hi, @ProfBoc75 i will try this from your last post right now. But first of all here are the result from the post.
The flex decoder with the 5 old cu8 files is not working. In this new files recorded with "rtl_433 -S unknown -s 1024k" should be 5 messages to the station.
And here is the JSON recording. But i think all of this cannot help us???
BR kami
kami83
commented
2 months ago Hi,
so i tested it now. The cmd:
rtl_433 -X "n=Bresser_3CH,m=OOK_PWM,s=250,l=500,r=1250,sync=750,g=625,bits>=40,invert"
just gives the right output for the Bresser 3ch but only this error sometimes for the Bresser soil meter.
bitbuffer_add_bit: Warning: row count limit (50 rows) reached
i also tested with the flexdecoder the sending of the g002_433.92M_1024k.cu8 file but the station doesnt react.
Could it be that the sensor is in another range? 868??? I dont know.
BR kami
ProfBoc75
commented
2 months ago bitbuffer_add_bit: Warning: row count limit (50 rows) reached
It's linked to interference when lot of noise, see https://github.com/merbanan/rtl_433/issues/1854, it's just a warning but could be an antenna issue too which must be as far as possible from noise source like the PC or external screen. Same, better to use a 50cm/1m extension USB cable to put the dongle far from the PC, i.e. far from rf noise.
About the frequency, from the user guide of your moisture sensor it's 433.92 Mhz, may be you have the same written information on the sensor battery compartment cover
From user guide, the moisture sensor transmits every 8 minutes, so you have to check that from the base station, the exact update frequency (more or less every 480 secondes) , but you have also the test button (when buttons are at the bottom, the right button if for test, the left is on/off for water timer valve).
So start recording the signal, without antenna:
rtl_433 -S all -s 1024kThen press the test button, must initiate a transmit (I hope so), and you should have a sample. If not, try at 868M and/or wait for next 8 minutes.
-S all to capture all rf signals including known signals, this can help also, but you may have lot of files.
Then try to replay / play with flex.
kami83
commented
2 months ago bitbuffer_add_bit: Warning: row count limit (50 rows) reached
It's linked to interference when lot of noise, see #1854, it's just a warning but could be an antenna issue too which must be as far as possible from noise source like the PC or external screen. Same, better to use a 50cm/1m extension USB cable to put the dongle far from the PC, i.e. far from rf noise.
About the frequency, from the user guide of your moisture sensor it's 433.92 Mhz, may be you have the same written information on the sensor battery compartment cover
From user guide, the moisture sensor transmits every 8 minutes, so you have to check that from the base station, the exact update frequency (more or less every 480 secondes) , but you have also the test button (when buttons are at the bottom, the right button if for test, the left is on/off for water timer valve).
So start recording the signal, without antenna:
rtl_433 -S all -s 1024kThen press the test button, must initiate a transmit (I hope so), and you should have a sample. If not, try at 868M and/or wait for next 8 minutes.
-S allto capture all rf signals including known signals, this can help also, but you may have lot of files.Then try to replay / play with flex.
Hi, so i tested it today. I now used a 1,5m USB Cable extender to bring the rtl-sdr more away from my PC an Monitor.
I take a look at the recievings of the station and if i press the test but i get directly new values. So this is working. If i just wait and take look when the station gets new values it is different, because sometimes it takes 6-8 minutes and sometimes for example if i touch the sensor and change the temperature the station gets new values after 1-2 minutes. But i can say if i press the test-button i always get directly new values. So for this i made some samples with rtl_433 -S all -s 1024k and they include ~5-6 new values which are recieved by the station. Newsamples.zip
But if i run
rtl_433 -X "n=Bresser_soil,m=OOK_PPM,s=1000,l=2000,r=3500,bits>=88" -r *.cu8
I cannot see any changes on the station.
i made all this samples without an antenna and with a distance of 10cm between Sensor and RTL-SDR.
BR kami
ProfBoc75
commented
2 months ago Hi @kami83: g004, 6 and 7 are promising (same kind of signal), g003 and 5 not good, not same signal, some noise.
I'm checking and back soon.
ProfBoc75
commented
2 months ago Unfortunately , I'm lost, the 3 promising codes look too complex, too long signal for such "simple" device or I'm wrong ... rf signal is not the same, far from expected Bresser protocol.
rtl_433 -X "n=Bresser_soil,m=OOK_PCM,s=45,l=45,r=5500" *.cu8 | grep codes
codes : {745}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaf3e9105e51881600011f0500470d03070509880085000300000000000000000000000000b18a0000000000000000000000000000000
codes : {746}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaf3e9105e51881600011f0500470f03070509880085f302000000000000000000000000004e5d0000000000000000000000000000000
codes : {746}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaf3e9105e51881600011f0500471103070509880085f30200000000000000000000000000280b0000000000000000000000000000000For the captures without antenna, 10 cm could be too close, around 1m is nice and avoid clipping.
Just to give us some information to help decode, what is your system (Windows/Linux/VM) , your dongle model and your rtl_433 version ?
Some dongle models are not good (with FC00xx tuner), and rtl_433 default version for linux is too old for example, a more recent should be used. It's just to exclude any root cause.
kami83
commented
2 months ago Hi, so i now put it in a distance from 1m and for pressing the test button 4 times i get this for samples:
Also here is my Linux system:
Linux 6.6.9-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.6.9-1kali1 (2024-01-08) x86_64 GNU/Linux
and my rtl_433 version with the SDR device:
`rtl_433 version 23.11 (2023-11-28) inputs file rtl_tcp RTL-SDR SoapySDR
[Protocols] Registered 216 out of 250 device decoding protocols [ 1-4 8 10-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-232 234-241 243-244 246-247 249-250 ] [Input] The internals of input handling changed, read about and report problems on PR #1978 [SDR] Found 1 device(s) [SDR] trying device 0: RTLSDRBlog, Blog V4, SN: 00000001 Detached kernel driver Found Rafael Micro R828D tuner RTL-SDR Blog V4 Detected [SDR] Using device 0: RTLSDRBlog, Blog V4, SN: 00000001, "Generic RTL2832U OEM" Exact sample rate is: 250000.000414 Hz [SDR] Sample rate set to 250000 S/s. [Input] Bit detection level set to 0.0 (Auto). [SDR] Tuner gain set to Auto. [Input] Reading samples in async mode... [SDR] Tuned to 433.920MHz. Allocating 15 zero-copy buffers [Baseband] low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us`
Thx a lot and have a nice day.
BR kami
ProfBoc75
commented
2 months ago Hi @kami83:
Ok, thanks, the new samples are same as previous promising, but very strange, now decode with FSK_PCM instead of OOK_PCM.
It's not easy to capture good samples, so the previous one, g004/6 & 7 are the best ones, the last g009 and after are too low.
Your dongle is the RTL-SDR last V4 version, using the good tuner R828D, you need to take care about this version, especially with the library, look here https://github.com/merbanan/rtl_433/issues/2706 and here https://github.com/merbanan/rtl_433/issues/2703
And look at the readme here https://github.com/merbanan/rtl_433?tab=readme-ov-file#troubleshooting
kami83
commented
2 months ago Hi @ProfBoc75:
i have got another older RTL-SDR this one:
rtl_433 version 23.11 (2023-11-28) inputs file rtl_tcp RTL-SDR SoapySDR [Protocols] Registered 216 out of 250 device decoding protocols [ 1-4 8 10-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-232 234-241 243-244 246-247 249-250 ] [Input] The internals of input handling changed, read about and report problems on PR #1978 [SDR] Found 1 device(s) [SDR] trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001 Detached kernel driver Found Rafael Micro R820T tuner [SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM" Exact sample rate is: 250000.000414 Hz [R82XX] PLL not locked! [SDR] Sample rate set to 250000 S/s. [Input] Bit detection level set to 0.0 (Auto). [SDR] Tuner gain set to Auto. [Input] Reading samples in async mode... [SDR] Tuned to 433.920MHz. Allocating 15 zero-copy buffers [Baseband] low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us ^[[A^CSignal caught, exiting! Reattached kernel driver
I made some samples with this one:
Does this looks better? What else can i do?
BR kami
ProfBoc75
commented
2 months ago I did not yet finish to analyze your last samples, but I noticed this sensor "Hideki-TS04" in your log / json file, also into last g016 & g017 files. It looks like compatible with Bresser 5CH weather station, did you see this sensor before ? It could be your moisture sensor. This could also explain why you're not able to capture since it's known device.
Edit: yes, they look better, stronger signal.
kami83
commented
2 months ago Hi, i just tested it right now. I saw it before and it is a little bit far away from my rtl-sdr, but i think its another sensor. I just moved it really far away and make new sample. This three samples are all created directly after pressing the test but and now without antenna there is also nothing in the near distance of the rtl-sdr. Hope you find something in this samples:
BR kami
ProfBoc75
commented
2 months ago So, with your last samples and other previous samples, we have data with this flex:
rtl_433 -X "n=Bresser_soil_test_button,m=FSK_PCM,s=50,l=50,r=20000,bits>=40"We have also data with the g004/6/7 with the same flex decoder but OOK_PCM, probably because the signal was too low. Since most of the other samples it's FSK_PCM, I guess we should keep it and try to get the data layout.
Some results: (short 626 = FSK_PCM, long 823 = OOK_PCM)
codes : {823}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaf3e9105e51881600011f0500470d03070509880085000300000000000000000000000000b18a00000000000000000000000000000000000000000000000000
codes : {824}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaf3e9105e51881600011f0500470f03070509880085f302000000000000000000000000004e5d00000000000000000000000000000000000000000000000000
codes : {824}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaf3e9105e51881600011f0500471103070509880085f30200000000000000000000000000280b00000000000000000000000000000000000000000000000000
codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b0000824180800000000000000000000000000000000000000049690
codes : {626}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaf3e9105e511f050047881600010583010000000000000000000000000000000000000000f7d90
codes : {626}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaf3e9105e511f05004788160001068301000000000000000000000000000000000000000058c40
codes : {626}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaf3e9105e511f0500478816000107830100000000000000000000000000000000000000003dcf0
codes : {823}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaf3e9105e51881600011f0500470903070509880085750300000000000000000000000000f95e00000000000000000000000000000000000000000000000000
codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000083418080000000000000000000000000000000000000002c620
codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000083c18080000000000000000000000000000000000000001ee78
codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b0000844180800000000000000000000000000000000000000007720
codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000084c180800000000000000000000000000000000000000035f78
codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b0000854180800000000000000000000000000000000000000062790
codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000084c180800000000000000000000000000000000000000035f78
codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b0000854180800000000000000000000000000000000000000062790
codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000085c180800000000000000000000000000000000000000050fc8I will start a bitbench with this result. At your level, try again with my last flex decoder (fsk) and note the temp/humidity values reported on the station base. This will help to find the data layout.
Notice that it's normal to get 555555 or aaaaaa it's just 1 bit shift, with a preamble (to be found too) we can aligne the final data with bitbench it's easy.
kami83
commented
2 months ago Hi, i am sorry but if i test it with your new flex decoder i get no files or output.
There should be something wrong.
BR kami
ProfBoc75
commented
2 months ago And with:
rtl_433 -X "n=Bresser_soil_test_button,m=OOK_PCM,s=50,l=50,r=20000,bits>=40"Hi, same problem but strange output after a long while of waiting.
ProfBoc75
commented
2 months ago Try with max bits 1000:
rtl_433 -X "n=Bresser_soil_test_button,m=OOK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000"
rtl_433 -X "n=Bresser_soil_test_button,m=FSK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000"This will reduce such results. It's normal if you received another signal ook pcm but with a much biger pulse width and multiple of 50 micro seconds. The ffffffff..... is 1 and 00000000.... is 0 and at transition between 1 to 0 or 0 to 1 you have some other values.
kami83
commented
2 months ago Okay thanks. But also nothing with this both commands.
kami83
commented
2 months ago But i directly recieve something with:
rtl_433 -S all -s 1024k
if i press the test button: Saving signal to file g035_433.92M_1024k.cu8 (64877 samples, 131072 bytes) Saving signal to file g036_433.92M_1024k.cu8 (64876 samples, 131072 bytes)
ProfBoc75
commented
2 months ago Try:
rtl_433 -A g035_433.92M_1024k.cu8
rtl_433 -A g036_433.92M_1024k.cu8You should have the pulse width details
Try also to replay
rtl_433 -X "n=Bresser_soil_test_button,m=OOK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000" g036_433.92M_1024k.cu8
rtl_433 -X "n=Bresser_soil_test_button,m=FSK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000" g036_433.92M_1024k.cu8with all commands and with this one nothing happens on the station:
rtl_433 -X "n=Bresser_soil_test_button,m=OOK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000" g035_433.92M_1024k.cu8 rtl_433 -X "n=Bresser_soil_test_button,m=FSK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000" g035_433.92M_1024k.cu8
ProfBoc75
commented
2 months ago At least the -A should answer something since the file was created because of pulses. I had result using your file from withoutts04.zip, the g022 file:
rtl_433 -A g022_433.92M_1024k.cu8
rtl_433 version 23.11-134-gb74a6e4b branch feat-thermopro_tp829b at 202406211910 inputs file rtl_tcp RTL-SDR SoapySDR with TLS
[Input] Test mode active. Reading samples from file: g022_433.92M_1024k.cu8
Detected FSK package @0.016643s
Analyzing pulses...
Total count: 189, width: 31.36 ms (32110 S)
Pulse width distribution:
[ 0] count: 1, width: 0 us [0;0] ( 0 S)
[ 1] count: 176, width: 49 us [49;51] ( 50 S)
[ 2] count: 4, width: 199 us [199;200] ( 204 S)
[ 3] count: 3, width: 250 us [250;250] ( 256 S)
[ 4] count: 4, width: 100 us [100;100] ( 102 S)
[ 5] count: 1, width: 6 us [6;6] ( 6 S)
Gap width distribution:
[ 0] count: 169, width: 50 us [44;52] ( 51 S)
[ 1] count: 5, width: 101 us [100;105] ( 103 S)
[ 2] count: 5, width: 149 us [149;150] ( 153 S)
[ 3] count: 4, width: 263 us [250;300] ( 269 S)
[ 4] count: 1, width: 451 us [451;451] ( 462 S)
[ 5] count: 1, width: 800 us [800;800] ( 819 S)
[ 6] count: 1, width: 200 us [200;200] ( 205 S)
[ 7] count: 1, width: 351 us [351;351] ( 359 S)
[ 8] count: 1, width: 8052 us [8052;8052] (8245 S)
Pulse period distribution:
[ 0] count: 1, width: 44 us [44;44] ( 45 S)
[ 1] count: 165, width: 100 us [99;102] ( 102 S)
[ 2] count: 9, width: 316 us [300;351] ( 324 S)
[ 3] count: 3, width: 149 us [149;150] ( 153 S)
[ 4] count: 4, width: 199 us [199;200] ( 204 S)
[ 5] count: 3, width: 483 us [450;500] ( 495 S)
[ 6] count: 1, width: 899 us [899;899] ( 921 S)
[ 7] count: 1, width: 250 us [250;250] ( 256 S)
[ 8] count: 1, width: 8102 us [8102;8102] (8296 S)
Pulse timing distribution:
[ 0] count: 1, width: 0 us [0;0] ( 0 S)
[ 1] count: 345, width: 50 us [44;52] ( 51 S)
[ 2] count: 5, width: 199 us [199;200] ( 204 S)
[ 3] count: 7, width: 257 us [250;300] ( 263 S)
[ 4] count: 9, width: 100 us [100;105] ( 102 S)
[ 5] count: 1, width: 6 us [6;6] ( 6 S)
[ 6] count: 5, width: 149 us [149;150] ( 153 S)
[ 7] count: 1, width: 451 us [451;451] ( 462 S)
[ 8] count: 1, width: 800 us [800;800] ( 819 S)
[ 9] count: 1, width: 351 us [351;351] ( 359 S)
[10] count: 1, width: 8052 us [8052;8052] (8245 S)
[11] count: 1, width: 0 us [0;0] ( 0 S)
Level estimates [high, low]: 15860, 26
RSSI: -0.1 dB SNR: 27.9 dB Noise: -28.0 dB
Frequency offsets [F1, F2]: -15616, -24376 (-244.0 kHz, -380.9 kHz)
Guessing modulation: No clue...As you can see, I have answer, the pulse duration is clearly 50 µs.
If you drag & drop the file into pulseview, the same:
Just set Slicer = PCM, short = 50 and long = 50.
rtl_433 -X "n=Bresser_soil_test_button,m=FSK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000" g022*.cu8But, I just noticed that the frequency of the sensor is between 433.616Mhz and 433.536Mhz, so not in the default range for 433.92Mhz and sample rate 250k. You have 2 possibilities:
The last option will let you receive other sensors, where the first may exclude sensors > 433.725 Mhz.
Try this:
rtl_433 -X "n=Bresser_soil_test_button,m=FSK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000" -s 1024kor
rtl_433 -f 433.6M -X "n=Bresser_soil_test_button,m=FSK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000"Hi, thanks a lot for the long and good answer. I just tested both commands this morning and i got this result:
`rtl_433 -X "n=Bresser_soil_test_button,m=FSK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000" -s 1024k rtl_433 version 23.11 (2023-11-28) inputs file rtl_tcp RTL-SDR SoapySDR Detached kernel driver Found Rafael Micro R820T tuner [SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM" [R82XX] PLL not locked! Allocating 15 zero-copy buffers
30,8 °C 100%
time : 2024-07-17 08:19:55 model : Bresser_soil_test_button count : 1 num_rows : 1 rows : len : 627 data : 5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000084c180800000000000000000000000000000000000000035f78 codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000084c180800000000000000000000000000000000000000035f78
31,0 °C 78%
time : 2024-07-17 08:20:13 model : Bresser_soil_test_button count : 1 num_rows : 1 rows : len : 627 data : 5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b0000854180800000000000000000000000000000000000000062790 codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b0000854180800000000000000000000000000000000000000062790
30,8 °C 0%
time : 2024-07-17 08:20:29 model : Bresser_soil_test_button count : 1 num_rows : 1 rows : len : 627 data : 5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000085c180800000000000000000000000000000000000000050fc8 codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000085c180800000000000000000000000000000000000000050fc8
29,9 °C 0%
time : 2024-07-17 08:20:53 model : Bresser_soil_test_button count : 1 num_rows : 1 rows : len : 627 data : 5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b00008741808000000000000000000000000000000000000000207f8 codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b00008741808000000000000000000000000000000000000000207f8
27,1 °C 94%
time : 2024-07-17 08:22:47 model : Bresser_soil_test_button count : 1 num_rows : 1 rows : len : 627 data : 5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b0000884180800000000000000000000000000000000000000013548 codes : {627}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b0000884180800000000000000000000000000000000000000013548
rtl_433 -f 433.6M -X "n=Bresser_soil_test_button,m=FSK_PCM,s=50,l=50,r=20000,bits>=40,bits<=1000" rtl_433 version 23.11 (2023-11-28) inputs file rtl_tcp RTL-SDR SoapySDR Detached kernel driver Found Rafael Micro R820T tuner [SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM" Exact sample rate is: 250000.000414 Hz [R82XX] PLL not locked! Allocating 15 zero-copy buffers
26,0°C 15%
time : 2024-07-17 08:28:44 model : Bresser_soil_test_button count : 1 num_rows : 1 rows : len : 628 data : 5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b00008dc180800000000000000000000000000000000000000048c78 codes : {628}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b00008dc180800000000000000000000000000000000000000048c78
27,7°C 89%
time : 2024-07-17 08:29:30 model : Bresser_soil_test_button count : 1 num_rows : 1 rows : len : 628 data : 5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b00008ec18080000000000000000000000000000000000000006fca0 codes : {628}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b00008ec18080000000000000000000000000000000000000006fca0
28,7°C 74%
time : 2024-07-17 08:29:51 model : Bresser_soil_test_button count : 1 num_rows : 1 rows : len : 628 data : 5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b00008f4180800000000000000000000000000000000000000038448 codes : {628}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b00008f4180800000000000000000000000000000000000000038448
29,0°C 68%
time : 2024-07-17 08:30:06 model : Bresser_soil_test_button count : 1 num_rows : 1 rows : len : 628 data : 5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b00008fc18080000000000000000000000000000000000000000ac10 codes : {628}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b00008fc18080000000000000000000000000000000000000000ac10
29,2°C 99%
time : 2024-07-17 08:30:21 model : Bresser_soil_test_button count : 1 num_rows : 1 rows : len : 628 data : 5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000090418080000000000000000000000000000000000000003b198 codes : {628}5555555555555555555555555555555555555555555555555555555555555555555555555555555579f4882f288f828023c40b000090418080000000000000000000000000000000000000003b198 `
I think would prefer if there are no difference to stay in the standard range of 433.
BR kami
ProfBoc75
commented
2 months ago Hi @kami83:
I found something really interesting.
The 2 signals, one FSK_PCM and the other OOK_PCM are not from the same device, one is from the base, and the other from a sensor, my assumption, but confirmed by sample g019 (from older RTL r820t tuner / anothersamples.zip)
The last you shared, FSK_PCM, are answers from the base (or water valve actuator ?) to the moisture sensor, as no temp nor humidity information there, only an incremental counter.
But the other samples, the g004/06/07/019 are from the moisture sensor to the base as there is some information there.
In each message, we have the network id, the source id , the target id, a counter, a command, the message length, the message, few zeros then the CRC-16. It's very similar to another protocol I already saw for Frisquet Connect (between boiler, Frisquet Connect box and its thermostat)
My bitbench
So, the best sample, is the g019_433.92M_1024k.cu8 (anothersamples.zip), which contains the 2 signals, the OOK_PCM from moisture, then the answer in FSK_PCM !
And here also, some useful information, the OOK_PCM / Moisture is at 434.1 Mhz, where the FSK_PCM /Base is at 433.5/433.6 Mhz. So both are not centered to the same frequency, this normal to avoid conflict.
You can get more codes with preamble/sync word = 0xaaf3, and yes, 2 flex decoders on the same line it's possible:
rtl_433 -X "n=Bresser_Moisture,m=OOK_PCM,s=50,l=50,r=10000,bits>=40,bits<=1000,preamble=aaf3" -X "n=Bresser_Base,m=FSK_PCM,s=50,l=50,r=10000,bits>=40,bits<=1000,preamble=aaf3" -s 1024k -M levelThis should help to understand this bidirectional protocol. Try also with the ON/OFF left button, if I'm not wrong, the purpose is to open/close the water valve actuator, which probably have another id in the same network and probably another code for CMD data (see bitbench).
The last 2 bytes are CRC-16, poly = 0x1021 (standard), init = 0x3b6f (not standard, but depends where to start the CRC-16 calcul), with sync word F3, init = 0x74da, this can be managed, not an issue for a decoder.
EDIT: remaining is decode the info/message which contains the temp, humidity and ?? ... 7 bytes to discover.
kami83
commented
2 months ago Hi,
i think you are right there could be a communication with the water switch. But the problem is now another one. I just turned of the station and after this i pressed the Test button and then i catch NO signals. Nothing even with rtl_433 -S all -s 1024k. So i think the only messages i was recieving comes from the weather station.
:(
BR kami
ProfBoc75
commented
2 months ago Did you check / resit the battery in the sensor ? And put the antenna back on the dongle ?
kami83
commented
2 months ago Yes battery is full. I think all the recievings comes from the station.
ProfBoc75
commented
2 months ago Check other ISM Frequencies.
EDIT: And the usb cable/dongle, also, do you receive other sensors ? May be the left button if the ON/OFF of the sensor ?
kami83
commented
2 months ago Hi,
i tested now with this commands:
rtl_433 -f 433.92M -S all -s 1024k rtl_433 -f 868M -S all -s 1024k rtl_433 -f 315M -S all -s 1024k rtl_433 -f 345M -S all -s 1024k rtl_433 -f 915M -S all -s 1024k
i recieved nothing only with the 433.92M i can see directly a lot of my other Temp sensor like the Bresser 3CH. So the reciever is working.
What can i do now?
BR kami
Hi,
i would like to ask, if someone can tell me if he can decode this Bresser Sensor:
https://www.bresser.de/en/Weather-Time/BRESSER-Soil-Sensor-for-7510100-7510200-Smart-Garden-Smart-Home-Irrigation-System.html
Its nearly the same then the RainPoint Soil Sensor.
Can someone help me with this?
BR kami