Show page

Differences

This shows you the differences between two versions of the page.

--- pm:prj2026:theodor_ioan.buliga:catalin.manole1211 [2026/05/22 23:38]
catalin.manole1211
+++ pm:prj2026:theodor_ioan.buliga:catalin.manole1211 [2026/05/27 04:29] (current)
catalin.manole1211
@@ Line 1: / Line 1: @@
-====== Walkie Talkie With Print Verification ======
+====== Secure Communication Terminal ======
 ===== Introduction =====
-The **Walkie Talkie With Print Verification** project is a fully digital, hardware-secured wireless communication terminal. Unlike a classic radio station, the device allows real-time voice capture, P2P transmission, and playback only if the user passes a **biometric authentication** filter. The system integrates a permission-based access hierarchy (Admin vs. User) and is controlled by an ESP32 microcontroller.
+The **Secure Communication Terminal** project is a digital, secured wireless communication device. Unlike a classic radio station, the device allows real-time voice capture, P2P transmission, and playback only if the user passes a **biometric authentication** filter. The system integrates a permission-based access hierarchy (Admin vs. User) and is controlled by an ESP32 microcontroller.
 **What is its purpose:**
@@ Line 10: / Line 10: @@
 **What was the starting idea:**
 The idea stemmed from the main vulnerability of conventional analog radio stations: lack of security. Anyone owning a station on the same frequency can listen or transmit. I thought about how I could implement a fundamental principle of cybersecurity (*Access Control* based on "Something you are") directly into the physical environment, transforming a simple communication station into a strictly restricted data terminal.
 ===== General Design =====
-To illustrate the architecture of the **Walkie-Talkie with Print Verification**, I have created a block diagram highlighting the hardware components and the data flow (communication protocols) between the peripherals and the central processing unit.
+To illustrate the architecture of the **Secure Communication Terminal**, I have created a block diagram highlighting the hardware components and the data flow (communication protocols) between the peripherals and the central processing unit.
 {{:pm:prj2026:theodor_ioan.buliga:diagramdrawn.jpg?700|}}
 ==== User Roles & Access Control ====
-The Walkie-Talkie supports two types of users: **Admin** and **General User**.
+The terminal supports two types of users: **Admin** and **General User**.
   * The Admin fingerprint is permanently stored and cannot be modified or overwritten.
   * Only the Admin has the authority to enroll or remove a General User's fingerprint.
@@ Line 30: / Line 29: @@
 If the device is unlocked (a user is logged in), the incoming audio is actively played through the speaker. Once authenticated, the user can receive and transmit freely for a **2-minute session** before the system automatically times out, locks itself, and requires re-authentication.
-The reset button must be held for 5 seconds to perform a full reset of the system. The user data is lost upon resetting.
+The reset button must be held for 5 seconds to perform a full reset of the system.
 ===== Hardware Design =====
 | Component | Quantity | Description | Interface |
+| --- | --- | --- | --- |
 | **ESP32 DevKit V1** | 2 | Main Microcontroller (WROOM-32) | - |
 | **AS608 Sensor** | 2 | Optical Biometric Fingerprint Sensor | UART |
@@ Line 41: / Line 42: @@
 | **Mini Speaker** | 2 | 20x30mm Rectangular Speaker (1W) | Analog |
 | **Tactile Buttons** | 6 | PTT, Admin Mode, Reset | GPIO |
-| **Battery Holder** | 2 | 4 x AA (for 4.8V NiMH Rechargeable) | Power |
+| **Battery Holder** | 2 | 4 x AA Slots Enclosure | Power |
+| **NiMH AA Batteries** | 8 | 1.2V Rechargeable Cells (4.8V pack per terminal) | Power |
+| **Custom Enclosure** | 2 | 3D Printed Case & Breadboard Assembly | Mechanical |
+| **DuPont Wires** | Set | Male-to-Male / Male-to-Female Jumpers | Wiring |
 **System Architecture & Power Management:**
@@ Line 49: / Line 53: @@
 **Detailed Pin Mapping & Motivation:**
 ^ Component ^ Peripheral Pin ^ ESP32 Pin ^ Signal Type ^ Design Motivation ^
 | **Power Supply** | Plus (+) Bat. | VIN | Power (4.8V) | System power. Feeds Amp directly and ESP32 regulator. |
