Systems-oriented software engineer with a focus on Linux userspace, embedded systems, and low-level infrastructure software.
My background is in C and embedded systems. I care about software that is honest about its boundaries — things that do one job correctly and compose well with everything else.
Earlier in the year, there was a collaborative effort towards building TorqLoop, a digital twin platform designed for use in factories. The purpose was to model real-world machines, track their operational health, and extract insights for prediction purposes. TorqLoop reached the development and simulation stages, but building an actual proof-of-concept ended up being impossible due to limitations in accessing a real industrial environment.
Developing TorqLoop uncovered a problem that kept coming back and required further attention.
There is much noise in an industrial setting, not only electrical but protocol-related noise as well. Devices speak multiple protocols, including Modbus, MQTT, BLE, CAN, serial, TCP, and proprietary ones. Every integration works differently, none are reusable, and no downstream system can trust the data it receives due to an unreliable ingress layer. Much more attention had to be spent overcoming protocol differences than making the platform better.
With the conclusion of TorqLoop came more focus on the layer that solves this problem. That is what led to the development of STICH.
STICH is a canonical integration runtime: infrastructure software sitting between hardware protocols and any higher-level application. It transforms protocol-specific inputs into a single normalised, trustworthy data stream. STICH does not interpret data; domain logic stays outside. It is protocol-agnostic, deterministic, and composable. Designed after the operational model of infrastructure software like Nginx: install it, connect your protocols, configure routing, and run.
Engineering highlights:
- Strict subsystem separation into canonical layer, thread, adapters, and sinks; each with well-defined responsibilities and dependency direction
- Frame-based data model where every data item is validated, normalised, and sealed before it moves further
- Adapter contract that allows integrating any protocol without the runtime being aware of its existence
- Written in C, targeting Linux edge deployments, with no heap allocation in the core path
STICH is currently at v0 PoC. The end-to-end path from adapter ingestion through normalisation and routing is implemented. The architecture is already specified down to engineering-level decisions.
TorqLoop is done. STICH continues, because the problem it solves does not belong to any particular platform.
ARM-stopwatch — Digital stopwatch on LPC2148 ARM7 with keypad input and LCD display. Interrupt-driven firmware, real hardware constraints.
Dual_Motor_Controller — PIC16F877A-based dual DC motor controller via H-bridge with hardware display feedback. Demonstrates embedded control loop design.
Residual-Current-Monitor-PIC16F877A — Current monitoring prototype using ADC thresholds. Foundational analog-digital integration on constrained hardware.
simple-linux-log-monitor — Shell-based log monitoring and parsing tool. My first step toward systems observability tooling.
Languages: C (primary) · Bash · Rust (learning)
Systems: Linux userspace · process lifecycle · embedded firmware · protocol integration
Design: subsystem boundary definition · data lifecycle modelling · error propagation · low-level observability
Hardware: MCU interaction · GPIO · serial protocols · real-time control loops
Building STICH toward a working edge deployment — real protocol adapters, real sink delivery, real frame routing. The v0 PoC proved the architecture. The next phase proves it under real conditions.
Interested in roles at the intersection of embedded Linux and systems infrastructure — places where the software has to be right because the consequences of it being wrong are visible in the physical world.