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.
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...111110011001110110111111111101100011110101110100111100110001101100All 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 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.
if(digitalRead(buttonPin) == HIGH)
I did it all again, calculated myself and everything. I can say I fully understand the process now.That's good. Better you understand something instead of having blind faith in someone else's ramblings. I would just, in no bad intention, tell you that checking if button is pressed should be done so:Code: [Select]if(digitalRead(buttonPin) == HIGH)Depends on how the button is wired. I tend to wire buttons to GND and use INTERNAL_PULLUP for the pin definition. This way the pin reads HIGH when the button is not pressed. When the button is pressed it connects the pin to GND and reading the pin it will be LOW. The reason for doing this is you don't need a resistors with the button as you would if you wired the button to VCC.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!I have looked and the codes are different every time the button is released and pressed but remain the same while a button is pressed for a long enough to repeat the TX.EDIT: I checked again. Are we talking about rolling codes?Looks like it. Can you send details (model number etc) and links to the remote controller your using, maybe we can find a compatible replacement or details on the rolling protocol used.
"algorithm of floating code for signal KeeLoq;"
The Microchip HCS301 was once the most widely used system on garage and gate remote control and receivers. The chip uses the KeeLoq algorithm. The HCS301 KeeLoq system transmits 66 data bits.34 bits are not encrypted : a 28-bit serial number, 4 bits of button information, and 2 status bits (repeat and low battery indicators).32 bits are encrypted (the rolling code) : 4 bits of button information, 2 bits of OVR (used to extend counter value), 10 bits of DISC (discrimination value; often the low 10 bits of the serial number), and a 16-bit counter. In a resyncing situation, the encrypted 32 bits are replaced with a 32-bit seed value.
So we found out there is 90% taht it's keeloq algorithm. How do we proceed in building our project with this knowledge?
You will need to determine the format of the Keeloq payload (probably documented nicely somewhere).Determine the key/serial number and discrimination value used to encrypt the Keeloq part of the payload (having the remote in your hand you might be able to brute force it with enough samples or try the side channel method)Write Arduino code to generate/emulate the Keeloq encryption so you can transmit it.All in all a very steep hill to climb.
What do you mean format of the Keeloq payload?This...I think I should read on how to decrypt keeloq yes? Hmm Will get back to you once I find out something, think it will require a lot of thinking and calculating :/Yes it will. The hard part would be figuring out the 64bit key used to encode the encrypted payload with.P.S. I saw Nohawk's methods on attacking rolling code, but that is only one time thing right? just to block code from being accepted to use it a later time, but only once?Yes, and this raises an interesting point/problem. Because of the sync counter you cannot make an exact clone of a remote and expect both to work properly as the last remote to transmit will have a higher sync counter so when you try to transmit on the other remote it will not work as its sync code has already been used.If you can program multiple remotes to the receiver then you can maybe make your own remote (a HCS301 costs about $1.50) with a unique serial that get over the sync counter problem mentioned above or just buy another remote.