Problem

A biolink platform needed to turn public interactions into useful signals for analyzing and improving conversion.

Context and constraints

The product separates the public frontend, dashboard, and API, while event processing must not couple background work to the public experience.

Architecture

The solution combines a Next.js public frontend at the edge, a Node.js API, and asynchronous processing through RabbitMQ and Rust workers. MongoDB receives bulk writes after events are grouped in memory; deployments use Vercel and Railway.

Key engineering decisions

• Separate the public frontend, dashboard, and API to keep responsibilities clear.
• Use queues and workers to decouple event ingestion from asynchronous processing.
• Batch events in memory and use bulk writes to reduce individual database operations.

Challenges

• Coordinate the event path across components with different responsibilities and processing times.

Development approach

Development focused on splitting the system by responsibility and designing an explicit pipeline from ingestion to persistence.

Technologies

• Next.js
• TypeScript
• Node.js
• Rust workers
• RabbitMQ
• MongoDB
• Cloudflare Edge
• Vercel
• Railway

Problem

The physical controls of a DIY steering wheel needed to become inputs that Windows games could recognize.

Context and constraints

As a personal technical project, it integrates real hardware with desktop software and includes a public repository and a screenshot of its control panel.

Architecture

The ESP32-S3 reads the controls through Arduino/C++, sends data over Wi-Fi using UDP, and a C#/.NET 8 application receives it and exposes it to Windows through vJoy.

Key engineering decisions

• Use Wi-Fi/UDP as the link between the microcontroller and desktop application.
• Keep hardware input, data transport, and gamepad emulation through vJoy as separate concerns.

Challenges

• Translate physical control signals into a format that a Windows application and games can consume as gamepad input.

Development approach

Development connected Arduino/C++ firmware, UDP transport, and a WinForms interface in C#/.NET 8 around a physical device.

Validation and testing

Validation used real hardware and the input and vJoy connection view shown in the project screenshot.

Outcome

The project provides a functional bridge between DIY steering-wheel controls and a wireless Windows gamepad, with a public repository.

Technologies

• C#
• .NET 8
• ESP32
• Arduino/C++
• Wi-Fi
• UDP
• vJoy

Problem

Optical S/PDIF carries only two channels of PCM, so sending 5.1 across it requires compressing the audio to AC-3. Windows does not do this in software, and the sound cards that solve it in hardware are a minority: on the rest, any program playing 5.1 ends up downmixed to stereo the moment the digital output is selected.

Context and constraints

The project spans a kernel-mode driver through to a desktop application, running against real audio hardware and a digital output connected to a receiver.

Architecture

A KMDF/ACX driver exposes a 5.1 render endpoint that Windows materializes as an ordinary device; the driver discards the samples and exists only so that endpoint is real, since one cannot be created from an application. The mix is then captured in user mode through WASAPI loopback, per-channel gain is applied, FFmpeg encodes it to AC-3, the result is framed as IEC 61937, and it is delivered to the digital device in exclusive mode.

Key engineering decisions

• Keep the driver a sink with no processing and capture the audio in user mode, leaving the risky logic outside the kernel.
• Choose the output device by probing which ones accept an IEC 61937 AC-3 carrier rather than trusting enumeration order.
• Record every driver lifecycle status in the Windows registry, because kernel debug output is unusable in unattended runs.

Challenges

• The endpoint enumerated correctly yet could not be opened in shared mode until the real-time stream was implemented and buffer-notification support was declared.
• Holding a stable presentation clock in the driver without blocking the real-time path.

Development approach

Development separated the driver, a reusable bridge engine, and the interface, so the desktop application and the command-line version share a single engine.

Validation and testing

The repository includes unit tests and four runtime gates against the installed driver: device state, endpoint contract, real six-channel playback, and loopback capture comparing per-channel energy against known amplitudes. A device-removal-during-playback test is also included.

Outcome

The result is a working chain between software playing 5.1 and a receiver connected over optical, released as open source. The driver is signed with a test certificate, so it requires Windows test mode.

Technologies

• C++
• Windows Driver Kit
• KMDF
• ACX
• WASAPI
• FFmpeg
• IEC 61937
• Win32
• CMake