Skip to content
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

Add samples for CED7000 shot timer #441

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ppapadeas
Copy link

Signed-off-by: Papadeas Pierros [email protected]

Signed-off-by: Papadeas Pierros <[email protected]>
@zuckschwerdt
Copy link
Collaborator

Thanks! Your analysis seems to be a perfect protocol description already!

Note that each repeat of the signal is prefixed with a aaaa preamble and then a 4d5e (de-)sync word, which does not decode as MC.

@ppapadeas
Copy link
Author

thanks @zuckschwerdt for the initial review.

Looking at the decoded data I cannot find the 4d5e , how do you mean?

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-10 19:57:56
model     : CED7000      count     : 1             num_rows  : 1             rows      : 
len       : 280          data      : 00008092800928009212f003c0002024a0024a002484bc00f00008092800928009212f
codes     : {280}00008092800928009212f003c0002024a0024a002484bc00f00008092800928009212f
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-10 19:57:59
model     : CED7000      count     : 1             num_rows  : 1             rows      : 
len       : 280          data      : 00004049200c2c00a982f003c000101248030b002a60bc00f00004049200c2c00a982f
codes     : {280}00004049200c2c00a982f003c000101248030b002a60bc00f00004049200c2c00a982f
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-10 19:58:12
model     : CED7000      count     : 1             num_rows  : 1             rows      : 
len       : 280          data      : 0000c02ce80424808c82f003c000300b3a0109202320bc00f0000c02ce80424808c82f
codes     : {280}0000c02ce80424808c82f003c000300b3a0109202320bc00f0000c02ce80424808c82f

@zuckschwerdt
Copy link
Collaborator

Try to get the raw PCM data (the MC decode will hide errors -- it is "lossy"):
rtl_433 -X "n=CED7000,m=FSK_PCM,s=1300,l=1300,r=9000" or
rtl_433 -X "n=CED7000,m=FSK_PCM,s=1300,l=1300,g=3500,r=9000"

@zuckschwerdt
Copy link
Collaborator

Why though? :) Any MC data stream of about this length could be this device. But read PCM, find the sync and only then decode MC. Now you know it is this device proper.

@ppapadeas
Copy link
Author

Thanks for the pointers @zuckschwerdt !

After using this rtl_433 -X "n=CED7000,m=FSK_PCM,s=1300,l=1300,g=3500,r=9000, match={12}0xf55" -f 434348000
I am getting this results:

time      : 2023-01-12 10:12:36
model     : CED7000      count     : 1             num_rows  : 4             rows      : 
len       : 204          data      : f55549abd2cb34aaacaab4acb532aab5332caaaaad34b552b54, 
len       : 201          data      : aaaa4d5e9659a5556555a565a99555a99965555569a5aa95aa0, 
len       : 201          data      : aaaa4d5e9659a5556555a565a99555a99965555569a5aa95aa0, 
len       : 0            data      : 
codes     : {204}f55549abd2cb34aaacaab4acb532aab5332caaaaad34b552b54, {201}aaaa4d5e9659a5556555a565a99555a99965555569a5aa95aa0, {201}aaaa4d5e9659a5556555a565a99555a99965555569a5aa95aa0, {0}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-12 10:12:40
model     : CED7000      count     : 1             num_rows  : 4             rows      : 
len       : 204          data      : f55549abd2cb34aab4aab4b2caacaaaab534aaaaaab4d2d4b54, 
len       : 201          data      : aaaa4d5e9659a555a555a59655655555a9a5555555a696a5aa0, 
len       : 201          data      : aaaa4d5e9659a555a555a59655655555a9a5555555a696a5aa0, 
len       : 0            data      : 
codes     : {204}f55549abd2cb34aab4aab4b2caacaaaab534aaaaaab4d2d4b54, {201}aaaa4d5e9659a555a555a59655655555a9a5555555a696a5aa0, {201}aaaa4d5e9659a555a555a59655655555a9a5555555a696a5aa0, {0}

Is there a way to see a binary representation of those?
Rows 2 and 3 work perfectly in bitbench applying manchester on top of the original results, but on row 1 I am having issues with the possible initial sync/preamble not being byte sized(?)

@zuckschwerdt
Copy link
Collaborator

BitBench is the right tool for other representations, from rtl_433 you'll only get hex codes.
In BitBench try 8b or even just v
The alignment in the first row is off, and that is always to be expected. Best to align on the sync word, e.g. use
rtl_433 -X "n=CED7000,m=FSK_PCM,s=1300,l=1300,g=3500,r=9000, preamble=aa4d5e"

@ppapadeas
Copy link
Author

merbanan/rtl_433#2319 contains a working description of the protocol that works with the captures of this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants