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).

Configure I-Button

Reminder: if I-Button is configured, please delete the prohibit* lines from .vemscfg file before uploading to a public storage.

Enable in VemsTune in [Base setup menu/ECU calibrations].

And set the prohibit/iButton low byte, and prohibit/iButton high byte

For example : iButton serial code(6 byte hexa format): 000000FBC52B


I-Button setup checklist (step by step)

The iButton is an affordable 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 below) the ignition and injector outputs will stay inactive before the (correct) iButton is touched on.

Other functionality will work, eg. RPM detection and fuel pulsewidth and igadvn calculations can be verified.

The ECU can indicate if iButton not detected: warning light output channel must be P259 or S259 (not injector FET output or i259 - ignition output is also disabled).

HW mod - "1-wire keepalive" function

A recommended HW mod useful for 1-wire theft-protection (standard for assembled controllers ordered with 1-wire=yes option since 2010-10-29) is an RC (1MOhm resistor and 10 uF) on atmega128's knock-ADC pin, so the "1 wire keepalive" function can work (if also enabled in config).

With the "1-wire keepalive" function enabled, and this RC installed, after a reboot the "1-wire authentication" will be remembered for about 10 seconds, so no need to touch on I-button again if power is removed only for a short time (or ECU reboots during driving because of some intermittent alternator spike, misconfigured too high dwell or some other reason).

For any controller with 1-wire=NO (which means +1 ADC input) this is irrelevant.


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] might make sense to sand out the ID text from it if (before) it is passed to nonauthorized persons.
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)
several laserprinter manufacturers use I-button memory (the other popular choice is i2c) for Drum-lifecounter and Toner-chip so theoretically the chip could be reset from v3. Exact image-data-pattern would be needed (not just blanking the memory) and this operation is not supported.

Here is what i've found:


This is the international reseller list of Dallas:


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


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


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:

cat hex.pl 
#!/usr/bin/perl -w

foreach $i (qw(c1 e1 33 ff ff ff ff ff ff ff ff e3 c1)){
        print chr(hex($i));

Recevied sequence was: (2 bytes intentionally erased)

 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).


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::


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

See also

related (imaginary?) stuff: