Jump to content
  • Welcome to 205GTIDrivers.com!

    Hello dear visitor! Feel free to browse but we invite you to register completely free of charge in order to enjoy the full functionality of the website.

lightflow

Decoding the Infra-Red Remote Central Locking

Recommended Posts

lightflow

I have a late Phase 2 and am lucky to have a working key fob and receiver for the central locking. The receivers can be subject to damage from water ingress from the roof and the key fob is of course vulnerable to all sort of issues.

 

I've always been fascinated with understanding how the key fob and receiver work and since I bought mine a few years ago I always intended to get into the guts of the electronics and understand how to decode the units - mainly in case I needed to repair, but also for interest. Over the years I have researched and pieced together information from a few sources sources which I've attached.

 

As the circuit technology is now 30 years old, whilst the circuits and electronics may still look modern - original datasheets and information are quite difficult to come by. Added to the fact that this is a security mechanism it's not widely documented how these devices work.

 

I'm going to keep this very short for the moment but will expand if anyone is interested to see more. Most of this information has previously shared by Laurent Deschamps:

 

http://laurent.deschamps.free.fr/plip/plip.htm

 

I thought it would be good to re-share (and add to it) in this topic forum so I have placed of copy of the documents of the key fob circuitry and some of Lauren's information into this forum for future reference.

 

Basically, the phase 1.5/2 key fobs send infra-red light pulses to the receiver dome in the ceiling console. The receiver is continually watching for the pulses and if it sees the correct sequence, it triggers a change of voltage on the wires which run down to the central locking control module which sits to the left of the steering column near the heater matrix. That change in voltage causes the central locking motors to cycle open/closed respectively.

 

The infra-red pulses carry a short, 5 digit, security code. That code is factory encoded into the key fob chip, which in the later Phase 2 key fobs, is the Philips OM1058T - it's an EEPROM device. It can be re-coded and should be possible, but I don't quite have the information on how to program this chip yet as it's not readily available. I know the general mechanism, but not the exact protocol required. It is very likely possible along these lines: Programming an EEPROM with an Arduino

 

The receiver which decodes the infra-red pulses is a variant of  the Philips TEA5500 and is covered in some detail by Laurent's web page. Generally speaking, the receiver is a simpler device than that of the Phase 2 key fob transmitter and the security code sequence is encoded at the factory with either the presence or absence of connections to a positive voltage, ground, or open (not connected). This is achieved by physical track connections on the board, some of which are drilled so that they are "open". It's possible to re-program a receiver to match a key fob by drilling or connecting tracks with solder - I'm not covering this here at the moment.

 

What I did want to start discussing was how to fault diagnose and decode the key fob signal. I'd been wanting to do this for a while and decided to get some components together to do this. I achieved it with some relatively simple electronics and the use of an Arduino Nano micro-controller - pictured in the attached document. I was then able to write some code and decode the key fob. In theory it would be possible to easily place this Arduino into a smaller, low-power, permanent circuit board, and create an after market receiver which could replace the original in the car. By writing this decoder, I have effectively made a central locking receiver module.

 

Let me know if you are interested in seeing more of the circuit and how I programmed the Arduino in order to decode the key fob signal. At the moment - I'm just posting to share that this was made possible using the Arduino and I'll expand more if anyone is interested in seeing how....

 

What I can add if you have a key fob and you are not sure it's working you can use a mobile phone camera to look at the key fob infra-red led as you press the button. You should see a short pulse of purple/white light through your phone screen which is not visible to the naked eye. If you have a key fob which you believe is working, but would like the code for, I should be able to decode it for you using the circuit I've made. This might be helpful if you are trying to put together a fully working pair from a spare receiver (which you can more easily re-code to match)

 

 

 

 

 

Key Fob and Arduino.pdf

Codage_du_numero.pdf

OM1058.pdf

Edited by lightflow
  • Like 2

Share this post


Link to post
Share on other sites
jackherer
1 hour ago, lightflow said:

What I can add if you have a key fob and you are not sure it's working you can use a mobile phone camera to look at the key fob infra-red led as you press the button. You should see a short pulse of purple/white light through your phone screen which is not visible to the naked eye.

