New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decoding GFSK telegrams #2898
Comments
The |
Yes, I assumed rtl_433 -vvv -r g036_169.44M_2048k.cu8 -Y autolevel -M level -M noise -M bits -Y minmax -Y magest -R 0 -X "n=WMbus,m=FSK_PCM,s=11,l=11,t=8,r=500" Is anyway to set bandwidth or decimation of the receiver other than default in live reception ? I tried the -t "bw=20" option to filter the reception in 20Khz but not works [sdr_apply_settings] Unknown RTLSDR setting: bw=20
|
There is |
Hi @xjols Unfortunately, at 169.44 MHz, this is the extract of m_bus.c
Mode N is less than 50khz bandwidth, so sample rate at 1Mhz is enough with a central frequency at 169.6M Because of 4 GFSK, you may have issue with rtl_433 not handle it. |
Hello. Finally I got this unknows GFSK 2.4kbps narrow band (Mode N) in 169.44MHz decoded as telegram with the default
I don't know exacty which protocol use this signals. It not seems to have the default preamble and sync used by wmbus n-band 0x55, 0xF6, and neither Wize protocol: 0x5555 preamble and 0xF672 sync. I only see in bitbench that can be aligned by 0x998 This frequency is used by telemetry water meters in my zone. Any help with decode this will be appreciated. Thank you! |
Great find! Lots of |
The filter helps to receiver the packets and decoded now! Where I can find all the options of RTL_433? The option |
There are some experimental options which are not mentioned in the help. |
Hello!
I'm trying to decode GFSK pulse code in 169.4375MHz wmbus narrow band. Have a several captures and the demodulated outputs in RTL_433 don't seems that have a valid bits.
I tried with several options. With -A option:
The attempting decoder doen't seems that have any efect. The real symbol bit is 416us in this signal (2400bps) and Freq offsets is +-2.4KHz. Not the estimated with RTL 0.49us and (+7.5 kHz, +14.2 kHz) offsets
The same signal in URH: 004cccccc053aaaa75b48f33daa6abd4aaa8d5572aa8d567abf5249345981018
I analized 22 packets in URH and all seems to have the same preamble and sync :
How I can decode this in RTL_433 ?
Thanks you!
rtl_433_169.44375_2.zip
rtl_433_169.44_1.zip
The text was updated successfully, but these errors were encountered: