GenBoard/VerThree has onboard electronics for supporting an iButton electronic key. It's supported from firmware 1.1.84 as an anti-theft device.
Even though it is supported, and "fancy", it is not the only possible solution for immobilizer, and NOT the best in all cases (since the 2nd serial port is more useful for [Android VemsDisplay]. Please read ImmobilizerSolutions
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
- prohibit/iButton high byte = C5 hexa -> 12*16+5=197 (in the example)
- prohibit/iButton low byte = 2B hexa -> 43(in the example, last byte of the iButton serial code)
I-Button setup checklist (step by step)
- Engine is tuned
- CEL (Check Engine Light, "warning output") is connected to P259 output. If the dash output light does not work for some reason, hook up a LED (or 2 LEDs in series; max 3 LEDs in series if they are all red) with 1k series resistor between a free p259 output and +12V
- verify that CEL is blinking after powerup (indicating "safe-mode") if I-Button antitheft is enabled
- touchon the configured button, and verify that blinking stops (TODO: upload video)
- when blinking has stopped, start the engine with the starter (disengage any other antitheft device if applicable)
- If using a very old fw (eg. 1.2.11) decide if behavior is exactly as expected
- Eg. newer fw (1.2.31 is newest at this time) might better tolerate bad contact, or if wrong ibutton was touched first (old fw might need power-cycle).
- In case of wish-item, or suspected problem, apply [error reporting procedure] with new fw, and new VemsTune (as behavior has likely improved, and old fw and VT release will be kept "as is" anyway, not changed).
The iButton is an affordable device with some nice properties:
- easy, fast and convenient touch-on (some immobilizer contacts are very small and must be touched rotated in the right direction: I find those very annoying)
- every iButton has its own unique ID number which makes it possible to make a simple check of the ID number against a list of known ID's stored in the VEMS EEPROM.
- more advanced iButtons have password protected memory in which the secret key could be stored (or temperature sensor, RTC clock, G-sensor, ...)
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:
- IRL10110: 10mm dia, max 7mm thick (recommended, default)
- IRL10130: 10mm dia, max 23mm thick
- IRL14130: 13.5 (?) mm dia, max 23mm thick (why so big?)
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.
Usage
- power up GenBoard/VerThree (do this first; maybe with a conventional key or a switch)
- touch the iButton onto the probe for a few milliseconds
- push the starter button (that cranks the engine)
- drive away
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:
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:
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.
![[Picture]](http://free.srv.hu/l/z/lzolcsi/images/shop/ibutton.jpg){kind=link}
![[Picture]](http://free.srv.hu/l/z/lzolcsi/images/shop/dallascsatl2.jpg){kind=link}
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
- I hooked up a test v3 with DS2480B chip to my linux PC
- connecting DS1990A iButton permanently is hard. I touched the iButton on during the experiment.
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):
- 0xC1 (reset, the DS2480B calibrates internal clock)
- 0xE1 (data mode)
- 0x33 (read sequence ID command)
- 0xFF (8 times; I don't fully understand why these "pulse command" bytes are needed, and if/why it uses VPP and arming)
- 0xE3 (back to command mode)
The same in a tiny perl program:\nÿ1ÿ
- I sent the output of the above simple perl program
- with gtkterm (alternative could have been minicom, or with perl or C program)
- to /dev/ttyUSB0 which was a UsbToFbus cable to the onboard (powered) DS2480B.
- I used a powered up v3.0 (but DS2480B TX,RX was hijacked cutting AVR=>DS2480B TX trace on the bottom of the board)
Recevied sequence was: (2 bytes intentionally erased)\n
00 33 01 8F .. .. 0C 00 - 00 51 CD
- 33 is just the command echo
- 01 is the "family ID of this button type"
- between 01 and 51: 6 byte ID printed on the iButton, but surprise: reverse order
- 51 is the CRC code (constant, since the ID is constant)
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:
- waiting for 0x33
- 0x33 received
- 0x01 received (X=0 N=0 special case of the states below)
- matched stored ID X upto byte N(=0..7). Take care: several IDs can have the same prefixes! So not enough to just check ID X for equality, but check all others as well that start similarly.
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:
- type (iButton, PS2/RS232 passwd, ...)
- a byte should hold the authentication bitfield. FF= everything is allowed (maybe this can include the ID-type described above)
- ID itself (6..7 bytes)
Authentication bitfield flags::
bits:
- engine start allowed
- driveaway allowed (putting to gear, higher MAP and rev above idle)
- high power allowed
- configuration change allowed
- table-tuning changes allowed
- reading conf allowed
- reading tables allowed
Putting it to the firmware should be child's play.
See also
related (imaginary?) stuff: