An ID48 emulator chip is a unique form of ID48 chip. All ID48 chips come with their own unique identity and ID48 emulator chips are no different, they have their own unique ID too. However, the difference is that a standard ID48 chip has a fixed unique ID that cannot be changed, whereas the emulator chip ID is changeable and this can be done simply with the right tool.
This means that an emulator chip ID can be changed to the exact same ID as one of the vehicles existing dealer supplied keys; so the vehicle will believe it is the original dealer supplied key. Therefore, essentially the emulator chip clones from an existing keys ID and data in the cars dump and takes on the identity of the original key.
Why is it beneficial to use an emulator chip you ask? As an emulator chip can take on the identity of one of the cars existing dealer supplied keys, it means that the main dealer, when scanning this key will see that the key does indeed show up on their dealer VAS system (as it is the same ID as the key supplied by them). So in theory, when they attempt to recode the key they will not shut down the dashboard and clocks as they do when attempting to code in an aftermarket key with an ID that doesn’t appear on their system. This prevents future compensation claims from customers who have fallen foul of a big bill when a dealer attempts to code in an aftermarket key and doesn’t turn to the locksmith for compensation.
The other benefit is the coding process is quicker and simpler and doesn’t involve altering the vehicles dump file in any way.
The only downside is in the stolen key situation; when keys are stolen the customer will not want them to still be able to start the car for obvious reasons. But, if we have used the emulator to clone an existing keys ID, and the key we emulated is the stolen key, then both your new key and the stolen key will still work the car, thus leave the car at risk from whoever has the stolen key. For us it’s a balancing act; do we risk litigation if we have added a new key and deleted the missing keys when a dealer shuts down the dash trying to recode it? Or do we emulate an existing key to avoid this possible litigation; but then in a stolen key situation, realise the car is still at risk to the thief with the stolen key.
Only you, the user can decide this based on the job in front of you. I.e. is it a stolen key, is it just lost keys or is it broken keys etc. The best advice is to judge each job in its own rite.
Your existing tool works fine on the Ford Kuga; the Kuga is the same HU101 lock as all Fords with the difference being it only has 7 wafers in it and not the 10 you expected to find. You will only feel wafers in positions 3 to 9 on the tool as the lock has no wafers in positions 1, 2 and 10.
Had you picked the wafers you could feel in positions 3 to 9 then the lock would have opened. Both the kuga and the explorer only have 7 wafers in positions 3 to 9.
If you’re using the old NSN14 2in1 you won’t pick up all 8 positions in the door lock due to a lock modification on the Juke and some other late model Nissans (like the NV200 etc.) You need the newer 3in1 NSN14 tool which is modified to work on these newer locks - you will then pick and decode these with ease.
This is a problem many are facing at present. PSA, on some models, have discontinued the old JCAE remotes in favour of Delphi remotes. The dealers now update their vehicle systems to take the new Delphi remotes; to do this you will need the Peugeot planet dealer tool. At the moment it is still possible to obtain some JCAE remotes for these; but once they have gone the cars system will need updating to take the new Delphi remotes on sale.
If you have both in stock, check what system is fitted. Or if it’s a spare, check if the customers’ existing remote is JCAE or Delphi - a quick look under battery cover confirms this which is which.
An alternative to burning keys is to use the KD900 NB PSA remotes and generate the correct remote needed - this way doesn’t burn keys as a key can be rewritten if the wrong one is selected.