@@ Line 58: / Line 61: @@
 | **Microphone (INMP441)**| VDD | 3V3 | Power (3.3V) | Native digital power. |
 | ::: | L/R | GND | Config | Tied to GND to configure transmission on the Left Channel (Mono). |
-| ::: | WS | D25 | I2S Clock | Allocated to standard output-capable pins for I2S0 Master mode. |
+| ::: | WS | D33 | I2S Clock | Allocated to standard output-capable pins for I2S0 Master mode. |
-| ::: | SCK | D32 | I2S BClock | ::: |
+| ::: | SCK | D18 | I2S BClock | ::: |
-| ::: | SD | D33 | I2S Data | ::: |
+| ::: | SD | D32 | I2S Data | ::: |
 | **Amplifier (MAX98357A)**| VIN | VIN | Power (4.8V) | Powered directly from batteries to prevent ESP32 brownouts. |
-| ::: | LRC / WS | D14 | I2S Clock | Allocated to the secondary I2S1 bus for independent audio output streaming. |
+| ::: | LRC / WS | D26 | I2S Clock | Allocated to the secondary I2S1 bus for independent audio output streaming. |
-| ::: | BCLK | D26 | I2S BClock | ::: |
+| ::: | BCLK | D27 | I2S BClock | ::: |
-| ::: | DIN | D27 | I2S Data | ::: |
+| ::: | DIN | D14 | I2S Data | ::: |
+| **Speaker** | Positive (+) | Amp OUT+ | Analog | Driven directly by the Class D Amplifier for high-efficiency output. |
+| ::: | Negative (-) | Amp OUT- | Analog | ::: |
 | **OLED (SSD1306)** | VCC | 3V3 | Power (3.3V) | Standard logic power. |
 | ::: | SDA | D21 | I2C Data | Native hardware I2C pins for maximum compatibility with the Wire library. |
@@ Line 71: / Line 76: @@
 ===== Software Design =====
-The project's software is built around a robust **Finite State Machine (FSM)** architecture, utilizing **FreeRTOS** capabilities for multitasking and asynchronous interrupt processing. The code directly integrates advanced time management features (Timers), hardware interrupts (ISR), and multiple buses (I2C, I2S, UART).
+The project's software is built around a robust **Finite State Machine (FSM)** architecture, utilizing **FreeRTOS** capabilities for multitasking and asynchronous interrupt processing. This allows the separation of time-critical tasks (audio streaming) from low-priority tasks (UI updates).
 ==== Libraries Used ====
 * **esp_now.h:** Chosen over classic Wi-Fi or Bluetooth to eliminate router dependency and ensure ultra-low latency, which is essential for voice transmissions (Voice-over-Radio).
-* **driver/i2s_std.h (ESP32 IDF):** Used for direct control of the I2S bus. Unlike a standard analog ADC/DAC, I2S allows pure digital reading of the microphone (INMP441) and digital control of the amplifier (MAX98357A), ensuring vastly superior audio quality free of circuit interference.
+* **driver/i2s_std.h (ESP32 IDF):** Used for direct control of the I2S bus. Unlike a standard analog ADC/DAC, I2S allows pure digital reading of the microphone and digital control of the amplifier, ensuring vastly superior audio quality free of circuit interference.
 * **Adafruit_Fingerprint.h:** Chosen for the efficient abstraction of UART communication with the AS608 sensor, greatly simplifying the complex mathematical operations involved in storing and matching biometric matrices.
-* **freertos/queue.h:** Vital for decoupling. It allows the separation of the radio reception process (ISR) from the audio playback process, using a memory queue to guarantee continuous voice playback without blocking when the processor is busy with other tasks.
+* **freertos/queue.h:** Vital for decoupling. It allows the separation of the radio reception process (ISR) from the audio playback process, using a memory queue to guarantee continuous voice playback without blocking.
-==== Finite State Machine (FSM) and Execution Logic ====
+==== Finite State Machine (FSM) and Logic Flow ====
 The application backbone runs through transitions between 4 distinct states:
