Abstract
The lock was designed so that it could be easily changed should future students, inventors, or tech nerds decide they want to peruse our code to either enhance or alter our current functionality. The locks main purpose is to provide visual aid to the user who is attempting to enter in a code which will in turn lock or unlock their device.
Bluetooth Communications
Bluetooth provided us with a reliable and sturdy connection after the two devices were paired. As mentioned more extensively in the section for the key (link here) the lock uses Bluetooth to communicate action codes which allow it to know what the user is doing. The main difference between the Bluetooth on the key and the Bluetooth on this device is this device does not need, NOR SHOULD IT HAVE, the Biscuit firmware.
How It Works
The lock is the slave device in our system and never requests to send data back to it’s master, the key. In a way, the lock knows nothing until it knows something. By this we mean that the lock device will always be listening for an action code it recognizes, and won’t do anything until it gets a valid action code. If the action code is a direction then it updates the screen display accordingly, and if it is a press action then it will cause a system change accordingly. For example, if the user twists their hand to the right we will see a change of the screen display showing that the last direction captured was a right (East in our configuration) while a single click in this case would mean the user is entering the password.
Capabilities
The lock is able to do a few essential things through a combination of key presses and a quick navigation of our UI (link here):
- Lock the device
- Unlock the device
- Reset password
- Notify the user of an incorrect or correct password
Difficulties
The biggest difficulty we faced when creating the UI came when we were reading the Bluetooth data. While the design itself was simple, we wanted to allow for the user to change the last detected direction should it be incorrectly detected. While this may seem trivial, all of the inputs were coming through via Bluetooth so we had to wait, poll, act and then clear to prevent repeated actions based on the last input.
Code Archive
The entire lock archive can be accessed by clicking on the conveniently placed link right here -> Lock_Archive.zip This will provide you with all ‘*.h’ and ‘*.c’ files. The file with our commented code is labeled ‘lock.c’.