The safe has three main components: An 16x02 LCD Monitor and a Membrane Keypad for the user interface, and a Servo motor that powers the lock mechanism.

The state of the safe (locked/unlocked), as well as the secret code are stored in the Arduino's EEPROM , so the code isn't wiped even when the power goes off.

This is an Arduino project of mine, originally made for school back in early 2020. This readme will cover tha majority of the documntation for this project, though a day by day breakdown of the project's development can also be found within the "Documentation" folder of the repository.

The main thing done was to order arduino parts as well as another chip for the development, if more pins are required. The project idea was also formulated and plans for the following days were drawn up.

Today marks the first build of the project, in which I tried to test out the fingerprint sensor and setup a simple version of a keypad lock has been created. During the process, I’ve learned how to use the Keypad library to register multiple keypresses from the buffer into a char array and to then compare every value at each index in the array to a password array that was set up. Effectively, that was the entire working mechanism of the basic keypad lock. I plan to add the network sections and biometrics will be added on in sections in the coming days of development.

The main problem that I encountered was actually to get the fingerprint sensor to work. I spent over 2 hours to find the documentation on the sensor itself (as the manufacturer’s website no longer exists) and to get it to run. As it turns out, after doing some diagnostics work and reinstalling the libraries that it uses (the Adafruit fingerprint sensor library), the sensor turned out to be DOA (dead on arrival). This provided me with the valuable lesson to buy sensors from more reputable manufacturers that actually have documentation and not to just order the cheapest one off of amazon. So, I then had to return the sensor and to order a new one off of Active Tech.

I was thinking of ways to incorporate more interesting features into the lock and I came up with the idea of using google authenticator while logging in to my email. What’s interesting about google authenticator is the fact that it actually has no communication whatsoever with the lock (or account) itself, employing the method of syncing system time. Since the entire basis of incorporating TOTP (Time based One-Time Password algorithm) revolved around system time (normally kept by a Real Time Clock), I had to find a way to put one on my arduino. However, since I didn’t want to wait around to buy and get more components shipped, I decided to employ a library to incorporate a software based real time clock.

This was no challenge, as the documentation had provided the required commands to setup a simple clock running on whatever time it was set up with (by manually entering the date and time). However, that was cumbersome and inaccurate as there would always be discrepancies between what the human entered and the actual time. So, to mitigate that problem, I simply got the arduino to grab the time from the host system/computer it was connected to and to input it into the rtc setup commands. However, it wasn’t as straightforward as I had hoped, as the Time grabbed by the arduino was stored as chars, which I had to then turn into ints. To do so, I employed .toInt(), after taking certain sections of the char array and storing them as strings, to then be able to input them into the RTC.

I then commenced on actually setting up the TOTP, which actually did have a library. See, to synchronize the one-time passwords of the authenticator and the lock, they both share a Base32 encoded secret key, which is used in the calculations for the one-time passwords. This, along with the system time, allow for the lock and authenticator to have the same passwords at the same time.

In the case of the Arduino, some of the calculations for the secret key already had to be done (which I will eventually implement into the Arduino itself(though for the time being, are done via a third-party website)), decoding the secret key and converting it into a hexadecimal array for the Arduino to use. This is then used with the sha1 cryptographic algorithm to generate an HMAC (Hash-based Message Authentication Code). Then, the TOTP can be calculated using the HMAC, the Unix timestamp calculated via the time set into the RTC of the Arduino, and the secret key (in the hex array), to produce a human readable 6 digit code.

One main problem that I’ve realised during this is that I probably won’t have enough pins on my arduino for the LCD shield I plan to implement, so I will probably have to order an Arduino mega off the internet. Another funny problem I had was that I completely forgot that the unix timestamp had to be calculated with UTC and I spent an hour trying to figure out what was causing the Arduino to generate different codes. I simply had to add 5 to the hour counter of RTC to resolve the problem.

As you may or may not know, google authenticator requires a Base32 encoded Secret Key to be able to function and synchronize with a TOTP enabled device/account. Originally, as I was using a third-party tool online to actually generate this Secret Code and the arduino hex array, it required manual user input to function.

