Need help/ guidance on decoding RF signal

I am writting to you cause I have a strange problem :confused:
I am trying to record and replay my garage door opener (DoorHan) using Rx and Tx.
Problem: When I try to receive signal from pressing garage door opener which is working on 433Mhz frequence and I have 433Mhz frequency receiver I get no data received :confused:

Things I tried:
I mounted 17cm antenna to rx and tx and uploaded some binaries to be transmitted from tx, just so I can clear the doubt of my 433Mhz rx being busted. I successfully got code from transmitter onto my receiver. I then tried again clicking garage door opener right next to my receiver…. still nothing.
At this point I am not sure what I can do or what could be wrong.

In fact I did catch a signal using SDR-RTL USB dongle… I found out that whenever I press key on DoorHan remote I get the same spikes of signal at 433.92/93 range (not quite sure on which but it’s just everything on same frequency). I even recorded it and I have .waw files (audio) which I am trying to decode in Audacity, however I am lost how to do it. :confused:

I think DoorHan is using OOK modulation → therefore I made something out of that in hopes I decoded it right… however it’s strange and I am lost as what would gap without peaks mean…

Anyway this is the hosted pic:

What am I using:

  • breadboard,
  • arduino Nano,
  • XY-MK-5V 433Mhz RF Receiver (antenna mounted),
  • FS1000A/XY-FST RF 433Mhz Transmitter (antenna mounted),
  • rc-switch library

I am wiring like so:
VCC → 5V (on Arduino Uno)
DATA/ATAD → digital pin (in this case: pin 2)
GND → GND

Code I am using:
Actually a rc-switch library example code called “ReceiverDemo_Advanced”.

/*
  Example for receiving
  
  https://github.com/sui77/rc-switch/
  
  If you want to visualize a telegram copy the raw data and 
  paste it into http://test.sui.li/oszi/
*/

#include <RCSwitch.h>

RCSwitch mySwitch = RCSwitch();

void setup() {
  Serial.begin(9600);
  mySwitch.enableReceive(0);  // Receiver on interrupt 0 => that is pin #2
}

void loop() {
  if (mySwitch.available()) {
    output(mySwitch.getReceivedValue(), mySwitch.getReceivedBitlength(), mySwitch.getReceivedDelay(), mySwitch.getReceivedRawdata(),mySwitch.getReceivedProtocol());
    mySwitch.resetAvailable();
  }
}

help me please,

BEST.zip (815 KB)

We can't help unless you post your wiring, your code (using code tags) and links to the devices. Please see "How to use this forum" at the top of every board.

This is a general introduction into how to decode typical signals from weather station sensors, etc.

However, most, if not all modern garage door openers are securely encrypted, so there is basically no chance that a beginner could decode one.

I am lost as what would gap without peaks mean

That is a pause to signal the start of a message, and to allow the receiver to calibrate itself to the signal level.

