sebmillet / RF433any

GNU Lesser General Public License v3.0
39 stars 4 forks source link

Decoding RF Signal #2

Closed khawajamechatronics closed 2 years ago

khawajamechatronics commented 2 years ago

Hi

Thanks for awesome library which responds to Unknow RF signal. I have a custom light controller device and I want to decode its RF signal.

Only timing code responds on RF key press which output something like this 00:02:20.831 -> Decoded: no , err: 0, code: U, rep: 1, bits: 34, data: 03 ff ff f5 77 00:02:20.878 -> I=0, LS=452, LL=1708, HS=128, HL=496, S=0, U=0, V=0, Y=0, Z=1716 00:02:21.064 -> Decoded: no , err: 0, code: I, rep: 1, bits: 0, data: 00:02:21.064 -> I=10012, LS=452, LL=1716, HS=488, HL=488, S=10016, U=0, V=0, Y=0, Z=0

Can you give some hint what kind of signal or what tools I need to debug?

Thanks again

sebmillet commented 2 years ago

Hello

the code cannot be understood by RF433any (this is what means "code: U").

The raw data given of 34 bits indicates what got received, short 0) or long (1) signals.

So if we consider the code received (03 ff ff f5 77) and output it in binary:

1111111111111111111111010101110111

This means (each sequence of 2 characters is low signal followed by high signal):

LL LL LL LL LL LL LL LL LL LL LL SL SL SL LL SL LL

RF433any cannot decode it, because it matches none of: tribit (where in a sequence of two, a S is always followed by a L, and a L is always followed by a S), tribit inverted (same S-then-L or L-then-S but high followed by low), Manchester (a bit more complex, Dr. google is your friend ;-) )

Given the weird timings output by the library: LS (low signal short)=452, LL (Low signal lLong)=1708, HS (high signal short)=128, HL (high signal long)=496, I guess either the 'code' is an artefact (no correct reception) or follows another logic, out of tribit/tribit inverted/Manchester.

It is indeed rare high signal timings differ from low signal timings (but it can happen, hence my code manages this possibility, as do FLO/R telecommands). Also most frequently, the long duration is twice as long as the short (sometimes 3 times instead of twice). Having 452 as short and 1708 as long suggests RF433any is interpreting durations as being "short" or "long" in a very arbitrary manner, and not relevant in this particular case.

I suggest you may use rf433snif project, to display the timings themselves, to see their structure.

Address: https://github.com/sebmillet/rf433snif

Hope you'll find how it works,

Best Regards, Sébastien Millet

sebmillet commented 2 years ago

Hello Was it a helpful response? Could you work out what is going on? I'd like to close the issue. Thanks, Seb