Key Coding - A Trap For The Unwary

egremont · 23rd December 2017, 04:28

A friend called around early this morning with a customers 75 to code a key into its BCU.
Quite frustrated. We tried to enter the two line barcode (as printed on the tag), three times. The screen acknowledged that our encoded input was successful.
However when attempting to lock or unlock the door nothing worked.

In frustration, I delved into my parts box and gave him one of my keys. This time everything worked, and my friend was able to head off to work at the dealership.

A bad key is of no use to me. The barcode tag (dated 08/07/04)looked genuine, but I had not seen an expanded barcode that incorporated a forward slash (/). You will have to excuse my ignorance as I have probably only seen 50 or so 75 / ZT keys.

I decided to check the code slip on the circuit board: it recorded "N3D7643".
Both strings on the barcode slip differed. No wonder the BCU retained its barrier.

The question is, did someone down the line attach the wrong bar code tag to this key? Or is it a case of the operator needing a set of spectacles.

I suspect that when ordering spare keys, dealerships supply the cars VIN through the system to BMW Godolphin. BMW would then be able to identify the cars immobilisers coding from its records. After processing (coding) the immobilise, the key(s) is returned to the "dealership" for entering the coding into the cars BCU.

It dawned on me that is probably why (at least here in OZ) some folk think that you match the transponders details to the immobiliser at the same time that you enter the data via T4 to the cars BCU. Of course Godolphin, holding the immobilisers recordings in its database, simply code the transponder chip to match that already stored in the immobiliser.

I still don't know how a new key could go through the system with a faulty listed barcode.

23rd December 2017, 04:28	#1
egremont Loves to post Rover 75 Connoisseur SE. Auto. Saloon. SE Join Date: Apr 2009 Location: Melbourne Posts: 458 Thanks: 163 Thanked 198 Times in 70 Posts	Key Coding - A Trap For The Unwary A friend called around early this morning with a customers 75 to code a key into its BCU. Quite frustrated. We tried to enter the two line barcode (as printed on the tag), three times. The screen acknowledged that our encoded input was successful. However when attempting to lock or unlock the door nothing worked. In frustration, I delved into my parts box and gave him one of my keys. This time everything worked, and my friend was able to head off to work at the dealership. A bad key is of no use to me. The barcode tag (dated 08/07/04)looked genuine, but I had not seen an expanded barcode that incorporated a forward slash (/). You will have to excuse my ignorance as I have probably only seen 50 or so 75 / ZT keys. I decided to check the code slip on the circuit board: it recorded "N3D7643". Both strings on the barcode slip differed. No wonder the BCU retained its barrier. The question is, did someone down the line attach the wrong bar code tag to this key? Or is it a case of the operator needing a set of spectacles. I suspect that when ordering spare keys, dealerships supply the cars VIN through the system to BMW Godolphin. BMW would then be able to identify the cars immobilisers coding from its records. After processing (coding) the immobilise, the key(s) is returned to the "dealership" for entering the coding into the cars BCU. It dawned on me that is probably why (at least here in OZ) some folk think that you match the transponders details to the immobiliser at the same time that you enter the data via T4 to the cars BCU. Of course Godolphin, holding the immobilisers recordings in its database, simply code the transponder chip to match that already stored in the immobiliser. I still don't know how a new key could go through the system with a faulty listed barcode.