AH

PLAYER ZERO

[TINY CHIPS]
BIG IDEAS

A playful showcase of embedded systems projects, technical experiments, and things I enjoyed building.

CLICK HERE!!!
OR SCROLL TO VIEW!!!
Ahsan Here!!!LV.25
Dreamy pixel-art welcome scene: a smiling creator with glasses and a blue turtleneck sitting on a stone ledge, holding a tablet, a sleepy gray-and-white cat curled nearby, stacked books labeled AHSAN, a lantern, a backpack with cat pins, an iced coffee, floating starlit castles, a crescent moon, and soft lavender clouds
QUIET
CURIOUS
TECHY

MAIN QUEST

PROJECT ARCHIVE

[DEVICE PHOTO // 01]
VOICE_FEED_01REC ●
DATA FLOW

[SYSTEM MAP]

SPEAK
STREAM
TRANSCRIBE
REFINE
ARCHIVE
01

Meet Pause ^_^

A physical voice-journaling companion that turns unfiltered thoughts into an organized personal archive.

Pause is a physical voice-journaling companion designed to make reflection effortless.

  • With the press of a button, the user can speak naturally without worrying about structure or perfect wording.
  • Pause preserves the original voice recording in Google Drive and transforms the conversation into a polished journal entry in Notion.
  • Animated OLED expressions give the physical device a subtle personality, making it feel more like a quiet companion than a conventional voice recorder.

[TECHNICAL IMPLEMENTATION]

Built around an ESP32 and an I²S MEMS microphone, Pause streams audio over Wi-Fi to a Python and Flask backend. OpenAI Whisper performs speech-to-text transcription, while Groq restructures the raw transcript into clear, expressive prose without changing its meaning. The original recording is stored in Google Drive and the journal entry is saved to Notion—combining embedded hardware, networked audio, AI processing, cloud storage and API integrations.

[MCU]
ESP32
[AUDIO]
I²S MEMS Microphone
[DISPLAY]
OLED
[NETWORK]
Wi-Fi / Audio Streaming
[BACKEND]
Python / Flask
[AI]
Whisper / Groq
[CLOUD]
Google Drive / Notion
GITHUB ACTIONS
SUPPLY_CHAIN_01SBOM / CVE
1/2
DATA FLOW

[SYSTEM MAP]

INVENTORY
GENERATE
SCAN
REPORT
MONITOR
02

Securing Pause ^_^: SBOM & Vulnerability Monitoring

An automated software-supply-chain security extension for Pause ^_^, designed to generate SBOMs, track dependencies, and continuously check firmware and backend components against live vulnerability databases.

  • Automated SBOM Generation — A custom Python tool generates CycloneDX 1.5 SBOM files for the Pause firmware and backend ecosystem, documenting libraries, versions, metadata, and dependency information.
  • Hybrid Vulnerability Scanning — Standard package dependencies are checked against OSV.dev using version-aware queries, while embedded and Arduino / ESP32 libraries use NVD keyword searches as a fallback for potential CVE discovery.
  • Continuous Monitoring — A GitHub Actions workflow runs on repository pushes and on a weekly schedule, automatically generating SBOMs, scanning dependencies, and storing security reports as workflow artifacts.

[OVERVIEW]

PAUSE ^_^ → SUPPLY CHAIN SECURITY

After building Pause ^_^, I wanted to understand not only how the system worked, but also what software it depended on and whether those dependencies introduced known security risks. The result is an automated SBOM and vulnerability-monitoring pipeline that adds software-supply-chain visibility to the original embedded system. It connects embedded development with DevSecOps by continuously tracking firmware libraries, backend packages, and potential security advisories.

[FORMAT]
CycloneDX 1.5
[LANGUAGE]
Python
[AUTOMATION]
GitHub Actions
[SECURITY DATA]
OSV.dev + NVD
[INPUT]
components.pause.json / platformio.ini
[OUTPUT]
SBOM + vulnerability report
THEME DISCOVERY
PERSONA_FEED_01LOCAL PROFILE
DATA FLOW

[SYSTEM MAP]

NOTION
FILTER
VECTORIZE
DISCOVER
PROFILE
03

[MACHINE LEARNING / PERSONAL SYSTEMS]

Pause ^_^: Unsupervised Machine Learning for Journal Personas

I added a machine-learning layer to Pause to explore what a journal can reveal over time. The system reads journal entries from Notion, discovers recurring themes using unsupervised machine learning, and builds an inspectable persona profile that evolves as more entries are added.

  • Theme Discovery — Pause uses TF-IDF and Non-negative Matrix Factorization (NMF) to identify recurring themes across journal entries.
  • Evolving Persona — After three eligible journal notes, the system creates its first persona profile and updates it as more entries are added.
  • Inspectable Results — The profile shows discovered themes, important words associated with each theme, and links back to the journal entries that influenced them.
  • Journal Synchronization — Pause regularly checks Notion so edited or deleted entries are reflected in the persona profile.
  • Test Filtering — Short recordings created only for testing the physical device are excluded from the learning process using programmed rules.

[OVERVIEW]

VOICE → JOURNAL → THEMES → PERSONA

Pause originally transformed voice recordings into structured journal entries. I wanted to explore what happens when those entries begin to form a history. Instead of treating each journal entry as an isolated note, this extension analyzes the collection over time and looks for recurring topics, patterns, and themes. The result is a persona profile generated from the journal itself.

[THEME DISCOVERY]

UNSUPERVISED MACHINE LEARNING

Pause retrieves eligible journal entries from Notion and converts the text into TF-IDF feature vectors. Non-negative Matrix Factorization (NMF) then discovers latent topics across the journal.

  • Strongest associated words
  • Journal entries most connected to each theme
  • Profile version in which each theme appeared

[WRITING STYLE ADAPTATION]

RULE-BASED · LANGUAGE MODEL NOT TRAINED OR FINE-TUNED

When an entry is edited in Notion, Pause compares the revision with the original generated draft. It extracts simple patterns in entry length, paragraph structure, and formatting tendencies, then uses programmed rules to guide the presentation of future journal entries.

THEMES

→ Unsupervised ML

WRITING STYLE

→ Rule-Based Adaptation

[DATA HANDLING]

Persona data and profile history are stored locally using SQLite, including persona versions, discovered themes, theme keywords, linked journal entries, and writing-style preferences. This keeps the profile inspectable rather than turning it into a hidden black-box output.

[LANGUAGE]
Python
[ML]
scikit-learn
[FEATURES]
TF-IDF
[MODEL]
NMF
[STORAGE]
SQLite
[SOURCE]
Notion API
[TYPE]
Unsupervised ML
[STYLE]
Rule-Based Adaptation
N8N WORKFLOW
WORKFLOW_OPS_01N8N / SPLUNK
1/2
DATA FLOW

[SYSTEM MAP]

[WORKFLOW]

ESP32
PYTHON / FLASK
GOOGLE DRIVE + WHISPER
N8N WAIT
AUTHENTICATED CALLBACK
GROQ + NOTION

[MONITORING BRANCH]

PYTHON / FLASK
STRUCTURED JSON EVENTS
SPLUNK HEC
SPL SEARCHES
DASHBOARD + ALERT
04

Operationalising Pause ^_^: n8n Workflow Automation & Splunk Monitoring

An event-driven workflow and privacy-conscious monitoring layer for Pause ^_^, combining n8n orchestration with Splunk Cloud to manage delayed processing, monitor ESP32 activity and investigate application failures.

  • Stateful Workflow Orchestration — The Python application sends a privacy-safe job ID and delay configuration to an n8n webhook. An n8n Wait node persists the execution for the selected Pause period before securely calling the Python server to resume processing.
  • Privacy-First SIEM Integration — Pause sends structured JSON telemetry to Splunk Cloud through HTTP Event Collector. Events contain operational metadata such as event type, device, status, timestamps and error categories. Recordings, transcripts, diary entries, prompts and API keys are never sent to Splunk.
  • Monitoring & Detection — SPL searches track ESP32 connections, received recordings, triggered pauses, completed workflows, invalid requests and application errors. A monitoring dashboard separates successful activity from failures and supports detection logic for repeated errors within five-minute windows.

[OVERVIEW]

Pause ^_^ originally processed each ESP32 voice recording as one continuous request. I extended the system into an asynchronous, observable workflow. After the ESP32 uploads a recording, the Python/Flask application stores the original audio in Google Drive and transcribes it locally with Whisper. Instead of immediately continuing to Groq and Notion, Python creates a recoverable pending job and starts an n8n workflow. n8n receives only the job identifier, callback information and delay duration. Its Wait node pauses the execution without receiving the private recording or transcript. When the timer expires, n8n uses an authenticated callback to resume the locally stored job. Duplicate-callback protection prevents the same diary entry from being created twice. In parallel, the application sends a restricted set of operational events to Splunk Cloud using HTTP Event Collector. Structured JSON fields support investigation with SPL without exposing personal diary content. This project gave me practical experience with asynchronous workflow orchestration, webhooks, authenticated callbacks, Splunk HEC, structured telemetry, SPL searches, dashboard creation and basic security detection logic.

[INTERVIEW TAKEAWAY]

“I combined n8n and Splunk to separate workflow orchestration from operational monitoring. n8n persists and resumes delayed processing, while Splunk ingests privacy-safe JSON telemetry for investigation, dashboards and error detection.”

[TECHNOLOGIES]

Python · Flask · ESP32 · n8n · Splunk Cloud · HEC · SPL · Whisper · Groq · Notion API · Google Drive API

[WORKFLOW]
n8n Webhook / Wait Node
[SIEM]
Splunk Cloud / HEC
[BACKEND]
Python / Flask
[DEVICE]
ESP32
[TELEMETRY]
Structured JSON / SPL
[PRIVACY]
Metadata only — no private content
[PROJECT IMAGE // 04-A]
SERIAL_FEED_01UART 115200
1/3
DATA FLOW

[SYSTEM MAP]

FUZZ
CRASH
TRACE
PATCH
RETEST
05

ESP32 Serial Fuzzing & Secure Firmware Remediation

A low-level embedded security project exploring memory vulnerability discovery, crash reproduction, and secure firmware remediation on an ESP32 microcontroller.

  • Automated Fuzzing — A custom Python fuzzer progressively sends increasingly large multi-byte payloads over UART to identify input boundaries and trigger firmware failure conditions.
  • Vulnerability Validation — Testing demonstrated how an unbounded strcpy operation copying data into a fixed 16-byte deviceName buffer could produce a stack buffer overflow and crash the ESP32.
  • Secure Remediation — The vulnerable implementation was replaced with bounds-checked string handling using strncpy, explicit null termination, and regression testing against malformed and oversized inputs.

[OVERVIEW]

A targeted security assessment framework built to test, crash, diagnose, and ultimately harden a UART command parser running on an ESP32. The project combines automated Python fuzzing with low-level firmware debugging to identify unsafe memory handling, reproduce the resulting hardware failure, and verify the effectiveness of a secure firmware fix.

[MCU]
ESP32
[INTERFACE]
UART Serial · 115200 baud
[HOST]
Ubuntu Linux
[FUZZER]
Python · pyserial
[TEST METHOD]
Progressive Payload-Length Scanning
[VULNERABILITY]
Stack Buffer Overflow
[ROOT CAUSE]
Unbounded strcpy into 16-byte buffer
[PROJECT IMAGE // 05-A]
CAM_FEED_01100 NODES
1/3
06

10×10 Raspberry Pi Camera Array for Lightfield Acquisition

Supported the network infrastructure of a 100-node Raspberry Pi camera array designed for synchronized lightfield acquisition and experimental multi-camera research.

  • Configured network protocols and static IP addressing across the 10×10 Raspberry Pi camera array.
  • Set up and configured individual Raspberry Pi units within the distributed embedded system.
  • Ensured consistent network connectivity across the array for synchronized multi-camera capture.
  • Produced infrastructure and network architecture diagrams to document and communicate the system topology to the research team.

Worked on the embedded network infrastructure for a 10×10 Raspberry Pi camera array. My contribution focused on configuring and maintaining the distributed Raspberry Pi nodes so the array could communicate reliably during synchronized multi-camera capture.

[PAPER REFERENCE]

Near, Far, Wherever You Are: A Multi-Camera Array using a Modifiable Layout for Lightfield Acquisition

[PLATFORM]
Raspberry Pi
[SCALE]
10 × 10 Nodes
[NETWORKING]
Static IP / Network Configuration
[SYSTEM]
Distributed Camera Array
[DOMAIN]
Lightfield Acquisition
[ROLE]
Research Internship
Project 07 hardware setup
DATA FLOW

[SYSTEM MAP]

ARDUINOARDUINOBEAGLEBONE
BEAGLEBONEARDUINOESP32 ✦
07

Multi-Hop Embedded Communication & Real-Time Analysis

Built and analyzed a multi-device embedded communication network connecting Arduino, BeagleBone and ESP32 platforms across wired and wireless links. The system forwarded messages through multiple embedded nodes using UART, Wi-Fi/TCP and Bluetooth, then measured communication behaviour and timing across the complete network.

  • Implemented a bidirectional multihop communication chain across Arduino, BeagleBone and ESP32 devices.
  • Used UART for serial links, Wi-Fi/TCP for wireless networking and Bluetooth RFCOMM for the return communication path.
  • Measured an end-to-end round-trip time of approximately 3 seconds across the complete chain.
  • Extended the experiment with CPU-intensive load to observe how processor scheduling affected communication latency.
  • Investigated priority inversion using FreeRTOS with high-, medium- and low-priority tasks sharing a resource.
  • Compared a binary semaphore with a mutex using priority inheritance to show how scheduling affects time-critical tasks.
[PLATFORMS]
Arduino / BeagleBone / ESP32
[NETWORK]
UART / Wi-Fi / TCP / Bluetooth
[RTOS]
FreeRTOS
[ANALYSIS]
Latency / Scheduling
[CONCEPTS]
Priority Inversion / Inheritance
Project 08 hardware setup
DATA FLOW

[SYSTEM MAP]

LAPTOPARDUINOBEAGLEBONEESP32ROBOT
□ SQUARE△ TRIANGLE○ CIRCLE▭ RECT
08

Remote-Controlled Embedded Robot

Developed a remotely controlled mobile robot where high-level movement commands travelled through a multi-device embedded network from a laptop, via Arduino and BeagleBone boards, to an ESP32 on the robot.

  • The ESP32 interpreted commands locally and drove four shape routines — square, triangle, circle and rectangle — using PWM motor control.
  • Two independently driven DC motors ran without encoders or an IMU, so the motion system was fully open-loop.
  • Speeds and turn durations were calibrated experimentally to compensate for drift, friction and accumulated motion error.
[MCU]
ESP32
[NETWORK]
CAN / UART / Wi-Fi / TCP
[CONTROL]
PWM Motor Control
[MOTION]
Open-Loop Control
[HARDWARE]
DC Motors / Motor Driver
[TESTING]
Experimental Calibration

PLAYER INFO

STATUS: CURIOUS ✦

[ABOUT ME]

I like understanding how things work beneath the surface. I like building things that are practical, slightly weird, and fun to figure out.   Outside of that, I’m probably reading, learning guitar, playing chess, drinking a banana smoothie, or wondering what I should build next.