-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add support for KeeLoq HCS362 #3113
base: master
Are you sure you want to change the base?
Conversation
Does this PR only support TE 200uS or also 800, 400 and 100? |
You'll have to modify the timings (near end of file) for that. When finished with the decoder we might add the other timings also. |
ok it should be simple.
my keyfob has the same schema showed in FIGURE 2-1 c.
looking at FIGURE 3-5 it is not certain that the status of the buttons is transmitted in the fixed code part, but given that the id is variable XSER should be at 0.
The battery voltage is 3.09V at sleep state and drops to 3.0V when transmitting.
I don't know which is the current configuration, but with 3V (CR2430) battery, it should use a value 2.0 - 2.3V, so I should never see a low battery. However I can do a test using different voltages
I don't know which is the current id, but different id codes are rigth with XSER = 0. |
I hadn't seen in the code that the last byte of the serial is taken in half with & 0xF0, so the id doesn't have to change depending on the button pressed, instead it happens and the strange thing is that it also changes by pressing the same button, with a sequence incomprehensible. |
I tried to decode without using your code with the follow command
it seems that there is an extra bit that moves the fixed code, when the SW4 (S2) button is pressed there should be the last bit at 1 but instead it is 0, the rest of the buttons also seem to ignore S2 in the last position. |
Yes, there is a problem with the MC decoding, the initial short pulses are read as 0's but likely should be 1's. That also might shift (or truncate) the code by one bit. I really need to rewrite the MC slicer. I don't think decoding will be reliable this way -- e.g. that's likely why the battery low bit is set and why the id seems variable. |
MC transmission in HCS362 provides start and stop bits, I tried to understand the pulse_slicer_manchester_zerobit function and it doesn't seem to handle these 2 bits. |
In MC long pulse/gap provide a clock recovery but short pulse/gap do not initially. We can't know the clock until the first long symbol. The start/stop bits must be hardcoded a s known 1's. Other decoders have the initial bit hardcoded as known 0 (i.e. |
sure in FIGURE 3-4 it is shown as logic 1 |
I used Universal Radio Hacker for record and decode the trasmission, after I used a python script (chatpgt generated) which implement a MC decoder and I got good result:
serial is always the same and pressed button match. |
Yes, I used a manual MC decode now and strip the start bit. Output should match now. |
Yes, works now. Battery is 1, I don't know if is correct. |
I think battery_low should be shown without inversion, Learn mode doesn't exist as bit and repeat should show queue bits which are 2. |
I tested repeat with this code:
and works. In the next few days I will try to reprogram HCS362 with other configurations so I can verify that it works in all ways. |
Battery is actually |
Sorry for the delay. Now I can program the EEPROM of HCS362 and change every parameter. |
I changed gap_limit to 550 and not 600 and used this function from your first commit and some changes
and works. |
I optimized the code in a single function, tested both protocol num and works.
|
Sketch for HCS362, not tested at all. Based on info from #3112