Inspiration:
Remote infrastructure, particularly telecom baseband cabinets and industrial towers, often operate in isolated locations vulnerable to unauthorized access and tampering. Traditional security systems rely heavily on cloud-based processing, which introduces a dangerous flaw: if the network connection drops or experiences high latency, the physical asset is left defenseless. The inspiration behind TowerPulse was to eliminate this vulnerability by designing an autonomous "split-brain" edge node. The goal was to build a system that can mathematically verify a threat, physically lock down a cabinet, and sound an alarm in milliseconds completely independent of the cloud, while still providing a highly scalable, real-time telemetry dashboard for centralized fleet management.
What it does:
TowerPulse is a real-time, autonomous AI edge security framework. It uses ultrasonic acoustics to continuously monitor the physical perimeter of a telecom cabinet. If an object breaches a strict 30-centimeter threshold, the edge hardware instantly and autonomously triggers a localized piezo alarm and drives a physical SG90 servo deadbolt to lock the asset. Simultaneously, the system acts as a high-speed IoT telemetry node. It streams mathematically filtered distance measurements, device health diagnostics, and system states to a Next.js command center exactly once per second. The dashboard provides remote administrators with live acoustic DSP charts, infrastructure mapping, and a Gemini Intelligence Layer audit log that tracks every unauthorized access attempt and servo actuation.
How we built it:
The project was engineered using a dual-microcontroller architecture to separate physical actuation from network overhead: The Edge Processor (Arduino Uno): Serves as the primary localized brain. It polls an HC-SR04 ultrasonic sensor every 60 milliseconds. To prevent erratic locking from phantom echoes or acoustic noise, the Arduino runs a custom Digital Signal Processing (DSP) Exponential Moving Average (EMA) filter ($\alpha = 0.4$) to smooth the raw data stream. The Network Gateway (ESP32 DOIT V1): The Arduino transmits the cleaned telemetry via a 9600-baud UART serial connection to the ESP32. The ESP32 acts strictly as a 2.4GHz Wi-Fi gateway, packaging the hardware states into JSON payloads and firing HTTP POST requests. The Command Center (Next.js & React): Hosted on a local server, the React frontend utilizes a strict 1000ms polling hook to fetch the latest API data. It includes a 3.5-second watchdog timer that automatically flags the hardware as offline if the network connection is severed.
Challenges we ran into:
Acoustic Wave Collisions & Hardware Lockups: Initially, polling the ultrasonic sensor too rapidly caused soundwaves to crash into each other in the air, resulting in the Arduino locking up and returning a constant 999 error code. This was resolved by enforcing a strict 60ms hardware timer and clamping the physical listening distance to 250cm using a 15,000µs pulseIn timeout. Serial Buffer Traffic Jams: Because the Arduino measures data every 60ms but the Wi-Fi transmission takes up to a full second, the ESP32's serial buffer overflowed with stale data, causing massive lag on the dashboard. This was fixed by engineering a while (Serial2.available()) loop that instantly flushes the UART backlog, ensuring only the absolute freshest millimeter measurement is transmitted. Network Initialization Crashes: The ESP32 repeatedly failed to bind to the local hotspot, trapped in an internal wifi:Set status to INIT loop. We mitigated this by explicitly forcing the radio into WiFi.mode(WIFI_STA) before executing the connection sequence. Mechanical Servo Overshoot: The deadbolt motor jittered erratically because the microcontroller cut the PWM signal before the motor finished moving. We corrected the actuation logic by mapping exact 0-degree and 90-degree coordinates and injecting a strict 500ms mechanical travel delay to allow the gears to settle under load.
Accomplishments that we're proud of:
We successfully bridged low-level electronics engineering with modern full-stack web development. Translating raw, volatile sensor voltages into a clean, stable UI required a deep understanding of UART serial handshakes, hardware-level timing, and React state management. By preserving the EMA DSP filter and strict 1000ms polling constraints, we achieved a highly stable split-brain architecture where the physical security node never has to wait for a network response, yielding an enterprise-grade IoT fleet management platform.
What we learned:
The development process highlighted the critical importance of asynchronous buffer management between devices operating at vastly different clock speeds. We learned that mathematical filters are absolutely essential in the real world to translate noisy, volatile physical environments into usable software metrics. Balancing strict network pacing constraints with the need for instant physical security responses proved that hardware and software must be developed synchronously, not in isolation.
What's next for TowerPulse: Autonomous AI edge security for telecom towers:
Moving forward, the architecture is perfectly positioned to integrate true Edge AI directly onto the microcontroller. Instead of relying purely on a 30cm distance threshold, the next iteration will implement a lightweight 1D-CNN anomaly detection model to analyze acoustic signal variances and predict tampering attempts before the perimeter is actually breached. Additionally, we plan to expand the fleet grid to support multi-node mesh networking via Modbus or MQTT, and integrate GSM/LTE cellular modules into the ESP32 to ensure the command center receives telemetry even if the local Wi-Fi infrastructure fails.
Built With
- arduino
- arduino-uno
- automation
- c++
- dsp
- edge-computing
- embedded-systems
- esp32
- full-stack
- hardware
- hc-sr04
- http-api
- iot
- javascript
- json
- next.js
- node.js
- react
- security
- servo-motor
- signal-processing
- typescript
- uart
- wi-fi
Log in or sign up for Devpost to join the conversation.