<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title>Stephan Bökelmann — From tape-out to TypeScript</title>
  <subtitle>Engineer, physicist, consultant. Silicon-level measurement systems, embedded development, monitoring infrastructure, and application-layer software.</subtitle>
  <link href="https://maxclerkwell.github.io/feed.xml" rel="self" type="application/atom+xml"/>
  <link href="https://maxclerkwell.github.io/" rel="alternate" type="text/html"/>
  <id>https://maxclerkwell.github.io/</id>
  <updated>2026-05-20T09:49:15+00:00</updated>
  <author>
    <name>Stephan Bökelmann</name>
    <email>stephan@boekelmann.net</email>
    <uri>https://maxclerkwell.github.io</uri>
  </author>
  <generator uri="https://jekyllrb.com/">Jekyll</generator>

  

  
  <entry>
    <title>Zero to One: Fun with SWD</title>
    <link href="https://maxclerkwell.github.io/posts/swd-openocd-blinky-may-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/swd-openocd-blinky-may-2026/</id>
    <published>2026-05-20T00:00:00+00:00</published>
    <updated>2026-05-20T00:00:00+00:00</updated>
    
    <summary>You do not need to write a single line of C to talk to a microcontroller. With OpenOCD and a telnet connection you can toggle GPIO pins directly from your terminal — and that is exactly how we build a blinky on an STM32F303K8 Nucleo-32.</summary>
    
    
    <category term="embedded"/>
    
    <category term="stm32"/>
    
    <category term="openocd"/>
    
    <category term="swd"/>
    
    <category term="hardware"/>
    
    <category term="beginners"/>
    
    <category term="zero-to-one"/>
    
    <content type="text">Most embedded tutorials start the same way: install the toolchain, write a `main.c`, fight the linker script, flash the binary, and then — finally — a LED blinks. That is a perfectly valid path. But there is a shorter one, and it teaches you something the longer path tends to skip: registers are just memory. You can read and write them directly, from your laptop, without compiling anything. This post shows how to do exactly that on an [**STM32F303K8 Nucleo-32**](https://www.mouser.de/ProductDetail/STMicroelectronics/NUCLEO-F303K8?qs=kWQV1gtkNndPxYr6NNfTBw%3D%3D) using **OpenOCD** and a plain **telnet** session. ![STM32F303K8 Nucleo-32 on the desk](/posts/swd-openocd-blinky-may-2026/assets/Title.jpg) --- ## What is SWD? **Serial Wire Debug** (SWD) is a two-wire protocol — `SWDIO` (data) ...</content>
  </entry>
  
  <entry>
    <title>Simulating Antiproton Energy Loss in an HV-MAPS Silicon Sensor with Geant4</title>
    <link href="https://maxclerkwell.github.io/posts/hv-maps-energy-loss-simulation-may-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/hv-maps-energy-loss-simulation-may-2026/</id>
    <published>2026-05-18T00:00:00+00:00</published>
    <updated>2026-05-18T00:00:00+00:00</updated>
    
    <summary>A first-principles walkthrough of using Geant4 to simulate how much energy an antiproton deposits in a thin HV-MAPS silicon sensor — including a hand-worked Bethe-Bloch example, the Landau distribution, and why this matters for detector design before you ever see a beam.</summary>
    
    
    <category term="geant4"/>
    
    <category term="simulation"/>
    
    <category term="particle-physics"/>
    
    <category term="hv-maps"/>
    
    <category term="silicon-detector"/>
    
    <category term="antiproton"/>
    
    <category term="hesr"/>
    
    <category term="panda"/>
    
    <category term="fair"/>
    
    <category term="bethe-bloch"/>
    
    <content type="text">![Stephan Bökelmann a.k.a MaxClerkwell and another researcher from RUB standing in a supermarket parking lot on Corfu — the store sign reads &quot;PROTON&quot;. Stephan holds his thumb down, because he is firmly on Team Antiproton.](/posts/hv-maps-energy-loss-simulation-may-2026/assets/me-being-anti-proton.jpg) Three years ago, a colleague and I stumbled across a supermarket on Corfu called **PROTON**. I am holding my thumb down in the photo. Team Antiproton does not endorse protons. That same commitment to antimatter is also why I spent a recent weekend setting up Geant4 to answer a very concrete question: how much energy does an antiproton actually deposit in a silicon pixel sensor as thin as the ones we work with? --- ## What is HV-MAPS? A conventional hybrid pixel detector is two separate chi...</content>
  </entry>
  
  <entry>
    <title>Zero to One: VHDL and a Lattice iCEstick</title>
    <link href="https://maxclerkwell.github.io/posts/fpga-blinky-vhdl-icestick-may-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/fpga-blinky-vhdl-icestick-may-2026/</id>
    <published>2026-05-14T00:00:00+00:00</published>
    <updated>2026-05-14T00:00:00+00:00</updated>
    
    <summary>A complete walkthrough of writing VHDL, simulating it with GHDL, and flashing a blinking LED onto a Lattice iCEstick — from zero assumptions to a physical result.</summary>
    
    
    <category term="fpga"/>
    
    <category term="vhdl"/>
    
    <category term="icestick"/>
    
    <category term="ice40"/>
    
    <category term="hardware"/>
    
    <category term="digital-design"/>
    
    <category term="ghdl"/>
    
    <category term="yosys"/>
    
    <category term="zero-to-one"/>
    
    <content type="text">![iCEstick leaning against a Ruhr-Universität Bochum physics department mug, mixer and monitor in the background](/posts/fpga-blinky-vhdl-icestick-may-2026/assets/titlepic.jpg) This post is the first in a series on FPGA development with open-source tools. By the end you will have blinked an LED on real hardware, and you will understand every step between writing the VHDL source and the moment the LED actually blinks. No prior HDL experience is assumed. If you know what a for-loop is, you have enough background. --- ## What is an FPGA, and why does it matter? A microcontroller runs a program. An FPGA does something fundamentally different: you describe a circuit, and the chip reconfigures its internal wiring to *become* that circuit. There is no instruction fetch, no program counter, no ...</content>
  </entry>
  
  <entry>
    <title>Viewing Plots from My Homelab Over SSH X11 Forwarding</title>
    <link href="https://maxclerkwell.github.io/posts/x11-forwarding-bastion-may-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/x11-forwarding-bastion-may-2026/</id>
    <published>2026-05-13T00:00:00+00:00</published>
    <updated>2026-05-13T00:00:00+00:00</updated>
    
    <summary>How to forward X11 through a bastion server to display images and plots from a home machine on a university workstation, without copying files.</summary>
    
    
    <category term="linux"/>
    
    <category term="ssh"/>
    
    <category term="x11"/>
    
    <category term="networking"/>
    
    <category term="homelab"/>
    
    <category term="bastion"/>
    
    <category term="wireguard"/>
    
    <content type="text">Sometimes I am in a terminal on my home machine, a Python or C++ script runs through, it produces a plot, and I want to look at it. The problem: I am sitting at my university workstation. Switching to another terminal, running `scp`, opening the file locally, then switching back — that is enough friction to be genuinely annoying when you are in the middle of iterating on something. SSH X11 forwarding solves this. The image renders on the remote machine and the window appears locally, as if the application were running here. Getting it to work through a bastion server took a few steps worth writing down. ## The Setup My homelab sits behind a router with no public IP. Between it and the outside world is Heimdall — a rented server with a public IP address. Heimdall is a **bastion server**:...</content>
  </entry>
  
  <entry>
    <title>How Two Teenagers, a Printer Plug, and a Forum Post Built a Company</title>
    <link href="https://maxclerkwell.github.io/posts/auto-intern-obd-vcds-may-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/auto-intern-obd-vcds-may-2026/</id>
    <published>2026-05-06T00:00:00+00:00</published>
    <updated>2026-05-06T00:00:00+00:00</updated>
    
    <summary>Auto-Intern GmbH turns 25. This is the story of how it started: two kids in a bedroom, a GTI, an RS-232 adapter, and the accidental invention of a market.</summary>
    
    
    <category term="auto-intern"/>
    
    <category term="vcds"/>
    
    <category term="obd"/>
    
    <category term="ross-tech"/>
    
    <category term="automotive"/>
    
    <category term="origin-story"/>
    
    <category term="diagnostics"/>
    
    <content type="text">I joined Auto-Intern in 2014, when the company acquired my workshop, Kfz-Technik Bökelmann. By then, Auto-Intern was already an institution in the German-speaking automotive world — the go-to address for VCDS diagnostic interfaces. But the story of how it got there is one I have spent the last decade slowly piecing together from the people who lived it. This year, Auto-Intern turns 25. It feels like the right moment to write it down. A GTI, a Radio, and a Wild Idea In 2001, Benjamin Menküc — everyone calls him Benne — and Odin Holmes were still in school. Odin was an American citizen, in Germany on a student exchange program. The two met as classmates. Benne had a Golf GTI. He also had the very specific frustration of anyone who drives on the Autobahn: at high speed, road noise drowns o...</content>
  </entry>
  
  <entry>
    <title>Are Machines Conscious? A Snapshot</title>
    <link href="https://maxclerkwell.github.io/posts/machine-consciousness-may-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/machine-consciousness-may-2026/</id>
    <published>2026-05-05T00:00:00+00:00</published>
    <updated>2026-05-05T00:00:00+00:00</updated>
    
    <summary>What does consciousness mean — and where on that spectrum do beetles, dogs, humans, and language models sit? No final answers, but an honest attempt to think the question through.</summary>
    
    
    <category term="consciousness"/>
    
    <category term="AI"/>
    
    <category term="philosophy"/>
    
    <category term="cognition"/>
    
    <category term="mind"/>
    
    <content type="text">![Are Machines Conscious?](/posts/machine-consciousness-may-2026/assets/title1.png) *What follows is not a finished argument and not a manifesto. It is a snapshot — an attempt to sort out thoughts that have been occupying me for a while. I explicitly reserve the right to think differently tomorrow.* --- ## The Bird and the Airplane Yesterday, in a conversation with Tabea, she made a remark that stuck with me. We were talking about AI and consciousness, and she said something along the lines of: a plane flies too, but it is not a bird. It turns out this intuition has a precise formulation. Steven Pinker writes in *How the Mind Works* (1997): &gt; &quot;To explain how birds fly, we invoke principles of lift and drag and fluid mechanics that also explain how airplanes fly. That does not commit us ...</content>
  </entry>
  
  <entry>
    <title>The Game of Life and the Limits of Prediction</title>
    <link href="https://maxclerkwell.github.io/posts/game-of-life-may-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/game-of-life-may-2026/</id>
    <published>2026-05-04T00:00:00+00:00</published>
    <updated>2026-05-04T00:00:00+00:00</updated>
    
    <summary>A colleague called it &apos;useless math but super fun.&apos; I objected. Conway&apos;s Game of Life connects self-replicating machines, Wolfram&apos;s computational irreducibility, and the unsettling possibility that entropy is not just disorder — it is the universe refusing to be calculated.</summary>
    
    
    <category term="cellular-automata"/>
    
    <category term="wolfram"/>
    
    <category term="entropy"/>
    
    <category term="philosophy"/>
    
    <category term="complexity"/>
    
    <category term="conway"/>
    
    <content type="text">A friend sent me a link to a simulation running in a browser tab: [oimo.io/works/life](https://oimo.io/works/life/). She had heard of it — two colleagues from the physics department had mentioned it. One of them called it &quot;useless math but super fun.&quot; I objected. It is the complete opposite of useless math. It is one of the most significant discoveries in science. That conviction is what this post is about. ![Conway&apos;s Game of Life — structures evolving on a grid](/posts/game-of-life-may-2026/assets/GoL-Opener.png) ## Where It Comes From In the late 1940s and early 1950s, Stanisław Ulam and John von Neumann were close friends and colleagues at Los Alamos, but they were circling the same idea from different angles. Ulam was studying how crystals grow: the way a regular structure can propa...</content>
  </entry>
  
  <entry>
    <title>Zero to One: A Personal Journal Bot with Telegram and Gemini</title>
    <link href="https://maxclerkwell.github.io/posts/telegram-journal-bot-may-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/telegram-journal-bot-may-2026/</id>
    <published>2026-05-03T00:00:00+00:00</published>
    <updated>2026-05-03T00:00:00+00:00</updated>
    
    <summary>I spent a day building a Dockerized Telegram bot that turns voice messages and scattered thoughts into a structured journal, Obsidian topic notes, and a compiled LaTeX memoir — and what I learned about LLM APIs along the way.</summary>
    
    
    <category term="telegram"/>
    
    <category term="gemini"/>
    
    <category term="docker"/>
    
    <category term="journaling"/>
    
    <category term="llm"/>
    
    <category term="python"/>
    
    <category term="latex"/>
    
    <category term="obsidian"/>
    
    <category term="zero-to-one"/>
    
    <content type="text">I have been meaning to journal consistently for years. The friction has never been motivation — it has always been the blank page. Opening a text editor, deciding on a format, remembering what happened, structuring it. By the time I have done all of that, the thought I wanted to capture has either sharpened itself into something obvious or dissolved entirely. So I built a bot that does the structuring for me. ## What it does You send a message to a Telegram bot. The bot asks you one follow-up question. You answer. It might ask another. After two or three exchanges it writes a journal entry, extracts a topic note in Obsidian-compatible markdown, and commits both to a private git repository. Voice messages get transcribed. Photos get analysed — Gemini looks at the image and asks what drew...</content>
  </entry>
  
  <entry>
    <title>Enclosureless Cases: When the PCB Is the Enclosure</title>
    <link href="https://maxclerkwell.github.io/posts/enclosureless-cases-april-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/enclosureless-cases-april-2026/</id>
    <published>2026-04-29T00:00:00+00:00</published>
    <updated>2026-04-29T00:00:00+00:00</updated>
    
    <summary>Five years ago we filed a utility model for an idea that sounds almost too obvious in hindsight: what if the PCB itself were the enclosure? Here is how Enclosureless Cases works, why we built it, and how you can use it.</summary>
    
    
    <category term="hardware"/>
    
    <category term="PCB"/>
    
    <category term="PCBA"/>
    
    <category term="enclosure"/>
    
    <category term="gebrauchsmuster"/>
    
    <category term="sensor"/>
    
    <category term="1-wire"/>
    
    <category term="BME"/>
    
    <category term="open-hardware"/>
    
    <category term="manufacturing"/>
    
    <content type="text">Five years ago Odin Holmes and I filed a utility model at the German Patent and Trade Mark Office. The registration number is DE202020106111U1, the official title is Leiterplattengehäusevorrichtung mit wenigstens drei gehäusebildenden Leiterplattenelementen — which is how you have to phrase things for the authorities — and the idea behind it is this: you do not need a separate enclosure if the PCB stack itself is the enclosure. We call it Enclosureless Cases. The Problem Sensors are cheap. A BME280 humidity and temperature chip costs well under a euro. A simple microcontroller to go with it costs similarly little. You can put together a capable sensing node for five or six euros in components. Then you need to put it somewhere. A plastic injection-moulded enclosure, even a simple one, a...</content>
  </entry>
  
  <entry>
    <title>The Recursion Problem in Relational Algebra</title>
    <link href="https://maxclerkwell.github.io/posts/relational-algebra-recursion-problem/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/relational-algebra-recursion-problem/</id>
    <published>2026-04-24T00:00:00+00:00</published>
    <updated>2026-04-24T00:00:00+00:00</updated>
    
    <summary>Relational algebra is clean, powerful, and deliberately limited. Here is where that limit bites you.</summary>
    
    
    <category term="databases"/>
    
    <category term="teaching"/>
    
    <category term="THGA"/>
    
    <category term="relational-algebra"/>
    
    <content type="text">Relational algebra is the theoretical backbone of every query you will ever write against a relational database. Selection, projection, join, union — five or six operations, and you can express almost any query imaginable. Almost. There is one class of problem it cannot touch, and understanding why is one of the more instructive moments in database theory. ## What Relational Algebra Is Good At A relational algebra expression takes one or more relations (tables) as input and produces a new relation as output. The expression is finite: a fixed number of operations, applied once, returning a result. This is a feature, not a bug — it makes queries predictable, optimizable, and mathematically well-behaved. Consider a simple employee table with columns `id`, `name`, and `manager_id`. Finding ...</content>
  </entry>
  
  <entry>
    <title>A Database Is Not an API</title>
    <link href="https://maxclerkwell.github.io/posts/databases-behind-an-api/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/databases-behind-an-api/</id>
    <published>2026-04-24T00:00:00+00:00</published>
    <updated>2026-04-24T00:00:00+00:00</updated>
    
    <summary>Why we never expose a database directly — and what we put in front of it instead.</summary>
    
    
    <category term="databases"/>
    
    <category term="architecture"/>
    
    <category term="FastAPI"/>
    
    <category term="Keycloak"/>
    
    <category term="nerd_force1"/>
    
    <content type="text">When we set up databases for clients at [nerd_force1](https://nerd-force1.com), one rule holds without exception: the database is never the outermost layer. This post explains why, and what we put in front of it instead. ## The Temptation of Direct Access Every relational database ships with access control. MySQL has users and privileges. PostgreSQL has roles and schemas. You can, technically, hand a client a connection string and call it done. The problem is that a database&apos;s built-in access model is designed for database administrators, not for application users. It answers questions like &quot;can this user read this table?&quot; — but not &quot;can this user read *their own* rows in this table, filtered by their organization, with rate limiting, and with that action logged?&quot; For anything beyond th...</content>
  </entry>
  
  <entry>
    <title>Zero to One: Why a Filesystem Is Not a Database</title>
    <link href="https://maxclerkwell.github.io/posts/dbms-01-why-files-are-not-enough/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/dbms-01-why-files-are-not-enough/</id>
    <published>2026-04-23T00:00:00+00:00</published>
    <updated>2026-04-23T00:00:00+00:00</updated>
    
    <summary>A practicum that makes the case for relational databases by forcing students to feel the pain of querying flat files first.</summary>
    
    
    <category term="databases"/>
    
    <category term="teaching"/>
    
    <category term="THGA"/>
    
    <category term="SQL"/>
    
    <category term="zero-to-one"/>
    
    <content type="text">Yes, I&apos;m aware: nobody in production actually stores sensor data as 120 CSV files in a flat directory. At least I hope not. But that&apos;s precisely why this works as a teaching exercise — it&apos;s artificial enough to be harmless, and realistic enough to sting. The first practicum I built for the DBMS course at THGA Bochum ([DBMS_01](https://github.com/MaxClerkwell/DBMS_01)) doesn&apos;t teach students how SQL works. It teaches them why SQL exists. ## The Setup Students generate synthetic sensor data: temperature readings from four sensors, three times a day, over thirty days. That&apos;s 120 CSV files and 360 rows total. Nothing exotic. Exactly the kind of mess that accumulates when a small team decides &quot;we&apos;ll figure out the storage later.&quot; Then they solve three tasks: 1. Filter and sort readings from ...</content>
  </entry>
  
  <entry>
    <title>If We Can Measure It, You Can Improve It</title>
    <link href="https://maxclerkwell.github.io/posts/ai-gruppe-manifesto/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/ai-gruppe-manifesto/</id>
    <published>2026-04-20T00:00:00+00:00</published>
    <updated>2026-04-20T00:00:00+00:00</updated>
    
    <summary>A manifesto on why monitoring systems are the foundation of human liberation — and why we build them.</summary>
    
    
    <category term="manifesto"/>
    
    <category term="monitoring"/>
    
    <category term="automation"/>
    
    <category term="auto-intern"/>
    
    <category term="philosophy"/>
    
    <content type="text">Robotics gives machines hands. AI gives machines judgment. Monitoring gives machines senses. Without the senses, the hands are blind and the judgment is deaf. The Apple on the Tree Ten years ago, as a student, I asked myself a simple question: why does this apple cost money? The apple growing on the branch costs nothing. The apple in the store costs something. The difference is human labor — hands that picked it, trucks that moved it, systems that tracked it. Every euro in the price tag is a unit of human time that had to be spent. If that is true, then the path to making humanity genuinely richer is not to work more. It is to need fewer human hours per unit of civilization. This is why we build what we build. The Uncomfortable Truth Most people fear automation because they think in zer...</content>
  </entry>
  
  <entry>
    <title>Travelling to China with a Peli Case Full of Electronics</title>
    <link href="https://maxclerkwell.github.io/posts/ata-carnet-china-travel/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/ata-carnet-china-travel/</id>
    <published>2026-04-09T00:00:00+00:00</published>
    <updated>2026-04-09T00:00:00+00:00</updated>
    
    <summary>A practical guide for engineers taking commercial electronics to China for testing — ATA Carnet, Peli cases, Frankfurt T2, Guangzhou customs, and everything the internet doesn&apos;t tell you.</summary>
    
    
    <category term="china"/>
    
    <category term="travel"/>
    
    <category term="hardware"/>
    
    <category term="EMC"/>
    
    <category term="logistics"/>
    
    <content type="text">When I went to Dongguan for EMC testing in March, I brought a Peli case full of custom electronics as checked luggage. This post is the logistics companion to that trip — everything I learned about ATA Carnets, airport customs, and travelling with hardware that looks suspicious to anyone who doesn’t build it. Why Not Just Ship It? Shipping electronics to China for testing and back is a customs nightmare. Import duties, VAT, potential seizure, weeks of waiting. The cleaner solution for temporary export of commercial goods is an ATA Carnet — essentially a passport for your equipment. You declare that you are taking specific items out of your home country, into a foreign country, and bringing them back. No duties, no VAT, as long as everything returns. Preparing the ATA Carnet In Germany, ...</content>
  </entry>
  
  <entry>
    <title>EMC in Dongguan: 2.5 Years of Work, 4 Days in a Test Chamber</title>
    <link href="https://maxclerkwell.github.io/posts/dongguan-emc-march-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/dongguan-emc-march-2026/</id>
    <published>2026-04-01T00:00:00+00:00</published>
    <updated>2026-04-01T00:00:00+00:00</updated>
    
    <summary>After 2.5 years of development, our reflow oven monitoring system passed CE, FCC, and CCC certification at NTC in Dongguan — and I learned more in four days than in any lab back home.</summary>
    
    
    <category term="hardware"/>
    
    <category term="EMC"/>
    
    <category term="China"/>
    
    <category term="monitoring"/>
    
    <category term="PoE"/>
    
    <category term="project"/>
    
    <content type="text">In March I flew to Dongguan, China for four days of EMC testing. It was the last major milestone before our reflow oven monitoring system goes into production. After two and a half years of development, the question was simple: does this thing radiate, and can it take a hit? It passed. But the story is more interesting than that. The Project The system was commissioned by GlobalPoint GmbH, now part of Kurtz Ersa GmbH &amp;amp; Co. KG, one of the leading manufacturers of reflow soldering equipment. The brief: build a monitoring system that attaches to Ersa’s reflow ovens and gives operators real-time insight into what is actually happening inside the machine — not what the oven thinks is happening, but what the physics says. The development was handled by skainet.io, the engineering office o...</content>
  </entry>
  
  <entry>
    <title>Ten Years of Conferences: What They&apos;re Actually For</title>
    <link href="https://maxclerkwell.github.io/posts/why-conferences-march-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/why-conferences-march-2026/</id>
    <published>2026-03-15T00:00:00+00:00</published>
    <updated>2026-03-15T00:00:00+00:00</updated>
    
    <summary>I&apos;ve spent ten years attending and organising technical conferences. Here&apos;s what I&apos;ve actually learned — about unknown unknowns, the hallway track, and why the dinner after the talks is the real event.</summary>
    
    
    <category term="conferences"/>
    
    <category term="community"/>
    
    <category term="emBO++"/>
    
    <category term="Open-Skunkforce"/>
    
    <category term="OSF"/>
    
    <category term="cpp"/>
    
    <category term="KiCad"/>
    
    <category term="reflection"/>
    
    <content type="text">In 2015 I went to my first real conference. I came back a different engineer. That sounds dramatic, but it&apos;s accurate, and it took me a while to understand why. This post is an attempt to write that down — both for myself, after ten years, and for the companies, universities, and open-source projects that keep asking us at [Open Skunkforce e.V.](https://skunkforce.org) how we think about this. ## Meeting C++, 2015 I went to **Meeting C++ 2015** with my colleague [Odin Holmes](https://x.com/odinthenerd). At that point I thought I was a reasonably competent programmer. I was wrong — not in the way that&apos;s demoralising, but in the way that only becomes visible when you&apos;re suddenly in a room full of people who have been thinking deeply about problems you haven&apos;t encountered yet. I didn&apos;t kno...</content>
  </entry>
  
  <entry>
    <title>Dual Uplink for 15 People: Starlink, Heimdall, and Linux Routing</title>
    <link href="https://maxclerkwell.github.io/posts/dual-uplink-feb-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/dual-uplink-feb-2026/</id>
    <published>2026-02-27T00:00:00+00:00</published>
    <updated>2026-02-27T00:00:00+00:00</updated>
    
    <summary>Our office network was struggling under 15 people. Philipp and I added a second uplink via Starlink in February — with automatic failover through Linux routing and a small Python dashboard to monitor both links.</summary>
    
    
    <category term="networking"/>
    
    <category term="Linux"/>
    
    <category term="Starlink"/>
    
    <category term="failover"/>
    
    <category term="infrastructure"/>
    
    <category term="Debian"/>
    
    <category term="sysadmin"/>
    
    <content type="text">At some point, one internet connection isn’t enough. We hit that point when 15 people were working in the office simultaneously and the line was noticeably sluggish — video calls, git pushes, remote access, all sharing a single uplink. Philipp and I tackled it in February. Philipp is our server administrator — still working on his bachelor’s degree, but already operating at a level that leaves many professional admins behind. Together we’ve set up mesh backhauls, VPNs, intranets, a Kubernetes cluster, Ceph storage, Keycloak for all our internal services — and quite a bit more. If a service runs in our office, Philipp either built it or knows every corner of it. The network upgrade in February was one more chapter in a long list. The Starting Point Our existing network was a standard set...</content>
  </entry>
  
  <entry>
    <title>Ten Years of PowerSense: Blood, Sweat, and Ferrite Cores</title>
    <link href="https://maxclerkwell.github.io/posts/skainet-powersense-jan-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/skainet-powersense-jan-2026/</id>
    <published>2026-01-15T00:00:00+00:00</published>
    <updated>2026-01-15T00:00:00+00:00</updated>
    
    <summary>January 2016, the DB Netz AG called. Ten years later, the skAInet-PowerSense is still one of the most technically demanding projects we have ever shipped — and the one that shaped how we build everything since.</summary>
    
    
    <category term="auto-intern"/>
    
    <category term="hardware"/>
    
    <category term="monitoring"/>
    
    <category term="rail"/>
    
    <category term="PoE"/>
    
    <category term="engineering"/>
    
    <content type="text">January 2016. A call came in through a mutual contact — [Steffen Scholle](https://eximentor.de/en/home/), at the time an Ex-inspector at DEKRA and today a respected Ex-consultant — connecting us with DB Netz AG. They had a problem: they needed a smarter way to monitor the power supply of their railway switching systems. Three-phase, 16A lines, 1.5mm² cross-section. And they needed it non-intrusively, clip-on, retrofit. No rewiring. No outages. No excuses. All the pieces already existed internally — E-field sensing, Hall probes, PoE prototypes — and the moment we heard the requirement, we knew exactly what to assemble. January 2016 was the moment it became real. A customer with a real problem, a real network, and real consequences if the measurements were wrong. Ten years later, that cal...</content>
  </entry>
  
  <entry>
    <title>PCB Design Starts With a README</title>
    <link href="https://maxclerkwell.github.io/posts/pcb-block-diagrams-december-2025/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/pcb-block-diagrams-december-2025/</id>
    <published>2025-12-10T00:00:00+00:00</published>
    <updated>2025-12-10T00:00:00+00:00</updated>
    
    <summary>Before opening KiCad, before ordering a single component, I create a GitHub repo, write a README, and let an LLM turn it into a block diagram. Here is why that order matters, what the README should contain, and how the whole thing works in practice.</summary>
    
    
    <category term="hardware"/>
    
    <category term="PCB"/>
    
    <category term="KiCad"/>
    
    <category term="PlantUML"/>
    
    <category term="block-diagram"/>
    
    <category term="workflow"/>
    
    <category term="documentation"/>
    
    <category term="version-control"/>
    
    <category term="LLM"/>
    
    <content type="text">The most expensive mistake you can make in PCB design is building the wrong board. The second most expensive is building a board whose purpose nobody on the team agrees on, because you never wrote it down. Both mistakes are preventable with the same tool: a plain text file in a version-controlled repository, written before any schematic work begins. ## The Workflow The process is simple enough to describe in a few steps, but the discipline behind it takes some practice. **Step 1 — Create a new repository.** A fresh repo on GitHub, cloned locally. This is where the design intent lives, separate from any KiCad project or firmware repo. The design intent should be version controlled on its own terms. **Step 2 — Write a README.** Not notes. Not bullet points in a chat message. A structured ...</content>
  </entry>
  
  <entry>
    <title>Biofilms in Rivers: EIS at the Clark Fork</title>
    <link href="https://maxclerkwell.github.io/posts/msu-eis-2024/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/msu-eis-2024/</id>
    <published>2025-11-28T00:00:00+00:00</published>
    <updated>2025-11-28T00:00:00+00:00</updated>
    
    <summary>From a governor&apos;s reception in Kalispell to a datalogger in the Clark Fork River — how a chance introduction led to a year of collaborative instrument development with Montana State University.</summary>
    
    
    <category term="EIS"/>
    
    <category term="MSU"/>
    
    <category term="Montana"/>
    
    <category term="biofilm"/>
    
    <category term="sensor"/>
    
    <category term="water-quality"/>
    
    <category term="skAInet"/>
    
    <category term="hardware"/>
    
    <category term="field-deployment"/>
    
    <content type="text">In the summer of 2023, Tabea, Odin Holmes, and I were in Montana for a series of meetings. We had been introduced to the state&apos;s network by **Frederick van den Abbeel**, who had arranged conversations with **Scott Osterman** and — unexpectedly — with **Governor Greg Gianforte**. We were even invited to the reception of the Governor&apos;s golf cup in Kalispell. None of us had anticipated that a research instrument would come out of any of this. Those conversations pointed us toward **Montana State University in Bozeman**, and through MSU to **Prof. Stephan Warnat** — an electrical engineer from Schleswig-Holstein who had ended up teaching in Montana, which is not the most obvious career trajectory for someone from the German-Danish borderland. We visited his lab that summer. ## Electrochemic...</content>
  </entry>
  
  <entry>
    <title>KiCon Asia 2025: Speaking on Wire Bonding in Shenzhen</title>
    <link href="https://maxclerkwell.github.io/posts/kicon-asia-2025/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/kicon-asia-2025/</id>
    <published>2025-11-15T00:00:00+00:00</published>
    <updated>2025-11-15T00:00:00+00:00</updated>
    
    <summary>I gave a talk on wire bonding at KiCon Asia 2025 in Shenzhen — two years of bonding CLICpix v3, MuPix8, and MuPix10 with a Delvotec bonder, condensed into 25 minutes.</summary>
    
    
    <category term="KiCad"/>
    
    <category term="wire-bonding"/>
    
    <category term="hardware"/>
    
    <category term="conference"/>
    
    <category term="Shenzhen"/>
    
    <category term="particle-physics"/>
    
    <category term="KiCon"/>
    
    <content type="text">**KiCon Asia 2025** took place in Shenzhen on November 13–15, co-organised by the KiCad project and [Huaqiu PCB](https://www.huaqiu.com). I was there as a speaker — and spent the rest of the time walking around one of the most interesting manufacturing cities in the world. ![KiCon 2025 Asia conference programme banner](/posts/kicon-asia-2025/assets/photo_1_2026-04-15_13-23-32.jpg) ## The Talk: A Poor Man&apos;s Intro to Wire Bonding My talk was called **&quot;A poor man&apos;s intro to wire bonding&quot;** — and that title is exactly right. This wasn&apos;t a talk about having the right equipment and a controlled process. It was about what you actually learn when you try to bond real detector chips onto PCBs over two years, with limited resources, and have to figure out most of it by doing. The chips involved w...</content>
  </entry>
  
  <entry>
    <title>OmnAIScope: A USB Oscilloscope for Automotive Diagnostics</title>
    <link href="https://maxclerkwell.github.io/posts/omnaiscope-august-2025/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/omnaiscope-august-2025/</id>
    <published>2025-08-28T00:00:00+00:00</published>
    <updated>2025-08-28T00:00:00+00:00</updated>
    
    <summary>How a small aluminium cylinder with a BNC and a USB-C port is changing how independent car workshops do electrical diagnostics — and why the synchronisation trick in firmware is the interesting part.</summary>
    
    
    <category term="hardware"/>
    
    <category term="automotive"/>
    
    <category term="oscilloscope"/>
    
    <category term="RP2040"/>
    
    <category term="KiCad"/>
    
    <category term="aw4null"/>
    
    <category term="open-access"/>
    
    <content type="text">The **OmnAIScope** is a single-channel USB oscilloscope designed for automotive diagnostics. It started as a prototype within the [autowerkstatt4null](https://github.com/nabla-B/paper_aw4null-overview) project — a three-year, federally funded initiative to bring AI-driven diagnostics to independent car workshops. This post covers what it is, how the synchronisation works, and where it&apos;s going. ![Four OmnAIScope prototypes — BNC input on top, USB-C on the bottom](/posts/omnaiscope-august-2025/assets/early_prototype.jpg) ## The Hardware The current prototype is built around an **RP2040** microcontroller. The specs are deliberately modest: - **500 kSa/s**, single channel - **Anodised aluminium housing**, epoxy-sealed after assembly — fully waterproof - **BNC** on one end, **USB-C** on the ...</content>
  </entry>
  
  <entry>
    <title>Getting Started: From Tape-Out to TypeScript</title>
    <link href="https://maxclerkwell.github.io/posts/getting-started/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/getting-started/</id>
    <published>2025-08-14T00:00:00+00:00</published>
    <updated>2025-08-14T00:00:00+00:00</updated>
    
    <summary>Why I&apos;m writing here, what to expect, and why the full vertical stack is worth covering in one place.</summary>
    
    
    <category term="meta"/>
    
    <category term="engineering"/>
    
    <category term="intro"/>
    
    <content type="text">This is the first post on this blog. It won&apos;t be the most technically dense — that comes later. ## Why a blog? Every platform I post on is rented ground. Algorithms change. Accounts get suspended. Platforms rise and fall. This blog is the one place I own outright. The plan: one longform post per week. Everything else — threads on X, LinkedIn posts, YouTube videos, Instagram carousels — is derived from what&apos;s written here first. The blog is the source of truth. ## What I&apos;ll be writing about Three pillars, based on where I actually spend my time: **Monitoring systems in production.** I&apos;ve been building and running measurement infrastructure since 2007 — from oscilloscope-based diagnostics in automotive workshops to telemetry stacks for critical rail infrastructure and particle physics exp...</content>
  </entry>
  
  <entry>
    <title>KiCon Europe 2024: Bochum Goes International</title>
    <link href="https://maxclerkwell.github.io/posts/kicon-europe-2024/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.github.io/posts/kicon-europe-2024/</id>
    <published>2024-09-20T00:00:00+00:00</published>
    <updated>2024-09-20T00:00:00+00:00</updated>
    
    <summary>After four KiCon Germany editions, we scaled up to KiCon Europe 2024 — 150 people in the Rotunde Bochum, Wayne Stambaugh and Seth Hilbrand flying in for the first time, and a programme that felt genuinely broad.</summary>
    
    
    <category term="KiCad"/>
    
    <category term="conference"/>
    
    <category term="Bochum"/>
    
    <category term="hardware"/>
    
    <category term="open-source"/>
    
    <category term="KiCon"/>
    
    <category term="Open-Skunkforce"/>
    
    <content type="text">**KiCon Europe 2024** took place on September 19–20 in the [Rotunde Bochum](https://rotunde-bochum.de), organised by [**Open Skunkforce e.V.**](https://skunkforce.org) together with the KiCad project. Around 150 people came — designers, engineers, developers, hobbyists — from across Europe and beyond. It was the largest KiCon we had run in Bochum. ## From KiCon Germany to KiCon Europe The conference didn&apos;t appear out of nowhere. In 2020, I organised the first **KiCon Germany** — a small, informal gathering of KiCad users in Bochum. We ran it four more times, each edition a little bigger, a little more polished. In 2024 we made the leap to a proper European edition: new venue, full two-day programme, workshops, international speakers. ![Pre-conference social the evening before — group di...</content>
  </entry>
  

</feed>
