Decoding automotive RKE (Remote Keyless Entry) signal us

[JPKNHTP]

-JPKNHTP

[bodgy]

Does the original equipment use any code hopping techniques or advertised as using any special encoding?<p>If not, then an oscilloscope to view the signal is what you need and then steps taken from there.<p>I take it the Pic is to receive the signal and engage the remote starter?<p>There are a number of issues here especially as you say there is signal noise on the line. The Pics power supply would need to be made as spike proof as possible, which will involve an LC network and you might need to drive the output signal via some sort of opto isolator.<p>That is not to say of course, that with no precautions it won't work, it may work perfectly or you may find sometimes it works and sometimes it doesn't.<p>Another thought in decoding the signal, would be to ignore trying to make sense of it, and just try amd measure (by oscilloscope) how long the transmissions last, and if there is any sort of pattern. Then you might be able to use a simple RC filter in an input pin to capture the signal for a certain period of time.<p>Just typing out loud here, you understand.<p>For future reference, the bestest (sic) Pic to use in a vehicle is the specially design 16HV part. Not only is it designed to take the car voltage, but also contains it own anti spike circuitry. Though I'd probably still play safe and add more.<p>Have you googled about for any info on your BCM? Someone may have already done hard yards.<p>Colin

[jwax]

Pardon me, but aren't those codes made so you cannot do what you're attempting? Is it a rolling code? Sounds like a challenging hack to me!

[Gorgon]

If you have access to the signal from the BCM, I suppose it is already decoded from the remote control. If it isn't a direct control signal but some sort of telegram, it might be in the CAN-bus format. Some cars distribute internal information in this format. To decode it is another story.<p>I think some PIC controllers has this CAN interface module.<p>TOK

[JPKNHTP]

-JPKNHTP

[Chris Smith]

A scope is your only way. <p>You need to map the signal, as in signal length, signal width, and signal height. <p>Most scopes will look like a standard house key, notches [timing], spacing between tips [width], and height [voltage], all which are relevant to opening the lock.<p>[ June 29, 2005: Message edited by: Chris Smith ]</p>

[JPKNHTP]

-JPKNHTP

[bodgy]

If the signal doesn't use any fancy encoding, then you might get away with using the CCP function of the Pic or by using RA4 (if that's TOCKI on the 627)to just measure the signal and act accordingly.<p>If of course the signal wire from your unit is already decoded, then just a standard is the pin high type funcion will do the job.<p>If you feel like experimenting, you could try putting a diode in line with the gadgets signal pin (doesn't matter which way around )with a cap of something like 47nF - 1uF from pin to ground and with a multimeter see if you get a reasonable DC level. If the diodes anode is connected to the gadget signal pin then WRT ground, you will get a high. If you have the banded end (cathode) to the pin then you will get either a minus reading or a low depending on how you pronged your meter onto the circuit.<p>If this works, then you could use the same arrangement with the Pic BUT most important, either use a 4.7v Zener between ground and pic pin or use two diodes connected in series with the junction going to the Pic pin. Using a zener will also require a resistor in series with the Pic input pin to ensure that you don't bung too much current through the zener and the Pic. In fact I'd probably be inlcined to have the series resistor there anyhow just in case.<p>Colin

[philba]

<blockquote><font size="1" face="Verdana, Helvetica, sans-serif">quote:</font><hr>Originally posted by JPKNHTP:
Can't I just make the PIC micro just learn whatever signal it receives through programing? I could enable a pin to put the chip in "programming mode" and then whatever signal its gets when it's in programming mode it learns. But how can it "learn" the signal? If this is a thickheaded response I apologize I'm just curious not stubborn. Thanks again. -JPKNHTP<hr></blockquote><p>well, no.<p>You'll need to do a little more than that. You'll need to write a program that implements learning and recognition modes. It would sample the line (at >2X the speed of signal you are looking for) and save the signal it sees. Then in "recognition mode" it would compare the sampled signal against the input signal and if there is a match, then do what ever you want. The problem is determining where the start of the signal is and handling the noise you mention. Not a simple problem to solve in full generality (any signal recorded). You want to know more about the signal. As people have said, a storage scope would help you. Perhaps a logic analyzer would as well though you'd need to condition the signal so it does exceed the LAs limits.<p>I agree with gorgon, the signal is probably in some sort of networking protocol. As such, you will have to look for a pretty long sequence if you are recording/matching. CAN bus is a likely one to try. Look here for a list of various automotive buses If you can figure out the bus then you ought to be able to read the packets and do what you want. You could try googling around for info on what chrysler was using in 96.<p>[ July 01, 2005: Message edited by: philba ]</p>

[rstofer]

The way it is done when using a PIC for decoding IR Remote Control signals is to start a timer counting at the leading edge of the first pulse and then timing and recording pulse and gap widths until some long pause occurs.<p>It should be quite possible to store this pattern in the internal RAM of the PIC.<p>But, there is a difference between data and information. You will have a pattern without understanding. It may not matter if all you want to do is detect when it occurs.<p>I find it easier to use a logic analyzer for this type of thing. Particularaly when the signals are fairly slow.<p>I can hear the groans - "Logic Analyzer - too expensive". Well, maybe not! I built this one and find it far easier to use than my FPGA based analyzer, particularly for slower signals like IR Remotes.<p>If you can get a PC anywhere close and the logic signals are in +5 and ground. If not, you might be out of luck.

[rstofer]

Oops! I left out the link to the Logic Analyzer.<p>http://www.kronosrobotics.com/pj_analyz ... yzer.shtml

[Gorgon]

Hi,
If the signal is just some sort of pulse train, you need to recognize the 'open' pulse train.(this is also true for a communication type block) If you react on any pulse train, you will start the car for all codes, 'open', 'lock', 'open boot', 'alarm on/off'. If you stop the car manually it's not wise to start it again when you lock the door? Or, am I barking up the wrong tree? <p>TOK

[Chris Smith]

In theory it sounds good, However in reality hash, noise, impurities, actual signal to noise ratio, comparisons, voltage height, etc., will all be off slightly and probably by a degree that you wont or cant see, [you don’t have a scope] thus you have no ability to correct for it?<p> I did an exact type of project that required sound to be picked up, [dial tones for a lock] via a hard wire,[ and then by air] and then stored it in memory. <p>The problem was the sound level, distortion, decibels, etc,....all were recorded duly via a wire,...and all of the play back of these features [through a speaker] were either missing or over amplified,... and thus screwed up MY “fidelity” for any sort of play back recognition system. <p>When the sound was reproduced in a speaker environment, all the distortions were either absent or over amp-ed? <p>Thus it didn’t work? <p>Same goes for a Transistor pick up, or a light emitter circuit.