ButtonImmobilizer (2010-10-21 10:17:14)

GenBoard/VerThree has onboard electronics for supporting an iButton electronic key. It's supported from firmware 1.1.84 as an anti-theft device.

An 8 pin DS2480B (1-wire) chip is used which can talk to the [iButton] via the 1-wire bus standard (the supply and bidirectional data is sent over the same wire: but a separate GND is also used of course).

The iButton is a cheap device with some nice properties:


Probe contact

To read the iButton, a small probe must be installed in the car. The probe is very nice: the stocked versions are all look the same: 25mm outer diameter, chrome bezel with 3mm red LED and small gold-color middle-contact.

The probe is installed into a simple (round) drill. Since the rim is GND, Maxim recommends that it is mounted on a non-conducting plane (to avoid ground loops).

The (min) drill diameter and max plate thickness the probe can be bolt on:

The probe can be installed to a visible or a secret location.


Anti-theft iButton

If configured (see behind) the ignition and injector outputs will stay low while the iButton not connected.

All other functionality of the ECU will work, so RPM detection and calculations can check.


Configurating

Enable in VemsTune in Base setup menu/Ecu calibration.

Set the prohibit/iButton high byte, it is the last byte of the iButton serial code ( set in decimal format)

And set the prohibit/iButton low byte, it is the byte before the last of the iButton serial code


iButton serial code

Each iButton has a uniqe 6byte serial ID, it is written on it in hexa format


Usage

Several circuits (ignition, injectors, starter, ...) could be cut by relays and only enabled when the iButton has been authenticated.


More ideas

Alternatively the cranking and starting might be allowed, but the engine would be shut if MAP, TPS or RPM raised above a threshold or clutch or gear-switch was switched before successful authentication.

In an advanced setup the revlimit and boost-limits could depend on the iButton (for child / wife / aggressive mechanic :-)


Advanced-user info

ID-only [DS1990A-F5] might make sense to sand out the ID text from it.
Password protected [DS1991]
Probe with LED [DS9092L]
Fobs for keyring
DS9093N + DS9093RA (angled through-hole fob, black, secures the iButton with a lock ring) or DS9093A-0 (angled snap-in fob, black)

Here is what i've found:

[software]

This is the international reseller list of Dallas:

http://www.maxim-ic.com/company/contact/sales_offices_en.cfm/filter/idistributors

Here is the germany reseller iButton page for example, you can find the above iButtons there:

http://www.spezial.de/eshop_artikel.php?nav=ps&navunter=Produkte&ATARTH=DALLAS&ATARTG=034120&HST=DALLAS&OGR=Automatic+Information&UGR=iButtons&attxt2=&attxt23=

And here is a page about iButtons, and accerssories for it:

http://para.maxim-ic.com/iButton.htm


Suggested buying list (eg. 20-25 pieces of each):

-DS1990A [Picture] ,[PDF] Looks like a button shaped battery.
-DS9093N iButton holder for keyring [PDF] (even though this is basically out of fashion, there are similar items in 5 color; this part looks a bit cheap plastic)
-DS9092 iButton probe for easy installing [Picture], [PDF] Why is the 25 quantity price (in EU) more than double than the 1000-quantity (US) price? The somewhat nicer, above IRL10110 ... items are used instead.

All are available (in quantity of 25). The last item, the panel-mount contact is a bit expensive, > 10 Euro (+VAT).

Anything else that we should look into (to stock)?

Is there a cheaper vesion of that panel mount contact? (besides 2 blanked wires - hehe :-)


Successful reading of the iButton ID

What codes are used to read out content?

I first read about iButton in 1992 or so. Since than I feel like I spent days with reading Dallas datasheets.

Now I suspect that the following sequence must be used at 9600 baud to read the ID of DS1990A when nothing else is on the 1-wire bus (DS2480B datasheet, page 23):

The same in a tiny perl program:\nÿ1ÿ

Recevied sequence was: (2 bytes intentionally erased)\n

 00 33 01 8F .. .. 0C 00 - 00 51 CD

I tried with another button too, it worked.

The problem was, I had to power down DS2480B each time. Otherwise I read C0 FF FF CD ... which was not good (I could only tell there was button on the bus: without button CF was returned instead of CD). Obviously, the DS2480 got confused, maybe remained in DATA mode (despite the e3).

With the longer qw(c1 c1 e1 33 ff ff ff ff ff ff ff ff e3 c1 e1 33 ff ff ff ff ff ff ff ff e3 c1) double sequence it worked any number of times. I couldn't come up with anything shorter that enabled safe reread if the device any number of times..

When the button is not on the 1-wire bus, the answer to C1 is CF instead of CD (apparently as in datasheet) and it reads code FFFF....

There is no need to continously poll the DS2480B, because if it's initialized into command mode (with an initial C1 or after the longer read attempt) it will report the touchon with a CD byte.

Implementation notes

The 0x33, 0x01 pattern sounds like a good way to initialize the comparison of the interesting 6 or 7 bytes (depending on if we check CRC or not).

States:

Where X can be 0..E allowing for max 15 IDs. F means none matched.

IDs can be stored in flash or EEPROM. ID structure:

Authentication bitfield flags::

bits:

Putting it to the firmware should be child's play.


See also

related (imaginary?) stuff: