milaq / rpi-rf

Sending and receiving 433MHz signals with cheap GPIO RF modules on a Raspberry Pi
BSD 3-Clause "New" or "Revised" License
505 stars 179 forks source link

receiving completely random stuff, nothing frommy remotes #21

Open Liquidmasl opened 6 years ago

Liquidmasl commented 6 years ago

nothing seems to relate to any button presses, i can press the same button 20 times 2 cm next to the receiver and i get nothing for multiple times, or nothing at all, or 2 complete random things..

what am i doing wrong?

2018-03-03 04:39:00 - [INFO] rpi-rf_receive: 8 [pulselength 2252, protocol 2] 2018-03-03 04:39:30 - [INFO] rpi-rf_receive: 2048 [pulselength 1545, protocol 4] 2018-03-03 04:41:18 - [INFO] rpi-rf_receive: 16 [pulselength 2419, protocol 4] 2018-03-03 04:41:55 - [INFO] rpi-rf_receive: 64 [pulselength 1521, protocol 4] 2018-03-03 04:42:37 - [INFO] rpi-rf_receive: 33 [pulselength 182, protocol 1] 2018-03-03 04:43:00 - [INFO] rpi-rf_receive: 8 [pulselength 2538, protocol 2] 2018-03-03 04:43:15 - [INFO] rpi-rf_receive: 64 [pulselength 842, protocol 2] 2018-03-03 04:44:31 - [INFO] rpi-rf_receive: 128 [pulselength 850, protocol 1] 2018-03-03 04:46:46 - [INFO] rpi-rf_receive: 1073741826 [pulselength 1203, protocol 1] 2018-03-03 04:47:37 - [INFO] rpi-rf_receive: 64 [pulselength 1638, protocol 4] 2018-03-03 04:47:43 - [INFO] rpi-rf_receive: 1 [pulselength 988, protocol 2] 2018-03-03 04:47:46 - [INFO] rpi-rf_receive: 2048 [pulselength 1045, protocol 4] 2018-03-03 04:48:20 - [INFO] rpi-rf_receive: 2 [pulselength 374, protocol 3] 2018-03-03 04:49:01 - [INFO] rpi-rf_receive: 16 [pulselength 905, protocol 2] 2018-03-03 04:49:01 - [INFO] rpi-rf_receive: 16 [pulselength 1492, protocol 4] 2018-03-03 04:49:46 - [INFO] rpi-rf_receive: 1 [pulselength 1140, protocol 2] 2018-03-03 04:49:46 - [INFO] rpi-rf_receive: 8 [pulselength 148, protocol 3] 2018-03-03 04:51:16 - [INFO] rpi-rf_receive: 1 [pulselength 1594, protocol 4]

enso-media commented 6 years ago

Yep, same here. Tried with different outlet sets, and different remotes. Always a different code for the same button.

Liquidmasl commented 6 years ago

in my case the codes doesnt even correspond to the timing of my button presses, it seems the remote gets completely ignored. if i send codes via PI transmitter they get received just fine. it seems the remotes use a protocol which is not supported, which is a shame really, i dont know how to utelize all my light switches now D:

zzmike76 commented 6 years ago

have the same issue. sending from Arduino fixed codes and receiving on Raspberry. doesn't matter if Arduino is on/off, I keep receiving garbage data.

aomanchuria commented 6 years ago

I was recently receiving absolutely nothing using an RPI and an ALEKO keyfob which are based on HSC301 KEELOQ. Using the Piscope, I was able to see the signal when I pressed the button. I also got a similar signal using another receive app. I started messing with the source: https://github.com/milaq/rpi-rf/blob/master/rpi_rf/rpi_rf.py

I changed the line 187: if duration > 5000: to: if duration > 500:

and now I am able to see "something" when I press the buttons. Basically I see several lines created at a time. However nothing in the lines is repeated. If I don't press anything, I get nothing (which is great) but again pressing only gives me garbage.

So my question is why duration must be 5000? what are the units. Its a small code and just knowing a little about the various functions would be great to add more protocols.

