Brief
The project is a biometric access control system that uses a fingerprint scanner to grant access to an access-controlled space. Users are enrolled into the system, by adding their fingerprints to the system’s database, and they’re then able to gain access into the restricted space by scanning their fingerprints on the fingerprint reader. The project includes a custom PCB, which is powered by the ATMega328P AVR microcontroller, a 128×64 OLED display, a fingerprint reader module, a solenoid lock, and a magnetic contact switch which detects the state of the door. A good addition to the system would be a hydraulic door closer, which ensures that the door always shuts, and can subsequently be automatically locked, by the help of the magnetic contact switch.
Note to self: Take some damn photos of your projects, when working on them!
Primary objectives:
- Designing and implementing a system that controls access into a restricted space by using biometric verification
- Designing and developing a low-cost solution with minimal latency in its operations (verification, keypad access, display updates, etc.)
Hardware
The hardware for this project includes the following as the main components:
- Custom PCB including:
- ATMega328P microcontroller
- Buzzer and its switching circuit
- Connectors for: the OLED display, solenoid lock, fingerprint reader module, magnetic contact switch, push button
- OLED display module, 1.3 inch 128×64 resolution
- Solenoid lock
- Fingerprint reader module
- Magnetic contact switch
- Push button
- 5V power supply adapter
The custom PCB is powered by a 5V power supply adapter through a barrel-jack connector, which powers the components on the board.
The hardware components are connected as in the schematic below:
Software
The software for the system primarily includes the firmware that brings the entire system together to achieve its primary objectives.
The firmware for the system was architected as follows:
The system can exist in either one of the following states: idle state, default state, pin state, navigation state. The switching between the different states is controlled by use of the keypad which is the main user interface device.
- Default state – This is the default state of the system. When in this state, the system waits to read fingerprints on the fingerprint reader, performs verification, and grants, or denies access.
The system leaves this state to enter the pin state, on request from the user to access the configuration menu when the user long-presses a specific key.
- Pin state – The system enters this state from the default state when the user requests to access the configuration menu (administrator menu).
When in this state, the system reads passcode input by the user on the keypad to and grants or denies access to the user depending on the security code entered. The system doesn’t perform any fingerprint verification in this state.
This also where the option of logging in to the configuration menu using specific user fingerprints (administrator users) would be included. This option was however not included since it would have been more complex to implement. The system would also be less versatile for its particular use-case. It would require very specific users to be present in order to add regular users to the system, which was not logistically optimal. Though the latter could easily be addressed by including both options for logging in as an administrator.
The security code administrator access was sufficient for this particular system.
- Navigation state – In this state, the keypad would primarily be used to navigate the configuration menu. Fingerprint verification is also not performed while in this state.
- Idle state – This state (keypad state) is used when enrolling fingerprints to the system, at the stage when the only input required is the new fingerprint to be enrolled. Keypad access is paused in this state, with the exception of one particular key which enables navigating to the previous menu.
The display is configured to display either of the following types of user-interface screens:
- Selection screen – This is a menu screen within which the user can scroll (up/down) and make a selection of a menu component, using the keypad.
- Status screen – This is an information screen that displays a message to the user about the status of the system for a short period of time.
Status screens include: access granted/denied information messages on fingerprint verification, administrator access granted/denied information messages on security code entry, fingerprint enrollment success/failure, etc.
- Passcode screen – This is the screen displayed during security code entry.
The buzzer is used to provide audio feedback for the status of the system, supplementing the status messages displayed on the OLED. A single long beep indicates a successful operation, while three short beeps indicate an error state in the immediately completed operation.
I was pretty happy with the functioning of the system firmware. The system was able to operate quite well with very little latency in responding to user input (fingerprint verification and keypad inputs). The software could perhaps benefit from more robust architecture in the reading of user input signals, managing processing requirements and providing outputs. This would call for the employment of a different design pattern for the firmware. Perhaps making user inputs fully
event-based, and reducing the number of operations within the interrupt service routines, among other changes (the above were off the top of my head).
Challenges
- The system would occasionally freeze after a couple of hours of active running. This freezing meant that the system essentially stopped working until it was restarted by cycling the power
- User fingerprint registrations were not strictly enforced, which meant that a fingerprint could be registered more than once, which reduces the system’s fingerprint storage capacity. It also meant that it was difficult to remove fingerprints from the system.
- The system had no provision for a power backup. For the system to be operational, and for the solenoid lock to unlatch, opening the door, the system had to be supplied with power. Since the system was totally dependent on mains power, power outages meant that the controlled space was essentially inaccessible, unless a power source was connected to energize the solenoid and unlock the door.
- The system was deployed in a closed space, which meant that an unregistered user requiring access would have to be let in by the pressing of the exit push button. This turned out to be an inconvenience since occupants of the restricted space had to walk over to the door every time an unregistered user required access.
Solutions and Improvements
- I didn’t find the root cause of the system freezing. Determining the cause would require debugging which I didn’t find the time to carry out. The freezing was also irregular and difficult to reproduce. The immediate solution, in addition to cycling the power, was configuring a watchdog timer to restart the system every time it froze.
- A more robust user database would have to be maintained, since the version on the system only saved user data, without storing any other user details. The user database would store rudimentary user details in addition to the fingerprint data, to enable deletion as well as to ensure that a single fingerprint was not registered multiple times.
- Including a battery backup with charging circuitry to power the system during a power outage. This would ensure no system downtime.
- Also, to ensure the maximum battery-life, the system could switch to a low power state when running on battery power, occasionally waking up to perform fingerprint verification, and then returning to the low-power state.
- To make a provision for remote control of the system, additional hardware would have to be provided. This could be either wireless hardware (IR, Bluetooth, WiFi, etc) or an extended physical button connection to unlock the door from further away.
Final Thoughts
This project turned out to be a superbly successful prototype, even with its minor shortcomings. The system was installed and in use for at least a year. The project was an interesting learning experience. I was able to actively engage in every single stage of prototyping, including requirements specifications, design and development, and extensive testing of the system. A subsequent iteration of this system would address the major challenges, as well as improve user experience.
Adding connectivity to the system would bring along its own unique challenges, especially in protecting the system from external parties who would try to gain access. This is a consideration that I find is often overlooked for embedded systems and IoT. Protecting the system in case of any attackers is crucial to the proper operation of the system, but is often overlooked.
I may revisit this project in the future, and perhaps integrate an intrusion-detection system.
GitHub
Check out the code on GitHub: