Home on Systems & Embedded Software Engineer

IT Messe Wien — System Analysis Challenge (triscon)

Thu, 12 Feb 2026 00:00:00 +0000

🏆 Result#

Reached maximum score in a browser-based challenge at IT Messe Wien
Won: Nintendo Switch

🧠 What Made This Interesting#

The challenge imposed no restrictions on how the score could be achieved.

Instead of optimizing gameplay, I treated it as a systems problem:

Where is validation actually enforced?

What does the backend really trust?

How does score flow through the system?

📖 Overview#

I analyzed the client-server interaction with a focus on trust boundaries and score flow rather than UI behavior. That turned a simple browser game into a systems analysis exercise.

Deterministic Multiplayer Engine (ESP32-S3)

Sun, 01 Feb 2026 00:00:00 +0000

Overview#

Deterministic multiplayer retro engine running on ESP32-S3 using ESP-IDF.

Architecture: Fixed-step simulation (host-only) -> snapshot replication -> pure snapshot rendering -> DMA present.

No client prediction. No ISR rendering. Pixel-identical frames.

Your browser does not support the video tag.

RetroLink running on real hardware

Technical Highlights#

Double-buffered rendering
DMA display output
Tile/sprite-first pipeline
Deterministic sync over ESP-NOW
Minimal network overhead
Real hardware validation

Key Lessons#

Determinism simplifies debugging
Rendering must be separated from simulation
Network simplicity beats clever hacks

Technologies#

ESP32-S3
ESP-IDF
ESP-NOW
SPI DMA display pipeline
ILI9341
Double-buffered rendering

Flowchart

Details

RetroLink follows a strict contract. These are architectural rules, not preferences. ### Phase Order (Never Changes) - `Simulation -> Snapshot -> Rendering -> Present` - Host only simulates authoritative state. - Clients never simulate, predict, smooth, or invent state. - Rendering is snapshot-only and must be idempotent. ### Deterministic Rendering Rules - Every visible pixel change must come from exactly one simulation tick. - `render()` and draw helpers must not use `millis()`, `micros()`, timers, or randomness. - Rendering must not mutate gameplay state. - No role-based branching in rendering logic. ### Display and Buffer Rules - Always render to back buffer only. - Always present back buffer through RetroGoDisplay SPI DMA queue. - After present: copy back to front, then swap. - Front buffer is safety sync only, never a render target. - Any tearing, flicker, ghosting, or frame desync is a critical defect. ### Interrupt and Networking Safety - No display API calls from ISR or ESP-NOW callbacks. - ISR path may only store packet data and set flags. - Display work is deferred to main loop / task context. - SPI transaction payloads must be stable memory, never stack buffers. ### Memory and Asset Policy - DMA buffers must be internal DMA-capable RAM, not PSRAM. - Large transient decode buffers may use PSRAM. - Core gameplay visuals are tiles and sprites, not full-frame RGB565 assets. - PNG assets are allowed in SPIFFS for UI and loading paths, decoded outside `render()`. ### Why This Works This contract is what keeps multiplayer output deterministic across devices while preserving display stability on constrained hardware. The architecture was shaped by failures (white screens, bus corruption, stack-lifetime DMA bugs, and desync) and is intentionally strict to prevent regressions.

Gallery

4 images

Ekonio.cloud - Self-Hosted Engineering Platform

Thu, 12 Feb 2026 00:00:00 +0000

Overview#

Ekonio.cloud is my self-hosted infrastructure environment used to deploy and operate internal engineering tools and structured procurement workflows.

Ekonio.cloud

The project represents full ownership of the software lifecycle:

Architecture design
Backend development
Data modeling
Deployment
Server configuration
Ongoing maintenance

It serves as a production-grade environment for structured data workflows, automation scripts, and system experiments.

Technical Highlights#

VPS provisioning and Linux server configuration
Docker-based service deployment
Symfony backend architecture
Entity-based data modeling (Component, Supplier, PriceDetail, OrderDetail)
CSV import pipelines for structured bulk ingestion
Price tier tracking and historical cost analysis
Automated scraping integration for supplier comparison
Secure remote access and environment isolation

This environment supports real-world operational tooling rather than demonstration code.

USB-C PD Debugging & Firmware Recovery

