Proximity Enabled Push-Button Start
As promised many eons ago, here is the thread I have created for my pushbutton start project.
Current Status: On hold until I get my 3D printer for making parts
Features:
-No keys!
-Toggle accessory mode by a single button press
-Hold button to start the car
-Auto TCS off output (optional)
-User-configurable through Bluetooth connection via smartphone app
Requirements:
-A properly operating car.
-Decent understanding of electronics and circuitry -- I'm doing this with zero formal experience or schooling, so it shouldn't be too difficult to figure out.
-PK3 bypass module.
-Arduino -- I'm using an Uno for development, but any 5v device with at least 14 digital pins should work. I recommend the Nano for its tiny size + USB port.
-Pushbutton -- I recommend one with two integrated status lights like mine has. This is the one I have (scroll down to LX Start Switch) (eBay link), except the backlight is red only and I got it on eBay for like $12.
-Wires of assorted colors, or the same color if you wish pain upon yourself -- 18-20awg should work fine.
-Soldering equipment -- very small tip is very recommended.
-Some optocouplers for the digital inputs we'll use to read the status of the car. I'll get an exact count and specifications when I reach this stage.
-Some relays. I'll get an exact count and specifications when I reach this stage.
-Some breadboard. Or a homemade PCB if you're a true baller.
-Resistors -- so far I've only used 150Ω resistors for the LEDs, but it's always good to have an assortment at your disposal.
-(04+ only) Spare key cylinder bezel if you're installing in place of the key (we still need to keep this assembly accessible, however) or make your own.
-Two (2) XBee Series 1 1mW for communication
-Balls of steel.
This list will change in the future as the project progresses. I do have a mocked up circuit along with the Arduino sketch mostly completed, and I'll get pictures/technical documentation up here shortly.
Concept:
I've decided to use two XBee radio devices to form the communication layer between the fob and the car. This choice was mostly made by convenience as well as feature set and general community support. Each XBee has a globally unique 64-bit serial number which we will use to identify each fob. The communication layer between them for the PAN (personal area network) also supports 128-bit encryption, which works perfectly for me since this will save me from having to figure out the encryption piece, allowing me to move right ahead to the dynamic key exchange which will drive the security of this system.
How It Works:
The fob will sit idle for 7 seconds with the radio in sleep mode (very low current draw for maximum battery life), then wake up and listen for the car's beacon. If the beacon is either too weak or not heard at all, the fob will sleep for 7 more seconds. If it receives a strong enough signal, the fob will request access to the PAN. If denied, the fob will sleep (this is the default behavior until you authorize the fob).
If allowed, the fob will request the current status of the car. If it is currently running, the fob will go back to sleep, but if it's off then the fob will request a key from the car. The car will then generate a 128-bit key and associate it with that fob's serial number, which will have a TTL (time to live) of 15 seconds. If the car does not receive a signal back from the same fob with that key within this TTL period, the car will invalidate the key and the fob will need to request a new one. This will happen automatically the next time the fob queries the car for its status and sees that it is not running.
If, however, the key is returned to the car within its TTL from the verified owner, the car then considers this key active and the driver has 15 seconds from this point to start the car. The fob will continue requesting keys until it is notified that the car is running, however the time slots overlap so there is no downtime between the end of the previous key's authenticated TTL and the new key's authentication period (unless of course . Once the new key is validated, the car will invalidate the old one, and so forth so we don't have a bunch of keys accumulating. I'll have a visual up sometime soon to graphically illustrate this concept for those of you who are having a hard time of putting it together.
Once the car is running, it will send a signal to the fob indicating its status. Once the fob is notified of this, it will once again go into idle mode, waking up and checking the status every 7 seconds.
