Final year project · University of Benin
Security need not be physical
That is the line my paper ends on. A padlock needs a key, a gate needs somebody standing at it, and neither one holds up against a crowd or against four in the morning. So instead I built a door that checks, and refuses.
Register, scan, open
The whole system does one thing. It is worth seeing it in one line before any of the parts make sense.
Register a card
Its ID goes on the list, in code
Hold it to the reader
No slot, no keyhole, no contact
The Arduino reads its ID
Every card carries a unique one
Is it on the list?
The only question the door asks
Yes
It unlocks, then locks itself again
No
It stays shut, and says so
Resting state
Scan tag to open door
Registered card
Access Granted Successfully
- Light
- Green
- Buzzer
- A single tone
- Lock
- Releases for a few seconds, then holds again
Unregistered card
Invalid card, please try again
- Light
- Red
- Buzzer
- A repeated tone
- Lock
- Does not move
I registered one card and deliberately left a second off the list. A demo that only shows a door opening has not shown you an access control system. It has shown you a door.
First problem: getting the parts
None of this is one order from one shop. Every component was tracked down separately, and a part that turns out to be wrong is a week gone, not an afternoon. Before anything could be designed, all fourteen of these had to exist on the table.
- Transformer
- Diodes
- Capacitor
- Resistors
- Arduino UNO
- LEDs
- Wires
- Voltage regulator
- Transistors
- LCD
- RFID reader
- RFID card
- Solenoid lock
- Buzzer
Then, one part at a time
Nothing was assembled until each piece worked alone. A fault found after everything is soldered into a sealed house means taking the house apart to reach it.
01
Power first, because nothing runs without it
Mains is not something you hand to an Arduino. Four stages, each one cleaning up what the last one leaves behind.
- 220V AC
- Transformer
- Rectifier
- Smoothing
- Regulator
The transformer, stepping the mains down 
Labelled by hand, because at 2am everything looks alike
02
Then something to say what happened
Four wires instead of a dozen. The board has fourteen digital pins, and the reader, the lock, the buzzer and both lights all want one, so the display went on the I2C bus and gave eight of them back.
The I2C backpack, which is what buys the pins back
03
The part that makes the decision
The reader hands the Arduino an ID, and the Arduino checks it against the list. It never powers the lock itself: a solenoid pulls far more current than any pin can give, so the pin switches a transistor and the transistor does the work.
04
Off the breadboard, for good
A breadboard is for finding out whether an idea works. It is not something you mount in a door and expect to still be holding next week. Every proven connection got soldered down.
Three things that went wrong
None of this is in the paper. It is the part that actually took the time.
01
The Arduino burnt out
I killed the first board and had to buy another. On a student budget that is not a line item, it is a fortnight. It is also why the lock is switched through a transistor and never off a pin.
02
The supply gave 9V, the lock wanted 12V
The solenoid is a 12V part and the supply I had built was delivering nine. Not enough to throw the lock reliably, which looks exactly like a software fault until you measure it. I added a 12V battery to bring the rail up.
03
Parts were slow to find
Every component was sourced separately, and the schedule was set by whatever arrived last rather than by the work.
And then it opened
Every output was brought out to one side of the board, so the thing can be rewired without taking the house apart to reach it. Cards go on and off the list in code, which means a resident who leaves stops being one.
The house itself I contracted out. The project was the door and the system behind it, and hand-building a scale house would have eaten the weeks the electronics needed.
This is the project I came to software from, and the one that taught me to build the failure path first. Nothing here can be redeployed. A mistake costs a component and a fortnight, not a git revert.
Best Graduating Student in Physics and Electronics Techniques, 2022/2023
The research behind it
The build did not stop at a working door. It was written up and published as a research paper, co-authored with K. O. Ojo in the Department of Science Laboratory Technology at the University of Benin.
That meant doing the reading as well as the soldering: what RFID actually is and where industry already relies on it, what an Arduino contributes to a security system, and what the literature says about contactless access control against a padlock and a person on the gate. Twenty-five sources sit behind the argument. The paper is where the engineering lives, in the detail this page deliberately keeps out of the way.
Download the paperOne line of personal contact details has been removed from the published copy.