Tue, 10 Feb 2026 00:00:00 +0000

Overview#

Laptop was stuck at 5 V over USB-C with no proper PD contract negotiation, making the system appear dead.

Even after replacing a visibly damaged power-path component, behavior stayed unchanged, which indicated a deeper control-layer fault.

Technical Highlights#

Diagnosed NX20P5090 failure in the USB-C power path
Measured CC and VBUS behavior during PD negotiation
Verified behavior after TPS65988 replacement
Identified external SPI configuration dependency
Regenerated and reflashed TPS65988 configuration
Restored full USB-C PD negotiation

Key Lessons#

Hardware repair now includes firmware and configuration state
A valid power rail set does not guarantee functional system behavior
Controller configuration memory can be as critical as controller silicon

Technologies#

USB-C Power Delivery
NX20P5090
TPS65988
Oscilloscope-based signal validation
SPI flash reprogramming
TI configuration tooling

Flowchart

Details

This repair started as a power-path failure and quickly turned into a mixed hardware and firmware fault analysis. The first confirmed fault was the NX20P5090 USB-PD protection and switch device. Replacing it restored basic path integrity but did not recover PD contract negotiation. Signal-level checks on CC and VBUS showed the policy engine was not completing valid negotiation states. Replacing the TPS65988 controller also produced no functional change. That narrowed the fault domain to external dependencies, specifically the SPI flash used for TPS65988 configuration. After rebuilding and flashing the configuration image with TI tooling, the controller resumed normal policy behavior and negotiated correctly. Key lesson: do not treat PD controllers as standalone silicon. Configuration memory is part of the active control plane.

Gallery

4 images

Runtime Rendering and Client-Server Observability (PoC)

Thu, 12 Feb 2026 00:00:00 +0000

Overview#

This proof-of-concept explores how modern SaaS applications expose structured system behavior at runtime, even when that structure is abstracted behind complex interfaces.

Using browser-level instrumentation and execution tracing, the project demonstrates how client-side rendering pipelines and network interactions can be observed, analyzed, and modeled without modifying backend systems.

The objective was not feature manipulation, but architectural understanding: identifying where authority resides, how state transitions occur, and how frontend abstractions relate to backend contracts.

OptiMOS™ 5 Power Stage Design & Simulation

Tue, 10 Feb 2026 00:00:00 +0000

Overview#

OptiMOS™ 5 IQDH29NE2LM5CGSC.

What surprised me most wasn’t the topology — but how much performance is hidden in a very small package. According to the datasheet, this device can handle extremely high pulsed currents when used correctly, which pushed me to dig deeper into pulse conditions, thermal limits, and PCB layout rather than just headline numbers. I designed the PCB, reviewed the datasheet in detail, and validated assumptions using LTspice (electrical + thermal behavior).

AMS Job Market Analysis Tool

Sun, 27 Aug 2023 00:00:00 +0000

Overview#

Python tool to collect and analyze publicly available remote job listings from the Austrian Public Employment Service (AMS).

Exports:

Job titles
Descriptions
Excel datasets

Second script:

Analyzes programming language demand
Generates trend graphs

Technical Highlights#

Automated collection of publicly available job listings
Structured extraction of titles and descriptions
Data cleaning and normalization pipeline
Programming-language demand analysis
Excel export for stakeholder-friendly reporting
Chart generation for trend visibility

Key Lessons#

Small automation workflows can produce decision-ready market insights
Data normalization is essential before trend analysis
Export format matters when sharing results with non-technical stakeholders
Public datasets often require structured preprocessing before becoming useful

Technologies#

Python
HTTP data extraction
Pandas
Excel export
Data visualization

Flowchart

Details

The AMS toolchain was built as a repeatable data collection and analysis workflow for remote software roles. Script one retrieves listings, parses structured fields, and stores normalized records for downstream processing. Data quality controls address duplicated posts and inconsistent text fragments. Script two analyzes language and technology demand by scanning job descriptions and aggregating frequency trends. The output includes both tabular datasets and visual summaries. Excel export was selected for portability, enabling distribution to non-technical stakeholders without additional tooling. The project demonstrates how lightweight automation can transform fragmented public listings into structured, decision-ready market insights.

Gallery

3 images