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

Help to debug unknown protocol #276

Open
rickitaly opened this Issue Feb 16, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@rickitaly
Copy link

rickitaly commented Feb 16, 2019

Hi, i purchased now from amazon a key finder running at 433.92 MHZ because i would like to use just the remote transmitter to trigger some mqtt action. It is very nice with 5 colored buttons signals i would like to catch.
Here is the product: https://www.amazon.it/gp/product/B07CYSNQK1
The board of the transmitter is equipped with an NDR4208 K3 chip and the FCC file says that the device uses the ASK modulation.
I am already using rc-switch with Openmqttgateway on several esp32-esp8266 devices and i am very happy about it.
Unfortunately it looks like there is no standard protocol for this device, so i started to approach the very interesting wiki about adding new remotes. I could carry on investigation with the following results.
For this test i am using an Arduino Uno with SRX882.
rawdata
As you can see i can identify a base sequence which is repeated several times, and the different buttons have different sequences.
There is for all colors a pulse lenght of around 300-330µs and then i find these averages i identified:

red:
305,7143
464,3478
1044,141
3035,091

green:
308,225
419,4783
1038,177
3047,956

blue:
307,673
542,087
1037,833
3049,099

purple:
331,7215
512,8696
1021,374
3061,652

yellow:
302,9814
636
1049,646
3042,545

I also performed scan with the Martin-Laclaustra modified library and surprisingly just the red button is giving me an help that is the following:
13 times i get this:

`Received 254 / 8bit Protocol: 0

data bits of pulse train duration: 10596
proposed protocol: { 265, { 11, 12 }, { 1, 4 }, { 4, 1 }, true }

first level down
3020 3060
1044 300 1048 304 1044 308 1040 308 1040 308 1040 312 1016 308 128 1048
 

`

The purple button only few times (maybe 1 time out of 20 push) is giving an output like this:
`
Received 63 / 6bit Protocol: 4

data bits of pulse train duration: 8140
proposed protocol: { 339, { 1, 9 }, { 1, 3 }, { 3, 1 }, false }

first level down
3044
1048 312 1044 316 1040 320 1036 324 1032 328 1028 312
292

`
Other buttons are not triggering any feedback from the Martin-Laclaustra.

At this point of my investigation i don't understand how to proceed according to the wiki, what can i identify from this and how to implement the new protocol data.
Actually i don't really need to send any data, would be enough for me to identify which button has been pushed so that i can trigger some mqtt signal.
I include also raw data used to show you the results.
Can anybody help me in my investigation? How should i proceed in the definition of the protocol?
Thank you and have a nice day!
rfanalysis.xlsx

@Martin-Laclaustra

This comment has been minimized.

Copy link

Martin-Laclaustra commented Feb 24, 2019

With this library you can only expect to mimic the signal, but never to receive it. To achieve producing a similar signal (which does not seem to be you aim) you should use my branch https://github.com/Martin-Laclaustra/rc-switch/tree/transmittimingsarray
Search around a little bit in issues and pull request to find out what to do if you want to try that.
Just for curiosity, I provide here some ideas about your data. Your alignment above seems suboptimal. I propose a different one. I approximated and rounded durations.

Base (pulse) 150

bits Red     Green     Blue     Purple     Yellow    
strange 300 2   300 2   300 2   300 2   300 2  
  450 3   450 3   450 3   450 3   450 3  
long 1050 7 0 1050 7 0 1050 7 0 3000 20 1 1050 7 0
  3000 20   3000 20   3000 20   1050 7   3000 20  
  1050 7 0 1050 7 0 3000 20 1 1050 7 0 1050 7 0
  3000 20   3000 20   1050 7   3000 20   1050 7  
  1050 7 0 3000 20 1 1050 7 0 1050 7 0 3000 20 1
  3000 20   1050 7   3000 20   3000 20   1050 7  
  3000 20 1 1050 7 0 1050 7 0 1050 7 0 3000 20 1
  1050 7   3000 20   3000 20   3000 20   1050 7  
short 300 2 0 1050 7 1 300 2 0 1050 7 1 300 2 0
  1050 7   300 2   1050 7   300 2   1050 7  
  300 2 0 1050 7 1 300 2 0 1050 7 1 300 2 0
  1050 7   300 2   1050 7   300 2   1050 7  
  300 2 0 300 2 0 1050 7 1 1050 7 1 1050 7 1
  1050 7   1050 7   300 2   300 2   300 2  
  300 2 0 1050 7 1 300 2 0 1050 7 1 1050 7 1
  1050 7   300 2   1050 7   300 2   300 2  
  300 2 0 300 2 0 1050 7 1 1050 7 1 1050 7 1
  1050 7   1050 7   300 2   300 2   300 2  
  300 2 0 300 2 0 1050 7 1 1050 7 1 300 2 0
  1050 7   1050 7   300 2   300 2   1050 7  

This is what I inferred: There is a "strange" bit, that could be the sync. It is very short high + aprox. very short low.
Followed by 4 "long" data bits: long high + short low (1) or short high + long low (0).
Followed by 6 "short" data bits: short high + very short low (1) or very short high + short low (0).

At least this is an initial approach to these devices.
Best luck!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.