rtl_433
rtl_433 copied to clipboard
merbanan
Problems with the Flex Decoder
Hello Guys, I'm apologizing in Advance, in case this is not a bug but I just don't know how to use the software properly, but:
I am trying to analyse a signal and thus I captured a few samples (-S all) and tried to analyze them with -A -a. My Problem/Bug now is, that -A is recommending a flex decoder setup, but whenever I use this flex decoder, even on the same sample that brought that recommendation, I don't get any data at all and when I run it in live mode, I just get data: 0 for some reason.
Is this expected because -A is more fault tolerant than the suggested flex decoder?
Off-Topic: I am uncertain if the signal really is the recommended OOK_PWM, though as opposed to my suggestion FSK, because I see two strong signals at slightly different freqs in the waterfall of gqrx. Then when looking at the sample in audacity, I see the typical FSK combination of a more dense (higher freq) sine and a lower freq sine. Also it seems the amplitude of the Signal is always 1.0
For OOK_PWM, I would rather expect the signal to be cut off (Amplitude 0 for a few µs) in a repeating scheme, is that right?
Now I am still wondering because -A yielded a hexcode which looked very promising (a few 0xFF for sync and then a fix part and a changing part (CRC, Rolling Code). Is there a way to direct it into trying to analyse it as FSK? Because I wonder if it's even possible for me to detect the pulse width/length of a FSK signal at all? That would probably just be the smallest pulse time/change between high and low freq?
# rtl_433 -G -A g008_433.92M_250k.cu8
rtl_433 version 18.12-207-g82d0f55 branch master at 201905061642 inputs file rtl_tcp RTL-SDR
Trying conf file at "rtl_433.conf"...
Trying conf file at "/root/.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"...
Consider using "-M newmodel" to transition to new model keys. This will become the default someday.
A table of changes and discussion is at https://github.com/merbanan/rtl_433/pull/986.
Registered 119 out of 125 device decoding protocols [ 1-4 6-8 10-17 19-26 29-64 67-125 ]
Test mode active. Reading samples from file: g008_433.92M_250k.cu8
Detected FSK package @0.301728s
Analyzing pulses...
Total count: 147, width: 173.37 ms (43343 S)
Pulse width distribution:
[ 0] count: 1, width: 0 us [0;0] ( 0 S)
[ 1] count: 122, width: 496 us [492;504] ( 124 S)
[ 2] count: 23, width: 1000 us [996;1004] ( 250 S)
[ 3] count: 1, width: 32 us [32;32] ( 8 S)
Gap width distribution:
[ 0] count: 1, width: 4152 us [4152;4152] (1038 S)
[ 1] count: 120, width: 500 us [496;508] ( 125 S)
[ 2] count: 25, width: 1004 us [996;1188] ( 251 S)
Pulse period distribution:
[ 0] count: 1, width: 4152 us [4152;4152] (1038 S)
[ 1] count: 109, width: 1000 us [996;1004] ( 250 S)
[ 2] count: 24, width: 1504 us [1496;1684] ( 376 S)
[ 3] count: 12, width: 2000 us [1996;2004] ( 500 S)
Level estimates [high, low]: 15923, 626
RSSI: -0.1 dB SNR: 14.0 dB Noise: -14.2 dB
Frequency offsets [F1, F2]: 7328, -5478 (+28.0 kHz, -20.9 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
Attempting demodulation... short_width: 496, long_width: 1000, reset_limit: 4156, sync_width: 32
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=496,l=1000,r=4156,g=0,t=0,y=32'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {145} ff ff ff ff ff ff ff b6 ef cf ff 6f df d5 e6 6d db b6 80
[01] { 0} :
Detected FSK package @0.809676s
Analyzing pulses...
Total count: 147, width: 173.36 ms (43340 S)
Pulse width distribution:
[ 0] count: 1, width: 0 us [0;0] ( 0 S)
[ 1] count: 122, width: 496 us [492;508] ( 124 S)
[ 2] count: 23, width: 1000 us [1000;1004] ( 250 S)
[ 3] count: 1, width: 40 us [40;40] ( 10 S)
Gap width distribution:
[ 0] count: 1, width: 4148 us [4148;4148] (1037 S)
[ 1] count: 120, width: 500 us [492;508] ( 125 S)
[ 2] count: 25, width: 1004 us [996;1172] ( 251 S)
Pulse period distribution:
[ 0] count: 1, width: 4148 us [4148;4148] (1037 S)
[ 1] count: 109, width: 1000 us [996;1004] ( 250 S)
[ 2] count: 24, width: 1504 us [1492;1668] ( 376 S)
[ 3] count: 12, width: 2000 us [1996;2004] ( 500 S)
Level estimates [high, low]: 15957, 1005
RSSI: -0.1 dB SNR: 12.0 dB Noise: -12.1 dB
Frequency offsets [F1, F2]: 4433, -7082 (+16.9 kHz, -27.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
Attempting demodulation... short_width: 496, long_width: 1000, reset_limit: 4152, sync_width: 40
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=496,l=1000,r=4152,g=0,t=0,y=40'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {145} ff ff ff ff ff ff ff b6 ef cf ff 6f df d5 e6 6d db b6 80
[01] { 0} :
So on one hand it says detected FSK package, but recommends OOK_PWM. Looking at the pulse distributions implies PCM though (Gap being twice as long could be a LOW and Pulse Width being doubled could be two HIGHs). sample.zip
Try with -X 'n=name,m=FSK_PWM,s=496,l=1000,r=4152,g=0,t=0,y=40' and see if that helps.
I looked at the code and the modulation is not a property of the pulse coding. Thus the suggestion might miss this information.
Wow, lightning fast answer. Yes that's it! A few questions arise though: How is a "row" defined, because I have this trailing but empty row (len: 0, data empty)? And: With that flex decoder it looses the trailing 0, so the last byte of row 0 seems to be 8 for me. Now I am uncertain whether the -A output is maybe adding a 0, or what seems more possible, X maybe accidentially truncates one byte too early? I will check the other samples for that.
Edit: Actually if I skip that last "8", I have 18 byte, which would be 144 bits, the row is 145 bits long though
I would ignore it. Most likely the stray pulse
[ 0] count: 1, width: 0 us [0;0] ( 0 S) or [ 3] count: 1, width: 32 us [32;32] ( 8 S)
Anyway now you can sync the payload to the preamble and then start to figure out the meaning of the bits. Read the help of the flex decoder for the available options.
That's another problem I'm having unfortunately: The Preamble seems to be 7 times 0xFF, so I tried preamble={56}0xf or preamble={56}0xff as well as preamble={7}0xff but then the package isn't detected anymore. The closest I got was with {6}0xff, but even that changed the bytestream
Okay, Preamble works that way, decoding will be more fun :D I have the problem that the length varies from 81 to 90 bits (including everything in between), is there a way to filter false pulses out?
If you post the actual output it is more easy to answer questions. For all I know the signal just might be shorter in some cases. Maybe another type of signal but from the same transmitter.
Which output do you mean exactly? The one of -A (Pulse Distributions)?
length: 145 data: ffffffffffffffb7b7cfff6f9f7df54ed5ed8
length: 145 data: ffffffffffffffb7b7cfff6f9f7df54ed5ed8
length: 140 data: ffffffffffffffb7b7cfff6f4d8ee47fb05
length: 140 data: ffffffffffffffb7b7cfff6f4d8ee47fb05
length: 144 data: ffffffffffffffb7d7cfff6ffb6dad8ded97
length: 144 data: ffffffffffffffb7d7cfff6ffb6dad8ded97
length: 143 data: ffffffffffffffb5af9ffedf6967bffadc3a
length: 143 data: ffffffffffffffb5af9ffedf6967bffadc3a
length: 144 data: ffffffffffffffb6af9ffedfe4f73deeea9f
length: 144 data: ffffffffffffffb6af9ffedfe4f73deeea9f
length: 145 data: ffffffffffffff76af9ffedefe6edefec5fa8
length: 145 data: ffffffffffffff76af9ffedefe6edefec5fa8
length: 146 data: ffffffffffffffb72f9ffedef76746ffaff7c
length: 146 data: ffffffffffffffb72f9ffedef76746ffaff7c
length: 140 data: ffffffffffffffb45f3ffdbed877f495b2f
length: 140 data: ffffffffffffffb45f3ffdbed877f495b2f
length: 143 data: ffffffffffffffb72f9ffeded763debcdd6e
length: 143 data: ffffffffffffffb72f9ffeded763debcdd6e
Those are a few samples, and the only one being reliable is the first byte after the preamble, it is b, 7 or 3 depending on the pressed button. Also some sequences keep appearing a few times before they are gone again. But I wonder if that depends on the length or if this is just invalid values at the end (which probably don't even show up here, because they aren't 8 bits long)
Edit: Oh and a feature suggestion: json output should output multiple datasets as an array or else parsing it is a problem as soon as there are multiple packets caught
Edit2: Here a better dataset without the preambles:
length: 85 data: b72f9ffedf6f0fd38fbc88
length: 85 data: b72f9ffedf6f0fd38fbc88
length: 84 data: b7d7cfff6f73d647b9998
length: 87 data: b5af9ffedff7de5a745dec
length: 87 data: b5af9ffedff7de5a745dec
length: 87 data: b6af9ffede5b1feed6eabe
length: 87 data: b6af9ffede5b1feed6eabe
length: 84 data: b6af9ffedec3d6cfa537c
length: 84 data: b6af9ffedec3d6cfa537c
length: 85 data: b7d7cfff6fbe54e58b56f0
length: 85 data: b7d7cfff6fbe54e58b56f0
length: 86 data: b5af9ffedeebafbb13f8e8
length: 86 data: b5af9ffedeebafbb13f8e8
length: 91 data: b7d7cfff6f77eefb3f7af74
length: 91 data: b7d7cfff6fef976fbdfceae
length: 91 data: b7d7cfff6fef976fbdfceae
Well bxxxxff seems stable. Anyway I took a look at the pulse formation and it might be Manchester coded. Try with that and see if you get the same amount of bytes.
Sorry for the slow answer, I tried it with MC_ZEROBIT, but I couldn't get any output anymore (but probably I'd have to change some parameters?)
I tried to analyse the data further and came up with this:
btn_id: b unk1: 51f3 ff: ff unk2: db rest: ee 7f 5c cf 92 ba 8
btn_id: b unk1: 51f3 ff: ff unk2: db rest: ee 7f 5c cf 92 ba 8
btn_id: b unk1: 78f9 ff: ff unk2: ed rest: fd 27 fa b5 dd 35 e
btn_id: b unk1: 78f9 ff: ff unk2: ed rest: fd 27 fa b5 dd 35 e
btn_id: b unk1: 78f9 ff: ff unk2: ed rest: fe ed 8f b4 ff ac 4
btn_id: b unk1: 78f9 ff: ff unk2: ed rest: fe ed 8f b4 ff ac 4
btn_id: b unk1: 7e7c ff: ff unk2: f6 rest: f2 ee bf 47 de 3b d
btn_id: b unk1: 7e7c ff: ff unk2: f6 rest: f2 ee bf 47 de 3b d
btn_id: b unk1: 5cf9 ff: ff unk2: ed rest: ff d2 f5 dd af 51 c
btn_id: b unk1: 5cf9 ff: ff unk2: ed rest: ff d2 f5 dd af 51 c
btn_id: b unk1: 6cf9 ff: ff unk2: ed rest: f1 55 bd b9 15 f7 8
btn_id: b unk1: 6cf9 ff: ff unk2: ed rest: f1 55 bd b9 15 f7 8
btn_id: b unk1: 6cf9 ff: ff unk2: ed rest: e3 37 f5 a9 93 98
btn_id: b unk1: 6cf9 ff: ff unk2: ed rest: e3 37 f5 a9 93 98
btn_id: b unk1: 74f9 ff: ff unk2: ed rest: e7 ad fd fc df c3 fc
btn_id: b unk1: 74f9 ff: ff unk2: ed rest: e7 ad fd fc df c3 fc
btn_id: b unk1: 49f3 ff: ff unk2: db rest: ff bf 6b 2e dc de e
btn_id: b unk1: 49f3 ff: ff unk2: db rest: ff bf 6b 2e dc de e
The device seems to send the signal twice, but the data is interpreted just the same, so it doesn't seem to be "real" noise, maybe the packets are legitimately of different size. I am worried about the field unk_2 though: Usually it's ed or f6 (db being an exception here). Now the problem is: All of these three have the same bit-pattern but shifted. Then pattern is basically 0110, so F6 is 0b11110110, ED is 0b11101101 and DB is 0b11011011, so it seems DB has two bits too much or F6 is lacking two bits.
OR I just cannot try to interpret the data bytewise but bitwise, but even then, dynamic length is strange.
I am 99% sure the data is Manchester coded. You need to get that working to get proper decodes. Try setting the short value and long value to 2*times the short pulse duration.
You could use PCM coding also. That should output fixed lengths of the pulses.
So how can I try to determine the parameters? I tried m=FSK_PCM,s=500,l=1000,r=4500 and m=FSK_MC_ZEROBIT,s=500,l=1000,r=4500 as well as with s=1000 and l=2000 for each, which is strange because 500us and 1000us are indeed pulse values, I wonder why I don't get any output?
With PCM encoding s -> Nominal width of pulse [us] and l -> Nominal width of bit period [us]. So PCM should have worked with s=496 and l=1000. For Manchester s -> Nominal width of clock half period [us], so s=496 should have worked, l is unused.
mhh, if I leave out "l" for FSK_MC_ZEROBIT, I get a bad flex spec. I now ran PCM with 496 and 1000 on all samples and some trigger an answer, but there it works for 3 out of 8 samples, once 0x8, once 0xe and once 0xfff0 :/
rtl_433 -v -X 'n=sig,m=FSK_PCM,s=500,l=500,r=4500' -r g008_433.92M_250k.cu8 gave ok output, might be a factor wrong in length.
'n=sig,m=FSK_PCM,s=950,l=950,r=4500' -r g008_433.92M_250k.cu8 also work but the preamble should be a or 5 which it isn't. I need to look into the code more to understand what goes wrong.
Well, that "works", but I doubt that it's the right decoding (at least), because the data doesn't look "random enough" to me:
015555555555555555555555555552d53554d4d3354ccab2b3552aaab33554ad352b52cd353352b4b4b4ca
015555555555555555555555555552d53534d4d3354ccab2b3552ab52aab4cb4d54d532b2d2ccb2b4ab2ca
015555555555555555555555555552d534b4d4d3354ccab2b3552aab4b4ccb52ad2cd32aab2b4d333332b2
etc, but, 500 is the only way to produce packets of the very same size. All others differ. Today I tested another device from that manufacturer (recorded them), and at least when using FSK_PWM, I can almost decode the values as much as I could for the other device. At least the "button id" is encoded the same: It's the first 4bits.
On the other hand, the encodings are so similar, that PWM could look okay, where it really is PCM or MC.
Can you post more signal recordings? Then we can figure out how to decode the payload.
@zuckschwerdt Does this mean I'd have to use FSK_MC_ZEROBIT? or is it MC on top of PWM/PCM? (Because your code seems to be able to decode it based on the output I gave above?)
I was commenting on the "not random enough" (which is true, encoding doubles the bandwidth) note on your findings. FSK_MC_ZEROBIT should work, but there was a bug ;) Fixed with 7ab2894 now and this works:
rtl_433 -R 0 -X 'n=sig,m=FSK_MC_ZEROBIT,s=500,l=500,r=4500' g008_433.92M_250k.cu8
@zuckschwerdt thanks. I suspected some bug as the the parameters should have worked.
So, package disassembly time, I unfortunately fail at determining the CRC checksum (and their position): For instance:
btn_id: 1 unk1: dfd key_id: f0 bf f0 ef unk2: 85 66 f9 d1 8f 50 78 a2 unk3: 0 rest:
btn_id: 1 unk1: dbd key_id: f0 bf f0 ef unk2: c6 29 f0 6a b0 24 bc 0b unk3: 0 rest:
btn_id: 1 unk1: ddd key_id: f0 bf f0 ef unk2: a1 b7 b4 c8 64 18 37 82 unk3: 0 rest:
Here when you press the button long enough, btn_id changes to 5.
btn_id: 2 unk1: e9d key_id: f0 bf f0 ef unk2: e1 f7 a0 63 5a 76 74 d7 unk3: 0 rest:
btn_id: 5 unk1: ded key_id: f0 bf f0 ef unk2: bd 9c 38 01 db b5 d8 7c unk3: 8 rest:
btn_id: 2 unk1: ead key_id: f0 bf f0 ef unk2: ac 6c 76 4a f5 a2 16 60 unk3: 0 rest:
btn_id: 5 unk1: dcd key_id: f0 bf f0 ef unk2: e8 9b e3 65 3f a0 71 96 unk3: 8 rest:
btn_id: 2 unk1: e8d key_id: f0 bf f0 ef unk2: f6 b7 73 d0 8b 55 bb cd unk3: 8 rest:
btn_id: 5 unk1: df5 key_id: f0 bf f0 ef unk2: 89 84 74 b0 ba 40 4b c3 unk3: 0 rest:
I only discovered, that the bit length sometimes variies by 1 (usually packets are sent twice and I noticed that the data field is exactly the same, but the length is either 113 or 114. I guess that doesn't matter though.
I am uncertain about the role of unk1 and unk3, I suspect unk2 is the rolling code and might also contain the checksum to some degree.
unk1 seems a bit incremental though:
btn_id: 1 unk1: db9 key_id: f0 bf f0 ef unk2: ed 46 18 48 9d 83 6f e7 unk3: 8 rest:
btn_id: 1 unk1: dd9 key_id: f0 bf f0 ef unk2: a7 5c fb bd de 3a b8 e9 unk3: 8 rest:
btn_id: 1 unk1: da1 key_id: f0 bf f0 ef unk2: e1 ac 14 b9 e2 96 8f fc unk3: 0 rest:
btn_id: 1 unk1: dc1 key_id: f0 bf f0 ef unk2: f4 c5 05 41 60 58 56 27 unk3: 8 rest:
So I've made some progress on the above (there is no checksum and unk3 is the stopbit), but I'll come back to this after my vacation. I'm having odd problems there as the preamble actually isn't 7 times 0x0 (byte) but 55 bit "0" and one start bit "1". I've also noticed that they used the IEEE notation where I think a falling flank was a 1? Either way it was the opposite of how rtl_433 interpreted it, which doesn't matter much as in the end I would simply reverse the bytes "opposite". I'm more worried that me changing the manchester coding in my synthesizer yield the same results. So this deserves more inspection and precise information.
A different device which works on 126 kHz inductive, I am experiencing the following strange signals. Technically this seems to be a wake-up signal to trigger transmission on 868 MHz which would be the sinus that is so clearly visible. I'm worried by the "noise" before that, though, which despite looking random seems to be precisely the same every time.
Demodulation with -X 'n=1,m=OOK_PWM,s=100,l=200,r=2000' yields almost stable values.
What do you think? I don't care about the interpretation of the values, but transmitting them "blindly" doesn't work as I expected yet, so I only need to see whether these are some "challenges" or just the same pattern and my issue is more related to transmitting/timing.
samples.zip
Should this still be open? If so, please retest with current master as a lot has changed in the last 4 years. Starting 30-day timer.
I realize this is a very old thread, but stumbled upon it and it looked interesting.
I just took a look at the .cu8 file posted above and took a stab at a decoder.
Here's what works for me to decode the MC data in this signal:
-X "n=F,m=FSK_PCM,s=500,l=500,r=8000,preamble={32}aaaaaaa9,match={32}aaaaaaa9,bits>=300,bits<=350,symbol_one={2}8,symbol_zero={2}4"
This seems to work well to get :
{112}3bbde17fe1df9f0920a288f4723a [-r "g008_433.92M_250k.cu8" 2019-05-13]
{112}7bf76bd422f802bf1b8e5bae3334 [-y "015555555555555555555555555552d53554d4d3354ccab2b3552aaab33554ad352b52cd353352b4b4b4ca"]
{112}7bb76bd422f8380d37de89948c24 [-y "015555555555555555555555555552d53534d4d3354ccab2b3552ab52aab4cb4d54d532b2d2ccb2b4ab2ca"]
{112}7b376bd422f80cd4e196808daaa2 [-y "015555555555555555555555555552d534b4d4d3354ccab2b3552aab4b4ccb52ad2cd32aab2b4d333332b2"]
Not sure if those "-y" values are good to begin with, though, since they don't seem to look similar to anything else.
If, instead, I pull the bytes out of the data @MeFisto94 posted on 2019-05-30 and shift by a bit, the data seems to align better:
{112}3bbde17fe1df9f0920a288f4723a [g008_433.92M_250k]
{112}3bfbe17fe1df0acdf3a31ea0f144 ["btn_id: 1 unk1: dfd key_id: f0 bf f0 ef unk2: 85 66 f9 d1 8f 50 78 a2 unk3: 0 rest:" shifted 1 bit]
{112}3b7be17fe1df8c53e0d560497816
{112}3bbbe17fe1df436f6990c8306f04
{112}5d3be17fe1dfc3ef40c6b4ece9ae
{112}bbdbe17fe1df7b387003b76bb0f9 [long press]
{112}5d5be17fe1df58d8ec95eb442cc0
{112}bb9be17fe1dfd137c6ca7f40e32d [long press]
{112}5d1be17fe1dfed6ee7a116ab779b
{112}bbebe17fe1df1308e96174809786 [long press]
{112}3b73e17fe1dfda8c30913b06dfcf
{112}3bb3e17fe1df4eb9f77bbc7571d3
{112}3b43e17fe1dfc3582973c52d1ff8
{112}3b83e17fe1dfe98a0a82c0b0ac4f
BitBench with some attempt at identifying fields
I can't seem to find a CRC in this. This doesn't return anything and shifting bits around didn't seem to help.
reveng -w 16 -s 3bbde17fe1df9f0920a288f4723a 3bfbe17fe1df0acdf3a31ea0f144 3b7be17fe1df8c53e0d560497816
@MeFisto94 - could you post a bunch more of these samples in .cu8 format with explanations of the effect each one has on your device? What is this device?