Some phones (including at least some iPhones) have an IR filter on the main (rear) camera so this doesn't work, you have to use the secondary (front) camera on my phone. Test your camera using e.g. a TV remote before condemning a 205 plip.

  • Like 1

Share this post


Link to post
Share on other sites
AaronMountford1990

I found a company that was actually recoding these a while back I think they were on FB. 

 

Yeah I brought a Plip remote about 6 months ago with the intent of pairing it to my system, I just need to strip everything down and read the EEPROM as it's neater than link wiring the receiver. 

Share this post


Link to post
Share on other sites
lightflow

Aaron - do you mean re-write the EEPROM? If you did, do have any information on how to do so? The protocol for writing this is not documented anywhere that I have found (yet)

Share this post


Link to post
Share on other sites
2-Pugs

NicG and Henry Yorke on here have figured out the coding of those plips, if all you want to do is get it working.  You don't need to reprogram the EEPROM.  The code is set by joining or breaking tracks between pin legs.  Often there is a label with a code written on it, stuck to the chip.  Even if not, its possible to deduce it easily by looking at the circuit board.  You can then pair the two devices.  So if either fails, you can simply get a replacement and then with some judicious pcb work, match it to the plip.  Using this method you can pair as many plips to the receiver as you want.  Its possible to pair either one to the other, as I understand it.

 

But this is my fairly basic understanding of it, Nic may be along to expand :-)

Share this post


Link to post
Share on other sites
lightflow

Indeed Rob - how to encode the receiver to match the fob transmitter is all listed in the links at the top of my original post :-) 

 

Aaron knows this I think as he said above "...as it's neater than link wiring the receiver..." :-)

 

My preference would also be to know how to write the EEPROM on the key fob transmitter, there used to be OEM tools for this. However, this information seems to be lost or at least not published and I guess it is unlikely that Philips would ever track this down some c. 30 years later. Perhaps somebody might "know a guy who knows a guy..." at Philips. The informaiton will be somewhere out there I'm sure.

 

Having said that it's only a serial protocol which would be very easy to drive into the chip using something like an Arduino (as per my original post), it's just knowing what that serial protocol is...

Edited by lightflow

Share this post


Link to post
Share on other sites
stanz

Slight hijack thread but ties in nicely, Not driven mine for a few weeks, was out the other night in it on a dark country lane when the central locking circuit board in the roof console caught fire, could smell it first, thought it was clutch/brake smell then caught sight of the flame flickering just past the sunroof lever, thankfully managed to yank the console down,put the flame out and pull the wires apart. Could have got so much worse so quickly. Car does get really bad condensation when it's sat for a while or could have been leaking through the sunroof, just worth people keeping an eye on theirs. 

20191207_152213.jpg

20191207_152224.jpg

Share this post


Link to post
Share on other sites
jackherer
1 hour ago, stanz said:

worth people keeping an eye on theirs.

Add a fuse!

 

There has been some discussion on this subject recently, it seems to be happening more and more.

 

Share this post


Link to post
Share on other sites
stanz

Thanks for the link. Mine wasn't in use so not taking the chance anymore, going to delete the live from up there, don't think there's any need for it. Any further posting on this I'll put in that other thread

Share this post


Link to post
Share on other sites
UnintegratedCircuit

Hi folks,

 

First post here, just picked up a '97 Pug 106 a couple days back and it has the same IR locking as here (the OM1058 based key fob). In my case, the key fob wasn't working due to a severely underused clicky button on the PCB. This was fixed with a few drops of isopropyl alcohol directly on the stem of the tactile switch, and mashing it repeatedly, along with some forceful presses as well to break through whatever oxidisation was present.

With the key now working, I took it out to the car and when I pressed it, I could hear the locking mechanisms 'twitch', but the locks didn't actually actuate (i.e. lock/unlock the doors). I can take and attach/link to a video if that'd help?

As I understand, the OM1058 is not a 'rolling code' type (it only has a 24-bit EEPROM and the datasheet mentions a factory-programmed "individual code").

 

My question is, do my symptoms now align with an electrically faulty receiver (unable to drive the locking mechs?), or does it sound like it's receiving the wrong code? I'm not sure if there are any other possible failure modes of this basic receiver? I'm happy to do some poking around, but if anyone happens to know an answer first, that'd be jolly helpful. Mine does have a sunroof (no apparent leaks) so water ingress into the receiver is not impossible.