OP mentions not receiving any data, that sounds like a protocol and/or frequency mismatch. As a rule of thumb, different radios can not communicate with one another, even if on the same frequency (e.g. LoRa, RFM69 and HC12 radios are can transmit at 433 MHz but won't talk to one another).

OP mentions that an OOK signal [u]is[/u] picked up at 433 MHz using an SDR, so the wiring of the cheapo 433 MHz receiver is suspect.

jremington: OP mentions that an OOK signal [u]is[/u] picked up at 433 MHz using an SDR, so the wiring of the cheapo 433 MHz receiver is suspect.

I corrected the initial thread starter. Let me know if it's good now. Regards

wvmarle: OP mentions not receiving any data, that sounds like a protocol and/or frequency mismatch. As a rule of thumb, different radios can not communicate with one another, even if on the same frequency (e.g. LoRa, RFM69 and HC12 radios are can transmit at 433 MHz but won't talk to one another).

Hello! Thanks for replying! So if I understand correctly: I am successful in receiving data sent via 433MHz Tx, but I am unable to receive data from my DoorHan (garage remote) ?

Regards

Does your SDR dongle receive the signal from your remote okay? If so then record a couple or more presses of the remote as audio and using audacity see if the signals match between presses. If they don't then your remote is using a rolling code and life will be difficult. If they are the same then life should be easier.

Actually a rc-switch library example code called "ReceiverDemo_Advanced".

This won't work, as it detects only signals that match one of the recognized RC-Switch protocols.

Riva: Does your SDR dongle receive the signal from your remote okay? If so then record a couple or more presses of the remote as audio and using audacity see if the signals match between presses. If they don't then your remote is using a rolling code and life will be difficult. If they are the same then life should be easier.

Hello!

my SDR dongle I am using with SDR Sharp software receives the signal I posted above. Like I said I am trying to decode it in audacity (that is where the picture is taken from). Signal is the same on each button press.

thanks for reply! let me know

jremington: This won't work, as it detects only signals that match one of the recognized RC-Switch protocols.

Hey! So what you are saying is that I don't have recognized protocol? that I must write my own code?

best

So what you are saying is that I don't have recognized protocol? that I must write my own code?

Correct.

The chance that you will be able to figure out the remote protocol/code is vanishingly small for a garage remote. No one wants a thief to be able to open their garage door with a simple Arduino gizmo.

Do the experiment suggested in reply #6, post the results, and we will know for sure.

Hmm, I forgot to mention, the signal is exactly the same on each press. Same signal/ pattern that I posted above. I can upload and share the whole audio file if it’s better.

where can I read about this protocols?

Best

If the signal [u]really is[/u] the same every time you push the button, then it is not a rolling code. Just duplicate it and see if the door opens. Easy for a thief to do, too.

RF protocols tend to be proprietary and manufacturer-specific.

Hey, well I am trying to duplicate it. That's why I posted the picture above, so you guys can tell me if I decoded it correctly! if the above is correctly decoded then it's to long to be sent, as the biggest value it can be sent is 32bits. Need help on that. Also, how can I just duplicate it?

Best

EagerT0L3arn: my SDR dongle I am using with SDR Sharp software receives the signal I posted above. Like I said I am trying to decode it in audacity (that is where the picture is taken from). Signal is the same on each button press.

Okay, I was uncertain if you was receiving the DoorHan signal because of the reply in #5

So if I understand correctly: I am successful in receiving data sent via 433MHz Tx, but I am unable to receive data from my DoorHan (garage remote) ?

I see from other post the signal is the same so no rolling code, this will make the job easier. From the image you initially posted the on/off sequence before the long gap is just a signal to feed the receiver AGC (automatic gain control) so it reads the signal correctly. The gap is so the decoder knows the payload data is about to begin and then you have the payload with a long off period at the end of the payload. If you attach a sample recording to a post or upload it somewhere we can get it then working out the timings and code to transmit it will be easier. If you want to do the job yourself then the principle involved is to set Audacity to display hh:mm:ss + milliseconds and select the width of a few sample peaks and note the selected lengths. From the image it looks like each bit is the same time length and just the high/low duration determine if the the bit is a 1/0. Once you have the timings for the header, gap, zero & one you can create a simple program to replay a bit sequence that matches your remote.

Riva: Okay, I was uncertain if you was receiving the DoorHan signal because of the reply in #5I see from other post the signal is the same so no rolling code, this will make the job easier. From the image you initially posted the on/off sequence before the long gap is just a signal to feed the receiver AGC (automatic gain control) so it reads the signal correctly. The gap is so the decoder knows the payload data is about to begin and then you have the payload with a long off period at the end of the payload. If you attach a sample recording to a post or upload it somewhere we can get it then working out the timings and code to transmit it will be easier. If you want to do the job yourself then the principle involved is to set Audacity to display hh:mm:ss + milliseconds and select the width of a few sample peaks and note the selected lengths. From the image it looks like each bit is the same time length and just the high/low duration determine if the the bit is a 1/0. Once you have the timings for the header, gap, zero & one you can create a simple program to replay a bit sequence that matches your remote.

I uploaded audio file to be opened in audacity, let me know if you can download it. best

Assuming your sample rate is 37500Hz then measuring the lengths of highs/lows in the preamble shows each is about 15 samples. Measuring silence after the preamble it's about 135 samples long.

The payload bits are either... 30 samples high - 15 samples low (HHL) or 15 samples high - 30 samples low (HLL) This indicates a period rate of about 15 samples so first is 2 periods on, 1 period off (HHL) and the other is 1 period on, 2 periods off (HLL). The preamble is 1 period on, 1 period off (HL) repeated 12 times. The silence is about 9 periods off. With a sample rate of 37500Hz a period is about 400 microseconds (1 / 37500 * 15 = 0.0004uS)

It does not matter what one is the one/zero bit if your just going to repeat the pattern. Taking the 30-15 as a one bit and the other a zero then the payload looks like 66 bits... 111110011001110110111111111101100011110101110100111100110001101100

All we need now is to knock up some code to re-create this pattern. I can work on this later unless you prefer to do the code yourself?

Riva:
Assuming your sample rate is 37500Hz then measuring the lengths of highs/lows in the preamble shows each is about 15 samples.
Measuring silence after the preamble it’s about 135 samples long.

The payload bits are either…
30 samples high - 15 samples low (HHL)
or
15 samples high - 30 samples low (HLL)
This indicates a period rate of about 15 samples so first is 2 periods on, 1 period off (HHL) and the other is 1 period on, 2 periods off (HLL). The preamble is 1 period on, 1 period off (HL) repeated 12 times.
The silence is about 9 periods off.
With a sample rate of 37500Hz a period is about 400 microseconds (1 / 37500 * 15 = 0.0004uS)

It does not matter what one is the one/zero bit if your just going to repeat the pattern.
Taking the 30-15 as a one bit and the other a zero then the payload looks like 66 bits…
111110011001110110111111111101100011110101110100111100110001101100

All we need now is to knock up some code to re-create this pattern. I can work on this later unless you prefer to do the code yourself?

Woah!
Thank you very much! You calculated everything. I will first try to understand how you got to these conclusions then I will tell you whether I encountered any questions!
I will try to code the code myself first, I will post it here, then you can correct it okay? Think it’s only fair I try to write code myself, since you did all the work yourself :confused:

I greatly appreaciate it ! Thank you Riva!
Will update when I get done with what I said above.

best of regards!

EagerT0L3arn:
Woah!
Thank you very much! You calculated everything. I will first try to understand how you got to these conclusions then I will tell you whether I encountered any questions!
I will try to code the code myself first, I will post it here, then you can correct it okay? Think it’s only fair I try to write code myself, since you did all the work yourself :confused:

I just used Audacity wish scale set to h:m:s + samples and selected regions. It then shows the selected length in samples. To convert samples to time you need to divide 1 by the the sample rate (audacity says 37500 in lower left) to get the time of one sample and then multiply it by the number of samples in your selection to get the selection time.

I have already written code and checked the timings using a logic analyser. Obviously it wont work for you directly because I don’t know what pins your button and transmitter are connected to.
I have also written the code in a very simple and wasteful way to hopefully make it easier to understand and adapt.

sketch_sep25a_DoorHan.ino (2.14 KB)

Riva: I just used Audacity wish scale set to h:m:s + samples and selected regions. It then shows the selected length in samples. To convert samples to time you need to divide 1 by the the sample rate (audacity says 37500 in lower left) to get the time of one sample and then multiply it by the number of samples in your selection to get the selection time.

I have already written code and checked the timings using a logic analyser. Obviously it wont work for you directly because I don't know what pins your button and transmitter are connected to. I have also written the code in a very simple and wasteful way to hopefully make it easier to understand and adapt.

Hey Riva!

I did it all again, calculated myself and everything. I can say I fully understand the process now. I would just, in no bad intention, tell you that checking if button is pressed should be done so:

if(digitalRead(buttonPin) == HIGH)

I would however, want you to take a look at the audio recording, to tell me whether I am confused or I am right and the patterns are not all the same. I would really appreaciate if you did that!

EDIT: I checked again. Are we talking about rolling codes?

Thank you very much!