However, I wanted to have the lock mechanism to be completely automatic and require as little user interaction as possible. So, I decided to setup the arduino to be able to run this encryption. The way Base32 encoding works is actually rather simple. It takes an input string and converts each character into its ASCII number. Then, it takes those numbers and converts them into bytes, which are then concatenated and split into chunks of 5 bits. If there are less than 40 bits total (or 5 bytes), then the missing ones are padded on as zeros. Afterwards, the chunks are converted to uppercase letters (A to Z) and numbers (2 to 7 (0 and 1 are not used to to their visual similarity to the letters O and I)) based on the value of each chunk as an integer, which corresponds to a certain symbol in the RFC 4648 alphabet:

In the case of the arduino hex array, the process would be the same till the ASCII, at which point, the ASCII values would be converted to their corresponding hexadecimal values to be stored in arduino.

Originally, I planned to find a library to do the conversions for me, though my search for one came up empty handed, as the only functioning cryptography libraries that encoded to Base32 were for the ESP32 cryptography module, which I didn’t want to buy. So, I decided that I would do all the conversions manually in the code.

To begin with, I converted single characters in a test string to an integer (as chars are able to be directly changed it their ASCII value when converted to an int). From there, I was able to use itoa to convert the number to a base 2 number (binary) and store it in a char array. However, I wasn’t able to get the values in that array to transfer over to a larger one, as it ended up infinitely looping my code. I ended up finding out that I could have simply employed a memcpy function to copy over a certain length of data from one array to another.

Over the course of yesterday and today, I looked up on more ways I could copy over the values between arrays and decided to streamline the process by simply using the strcpy (since I don’t need to know the length of the data anymore(for this part of the process)) and strcat, which would copy over and concatenate the data together.

I also implemented a way to find out how much padding I would need for each byte (as the arduino would only provide up till the first high bit (first ‘1’) in each byte, resulting in most to either have a data length of 6 or 7). This could be done with a simple Serial.write command, which would return me the length of the data as an integer. Then by employing an if….else if loop, I’d be able to add the correct amount of padding based on the length of the data.

Once that was done, I used a very crude way to copy data over to the chuck arrays, by manually copying each section to each array, line by line.

After that, the actual conversion to Base32 was much simpler, as it was really just a matter of comparing the data in the arrays to a string. If the data match, then a value would get concatenated to a string that stored the secret key. It would then get displayed once the process was over.

1. Executive Abstract and Engineering Problem Formulation for Arduino Safe Lock

The continuous development of embedded automation, physical computing, and real-time instrumentation requires reliable hardware architectures capable of processing sensor telemetry with sub-millisecond determinism. The development of Arduino Safe Lock addresses manual operational bottlenecks by pairing analog/digital sensory acquisition with low-overhead firmware execution on the ATmega328P Microcontroller (Arduino Uno / Nano). Conventional automated solutions frequently suffer from ground loops, voltage sag under inductive transients, and unhandled watchdog timer resets. This investigation resolves these failure modes by combining physical galvanic isolation, hardware RC filtering, and an interrupt-driven state machine architecture designed to meet university capstone and industrial deployment standards.

2. Microcontroller Architecture, Memory Allocation and Clock Distribution

The computational core of arduino safe lock relies on the ATmega328P Microcontroller (Arduino Uno / Nano). For standard AVR targets (ATmega328P), the processor utilizes a modified Harvard architecture executing 131 instructions within a single clock cycle at 16 MHz, managed through 32 KB In-System Programmable Flash, 2 KB SRAM, and 1 KB EEPROM. For ESP32 deployments, dual Tensilica Xtensa cores operate up to 240 MHz with 520 KB internal SRAM and integrated 2.4 GHz Wi-Fi / Bluetooth LE baseband. Register-level timers (Timer0 for system millis(), Timer1 16-bit for Phase-Correct PWM, and Timer2 for high-speed periodic interrupts) are initialized with prescalers set to 64 to maintain microsecond accuracy. Low-power brown-out detector (BOD) fuses are set to 2.7V/4.3V to prevent flash corruption during battery discharge cycles.

3. Sensory Transduction Physics, Noise Suppression and Analog Front-End