lukesUbuntu commented 6 years ago

@aomanchuria think thats 5000ms, so every 5seconds its polls...

Are the random code/channels is it rolling remote codes?

aomanchuria commented 6 years ago

its rolling code:

Aleko sliding gate key fob signal analysis: 50% signal preamble = 390us ~ 400us each step = Te total preamble = 9055us (a 23Te 50% cycle wave) total low after preamble = 3960us (a 10Te pause) zero = 2 highs, 1 low (1te each step) one = 1 high, 2 lows (1te each step) numbers: 101011111000011111110100100010101110111011100000101111101010010011<-has noise error 000111010111111100100011011010111110111011111000101111101010010011 000111010111111100100011011010111110111011111000101111101010010011

rental house keyfob: button A 100001010000000000110111001110011110111011111000101111100110010011 100001010000000000110111001110011110111011111000101111101010010011 100001010000000000110111001110011110111011111000101111101010010011 button B 010111000010101110011010110011011110111011111000101111101010001011 010111000010101110011010110011011110111011111000101111101010001011 ****ssssssssssssssssssssssssssssbbbbSS *-encrypted bits s-serial code b-button SS-status

rental house keyfob again(d= delta, s= same as before): button A 010110110010111100110011001101111110111011111000101111101010010011 100001010000000000110111001110011110111011111000101111101010010011<-previous run dddddddddddddddddddddddddddddddsssssssssssssssssssssssssssssssssss button B 100010010000111100010100010011111110111011111000101111101010001011 010111000010101110011010110011011110111011111000101111101010001011<-previous run dddddddddddddddddddddddddddddddsssssssssssssssssssssssssssssssssss

seems like the encrypted portion ends in a 1 each time

button C 111100111010110110010000010000101110111011111000101111101010001111 111100111010110110010000010000101110111011111000101111101010001111 ****ssssssssssssssssssssssssssssbbbbSS button D 100011111011011000000011101101111110111011111000101111101010000111 100011111011011000110111101101111110111011111000101111101010000111 ****ssssssssssssssssssssssssssssbbbbSS

buttons A to D 0100 0010 0011 0001

the last two bits are for battery low in voltage and code repeated it seems that when you press the button it always repeats the same code until you depress it. Vlow is 0 at 6.6volts 1 at 13v. Confirmed that code repeat is 0 the first message, 1 the rest of the repeats.

aomanchuria commented 6 years ago

with 5000:

^Cpi@raspberrypi:~/gate_opener/rf433ctrl $ rpi-rf_receive 2018-03-17 09:09:00 - [INFO] rpi-rf_receive: Listening for codes on GPIO 27

with 500: line ~189: if duration > 500: #in micro seconds so .5secons is 500us ^Cpi@raspberrypi:~/gate_opener/rf433ctrl $ rpi-rf_receive 2018-03-17 09:09:34 - [INFO] rpi-rf_receive: Listening for codes on GPIO 27 2018-03-17 09:09:36 - [INFO] rpi-rf_receive: 16 [pulselength 27, protocol 1] 2018-03-17 09:09:36 - [INFO] rpi-rf_receive: 4 [pulselength 150, protocol 4] 2018-03-17 09:09:37 - [INFO] rpi-rf_receive: 32 [pulselength 13, protocol 3] 2018-03-17 09:09:37 - [INFO] rpi-rf_receive: 8 [pulselength 135, protocol 4] 2018-03-17 09:09:38 - [INFO] rpi-rf_receive: 2 [pulselength 256, protocol 4] 2018-03-17 09:09:38 - [INFO] rpi-rf_receive: 4 [pulselength 11, protocol 3] 2018-03-17 09:09:38 - [INFO] rpi-rf_receive: 2 [pulselength 28, protocol 1] 2018-03-17 09:09:38 - [INFO] rpi-rf_receive: 2 [pulselength 27, protocol 1] 2018-03-17 09:09:38 - [INFO] rpi-rf_receive: 16 [pulselength 25, protocol 1] 2018-03-17 09:09:38 - [INFO] rpi-rf_receive: 16 [pulselength 101, protocol 4] 2018-03-17 09:09:38 - [INFO] rpi-rf_receive: 4 [pulselength 11, protocol 3] 2018-03-17 09:09:41 - [INFO] rpi-rf_receive: 8896 [pulselength 213, protocol 2] 2018-03-17 09:09:41 - [INFO] rpi-rf_receive: 19055234 [pulselength 135, protocol 4] 2018-03-17 09:09:41 - [INFO] rpi-rf_receive: 1 [pulselength 76, protocol 6]