-* **STATE_LOCKED:** The system is completely isolated (hardware Zero-Trust). It neither receives nor transmits data. Only the biometric validation of a registered user unlocks the device.
+* **STATE_LOCKED / ST_LOCKED:** Default state. The system is completely isolated. The I2S output is muted, and the system polls the AS608 sensor via UART.
-* **STATE_WAIT_ADMIN:** An intermediate state triggered by the Admin button. It awaits the exclusive validation of the fingerprint with ID 1.
+* **STATE_UNLOCKED / ST_UNLOCKED:** Reached after a valid fingerprint match. A timer is started (2 minutes).
-* **STATE_ADMIN_MENU:** The management menu. It allows enrollment operations (short press > 50ms) of a new user via a 3-step software routine (Read -> Lift finger -> Confirm) or their deletion (long press > 3000ms). It features an automatic 5-minute timeout to prevent leaving the system vulnerable.
+* **STATE_WAIT_ADMIN / ST_ADMIN:** An intermediate state triggered when the Admin ID (ID 1) is recognized. Enables 'Enroll' and 'Delete' functions via the Action Button. Features an automatic 5-minute timeout.
-* **STATE_LIVE_STREAM:** The "Walkie-Talkie" communication mode. By pressing the PTT button (configured as INPUT_PULLUP), the station instantly switches between Receiver and Transmitter modes (Half-Duplex).
+* **STATE_LIVE_STREAM / ST_TRANSMIT:** The "Walkie-Talkie" communication mode. Triggered by the PTT button (GPIO Interrupt), the station switches between Receiver and Transmitter modes (Half-Duplex). Audio is sampled via I2S and sent through ESP-NOW.
-==== Audio Flow and ESP-NOW Calibration ====
+To avoid needing excessive physical buttons, **temporal multiplexing** is used for the Action Button:
+  * **Short Press (< 2s):** If in ''ST_ADMIN'', it triggers the `fingerprintEnroll()` function to add the General User via a 3-step software routine.
+  * **Long Press (> 5s):** If in ''ST_ADMIN'', it triggers `fingerprintDelete(USER_ID)` to wipe the database.
-A major technical challenge was the limitation of the ESP-NOW hardware protocol, which strictly supports **250 bytes per payload**.
+==== Hardware-Level Encryption (AES-128) ====
-System calibration was achieved by reading the microphone stream (which is natively 32-bit) and truncating/packing it into a buffer of exactly **120 samples of 16-bit**. The result is a packet of exactly **240 bytes**, maximizing the available audio bandwidth without hitting the ceiling that would cause packet loss on the network.
+To prevent unauthorized interception of the radio traffic (packet sniffing), the system implements ESP-NOW's native **AES-128** encryption at the MAC layer.
+  * **Symmetric Keying:** A 16-byte secret key (''secretKey'') is hardcoded and shared between the ALPHA and BRAVO terminals. This acts as both the Primary Master Key (PMK) and the Local Master Key (LMK).
+  * **Secure Payload:** By setting ''peerInfo.encrypt = true'' during the peer registration phase, the ESP32's Wi-Fi hardware automatically encrypts the outgoing 240-byte audio payloads and decrypts them upon arrival. This zero-overhead hardware encryption ensures that the P2P voice stream remains strictly confidential.
+==== Communication Protocol & Audio Flow ====
+A major technical challenge was the limitation of the **ESP-NOW** hardware protocol, which strictly supports **250 bytes per payload**.
+System calibration was achieved by reading the microphone stream (which is natively 32-bit) and truncating/packing it into a buffer of exactly **120 samples of 16-bit**. The result is a packet of exactly **240 bytes**, maximizing the available audio bandwidth without hitting the ceiling that would cause packet loss.
 Received packets are captured through an interrupt routine (''OnDataRecv'') triggered asynchronously by the hardware, using the ''xQueueSendFromISR'' command to safely place the data into the playback buffer.
