I am writting to you cause I have a strange problem
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
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.
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…
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();
}
}
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.
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).
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) ?
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.
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.
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.
If the signal really is 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?
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
I greatly appreaciate it ! Thank you Riva!
Will update when I get done with what I said above.
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
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.
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?