On a sidenote: what batteries did these take? Was it 2x CR2016 (with the higher voltage producing a brighter IR pulse)? If so, this could be worth me trying first.

Another sidenote: I have a good friend who works at NXP, I'll ask him to have a dig around for any declassified internal info on reprogramming the EEPROMs on the OM1058, assuming these haven't been lost in the past by now.

Share this post


Link to post
Share on other sites
UnintegratedCircuit

Second post it is then.

I can answer my own question in full:

No it wasn't the IR receiver being at fault, it was the central locking controller/'ECU'. This for me was a Kiekert one (part number 9611914080) which were also used on the 306 and some Citroen models so there are actually still replacements available (second hand) on eBay etc. It's a grey cuboid plastic case with a black socket and a brown plug with 9 terminals (1 of which is not populated).

 

To remove on a 1997 RHD peugeot 106 (since there isn't really a proper guide online):

  1. Remove the glovebox lid. There are two white plastic pins retaining this which are a bit of a nightmare to get to. I resorted to being upside down in the footwell with legs out the door, although removing the passenger seat is probably a good idea. I used a fairly short, fairly thin flathead screwdriver to pry these out. You have to feel right up and around the lip of the bottom of the glovebox lid. The one nearest the passenger door requires you to pull the bonnet release lever to get the screwdriver into the correct place to pry. Significant force was needed (though I am arguably kind of weak).
  2. You should see, just behind the fuse panel, a brown plug with 9 connectors and 8 wires. This is where the central locking unit is (and not right up against the firewall as other people mention). If you move aside the two loose-hanging relays (orange and blue in my case) this should reveal two torx screws (T10? T15?) which hold the grey plastic case in place. Remove these being careful not to drop the metal screws onto the live fuse panel (or just disconnect the battery and don't be lazy like me).
  3. manoeuvre the unit round into view and disconnect the brown plug. This was very tight for me and required plenty of wiggling side to side.
  4. Take the controller inside to a desk and pop off the black plastic sheath from the end. This has two locking tabs, one on each side. Press these in, and the black sheath should pop out fairly easily.
  5. Remove the PCB from inside, this is just a friction fit but again is quite tight. I used a pair of needlenose pliers on one of the metal contacts and just pulled straight outwards with some force and mild wiggling.
  6. The problem for me was 3 cracked solder joints (see photos) which were for one of the relays. I believe this is caused by age and possibly some slight mechanical resonance weakening the joints over time (all of those in that row were cracked but no others, and they were the furthest joints from the plug which would provide a degree of hard mounting). I used a medium-large sized soldering iron tip set to 380°C, leaded solder and extra rosin flux. Melt some solder onto the iron tip and heat the joint working your way around the pad for a few seconds at a time to melt through the lacquer coating. Clean the tip, apply plenty of flux, and repeat the previous step but whilst applying more fresh solder. You might hav to do this a few times to get the solder to adhere properly to the pad. Just like with paint, many thin coats (short attempts) are better than one thick coat (long attempt) as gross overheating will delaminate the copper pad from the PCB substrate, especially with cheaper bonded paper PCBs such as this one. Additionally, you could solder wires from the relay pin to exposed points on the PCB. The traces are easy enough to follow.

Reinstall the unit and test. I only tested with the IR remote in the fob, and now have both front doors locking and unlocking reliably. Still only using 1x CR2032 battery in the fob.

Glovebox Lid Pin.jpg

Kiekert Unit.jpg

Relay Cracked Solder Joints.jpg

Share this post


Link to post
Share on other sites
Leslie green

Good work  :D The pins were corroded off my little circuit  board below the sunroof due to a water leak and id like to get it working once the rest of my car is sorted .

Edited by Leslie green
  • Thanks 1

Share this post


Link to post
Share on other sites
UnintegratedCircuit

Ah disclaimer, this is not the IR receiver board shown in the picture, this is the central locking controller which basically just receives the lock/unlock signal from the switch on the drivers door lock mechanism and the IR receiver on the roof and translates it into a pulse which drives the lock motors one way or the other.

 

Fun bit of trivia, I believe that one end of the lock motors seems to be connected to 6V, and the other end is connected either to 12V or 0V through one of the relays. 12V - 6V = 6V (motor turns one way), and 0V - 6V = -6V (voltage reversed across motor thus it turns in the opposite direction).

Keep us posted on the IR receiver side of things, I'm happy to try help on the electronics (explanation or repair) side of things where I can :)

 

By the way, I have asked my NXP pal regarding the key fob EEPROM so we shall see if they find anything regarding how to program... If I stumble across a dead donor key then I'll investigate myself.

  • Like 1

Share this post


Link to post
Share on other sites
UnintegratedCircuit

Actually just had a thought, I may well just make my own PCB to go in the key fob. Given that the shell & blade blanks are cheap as, and they're fixed-code units, this should be plenty easy enough with just a small modern microcontroller. Just need to read up on the exact spec of the infrared pulses it puts out. I might even be able to make it user-programmable so as to act as a spare/replacement to existing systems.

  • Like 1

Share this post


Link to post
Share on other sites
Bremar

A pcb to go in a blank key (off ebay)  would be fantastic. Like me I guess there must be quite a few people who have broken or lost keys. Im certainly up for buying replacement key internals. 
Bremar. 

Share this post


Link to post
Share on other sites
UnintegratedCircuit

Good to know Bremar, I'll look into it probably starting this evening then - I'm attacking the car with clay, polish and wax today so that'll take a while.

Does anyone know how widespread these systems were? I believe they were installed on quite a few peugeot and citroen models, right? Not that it'll affect whether I make a batch of key fob PCBs (I want a spare regardless) - I'm just curious.

Share this post


Link to post
Share on other sites
SRDT

Renault was the very first tu use them on the Fuego with Peugeot not too far behind.

The 305/BX/205/309/405 remote/receiver combo was made mostly by Neiman (Valeo) that invented it but you can also find some Kiekert remote/receiver with similar exterior design and wiring. Jaguar used a Kiekert system on the XJ40 and the receiver design is clearly a variant the Peugeot one.

  • Like 1

Share this post


Link to post
Share on other sites
UnintegratedCircuit

The clay attack took longer than expected - just got the last bit of wax buffed off as the rain rolled in :) I've done some digging this evening and got the timing and protocol of my key. I won't be sharing loads of info on the design process itself, but rest assured it'll be happening. In theory though, with the info in this post, anyone could whip up their own if they were prepared to do the research, so I feel that's a fair trade?

 

As in the link at the top of this thread, the code is 24 bits (or binary digits, either a 1 or a 0) long. The protocol is pretty simple, see the TEA5500 datasheet in the top link for more info on that. Basically there's a periodic 'clock' pulse which is sent out once every 1.888ms in my case (I'll be specific because I'm not sure of the timing tolerances at play here). If a second pulse follows shortly afterwards (0.468ms in my case), that binary digit is a 1, otherwise, if there is no second pulse, that binary digit is a 0. Obviously this happens 24 times to make up the code. The code is transmitted 3 times. The width of each pulse was measured to be 0.041ms (or 41 microseconds). Below are some oscilloscope shots (I use a PicoScope 2204A) of a '0' followed by a '1', which should help the above make sense.

 

All you need to do is pulse an infrared LED (not sure whether it's 850nm or 940nm emission wavelength, both seem to be common, maybe it doesn't even matter?) according to those specs, with your car's code and it should lock/unlock.

 

Possible reasons why it wouldn't lock/unlock, in no particular order:

  1. Wrong wavelength infrared LED (again, maybe it matter, maybe it doesn't I don't yet know). This should obviously never be an issue with a genuine key.
  2. Wrong timing - pulses too close together or too far apart. This could be on the key side, or on the receiver side inside the car if either have drifted wildly out of tolerance.
  3. Wrong code for your car.
  4. Faulty receiver - think water damage/corrosion, cracked solder joint, failed component etc.
  5. Faulty key (again this would be a component failure or similar).
  6. Faulty central locking system - failed actuators, central locking controller, vehicle wiring, etc.

I guess 3, 4, 5, and 6 are pretty obvious, but perhaps the first two are less so?

Clock Pulse Period.png

Data Pulse Delay.png

Pulse Width.png

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×