aomanchuria commented 6 years ago

Can someone fill me in as to what this means: 32 [pulselength 13, protocol 3]

protocol 3 looks like this: Protocol(100, 30, 71, 4, 11, 9, 6),

the Te is 100, the sync is 30 high, 70 low. What does this mean? 30 Te high and 70 Te low? or 30 "ones" and 70"zeros". in the aleko or keeloq, the beginning of each message is 23Te long high and lows at 50% 1 Te high, then 1 Te low etc for 23 times. then each zero starts with 2 tee highs then one low. for 1's it starts with one Te high and two low.

my theory is that it should be: Protocol(400, 23, 10, 2, 1, 1, 2),#my own protocol for HCS301 Aleco or Protocol(400, 46, 20, 2, 1, 1, 2),#my own protocol for HCS301 Aleco

but that doesn't really do anything different.

evski commented 6 years ago

Same issue here, defintely see data when pressing remote but no pattern to it. I tried again with a remote I know the code for and I did get the correct code but very randomly in amongst loads of random data. Seems must be something fundamentally wrong here. I suspect perhaps certain protocols not supported. Can anyone help please?

aomanchuria commented 6 years ago

I found that the sleep uses rolling codes. It's possible to hack, but would take days off computing and basically a simple program, but I couldn't figure it out at the time so I gave up. Instead I was going to toss the original motherboard and replace it with a servo control for CNC diy machines...Hbridge with a controller like arduino or raspberry pi. So much simpler! Use the same remotes and eliminate the rolling code just a password maybe.... who's gonna waste time trying to remotely open your gate when they can bypass with a crowbar... LOL.

On Dec 2, 2018 6:31 AM, "evski" notifications@github.com wrote:

Same issue here, defintely see data when pressing remote but no pattern to it. I tried again with a remote I know the code for and I did get the correct code but very randomly in amongst loads of random data. Seems must be something fundamentally wrong here. I suspect perhaps certain protocols not supported. Can anyone help please?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/milaq/rpi-rf/issues/21#issuecomment-443511927, or mute the thread https://github.com/notifications/unsubscribe-auth/AaWwiSAmasx-synfMBJrnUDLsNotVei8ks5u0-QzgaJpZM4Saw99 .

lenaaar commented 5 years ago

I am having the exact same issue. I receive garbage data whatever I do. The remote controller that sends signals (it does because the lamp reacts to it) gets completely ignored. I'll try changing that line to 500 and see if that changes anything.

livus commented 5 years ago

I am also experiencing this issue. The input is more or less random, only about 1/10th of the data is correct. Everything else seems to be completely random. And also only if I am holding the sender directly next to the receiver. Also the python script rpi-rf_receive constantly uses 45% CPU.

These things I have already tried:

The sender is an Arduino with the RCSwitch library (which works perfectly when read by another Arduino)

milaq commented 5 years ago

Have you tried the latest master (including https://github.com/milaq/rpi-rf/commit/3bbd31cc3bbd4f1a7c2aba776d2541b37480e45b)? Does that improve your situation?

Rydako commented 4 years ago

Did this ever get solved? I'm having this issue myself, and trying to determine if the remote is using rolling codes or not

daffymarco commented 2 years ago

Any solution? I have the same problem... Random values ​​with the control button pressed or not.....

stephen-mw commented 2 years ago

This is unfortunately still a major issue.