@@ Line 101: / Line 116: @@
 * **How:** The ''display.display()'' command was strictly restricted only to the moments when the device changes its state (e.g., transition from TX to RX).
 * **Why:** I2C is a much too slow bus compared to the frequency of the incoming radio packets (dozens per second). Updating the screen for every packet would have led to "CPU starvation", severely fragmenting the audio playback fluency.
-* **Where:** Audio Feedback Loop (Sidetone Cancellation).
-* **How:** The local playback of the microphone through its own speaker was completely suppressed in the code during transmission.
-* **Why:** The physical proximity between the INMP441 and MAX98357A components inside the case instantly generated acoustic feedback (howling) and distortion.
 * **Where:** Background Noise Management (I2S Speaker).
@@ Line 112: / Line 121: @@
 * **Why:** This hardware method completely eliminates electrostatic hiss and white noise while in standby, maintaining absolute "digital silence" until the next transmission.
-===== Software Design =====
+===== Results =====
+Demo Link : https://youtube.com/shorts/ny9w-C_flPQ?is=Uj0ZvqpBS-vCuD1a
-The software is built on a multi-tasking architecture using the **FreeRTOS** kernel available on the ESP32. This allows us to separate time-critical tasks (audio streaming) from low-priority tasks (UI updates).
-==== Execution Logic & State Machine ====
-The system operates based on a **Finite State Machine (FSM)** with the following states:
-  * **ST_LOCKED:** Default state. The I2S output is muted. The system polls the AS608 sensor via UART.
-  * **ST_UNLOCKED:** Reached after a valid fingerprint match. A timer is started (2 minutes).
-  * **ST_TRANSMIT:** Triggered by the PTT button (GPIO Interrupt). Audio is sampled via I2S and sent through ESP-NOW.
-  * **ST_ADMIN:** Triggered when the Admin ID is recognized. Enables 'Enroll' and 'Delete' functions via the Action Button.
-==== Logic Flow for Admin Actions ====
-To avoid needing 6 buttons, we use **temporal multiplexing** for the Action Button:
-  * **Short Press (< 2s):** If in ''ST_ADMIN'', it triggers the `fingerprintEnroll()` function to add the General User.
-  * **Long Press (> 5s):** If in ''ST_ADMIN'', it triggers `fingerprintDelete(USER_ID)` to wipe the database.
-==== Task Distribution (Dual-Core) ====
-To ensure "zero-latency" audio, the software is split between the two cores of the ESP32:
-  * **Core 0 (Communication Task):** Handles the **ESP-NOW** stack, packet encryption (if implemented), and sending/receiving audio buffers.
-  * **Core 1 (System Task):** Handles the Fingerprint UART polling, OLED I2C updates, and monitoring the GPIO buttons.
-==== Communication Protocol (ESP-NOW) ====
-We use **ESP-NOW** instead of standard Wi-Fi because it eliminates the handshake overhead.
-  * **Payload:** Each packet contains a 250-byte audio chunk (PCM, 16-bit, 16kHz).
-  * **Security:** Although the device is locked biometrically, ESP-NOW packets can be encrypted using a Pre-Shared Key (PSK) for hardware-level security.
-===== Results =====
-TBD
-===== Conclusions =====
-TBD
 ===== Download =====
+Project files can be found here:
+https://github.com/Catalin951/Secure-Communication-Terminal/tree/main
-<note warning>
-O arhivă (sau mai multe dacă este cazul) cu fişierele obţinute în urma realizării proiectului: surse, scheme, etc. Un fişier README, un ChangeLog, un script de compilare şi copiere automată pe uC crează întotdeauna o impresie bună ;-).
-Fişierele se încarcă pe wiki folosind facilitatea **Add Images or other files**. Namespace-ul în care se încarcă fişierele este de tipul **:pm:prj20??:c?** sau **:pm:prj20??:c?:nume_student** (dacă este cazul). **Exemplu:** Dumitru Alin, 331CC -> **:pm:prj2009:cc:dumitru_alin**.
-</note>
-===== Journal =====
-<note tip>
-Puteți avea și o secțiune de jurnal în care să poată urmări asistentul de proiect progresul proiectului.
-</note>
-===== Bibliography/Resources =====
-<html><a class="media mediafile mf_pdf" href="?do=export_pdf">Export to PDF</a></html>