What I've worked on or am currently productionizing.
Partition-Tolerant Offline Communications Stack
CurrentSOSMesh — Infrastructure-Independent Emergency Messaging & Supply Coordination. A decentralized, offline-first communication system that keeps messaging and resource requests alive during large-scale outages using a LoRa mesh network.
When disasters knock out cellular and internet, information becomes the bottleneck: people can't request help, responders can't triage at scale, and supplies can't be allocated efficiently. SOSMesh is an offline-first communication and coordination system that keeps critical messaging alive during large-scale outages using a LoRa mesh of low-power nodes plus an optional gateway for aggregation and responder workflows.
Requirements-Driven Engineering
SOSMesh was built from explicit operational requirements: reliable message delivery, long-range community coverage, fast connection + routing, rugged deployment, and multi-day operation without grid power. I formalized these needs using QFD to convert stakeholder goals into concrete engineering targets (e.g., payload constraints, routing behavior, reliability mechanisms, battery/runtime priorities) and to make tradeoffs explicit.
Architecture: Edge Nodes + Mesh Data Plane + Gateway Sink
SOSMesh is a layered system designed for partitions, interference, and bounded airtime:
- Edge ingestion: a phone app sends structured SOS requests over Bluetooth Low Energy (JSON) to the nearest node.
- Mesh relay: nodes perform store-and-forward multi-hop delivery across LoRa links when connectivity is intermittent.
- Gateway sink (optional): a gateway aggregates incoming requests for filtering, exporting, and operations workflows—while remaining functional even if the wider internet is unavailable.
This architecture is intentionally infrastructure-independent: it does not require towers, carriers, or centralized availability to provide local-area coordination.
Protocol & Reliability: Designed for Constrained Radios
LoRa is powerful but unforgiving: bandwidth is scarce, collisions happen, and "naive flooding" can melt the network. SOSMesh implements a controlled forwarding pipeline with explicit safety constraints:
- Compact serialization: JSON requests are encoded into a binary LoRa packet under a ~200-byte limit
- Deduplication cache: repeated packets are dropped deterministically to prevent storms
- Hop-limited propagation: packets expire via bounded hop count (e.g., ≤8)
- Collision avoidance: randomized backoff reduces contention under load
- Retry discipline: limited retries per hop (e.g., ≤3) preserves airtime for high-priority traffic
Coordination: SOS Requests as Structured Events
SOSMesh supports more than chat. Requests are modeled as typed, machine-actionable events (e.g., medical, food, shelter, evacuation, utilities) with urgency and metadata, enabling:
- Triage filtering (critical first)
- Aggregation and batching (reduce operator overload)
- Clear lifecycle workflows (request → routed → received → handled)
This is what turns a radio network into a coordination system.
Sustainability & Field Viability
Because SOSMesh is meant for real deployments, I evaluated repairability, reuse, and end-of-life constraints alongside performance. Modularity improves reuse and maintenance; recovery-chain friction (e-waste pipelines, limited recycling routes, Li-ion handling requirements) informs material and enclosure decisions so the system can scale responsibly.
Perfect-Play Engine
CompletedChomping Glass Solver is a Rust perfect-play engine plus Solana execution client for an impartial combinatorial game (the 5×8 "Chomping Glass" variant). The core engine models game states as Ferrers shapes and runs a memoized depth-first search to classify every reachable position as winning or losing under impartial game theory.
Chomping Glass Solver is a Rust perfect-play engine plus Solana execution client for an impartial combinatorial game (the 5×8 "Chomping Glass" variant). The core engine models game states as Ferrers shapes (canonical column-height tuples) and runs a memoized depth-first search to classify every reachable position as winning (N-position) or losing (P-position) under impartial game theory. From this, it generates a complete policy table: a full opening book and the set of optimal replies from every state. The entire strategy can be exported to JSON for inspection, reproducibility, and regression testing.
On the blockchain side, the CLI acts as an end-to-end toolchain for interacting with the live on-chain game. It derives the player's PDA game account, decodes the on-chain 5-byte row-bitmask state into the solver's canonical representation, computes the deterministic optimal move, and submits it as a compact one-byte opcode (4 bits row + 4 bits column) inside a signed Solana transaction with the correct account metas. The result is a tight loop: inspect real-time game state, compute perfect-play actions locally, and execute optimal moves on-chain from a local wallet.
Outcome: the solver identifies a unique winning opening move at (1,2) and maintains a forced-win policy under optimal play, returning optimal responses from any reachable position.
Strategy
The solver reveals that the game has a unique winning opening move at position (1,2), and maintains a complete policy table mapping every reachable state to optimal moves. This enables perfect play from any position, making it impossible for an opponent to force a win when playing optimally.
Technical highlights
- Canonical state encoding via Ferrers shapes for collision-free memoization
- N/P-position outcome classification with cached search over the full reachable state space
- Strategy extraction: complete opening book + optimal reply mapping for every state
- Solana integration: PDA derivation, bitmap decoding, 1-byte move encoding, transaction construction & signing
Mixed-Integer Optimal Dispatch Engine for Energy Systems
CompletedA Mixed-Integer Linear Programming (MILP) optimizer for scheduling energy resources in a hospital microgrid. Optimizes dispatch of grid connection, solar PV, battery energy storage, and diesel generator to minimize operational costs while satisfying demand and physical constraints.
Reliable power is non-negotiable for hospitals—especially in remote settings where grid import is constrained and diesel generation is often the last line of defense. In this project, I built a 24-hour optimal dispatch engine for an actual hospital-style microgrid case (realistic load shape + transformer import limit), integrating solar PV, a battery energy storage system (BESS), a dispatchable diesel generator, and a grid connection with a hard capacity cap.
The goal is simple to state but hard to solve: minimize daily operating cost while guaranteeing feasibility under real operational constraints (ramping, minimum up-time, startup penalties, battery SoC physics). This is exactly where "greedy" dispatch fails and mixed-integer optimization becomes essential.
Why this is not a toy LP
I modeled the microgrid with realistic equipment and operational limits:
- BESS: 500 kWh capacity (bounded SoC), 125 kW charge/discharge limit, 95% charge & discharge efficiency, cycling (degradation) cost
- Diesel generator: min stable output 20 kW, max 118 kW, startup cost, ramp-rate limit, and minimum up-time (6 hours)
- Grid transformer limit: 60 kW hard cap on imports (active constraint by design)
- PV + load + tariff: hourly profiles across 24 hours (peak-driven hospital demand + time-of-use pricing)
Constraints enforced each hour include energy balance, SoC dynamics and bounds, end-of-day "reusability" (no battery dump at the horizon), exclusivity (no simultaneous charge/discharge), and full unit-commitment logic (on/off + startup + min up-time + ramping).
Mathematical formulation
I formulated the problem as a Mixed-Integer Linear Program (MILP):
- Continuous variables: grid import, PV used, battery charge/discharge power, generator output, battery SoC
- Binary variables: charge/discharge mode, generator on/off, startup indicator
- Objective: minimize total daily cost (grid energy cost + generator fuel/O&M + battery degradation + generator startup penalties)
Implementation + solver validation
Implemented in Python (Pyomo) with two independent MILP solvers:
- HiGHS
- COIN-OR CBC (Branch-and-Cut)
Both solvers returned the same globally optimal schedule and matched costs, providing strong evidence that results are numerically stable and not dependent on a single solver's heuristics.
Core insight the optimizer found
A key result is counter-intuitive: the diesel generator stays ON for the full 24 hours, often at minimum output, even during cheap off-peak grid pricing.
Why? The answer is feasibility under a binding transformer limit.
During night hours, hospital load saturates the 60 kW grid cap, leaving no headroom to charge the battery from the grid. To ensure enough stored energy to survive the large evening peak, the optimizer must run the generator at its minimum setpoint to create the extra power needed for overnight BESS charging. This is exactly the type of multi-hour, constraint-coupled decision that greedy dispatch misses.
Performance: global optimum in sub-second time
Despite being a nontrivial MILP, the solve completes in < 0.5 s and explores only 10–21 branch-and-bound nodes, indicating:
- strong linear relaxations (tight bounds → aggressive pruning)
- effective presolve reductions
- efficient LP solves per node
In other words: a real unit-commitment model, solved quickly enough to support rolling-horizon EMS operation.
Scenario analysis (robustness checks)
I stress-tested the model with structured what-ifs:
- Lower startup penalty: generator still stays online → behavior is constraint-driven, not cost-driven
- Higher fuel price: generator shuts down earlier → marginal fuel dominates, optimizer leans harder on grid
- Relaxed grid cap: generator runs only near peaks → MILP collapses toward an LP as commitment becomes less necessary
Brain–Computer Interface: 12-Class SSVEP Decoding
CompletedAn end-to-end decoding pipeline for Steady-State Visual Evoked Potentials (SSVEP) that reliably identifies which stimulus frequency a user is attending to, turning attention into discrete commands for BCI control. Implemented with FFT + Canonical Correlation Analysis achieving 93.1% mean accuracy across 10 subjects on a 12-class benchmark.
Brain–computer interfaces (BCIs) create a direct pathway between brain activity and external devices—enabling communication and control even when neuromuscular pathways are impaired (e.g., ALS, paralysis, stroke). This project focuses on Steady-State Visual Evoked Potentials (SSVEP), a high-signal-to-noise EEG paradigm where a user fixates on a flickering visual target and the brain generates a frequency-locked response measurable over occipital cortex.
The goal: build an end-to-end decoding pipeline that reliably identifies which stimulus frequency a user is attending to, turning attention into a discrete command for BCI control.
Why SSVEP BCIs work
When a subject focuses on a repetitive visual stimulus (typically >6 Hz), EEG power increases at the fundamental stimulus frequency and its harmonics, especially in occipital / occipito-parietal channels (e.g., Oz). This structure makes SSVEP particularly well-suited for multi-class classification with interpretable frequency-domain methods.
Dataset and task setup
We used a widely cited 12-class SSVEP benchmark dataset (Nakanishi et al., 2015):
- 12 flicker frequencies: 9.25–14.75 Hz (frequency-coded commands)
- EEG: 8 channels, sampled at 256 Hz
- Trials: subjects gaze at a target for 4 seconds, repeated across trials
- Goal: decode the attended class from short EEG windows
This is a realistic BCI setting: multiple commands, short decision windows, and noisy biological signals.
Implementation: full signal-processing → classification pipeline
Implemented in Python (NumPy / SciPy / scikit-learn), emphasizing correctness and reproducibility.
1) Preprocessing (noise + relevance filtering)
Extracted the task window per trial. Applied a 6–40 Hz bandpass (4th-order Butterworth) using zero-phase filtering (filtfilt) to preserve phase characteristics while removing drift and high-frequency noise.
2) Epoching / segmentation
Segmented trials into 4-second epochs (matching the stimulus fixation window). Structured data into consistent tensors: (class × channel × trial × samples) for reliable batch processing.
3) Frequency-domain verification (FFT)
Computed FFT magnitude spectra to confirm the expected SSVEP signature: peaks at the stimulus frequency and harmonics, strongest in occipital channels. This step isn't just for plotting—it's a validation layer that the signal is separable before classification.
4) Classification with Canonical Correlation Analysis (CCA)
CCA is a standard, high-performing approach for SSVEP detection because it matches EEG against analytically generated templates:
- Generated sin/cos reference signals at each target frequency, including harmonics
- For each EEG epoch, computed canonical correlations against each frequency template
- Predicted the class with the maximum correlation, yielding an interpretable "attention → frequency → command" decoder
This approach is efficient, robust, and explainable—ideal for real-time BCI systems where you want fast inference without opaque model behavior.
Results
Across 10 subjects, the CCA-based decoder achieved:
- Mean accuracy: 93.1%
- Std across subjects: 11.9%
- Several subjects achieved ~100% on 12-class decoding
This performance aligns with expectations for a strong CCA implementation on a clean multi-class SSVEP benchmark.
Technical highlights
- End-to-end SSVEP decoding pipeline: preprocessing → epoching → FFT validation → CCA classification
- Zero-phase filtering for signal integrity (important for EEG)
- Template-based CCA using fundamental + harmonic components
- Multi-subject evaluation with clear, interpretable metrics
- Fast, lightweight approach suitable for real-time BCI command decoding
Reference
Masaki Nakanishi, Yijun Wang, Yu-Te Wang, Tzyy-Ping Jung, "A Comparison Study of Canonical Correlation Analysis Based Methods for Detecting Steady-State Visual Evoked Potentials," PLoS ONE, 2015.