rtl_433
rtl_433 copied to clipboard
merbanan
Honeywell 5816 security contact initial sync // AGC overloading
I have a bunch of Honeywell 5800 series security contacts that decode reliably, but I have two 5816 door sensors that don't decode reliably. If the sensor within 15 ft of the rtl-sdr it doesn't decode at all. If the distance is larger than that I'll get some decodes, but it's not as reliable as the others, only some of the repeats will decode.
The analyzer (-A) isn't able to detect the pulses. Maybe it's saturating the receiver. Using -Y autolevel doesn't seem to help.
Frequency of both of the 5816 seems to be around 345.06 Mhz. I've got rtl_433 set to 345.0M. So they seem to be within range and not falling on the DC spike.
I'll attach samples. Thanks for taking a look.
rtl_433 version 21.05-111-gf30ee220 branch master at 202110220900 inputs file rtl_tcp RTL-SDR with
TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/rct/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 168 out of 198 device decoding protocols [ 1-4 8 11-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 ]
Test mode active. Reading samples from file: g070_345M_250k.cu8
baseband_demod_FM: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us
Detected OOK package @0.076016s
Analyzing pulses...
Total count: 4, width: 368.91 ms (92227 S)
Pulse width distribution:
[ 0] count: 4, width: 21732 us [21728;21736] (5433 S)
Gap width distribution:
[ 0] count: 3, width: 93992 us [93992;93996] (23498 S)
Pulse period distribution:
[ 0] count: 3, width: 115724 us [115724;115728] (28931 S)
Pulse timing distribution:
[ 0] count: 4, width: 21732 us [21728;21736] (5433 S)
[ 1] count: 4, width: 95496 us [93992;100004] (23874 S)
Level estimates [high, low]: 16049, 3704
RSSI: -0.1 dB SNR: 6.4 dB Noise: -6.5 dB
Frequency offsets [F1, F2]: 16340, 0 (+62.3 kHz, +0.0 kHz)
Guessing modulation: Un-modulated signal. Maybe a preamble...
view at https://triq.org/pdv/#AAB10254E475088181818155
Detected OOK package @1.244376s
Analyzing pulses...
Total count: 1, width: 21.73 ms ( 5433 S)
Pulse width distribution:
[ 0] count: 1, width: 21732 us [21732;21732] (5433 S)
Gap width distribution:
Pulse period distribution:
Pulse timing distribution:
[ 0] count: 1, width: 21732 us [21732;21732] (5433 S)
[ 1] count: 1, width: 100004 us [100004;100004] (25001 S)
Level estimates [high, low]: 15984, 3384
RSSI: -0.1 dB SNR: 6.7 dB Noise: -6.8 dB
Frequency offsets [F1, F2]: 17247, 0 (+65.8 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
view at https://triq.org/pdv/#AAB10254E486A48155
Detected OOK package @1.377480s
Analyzing pulses...
Total count: 1, width: 21.73 ms ( 5433 S)
Pulse width distribution:
[ 0] count: 1, width: 21732 us [21732;21732] (5433 S)
Gap width distribution:
Pulse period distribution:
Pulse timing distribution:
[ 0] count: 1, width: 21732 us [21732;21732] (5433 S)
[ 1] count: 1, width: 100004 us [100004;100004] (25001 S)
Level estimates [high, low]: 16062, 4154
RSSI: -0.1 dB SNR: 5.9 dB Noise: -6.0 dB
Frequency offsets [F1, F2]: 17937, 0 (+68.4 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
view at https://triq.org/pdv/#AAB10254E486A48155
Detected OOK package @1.510596s
Analyzing pulses...
Total count: 1, width: 21.74 ms ( 5434 S)
Pulse width distribution:
[ 0] count: 1, width: 21736 us [21736;21736] (5434 S)
Gap width distribution:
Pulse period distribution:
Pulse timing distribution:
[ 0] count: 1, width: 21736 us [21736;21736] (5434 S)
[ 1] count: 1, width: 100004 us [100004;100004] (25001 S)
Level estimates [high, low]: 15888, 2880
RSSI: -0.1 dB SNR: 7.4 dB Noise: -7.6 dB
Frequency offsets [F1, F2]: 17058, 0 (+65.1 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
view at https://triq.org/pdv/#AAB10254E886A48155
Detected OOK package @1.643704s
Analyzing pulses...
Total count: 1, width: 21.75 ms ( 5438 S)
Pulse width distribution:
[ 0] count: 1, width: 21752 us [21752;21752] (5438 S)
Gap width distribution:
Pulse period distribution:
Pulse timing distribution:
[ 0] count: 1, width: 21752 us [21752;21752] (5438 S)
[ 1] count: 1, width: 100004 us [100004;100004] (25001 S)
Level estimates [high, low]: 15449, 5065
RSSI: -0.3 dB SNR: 4.8 dB Noise: -5.1 dB
Frequency offsets [F1, F2]: 14438, 0 (+55.1 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
view at https://triq.org/pdv/#AAB10254F886A48155
This looks like PSK, not FSK. We would need samples at a higher sample rate (-s 1024k) to verify this.
This looks like PSK, not FSK. We would need samples at a higher sample rate (
-s 1024k) to verify this.
Ok I will capture and attach later today. However, I think FSK would be pretty surprising:
- the 5816 is an older member of the Honeywell 5800 series of contacts and can be used with the same alarm system receivers.
- This contact can be decoded if I move it far enough away from the rtlsdr.
Could be due to the low samplerate, but it looks like a solid carrier. And there are two side frequencies which don't look like aliasing, the changes switch the phase by 180 deg, best I could see.
(Side note: When I first tried 1024k sample rate, a sensor that is reliably decoded at the default sample rate no longer decoded. reliably. While scratching my head, I noticed the noise level was now -3 dB... So there was some noise I didn't pick up at 250K but did pick up with the wider bandwidth.)
Here's 4 recordings at 1024K. 2 for a 5800mini that decode just fine 2 for a 5816 that doesn't decode
rtl_433 version 21.12-78-gf380976d branch master at 202203180841 inputs file rtl_tcp RTL-SDR with TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/rct/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 184 out of 215 device decoding protocols [ 1-4 8 11-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 ]
Test mode active. Reading samples from file: g003_345M_1024k.cu8
baseband_demod_FM: low pass filter for 1024000 Hz at cutoff 102400 Hz, 9.8 us
Detected OOK package @0.047855s
Analyzing pulses...
Total count: 6, width: 604.14 ms (618643 S)
Pulse width distribution:
[ 0] count: 6, width: 21857 us [21850;21874] (22382 S)
Gap width distribution:
[ 0] count: 5, width: 94599 us [94593;94603] (96869 S)
Pulse period distribution:
[ 0] count: 5, width: 116457 us [116450;116467] (119252 S)
Pulse timing distribution:
[ 0] count: 6, width: 21857 us [21850;21874] (22382 S)
[ 1] count: 6, width: 95499 us [94593;100001] (97791 S)
Level estimates [high, low]: 15821, 1316
RSSI: -0.2 dB SNR: 10.8 dB Noise: -11.0 dB
Frequency offsets [F1, F2]: 4984, 0 (+77.9 kHz, +0.0 kHz)
Guessing modulation: Un-modulated signal. Maybe a preamble...
view at https://triq.org/pdv/#AAB1025561FFFF81818181818155
Good - 5800mini
5816 failed to decode
5816 15-20 ft away from the rtlsdr that partially decodes.
EDIT - adding a sample of the 5816 15-20 ft away from the rtlsdr that partially decodes.
honeywell-5816-1024k-partial.zip
It looks like the 1st, 3rd, and 4th 5816 samples in rtl_433_tests from 2019 show similar problems, but the 2nd sample (g002) does seem to get recognized as pulses and sliced up.
- https://github.com/merbanan/rtl_433_tests/tree/master/tests/honeywell_5816
Pulse timing distribution:
[ 0] count: 1, width: 21856 us [21856;21856] (5464 S)
[ 1] count: 1, width: 100004 us [100004;100004] (25001 S)
Something is very strange there. The 1024k signal is clearly good OOK and 135µs pulse/gap should always be okay at 250k. But as you show in the screenshots, the "Good - 5800mini" looks proper OOK, and the "5816 failed to decode" and the one above does not. Very much Iooks like FSK. Could that be something with the antenna? Maybe play with different center frequencies to inspect how that "harmonic" / "shadow" behaves?
@zuckschwerdt Thanks for looking into this.
Very much Iooks like FSK. Could that be something with the antenna? Maybe play with different center frequencies to inspect how that "harmonic" / "shadow" behaves?
I will try some more experiments and I certainly won't rule out something particular to my set up, but it is worth keeping in mind that:
- 3 of the 4 samples in the rtl_433_tests repo for the 5816 don't seem to decode correctly using https://triq.org/explorer/. Those aren't my recordings they are from @adamweiss back in 2019
- @rhinomods reported similar distance related problems for the 5816 back in some of the comments around PR #1384
Maybe play with different center frequencies to inspect how that "harmonic" / "shadow" behaves?
So at 250K that harmoninc the spectrogram shows at 344.786 Mhz shouldn't be in the passband. But I'll try different center frequencies. Is there any reason to keep using a sample rate of 1024k? Ideally I'd like to keep the sample rate to 250k since it works just fine with the other devices and is much less of a load.
Sorry, I didn't mean that true harmonic. I meant that artifact the looks like FSK. When the decoding works the signal looks like plain OOK (something like morse code), but in the not-decoding samples it looks like FSK (a zigzag pattern, a carrier at shifting frequency). That will be seen by rtl_433 also, so no chance to decode what already looks bad in the spectrogram.
If the sender really is pulsing OOK, then that carrier in the gaps must be coming from somewhere else. Maybe some resonance in the sender or receiver antenna?
Using 250k is fine. But the artifact will be less visible -- it just looked like a continuous carrier not that FSK zigzag
If the sender really is pulsing OOK, then that carrier in the gaps must be coming from somewhere else. Maybe some resonance in the sender or receiver antenna?
No antenna on the RTLSDR seems to be a little hit and miss, some full decodes of most of the repeats and some complete misses.
The spectogram between good and bad looks somewhat similar (to my eyes) with regard to the artifacts I think you are describing. What appears different between the successful ones seems more like a question of gain?
decode failed
223
decode succeeded
honeywell-5816-1024k-no-antenna.zip
@rct any update on this? I'm running into the exact same issue! I have a few sensors right near my antenna and it doesn't pick any of those up, but all of my father ones worked.
Currently I'm running an RTL-SDR with just an antenna extension cable dangling from it but I'd rather find a proper antenna or figure out why this is happening.
I've a novice with rtl_433 and using it to pick up my Honeywell 5816 sensors for home assistant.
From what we have seen here the problem looks like antenna overloading and with that some harmonics. Not ideal but should be recoverable. The minmax demod is not good at handling this and seems wrongly to run that signal as FSK.
Workarounds would be: use -Y classic or disable FSK (don't select any FSK decoder) or someone needs to work on the minmax demod.
@zuckschwerdt - Thank you for these tips! I'll experiment with just -R 70 as well as -Y classic.
How long ago (approx) did minmax become the default? That might explain why I think I was getting more successful decodes when I first started experimenting with these sensors.
(@thinkjk - sorry for not responding to you back in October I missed the mention. I had somewhat given up on this for a while and have mostly been using 5800mini / versa mini contacts which don't have this issue.)
Note: It's not just the 5816, I have some 5820L (slim sensors in awning windows) that haven't been being received reliably.
How long ago (approx) did minmax become the default?
Around end of 2019, then demod was in a664d0b.
I haven't had a chance to do anything but some very superficial analysis, the results so far:
-R 70 by itself, without -Y classic, did not improve reception of the problematic sensors. I think I still saw indications of attempted FSK decoding when the problematic sensors were triggered even with only protocol 70 enabled . (I had stats set for every 5 minutes which is too long to be sure.)
{"time" : "2022-11-27 10:50:37.029478", "enabled" : 1, "since" : "2022-11-27T10:45:37", "frames" : {"count" : 63, "fsk" : 7, "events" : 12}, "stats" : [{"device" : 70, "name" : "Honeywell Door/Window Sensor, 2Gig DW10/DW11, RE208 repeater", "events" : 68, "ok" : 12, "messages" : 12, "abort_length" : 56}]}
I think -Y classic improved reception of some sensors, but might have negatively impacted one or two others. It could also be environmental differences. I'll have to dig deeper, and probably reenable saving unknown decodes.
@thinkjk, @sandstormkeshav - did you have a chance to try any of this yet?
@rct I've been using -R 70 but I tried using -Y classic and I still have the exact same issue. All of the sensors that are close to my antenna don't get picked up, but anything slightly further away works perfectly. If I remove the antenna the closer ones get picked up perfectly the the ones further away don't. Here is my config
output mqtt://<filled_in>
frequency 345M
protocol 70
convert si
report_meta newmodel
pulse_detect classic
verbose 1
@rct I concur with @thinkjk findings. I don't notice any appreciable increase in successful decodes when modifying the settings. I can only get reliable decodes when operating with no antenna and nearby the sensors.
Any more thoughts on this, is there any other settings I can try?
I haven't been able to find a solution. I've resulted to using a USB extender to try to move the antenna away from some devices and then wrapping half of the antenna in aluminum foil :/ and even with that I can't find a perfect position where everything works.
Would happily donate for a working solution
I took a look at all the provided samples here and I'd agree with @zuckschwerdt that the root issue is signal overload. By the time the signal gets to rtl_433's decoders, the signal is so overblown that there's nothing useful for it decode. I might suggest you play around with rtl_433's gain setting (-g) to see if you can attenuate the signal better instead of using aluminum foil around the antenna.
The signal is definitely ASK, not FSK (even though a blown-out signal might start to look like this). If the signal is attenuated within reason, like a few of these samples are, rtl_433 can find the signal with a flex spec like this:
$ rtl_433 -R0 -r good-5800mini-g001_345M_1024k.cu8 -X "n=Honeywell,m=OOK_MC_ZEROBIT,s=136,l=272,r=600"`
codes : {64}00017bf70c7f066c
And you can feed a code like that back into rtl_433 to have it tell you its meaning with this:
$ rtl_433 -y {64}00017bf70c7f066c
model : Honeywell-Security id : 408f3
channel : 8 event : 80 state : open contact_open: 1 reed_open : 0
alarm : 0 tamper : 0 Battery : 1 heartbeat : 0 Integrity : CRC
Without the OOK_MC_ZEROBIT line code decoding, you can get the raw PCM code of these signals with this flex spec:
$ rtl_433 -R0 -r good-5800mini-g001_345M_1024k.cu8 -X "n=Honeywell,m=OOK_PCM,s=136,l=136,r=408"`
codes : {130}aaaaaaacd53554d4ab4ad554aad2d34a0
And here's an ASK demodulated view of that signal:
With some band pass filtering, this looks much nicer:
Now let's compare this with a message in the bad-5816-g003_345M_1024k.cu8 signal file:
The entire message signal is completely blown out. Even what should be gaps in the ASK signal are blown out. If I do the same band-pass filtering to try to clean it up, I get this:
Again, both pulses and gaps are blown out. Interestingly, before the message starts, there's about 4,451 μs of what should be "gap" silence that is so loud it's already blowing out the signal. Maybe the sensor is sending what it thinks is a very quiet or negligible signal for the gap, but your receiver's gain is so high that even this is too loud. Then the ASK pulses it sends that you want to receive can't be discerned above this floor. The transitions between gaps and pulses just look like very short useless spikes of noise.
To try to fix this, maybe start with something like this flex spec instead of the built-in decoder and provide a specific gain level:
$ rtl_433 -f 345M -s 1024k -R 0 -X "n=Honeywell,m=OOK_PCM,s=136,l=136,r=408" -S all -g 12.5
and see how well it picks up the signal. Try different gain levels other than 12.5 dB (I think the useful range is from 0.9 to 49.6) and see if you can find a setting to get a reliable and consistent signal from your various devices at their various distances. Once you find a gain setting that works for you, use that option with your normal rtl_433 usage.
@klohner - Thank you for your detailed analysis. I need to re-read this and digest it a bit in the morning.
Maybe the sensor is sending what it thinks is a very quiet or negligible signal for the gap, but your receiver's gain is so high that even this is too loud.
FWIW, I'm not setting an explicit gain.
-Y autolevel -Y classic -R 70 -f 345.0M -M level -M noise -M stats:1:300
I'm away from those sensors for a while, but when I'm back there I'll try some experimentation with fixed gains.
Interestingly, before the message starts, there's about 4,451 μs of what should be "gap" silence that is so loud it's already blowing out the signal.
I think that ~4.5ms of "gap signal" is likely a good area to investigate. I don't think the other sensors that are received well do that. It would be interesting to see how the presence of that long pulse (which if it was true OOK wouldn't exist) is impacting the various gain settings.
@thinkjk @sandstormkeshav have you experimented with fixed gain settings? You might be in a better position to do this sooner then I will.
You might want to take a look at @hdtodd's rtl_433_stats (formerly rtl_snr) and rtl_watch when you do your experiments. rtl_433's built in web interface should also be a help.
Also @klohner:
see if you can find a setting to get a reliable and consistent signal from your various devices at their various distances. Once you find a gain setting that works for you, use that option with your normal rtl_433 usage.
For what it is worth, I suspect a fixed gain isn't going to work to reliably receive a range of devices that are spread all over the house and deal with changes in background noise. But I do agree that if we can figure out that to what degree the various gains are effecting things, we can develop insights into a better solution.
Here's what that 4.5 ms of "gap signal" looks like in the "no-antenna-good-5816-g001_345M_1024k.cu8" signal:
It's rather faint, so I guess it doesn't interfere with the decoding.
However, compare that to "bad-5816-g003_345M_1024k.cu8":
You can't see the pulses through the noise of the gaps!
Yes, but how to figure out whether there is just too much power in the "gap" portion of the 5816's signal, or whether something has cause one (or more) of the gain functions to be turned up too high in software or hardware?
This is probably off topic, here's the rtl_433 web UI graph for my 345mhz rtl-sdr:
There is no one in that place right now, so the receives are infrequent and there isn't anything else on 345Mhz that I know of. Looks like the web UI only changes the noise level when there are decodes.
One minor curiosity to me: it looks like for some devices the noise (and presumably gain) change during the course of the 6 repeated messages that the device sends. (see the green dots in a vertical line). (This is from a 5800mini which is reliably received. I never get all six copies of the 5816s even those that are somewhat distant from the antenna.
{"freq" : 345.066, "rssi" : -0.135, "snr" : 15.410, "noise" : -15.545}
{"freq" : 345.066, "rssi" : -0.134, "snr" : 17.341, "noise" : -17.476}
{"freq" : 345.064, "rssi" : -0.111, "snr" : 18.689, "noise" : -18.800}
{"freq" : 345.066, "rssi" : -0.135, "snr" : 21.715, "noise" : -21.850}
{"freq" : 345.068, "rssi" : -0.108, "snr" : 26.015, "noise" : -26.124}
{"freq" : 345.065, "rssi" : -0.112, "snr" : 30.893, "noise" : -31.005}
Very interesting stats. Those receives indicate that the signal was at least at +15 dB, that's very much too loud. (The noise dropping means the (auto)gain is reduced.)
@klohner - Thanks for your work on this.
Per #2479 - I've added the flex decoder so I can start capturing some data comparing successful decodes between the builtin decoder and the flex spec.
-X n=Honeywell-Flex,m=OOK_PCM,s=136,l=136,r=408,preamble={24}555556,symbol_zero={2}8,symbol_one={2}4,get=@0:{4}:channel,get=@4:{20}:id,get=@24:{8}:event,get=@32:{16}:crc
At first glance, just counting output lines, it seems like there are a few more Flex decodes that the builtin decoder didn't capture. This appears to be the case for both 5816 and 5800minis, but there is a much bigger difference for the minis.
However this could be at least partially due to CRC checking. The flex decoder isn't checking the CRC.