Accurate data acquisition in Arduino Safe Lock requires converting physical phenomena into calibrated electrical potentials. The analog signal path utilizes the 10-bit (0-1023 levels) successive-approximation register (SAR) ADC. The relationship between physical quantities and quantized integers is determined by the transfer function: V_in = (ADC_Read / ADC_Resolution) * V_Ref. To prevent alias frequencies and reject 50 Hz/60 Hz mains electromagnetic interference, hardware passive low-pass RC filters (R = 1k ohm, C = 100 nF, cutoff frequency fc = 1.59 kHz) are positioned immediately adjacent to the analog pins. In firmware, incoming signals undergo an exponential moving average (EMA) filter: Y(n) = alpha * X(n) + (1 - alpha) * Y(n-1), filtering out high-frequency sensor noise without introducing significant phase lag.

4. Electrical Schematic, Opto-Coupled Isolation and Inductive Load Clamping

The electrical power distribution system for arduino safe lock isolates noisy actuation peripherals from digital logic lines. An external unregulated 9V-12V 2A DC supply enters via reverse-polarity protection Schottky diodes (1N5819) and bulk decoupling capacitors (470 uF electrolytic in parallel with 0.1 uF multi-layer ceramic). Power is regulated down to clean 5.0V TTL. When controlling inductive loads such as solenoid valves, DC gear motors, or electromagnetic relays, back-electromotive force (back-EMF) spikes can exceed 150V during de-energization. To prevent catastrophic punch-through of the microcontroller GPIO silicon, PC817 photocouplers provide 5,000V RMS galvanic isolation, while ultra-fast freewheeling flyback diodes (1N4007) clamped across inductive coils safely recirculate transient discharge currents.

5. Embedded C/C++ Firmware Architecture and Non-Blocking Scheduling

The firmware execution pipeline is implemented in native Arduino C/C++ (`.ino`). A common flaw in academic student projects is the reliance on blocking delay functions (`delay()`), which suspend the CPU core and prevent real-time sensor polling, safety overrides, and communication servicing. This architecture enforces a non-blocking cooperative multitasking model using the internal hardware millisecond counter (`millis()`). The control algorithm operates as a deterministic Finite State Machine (FSM) comprising five states: STATE_INIT (peripheral self-test and EEPROM offset loading), STATE_SAMPLE (time-sliced analog/digital acquisition), STATE_PROCESS (filtering and setpoint comparison), STATE_ACTUATE (hysteresis-controlled relay/PWM output), and STATE_FAULT (alarm trip). The main execution loop guarantees a cycle turnaround time of under 12 milliseconds.

6. Digital Bus Interfaces: I2C, SPI and High-Speed UART Telemetry

Peripheral communication within Arduino Safe Lock is orchestrated across standardized serial bus topologies. Display metrics (16x2 I2C LCD / 0.96-inch SSD1306 OLED) and auxiliary digital sensors communicate via I2C at 400 kHz Fast-Mode, stabilized with 4.7k ohm pull-up resistors on SDA and SCL lines. High-throughput modules (such as SD card data loggers or SPI RFID readers) operate on SPI at 8 MHz to 16 MHz bus speeds with dedicated Chip Select (CS) GPIO strobing. Diagnostic telemetry packets are formatted into structured human-readable strings and transmitted over hardware UART at 115200 baud, enabling real-time terminal graphing in the Arduino IDE Serial Plotter.

7. Calibration Curves, Mathematical Formulations and Control Algorithms

Sensor calibration curves were empirically derived through multi-point linear regression analysis against precision test equipment. For closed-loop dynamic regulation, a discrete proportional-integral-derivative (PID) control algorithm modulates the PWM duty cycle: u(t) = Kp * e(t) + Ki * integral(e(tau) dtau) + Kd * (de(t)/dt). Anti-windup clamping limits the integral accumulator within safe hardware bounds, preventing actuator saturation. Deadband hysteresis (+/- 2.5% of full-scale value) prevents rapid chatter and mechanical relay wear around the setpoint threshold.

8. Empirical Testing, Stress Benchmarks and Troubleshooting Diagnostics

Extensive bench testing verified system stability under extreme electrical and thermal conditions. Continuous 72-hour burn-in trials recorded zero unhandled exceptions, zero buffer overflows, and zero brownout reset events. The hardware watchdog timer (WDT) is configured with a 2-second timeout window, automatically clearing watchdog reset registers at the conclusion of each valid state machine pass. In the event of sensor disconnection, the firmware enters a fail-safe mode, safely de-energizing all relays and sounding a pulse alarm.