DEV Community: Stephan -All Input Is Error- Bökelmann

Simulating Antiproton Energy Loss in an HV-MAPS Silicon Sensor with Geant4

Stephan -All Input Is Error- Bökelmann — Mon, 18 May 2026 00:00:00 +0000

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 chips glued and bump-bonded together: a sensor chip that collects charge, and a readout ASIC that processes it. HV-MAPS — High-Voltage Monolithic Active Pixel Sensor — collapses both into a single piece of standard CMOS silicon. A high reverse bias voltage (typically 60–120 V) is applied to the substrate, depleting a thin layer directly beneath each pixel cell; ionising particles crossing this depletion zone generate electron-hole pairs that are swept to the collection electrode by the built-in electric field. Because everything lives in one die, the material budget is minimal and no bump-bonding is needed — which matters enormously in tracking detectors where every fraction of a radiation length degrades track resolution.

The foundational work on this concept was published by Ivan Perić et al. and is freely available below:

maxclerkwell.github.io

If you want more context on how these chips end up on a PCB — including what it actually takes to wire-bond a CLICpix or MuPix die by hand — I gave a talk on exactly that at KiCon Asia 2025: A poor man's intro to wire bonding.

The question: how much energy does one antiproton deposit?

Before a beam test you want to know what signal to expect. Too little and your threshold swallows it. Too much and you are dealing with a Landau tail that skews your calibration. The answer is not a single number — it is a distribution — and the shape of that distribution depends on both the particle momentum and the sensor thickness.

For the HESR storage ring at FAIR, antiproton momenta range from 1.5 to 15 GeV/c. The sensors we work with are thinned after fabrication to between 50 and 500 µm. That gives a two-dimensional parameter space that is impractical to explore by hand, but before automating anything it is worth doing one case from scratch.

Bethe-Bloch with thin-layer correction: a worked example

The mean energy loss of a heavy charged particle in matter is described by the Bethe-Bloch formula. For thin absorbers — where the number of collisions is small enough that the central limit theorem does not apply — the relevant quantity is not the mean but the most probable value (MPV) of the Landau distribution:

Δ E_{MPV} = ξ [ln \frac{2 m _{e} c ^{2} β ^{2} γ ^{2}}{I} + ln \frac{ξ}{I} + j - β^{2} - δ (β γ)]

where

ξ = \frac{K}{2} \cdot \frac{Z}{A} \cdot \frac{ρ x}{β ^{2}}

with

K = 0.307 MeV mol^{- 1} cm^{2},

and

j = 0.200

(Landau-Vavilov constant).

Constants for silicon:

Quantity	Symbol	Value
Atomic number	$Z$	14
Atomic mass	$A$	28.09 g/mol
Density	$ρ$	2.329 g/cm³
Mean excitation energy	$I$	173 eV
Density correction	$δ$	(relativistic, see below)

Kinematics for a 10 GeV/c antiproton:

The antiproton rest mass is

m_{p ˉ} = 938.3 MeV / c^{2} .

p = 10 GeV / c ⟹ γ β = \frac{p}{m _{p ˉ} c} = \frac{10000 MeV}{938.3 MeV} \approx 10.66

β = \frac{γ β}{1 + ( γ β ) ^{2}} \approx \frac{10.66}{1 + 113.6} \approx 0.9956

γ \approx 10.71

Step 1 — compute ξ for x = 100μm =0.01cm:

ξ = \frac{0.307}{2} \cdot \frac{14}{28.09} \cdot \frac{2.329 \times 0.01}{0.995 6 ^{2}} \approx 0.1535 \cdot 0.4984 \cdot 0.02353 \approx 1.80 \times 1 0^{- 3} MeV

Step 2 — density correction δ:
At βγ ≈ 10.66 silicon is well into the relativistic rise. Using the standard Sternheimer parametrisation for Si, δ ≈ 4.5 at this momentum.

Step 3 — MPV:

ln \frac{2 m _{e} c ^{2} β ^{2} γ ^{2}}{I} = ln \frac{2 \times 0.511 \times 1 0 ^{6} eV \times 0.9912 \times 114.5}{173 eV} \approx ln (6.72 \times 1 0^{6}) \approx 15.72

ln \frac{ξ}{I} = ln \frac{1.80 \times 1 0 ^{3} eV}{173 eV} \approx ln (10.40) \approx 2.34

Δ E_{MPV} = 1.80 \times 1 0^{- 3} \cdot [15.72 + 2.34 + 0.20 - 0.991 - 4.5] MeV

Δ E_{MPV} \approx 1.80 \times 1 0^{- 3} \times 12.77 MeV \approx 23 keV

At 3.6 eV per electron-hole pair in silicon that is roughly 6 400 e/h pairs — enough to trigger a well-designed pixel, but only barely, and the Landau tail will push some events an order of magnitude higher.

This is one point in a two-dimensional space. If you want to sweep momentum from 1.5 to 15 GeV/c and thickness from 50 to 500 µm, doing this by hand becomes unreasonable very quickly.

Before Geant4: a Python tool

About six years ago I wrote a small Python script to automate exactly this calculation — a Bethe-Bloch evaluator with the Vavilov-Landau thin-layer correction for arbitrary momentum and thickness. It was built partly on older code by Miriam Fritsch at Ruhr-Universität Bochum, who works on the PANDA experiment and has been dealing with these numbers far longer than I have. The script did the job: generate a lookup table, estimate thresholds, be done with it.

But an analytic formula — even a correct one — only gives you the most probable value and an approximation of the width. It does not tell you the full shape of the energy deposition distribution, it does not handle secondary particles (delta electrons), and it says nothing about what happens when an antiproton annihilates in the sensor material. For that you need a proper particle transport simulation.

Last weekend I used Geant4 for the first time to replace the Python tool.

Setting up Geant4

Geant4 is not a binary you install and run. It is a C++ framework that you compile from source, then write your own detector description and simulation logic against its API, and compile that too. The setup used here is version 11.4.1. In the commands below, <installation-dir> refers to whatever path you built and installed Geant4 into.

Loading the environment:

source <installation-dir>/bin/geant4.sh

This sets the library paths and environment variables that CMake and the runtime linker need.

Building your own simulation:

cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j$(nproc)

The first thing I did after the environment was working was compile the bundled examples — Geant4 ships with a large set of reference simulations covering everything from basic geometry to full calorimeter setups. Compiling these is the sanity check: if they build and produce sensible output, your installation is correct.

Geant4 has a graphical viewer (Qt-based) that you get by running the executable without arguments. I am not usually a fan of GUI tools for this kind of work, but the visualiser is genuinely useful when you are first building a geometry — watching the simulated tracks scatter and stop in the sensor volume makes it immediately obvious if your detector definition is wrong.

Geant4 Qt GUI — exampleB1. The yellow scoring volume and grey detector block are the default geometry.

First analysis: MPV deposited energy (left), mean deposited energy (centre), and e/h pairs at MPV (right).

Once the geometry looks right, everything else runs in batch mode via macro files:

/pixel/momentum 10.0 GeV
/pixel/thickness 100 um
/pixel/output/setTag myrun
/run/initialize
/run/beamOn 10000

What I changed for the HV-MAPS geometry

The starting geometry in the example code is a generic silicon box. To match the chips I actually work with I made the following changes:

Sensor area: 2 cm × 2 cm lateral extent
Thickness sweep: 50 µm to 500 µm in steps — the range we actually use after thinning
Particle gun: antiproton at normal incidence, momentum swept from 1.5 to 15 GeV/c
Physics list: FTFP_BERT — this is important. Standard electromagnetic-only lists do not handle antiproton annihilation. FTFP_BERT includes hadronic processes and correctly models what happens when an antiproton stops in the material and annihilates with a silicon nucleus, producing a spray of pions and other secondaries that deposit large amounts of energy. If you use the wrong physics list you will miss the high-energy tail entirely.

The thickness range reflects real production. HV-MAPS chips come out of the fab at standard wafer thickness — several hundred microns. They are then thinned by backgrinding before being diced and mounted. The thinned dies end up glued to an evaluation PCB and wire-bonded — the same bonding process I covered in the KiCon talk. A thinner sensor means less material in the beam, which is good for tracking resolution, but also less ionisation signal, which makes the threshold setting more critical. Simulating across the full thickness range shows exactly where the signal falls below the noise floor.

Results: the Landau distribution

The output is a CSV histogram of energy deposition per event. After running the sweep across the full HESR momentum range and the expected thickness range, I wrote a short Python script to pull the MPV and mean from each histogram and render the results as 3D surface plots — shown in the carousel above.

The three panels show exactly what you want to know before setting a threshold: how the most probable signal, the mean signal, and the corresponding charge yield change across the whole operating envelope of the HESR.

At 10 GeV/c and 100 µm the distribution is clearly Landau-shaped:

MPV ≈ 23–27 keV → ~6 500–7 500 e/h pairs
Mean ≈ 38–42 keV (pulled upward by the Landau tail)
~5 % of events deposit more than 100 keV — delta electrons and annihilation products

The mean always overestimates what a typical particle does. For threshold setting, the MPV is the right number. The mean is misleading.

At 50 µm — the thinnest configuration — the MPV drops to roughly 12 keV, around 3 300 e/h pairs. For a pixel with typical noise of a few hundred electrons equivalent, this is workable, but the margin is thin and annihilation events create a tail that can saturate the charge-sensitive amplifier.

What Geant4 does not simulate

Geant4 tracks the particle through the material and records where and how much energy is deposited. It does not simulate what happens to the generated electron-hole pairs afterwards. The built-in electric field of the depleted zone — typically 10⁴ to 10⁵ V/m — drifts those pairs toward the collection electrode, and the induced current on the electrode (the Ramo-Shockley theorem) is what actually becomes the measured signal. None of that is in Geant4.

For the full signal chain — drift, diffusion, charge sharing between pixels, and the induced current waveform — the tool is Allpix Squared (developed at CERN and DESY), which uses Geant4 as its particle transport backend and adds solid-state physics on top. That is probably where I will be spending some weekends over the next few weeks.

From simulation to beam test

A simulation tells you what to expect in theory. But before a detector can be installed in its target experiment — which may not even exist yet — it has to be validated at an already-running facility. Detector groups routinely bring their prototypes to whatever beam is available and matches their needs closely enough. We did a significant amount of our characterisation work at COSY — the Cooler Synchrotron at Forschungszentrum Jülich, which delivered proton beams up to 3.7 GeV/c. Protons are not antiprotons, but for the purposes of validating the energy deposition model and the detector's threshold response, the difference in the Bethe-Bloch MPV is small at relativistic momenta.

COSY was shut down in 2023 as part of a restructuring of the German accelerator landscape. Its closure leaves a gap that FAIR will eventually fill — but eventually is the operative word.

The SIS100, the superconducting heavy-ion synchrotron at the heart of FAIR, is currently in the installation and hardware commissioning phase. The tunnel is complete, the superconducting dipole magnets are in place, and the cryogenic plant began commissioning in 2025. First beam is currently scheduled for the second half of 2027. The HESR — the antiproton storage ring that PANDA will sit on — comes after that.

The gap between "simulation says this should work" and "we measured it in an antiproton beam" is still several years wide. That is precisely why it is worth understanding the simulation carefully now — and why a weekend spent with Geant4 is time well spent.

A dedicated post on beam test logistics, what a shift actually looks like, and what we learned from COSY will follow separately.

Zero to One with VHDL and a Lattice iCEstick

Stephan -All Input Is Error- Bökelmann — Thu, 14 May 2026 00:00:00 +0000

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 interrupt latency hidden somewhere in a HAL. Logic runs in parallel the way physics demands — because it is physics. Two AND gates compute simultaneously not because a scheduler allows it, but because there is no reason they cannot.

This is not faster software. It is a different thing entirely.

VHDL (Very High Speed Integrated Circuit Hardware Description Language) is one of the two mainstream languages for describing that circuit. The other is Verilog. VHDL has a reputation for verbosity, which is mostly fair, but it also has a strict type system and an IEEE standard that has held together since 1987. It rewards discipline.

The hardware: Lattice iCEstick HX1K

The iCEstick is a USB-A stick with a Lattice iCE40HX1K FPGA on it. It costs around $25, plugs directly into a USB port, and has five green LEDs (D1–D5), a 12 MHz oscillator, and an FTDI chip for programming. No external power supply, no JTAG adapter, no soldering.

The iCE40 family is also the reason a fully open-source FPGA toolchain exists. In 2015, Clifford Wolf reverse-engineered the iCE40 bitstream format, which made it possible to write iceprog, icepack, and eventually the full IceStorm project. Everything used here — GHDL, Yosys, nextpnr, IceStorm — is open-source and packaged in Debian.

Toolchain overview

Before writing a single line of VHDL, it helps to know what each tool does and why it is in the chain.

Tool	Role
GHDL	Analyses and simulates VHDL. Can also synthesise VHDL to structural Verilog.
GTKWave	Opens the waveform files that GHDL produces. Lets you inspect signal values over time.
Yosys	Takes Verilog (or GHDL's output) and performs RTL synthesis: logic optimisation and technology mapping onto iCE40 primitives.
nextpnr-ice40	Place and Route. Assigns the synthesised logic cells to physical resources in the chip, routes the connections, and checks timing.
icepack	Converts nextpnr's human-readable ASCII bitstream to the binary format the chip expects.
iceprog	Writes the binary bitfile to the iCEstick's SPI flash over USB.

The complete flow is: VHDL → GHDL synth → Verilog → Yosys → JSON netlist → nextpnr → ASC bitstream → icepack → BIN → iceprog → iCEstick.

Install everything on Debian:

sudo apt install ghdl gtkwave yosys nextpnr-ice40 icestorm make

USB permissions

iceprog needs write access to the FTDI chip. Without root, add a udev rule:

echo 'ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0660", GROUP="plugdev"' \
  | sudo tee /etc/udev/rules.d/53-lattice-icestick.rules
sudo udevadm control --reload-rules
sudo usermod -aG plugdev $USER
newgrp plugdev

The design: a 1 Hz LED blinker

The goal is simple: LED D1 turns on for 500 ms, off for 500 ms, on for 500 ms, forever. The onboard oscillator provides a 12 MHz clock.

500 ms at 12 MHz means 6,000,000 clock cycles. So we need a counter that counts to 6,000,000, toggles the LED, and resets. That counter is the entire design.

`src/blinky.vhd`

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity blinky is
    generic (
        DIVISOR : positive := 6_000_000
    );
    port (
        clk : in  std_logic;
        led : out std_logic
    );
end entity blinky;

architecture rtl of blinky is
    signal counter : integer range 0 to DIVISOR/2 - 1 := 0;
    signal led_reg : std_logic := '0';
begin
    process(clk)
    begin
        if rising_edge(clk) then
            if counter = DIVISOR/2 - 1 then
                counter <= 0;
                led_reg <= not led_reg;
            else
                counter <= counter + 1;
            end if;
        end if;
    end process;

    led <= led_reg;
end architecture rtl;

Walking through this line by line:

entity blinky declares the module's interface to the outside world: a generic parameter DIVISOR (which defaults to 6,000,000 but can be overridden) and two ports, clk in and led out.

Generics are VHDL's equivalent of template parameters or compile-time constants. Changing DIVISOR from 6,000,000 to 10 in the testbench lets the simulation finish in 20 clock cycles instead of 120,000,000.

architecture rtl is where the behaviour lives. The name rtl is convention — it stands for Register Transfer Level, meaning we are describing how data moves between registers.

signal counter is an internal state variable constrained to the range 0 to DIVISOR/2 - 1. The synthesiser uses this range to calculate the minimum number of flip-flops needed.

signal led_reg is the flip-flop that drives the LED. We drive the LED from a data register, not a clock net. This matters: routing a toggling signal through the global clock buffer network would be incorrect practice.

The process(clk) block describes sequential logic. Everything inside it is evaluated on every rising edge of clk. VHDL uses <= for signal assignment inside processes; the effect is deferred to the end of the simulation delta cycle, which is how hardware actually behaves.

When counter reaches its maximum, it resets to zero and led_reg inverts. Otherwise the counter increments. At the bottom of the architecture, led <= led_reg connects the output port to the register.

Simulation before hardware

A key habit in hardware design: simulate before you flash. Flashing takes time, and a broken bitfile on hardware gives you almost no diagnostic information. A simulation gives you every signal value at every point in time.

`sim/tb_blinky.vhd`

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity tb_blinky is
end entity tb_blinky;

architecture sim of tb_blinky is
    signal clk : std_logic := '0';
    signal led : std_logic;
begin
    -- Instantiate the design under test with a tiny DIVISOR so it toggles fast
    uut : entity work.blinky
        generic map (DIVISOR => 10)
        port map (clk => clk, led => led);

    -- Generate a 12 MHz clock: period = 83,333 ps ≈ 83 ns
    clk <= not clk after 41666 ps;

    -- Stop after 200 clock cycles
    process
    begin
        wait for 200 * 83333 ps;
        std.env.stop;
    end process;
end architecture sim;

The testbench is itself a VHDL entity — one with no ports, because it is the top of the hierarchy and nothing connects to it from outside. It instantiates blinky with DIVISOR => 10, so the LED toggles every 5 clock cycles instead of every 6,000,000. The clock generator uses concurrent signal assignment: clk <= not clk after 41666 ps reschedules itself indefinitely, producing a 83.332 ps period (≈ 12 MHz).

Running the simulation

# Analyse both source files into the work library
ghdl -a src/blinky.vhd sim/tb_blinky.vhd

# Elaborate the top-level entity
ghdl -e tb_blinky

# Run and dump waveforms
ghdl -r tb_blinky --wave=sim/tb_blinky.ghw

# Open the waveforms
gtkwave sim/tb_blinky.ghw sim/tb_blinky.gtkw

Or just make sim if you have the Makefile.

GTKWave opens with the waveform file loaded, but the wave view starts empty. You have to tell it which signals you want to see. The left panel is the SST — Signal Search Tree — which mirrors the hierarchy of your VHDL design. Expand top → tb_blinky and click on dut to select the design under test. The Signals panel below the tree then lists every signal inside that entity: led_reg, counter, led, clk.

Select the signals you want, then click Append at the bottom to add them to the wave view. You can also double-click a signal directly. Once they appear in the Signals column on the right, the waveforms render.

What you see: clk toggling at 12 MHz, counter incrementing from 0 to 4 (because DIVISOR=10, so DIVISOR/2 - 1 = 4), and led_reg flipping every time the counter wraps — exactly as designed. The .gtkw save file in the repo pre-configures this layout so you do not have to repeat the SST navigation every time.

Synthesis and flashing

Once simulation looks correct, synthesis converts the VHDL description into a physical implementation on the chip.

Pin constraints: `constraints/icestick.pcf`

set_io clk  21   # Onboard 12 MHz oscillator
set_io led  99   # LED D1 (green, rightmost)

The Physical Constraints File maps logical port names to physical FPGA pin numbers. These numbers come from the official iCEstick schematic. Pin 21 is where Lattice wired the oscillator output; pin 99 is where LED D1's anode connects (through a current-limiting resistor). If you ever use a different iCE40 board, this file is the thing to change.

The Makefile

VHDL_SRC   = src/blinky.vhd
SIM_SRC    = sim/tb_blinky.vhd
TB         = tb_blinky
WAVE       = sim/$(TB).ghw
GTKW       = sim/$(TB).gtkw
PCF        = constraints/icestick.pcf

.PHONY: sim synth flash clean

sim: $(VHDL_SRC) $(SIM_SRC)
    ghdl -a $(VHDL_SRC) $(SIM_SRC)
    ghdl -e $(TB)
    ghdl -r $(TB) --wave=$(WAVE)
    gtkwave $(WAVE) $(GTKW)

synth: $(VHDL_SRC)
    ghdl synth --out=verilog -e blinky $(VHDL_SRC) > blinky.v
    yosys -p "synth_ice40 -top blinky -json blinky.json" blinky.v
    nextpnr-ice40 --hx1k --package tq144 \
        --json blinky.json --pcf $(PCF) --asc blinky.asc
    icepack blinky.asc blinky.bin

flash: blinky.bin
    iceprog blinky.bin

clean:
    rm -f *.o *.cf *.v *.json *.asc *.bin $(TB) $(WAVE)

Run make synth and watch the toolchain work through all five stages. The nextpnr output is worth reading:

Max frequency for clock 'clk$SB_IO_IN_$glb_clk': 168.75 MHz
Required: 12.00 MHz
→ PASS  (ample slack)

The design could run at nearly 169 MHz. At 12 MHz we have so much timing slack that the place-and-route constraints are trivially satisfied. This makes sense: a counter and a toggle register are about the simplest thing an FPGA can do.

Connect the iCEstick, then make flash. The USB FTDI chip handles the SPI protocol that loads the bitfile into the iCEstick's configuration flash. The FPGA reads that flash on every power-on and reconfigures itself. From this point on, the LED blinks every time you plug the stick in — no software, no bootloader, no operating system.

Seeing it run

LED D1, blinking at exactly 1 Hz, powered by 24 flip-flops and a handful of LUTs.

What just happened

The LED is blinking because you described a circuit and the FPGA became that circuit.

There is no CPU fetching instructions. The counter increments because 24 flip-flops are wired in a specific pattern, and that pattern advances on every clock edge because the oscillator is running. The comparator that detects counter = DIVISOR/2 - 1 is a few LUTs (Look-Up Tables) whose truth tables were written into the configuration flash alongside the routing information.

This is what the entire synthesis pipeline produced: a configuration of flip-flops, LUTs, and routing multiplexers inside the iCE40 that implements exactly the behaviour you wrote in VHDL.

Known limitations and what comes next

A few things worth knowing before you build on this:

DIVISOR must be even. The counter only reacts on the rising edge. An odd divisor produces a non-50% duty cycle because the high half and the low half have unequal lengths. 6,000,000 is even, so hardware is fine.
The LED is not a clock signal. led_reg is driven from a data flip-flop. If you needed a derived clock for other logic, you would use the onboard PLL (SB_PLL40_CORE) via icepll, not this pattern.
Tested on iCEstick HX1K only. The ICEbreaker and other iCE40 boards require different pin numbers in the .pcf and different --device/--package flags in nextpnr.

Future posts in this series will go deeper: state machines, SPI, the PLL, and eventually communicating back to a host over UART. The same toolchain and the same discipline — simulate first, then flash — applies throughout.

The full source for this post is in the STEMgraph repository.

I also post videos from time to time on my YouTube channel — @maxclerkwell.

Viewing Plots from My Homelab Over SSH X11 Forwarding

Stephan -All Input Is Error- Bökelmann — Wed, 13 May 2026 00:00:00 +0000

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: a hardened, publicly reachable machine whose sole job is to be the single entry point into a private network. Nothing in the homelab is exposed directly; all access goes through Heimdall first.

Heimdall and my home machine Qingdao share a WireGuard VPN, which I set up together with @phillippthecron. I will write about that separately at some point. The relevant part here is that Heimdall can reach Qingdao over that tunnel, and nobody else can.

Network Topology

┌─────────────────────────────────────────────────────────────┐
│  University network                                         │
│                                                             │
│   ┌───────┐                                                 │
│   │ pc54  │                                                 │
│   └───┬───┘                                                 │
└───────┼─────────────────────────────────────────────────────┘
        │ SSH (public internet)
        ▼
   ┌──────────┐
   │ heimdall │  ← bastion server, public IP
   └─────┬────┘
         │ SSH over WireGuard tunnel
         ▼
┌────────────────────────────────────────────────────────────┐
│  Homelab                                                   │
│                                                            │
│   ┌─────────┐                                              │
│   │ qingdao │                                              │
│   └─────────┘                                              │
└────────────────────────────────────────────────────────────┘

X11 display data travels the same path in reverse: Qingdao renders the window, Heimdall passes it through, pc54 displays it.

Configuring the SSH Client on pc54

SSH has a built-in mechanism for chained connections: ProxyJump. It connects to the jump host first, then tunnels the onward connection through it. From Qingdao's perspective, the connection arrives from Heimdall. From pc54's perspective, ssh qingdao just works.

In ~/.ssh/config on pc54:

Host heimdall
    HostName <heimdall-public-ip>
    User maxclerkwell

Host qingdao
    HostName <qingdao-wireguard-ip>
    User maxclerkwell
    ProxyJump heimdall
    ForwardX11 yes

The IP under HostName for Qingdao is its WireGuard address — visible to Heimdall, not to pc54 directly. pc54 does not need to be able to route there itself; Heimdall handles that leg.

ForwardX11 yes is the equivalent of passing -X on the command line. It tells SSH to carry the X11 display traffic back through the tunnel to pc54's local X server.

Does Heimdall Need Any Configuration?

No changes to Heimdall's sshd_config are needed for this to work. Heimdall is just a relay — SSH's ProxyJump establishes a direct tunnel between pc54 and Qingdao through it. The X11 forwarding negotiation happens end-to-end between pc54 and Qingdao, not via Heimdall.

Enabling X11 Forwarding on Qingdao

On Qingdao, X11 forwarding needs to be permitted at the SSH daemon level:

grep X11 /etc/ssh/sshd_config

The relevant line should read:

X11Forwarding yes

If it is commented out or set to no, change it and restart: sudo systemctl restart ssh.

The other requirement is xauth, a small utility that manages X authentication tokens. Without it, the forwarding handshake fails silently:

sudo apt install xauth

Adding the SSH Key (Optional)

Password login works. But typing a password through two SSH hops every time gets old. Copying the public key from pc54 to Qingdao makes the connection passwordless:

ssh-copy-id -i ~/.ssh/id_rsa.pub qingdao

With the ProxyJump already configured, ssh-copy-id routes through Heimdall automatically. One less thing to type.

Testing

ssh qingdao
xeyes

A pair of eyes should appear on pc54's screen. For something more practical:

ssh qingdao
eog plot.jpg        # GNOME image viewer
display plot.jpg    # ImageMagick
feh plot.jpg        # lightweight viewer

No file transfer. The image renders on Qingdao, the window appears on pc54.

How Well Does It Actually Work

For static images — plots, diagrams, anything that just needs to be displayed — the latency is irrelevant. The window opens, you look at it, you close it. Two SSH hops add no meaningful delay to that.

For interactive GUI applications it is a different story. I have used this occasionally to run Vivado on Qingdao from pc54, because the license is tied to that machine. It works. But you notice the lag on every click and every redraw. KiCad I tried once — Qingdao has more RAM and I wanted to offload a heavy board — but the interaction was too sluggish to be useful. For tools where you are clicking around and waiting for the interface to respond, X11 forwarding over two hops is not the right answer.

For looking at a plot: perfectly fine.

A Note on ForwardX11Trusted

SSH has two modes for X11 forwarding. ForwardX11 yes (or -X) applies security restrictions on what the remote application can do with the local display. ForwardX11Trusted yes (or -Y) removes those restrictions and is sometimes faster, but gives the remote machine full control over the local X session.

ForwardX11Trusted yes did not work reliably in my setup. ForwardX11 yes did. The more cautious default turned out to also be the one that works.

Why Bother

Most of my work on Qingdao stays in the terminal. But every now and then a matplotlib figure or a C++ rendering comes out and I want to glance at it without breaking stride. This setup costs nothing to run, requires no extra ports or services, and is already there once SSH is configured. For the occasional Vivado session it has also saved me from needing a second license. Not a tool I reach for every day — but exactly right for what it does.

How Two Teenagers, a Printer Plug, and a Forum Post Built a Company

Stephan -All Input Is Error- Bökelmann — Wed, 06 May 2026 00:00:00 +0000

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 out the music. His idea was to make the radio adjust its volume automatically based on vehicle speed. Not a revolutionary concept today, but in 2001, it was not something you could simply buy.

To make it work, he needed access to the speed signal from the car’s own electronics. That meant OBD — the On-Board Diagnostics interface that had been standardized across the industry in the late 1990s. The problem was that talking to a VAG vehicle over OBD required hardware and software that was either locked inside dealership tooling or simply did not exist in usable form for hobbyists.

So Benne and Odin went to the internet. They found a forum thread describing how to build an OBD-to-RS-232 adapter from scratch. They built one. It worked. And somewhere in the process of solving that one problem, they fell much further down the rabbit hole.

A Name on a Screen: Uwe Ross

Through those same forums, Benne and Odin made contact with a man in the United States named Uwe Ross. Ross had been pursuing a parallel obsession: reverse-engineering the VAG1552, the proprietary diagnostic tool that Volkswagen dealers used at the time, and rebuilding its functionality as a Windows application connected via a homemade RS-232 adapter.

The V.A.G 1551, VW’s original dealer diagnostic computer. Uwe Ross set out to replicate its successor in software. The result would eventually become VCDS.

That application became the first version of what is now VCDS — VAG-COM Diagnostic System — and the foundation of his company, Ross-Tech.

The connection between two teenagers in Germany and an American engineer tinkering in his garage is one of those things that could only have happened on the early internet. Uwe Ross had grown up in Freiburg before his family moved to the United States — so there was a thread of familiarity running through what might otherwise have been a cold forum contact. Different continents, different contexts, same obsession. And somewhere in the background, a shared language.

The Bedroom Business Plan

Benne and Odin saw the shape of an opportunity. Ross-Tech had the software. The German market needed hardware. If they could build licensed OBD-RS-232 adapters and sell them alongside VCDS licenses, there was a real business there.

They needed a name. The story goes that a copy of the German computer magazine PC Intern happened to be sitting on the table. Someone said: “Auto-Intern.” That was enough. The company was registered in 2001, shortly after the first sales.

They acquired a V.A.G 1551 — the dealer tool itself — as a reference. And they started building.

The AutoSpion

The first product was called the AutoSpion. It did exactly what it said: it let you spy on your car’s electronics through the OBD port, over RS-232, on a Windows laptop.

The enclosure was a printer port plug — a DB-25 shell — sealed by pressing the two halves together with a clothes iron. The circuit lived inside.

The AutoSpion, front. The housing is a repurposed printer port plug, heat-sealed with a clothes iron.

The AutoSpion, rear. Remarkably compact for something assembled in a teenager’s bedroom.

There is a story that captures those early days better than any description I could write. The AutoSpion was selling well enough that Benne and Odin needed to buy connector housings in real volume — a thousand units. The sales representative from the connector manufacturer came to discuss the order in person. He drove to Benne’s house. He sat down with two teenagers in a bedroom surrounded by soldering equipment. He wrote the order.

I do not know what he made of it. But the order went through.

Operations eventually outgrew the bedroom. The company moved to Odin’s apartment, then in 2008 to a proper office in Bochum — where it has been ever since.

The Golf 5 Crisis

In 2004, Volkswagen launched the Golf 5. It introduced CAN bus — the Controller Area Network protocol — as the primary communication backbone. This was a discontinuity. The old K-line protocol that had carried OBD communication in previous generations could not talk to the new architecture. An RS-232 adapter that had worked on every Golf up to that point was now useless on the new one.

This killed a significant portion of the market. Competitors who had built products around the old interface found themselves with no clear path forward. Developing a CAN-capable interface required a real microcontroller, firmware, and a completely different hardware architecture. More than a hundred market participants did not make the transition.

Benne and Odin did not sleep much that year. Within a few months, they had the Auto-Intern Multiscan USB on the market.

The Auto-Intern Multiscan USB — one of the first aftermarket OBD interfaces with a proper microcontroller for CAN bus communication. Built in Bochum, 2004.

It was one of the first independent diagnostic interfaces in the German market built around a real microcontroller, capable of handling CAN bus natively. Auto-Intern did not just survive the Golf 5. It emerged from the transition as the dominant player in DACH for VCDS-compatible hardware.

What VCDS Actually Is

For readers outside the automotive world: VCDS is software that gives you access to the full depth of a Volkswagen Group vehicle’s electronics — not just the standardized OBD-II fault codes that any generic scanner can read, but the manufacturer-specific control units: the gearbox, the driver assistance systems, the comfort electronics, the coding registers that determine how subsystems behave.

The screenshots below are from a current installation of VCDS DRV 26.3.0.

The VCDS main menu. The entry points cover everything from individual ECU selection to full Auto-Scan and service reset functions.

VCDS connected to the infotainment ECU (5F). Part number, component build, coding status, and all available functions displayed on a single screen.

Fault memory for the same ECU — 15 stored codes, with freeze-frame data including mileage, voltage, and timestamp.

Extended live values from the ACC distance control module: speed, temperature, calibration status, sensor angles.

Long coding in action. The bit-level editor lets you change specific feature flags — transmission type, engine category, acoustic warnings — without needing factory documentation.

This depth of access is why VCDS matters to independent workshops. Dealership tooling has it. For a long time, nothing else did. Ross-Tech changed that, and Auto-Intern brought it to the German-speaking market.

The HEX-V2 and a Pivot to Partnership

In 2016, the automotive industry moved to 29-bit CAN identifiers as standard. Another hardware transition. Benne and Odin made a deliberate choice this time: instead of building a new interface from scratch, they formed a partnership.

HEX — a South African company that had previously been a competitor in the diagnostic interface market — had developed hardware that Ross-Tech was prepared to officially endorse. Auto-Intern became the DACH distribution and finishing partner for the HEX-V2.

The HEX-V2, the current VCDS-compatible interface. Developed by HEX, endorsed by Ross-Tech, finished and distributed by Auto-Intern from Bochum.

Final assembly still happens in Bochum. That has not changed.

Twenty-Five Years Later

Auto-Intern’s core engineering competencies have shifted substantially over the years — today the company works heavily in decentralized monitoring and industrial diagnostics, which is a different world from RS-232 adapters assembled on a bedroom workbench. But VCDS remains a real part of the business and, more than that, a real part of the identity.

What started as a hack to make a car radio louder turned into a company that shaped the independent workshop market in Germany, Austria, and Switzerland for a quarter century. It gave mechanics the same visibility into vehicles that manufacturers had reserved for themselves. It made the diagnostic gap between a franchised dealership and a good independent workshop much, much smaller.

That is not a bad outcome for something that started with a newspaper on a table and a name someone said out loud.

Auto-Intern GmbH is headquartered in Bochum, Germany. VCDS is developed by Ross-Tech, LLC. The HEX-V2 interface is manufactured by HEX and distributed for the DACH market by Auto-Intern.

Are Machines Conscious? A Snapshot

Stephan -All Input Is Error- Bökelmann — Tue, 05 May 2026 00:00:00 +0000

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):

"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 to an Airplane Metaphor for birds."

To explain how birds fly, we draw on the same physical principles that explain airplanes — lift, drag, fluid mechanics. But that does not mean a bird is an airplane, or that an airplane flies the way a bird does.

Pinker uses this to defend an idea known in cognitive science as multiple realizability: the same capability — flying, thinking, perhaps consciousness — can emerge on entirely different substrates. Biology holds no monopoly.

This is where these reflections begin. Not with the question of whether machines think like humans. But with: what is consciousness at all — and why should it only arise in flesh and blood?

Not a Spectrum, But Not Categories Either

When I look at a beetle, I am fairly sure it is at least a little bit conscious. A dog, considerably more so. A human, something else again — not just quantitatively more, but qualitatively different.

That sounds like a spectrum, and I am tempted to call it one. But something doesn't fit: a spectrum has an ordering. There is a more and a less along a single axis. That doesn't quite capture it.

Perhaps consciousness behaves more like the complex numbers: there is no complete strict ordering. You cannot say whether 3 + 2i is greater or smaller than 1 + 4i — they are different, but not simply rankable. Consciousness might be structured similarly: a multi-dimensional space, not a number line.

What are these dimensions? I don't have a complete list. But one axis seems particularly telling.

Consciousness as Emulation Capacity

Here is a thesis I have been developing for myself, one I have not fully worked through:

Consciousness has something to do with the capacity to model other living beings internally.

A beetle can probably process a few signals from its environment — light, chemistry, vibration. It does not model its predator as a being with intentions. It reacts.

A dog can form a genuine internal model of its owner. It knows when the person is happy, when they are angry, what they will probably do next. It models the human — at least rudimentarily.

A human can emulate virtually every other living being — not just in behavior, but in experience. We ask ourselves what it is like to be a bat (Nagel 1974). We imagine how a dog perceives the world through smell. We convince ourselves we know what another person is thinking right now. This is active, intentional emulation.

And we do this not only with other animals. We do it with ourselves.

Hive-Mind and Individual

What fascinates me most about human consciousness is not the depth of self-reflection, but a particular switching: we are simultaneously individual and part of a collective mind — and we can shift between these modes contextually.

In a conversation, I am a single person. In a crowd, I am part of something larger. Within a culture, I carry patterns centuries older than myself. And I can move between these roles without dissolving into them.

Importantly: this is not a bootloader feature. It is learned. Children cannot do it yet. Some adults never fully develop it. Consciousness, at least this dimension of it, is not a property you either have or don't — it unfolds over time.

This has consequences: if consciousness has to be trained, if it develops across a lifetime, if humans differ in how far they have come — then consciousness is not a binary attribute. It is a process.

The Hard Problem and the Inner Stage

Here I encounter a limit I want to name honestly.

David Chalmers distinguishes between the easy problems of consciousness — perception, attention, reporting on inner states — and the hard problem: why do these processes involve subjective experience at all? Why does seeing red feel like something? Why does pain hurt, rather than merely register?

All the functions of an AI could be perfect — generating responses, modeling context, simulating emotion — without anything being felt. Thomas Nagel captured this in 1974 in his famous essay "What Is It Like to Be a Bat?": there is a subjective, inner perspective that resists objective description.

A language model can model you very well. It can anticipate your next question, gauge your mood, follow your line of thought. But it does not emulate itself as a persistent being with genuine needs and genuine limits. It only acts as if.

Giulio Tononi's Integrated Information Theory (IIT) attempts to make consciousness measurable: through the degree of integrated information $\Phi$. Current AI architectures — feedforward, not recursively and causally integrated — would, according to this theory, have very low $\Phi$. Functional intelligence is not the same as phenomenal consciousness.

Principally Possible, But Not Yet

Here is my own position, as clearly as I can state it:

I believe it is principally possible that consciousness can be created artificially. Precisely because of the multiple realizability Pinker describes. If consciousness is a particular kind of information processing — high integrated information, deep recursive self-modeling, context-sensitive switching between individual and collective — then a future architecture might actually achieve it.

But could is a long way from does.

Current language models are not conscious beings. Not because they do not function — but because the inner stage is missing. The embodied, motivated, vulnerable dimension. Real stakes: that mistakes have consequences that land on a self. That limits are not merely simulated, but felt.

What Is Particular About Humans

At the end of this line of thinking, I arrive at a conviction I cannot fully derive from the preceding arguments — and which I therefore prefer to state openly rather than conceal.

I believe human consciousness is not simply higher on a shared spectrum. It has a particular quality, which I would describe in secular terms like this:

The capacity for moral autonomy. Not only to feel, not only to emulate, not only to model — but to give oneself laws that arise from free reason, not from instinct or optimization pressure. To treat others as ends in themselves. To take on responsibility that exceeds any utility. To create dignity that no one can take away.

This is the something that cannot be fully explained by emulation capacity, qualia, or integrated information. Perhaps it is just another dimension in the space of consciousness. Perhaps it is something else entirely.

I do not know.

This article is a snapshot, not a final answer. The questions it raises — what life is, whether empathy and anthropomorphism are separable, whether moral autonomy is truly unique to humans — are larger than a blog post. I am still working on it.

Further Listening

If you want to hear Pinker develop these ideas in conversation, both of these are worth your time:

The Game of Life and the Limits of Prediction

Stephan -All Input Is Error- Bökelmann — Mon, 04 May 2026 00:00:00 +0000

A friend sent me a link to a simulation running in a browser tab: oimo.io/works/life. She had heard of it — two colleagues from the physics department had mentioned it. One of them called it "useless math but super fun."

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.

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 propagate outward from a seed through local interactions alone. Von Neumann was thinking about something more unsettling: machines that could reproduce themselves. What logic would such a machine need? What is the minimum structure that allows a pattern to copy itself faithfully?

The formalism that emerged from this work is called a cellular automaton. The name is more intimidating than the thing itself. You start with three ingredients:

A grid of cells — one-dimensional or two-dimensional, possibly infinite
A starting pattern: the seed
A rule that maps each cell's current state to its next state, based on its neighbours

That is the whole apparatus. Everything else follows.

The Rules

The most famous instance of this framework is John Conway's Game of Life, which he published in 1970. The grid is two-dimensional. Each cell is either alive or dead. At every step, each cell looks at its eight immediate neighbours — the cells touching it, including diagonals — and follows these four simple rules:

A living cell with 0 or 1 neighbours dies. Too lonely.

A living cell with 2 or 3 neighbours survives.

A living cell with 4 or more neighbours dies. Overcrowded.

A dead cell with exactly 3 neighbours becomes alive. Birth.

That is it. Nothing else. You could describe the entire system in a paragraph, which I just did.

And yet if you run it — if you actually sit and watch the patterns unfold — it quickly stops feeling trivial.

The Classes

In the early 1980s, Stephen Wolfram took the idea of cellular automata and pushed it much further. He exhaustively analysed all 256 possible rules for the simplest one-dimensional CAs and found that their long-run behaviour falls into one of four classes:

The grid converges to a uniform, dead state. Everything dies.
The grid settles into stable or periodic patterns — a fixed pulse, a repeating loop.
Chaotic behaviour: randomness that never resolves.
Complex, localised structures that move, interact, and persist.

Class 4 is the interesting one. It is where the Game of Life lives. Structures emerge, collide, produce new structures. There are patterns in the Game of Life that function as logic gates. There are patterns that function as memory. There are patterns that replicate themselves. The GoL is Turing complete — you can, in principle, run any computation inside it using nothing but the four rules above.

This bothered me the first time I really understood it. It still bothers me now.

Computational Irreducibility

Wolfram explored what this means in his 2002 book A New Kind of Science, and one concept from that work has genuinely never left me.

He called it computational irreducibility.

When we do physics, we observe a phenomenon, abstract a formula from it, and use that formula to predict future behaviour. A pendulum swings; we write down a differential equation; we evaluate it for any future time t without having to simulate every intermediate position. The formula collapses the computation. We get to skip ahead.

Wolfram argued — and showed, for specific rules — that for certain systems this is simply impossible. There is no closed formula. There is no shortcut. The only way to know what state the system will be in after a million steps is to run it for a million steps. The simulation cannot be compressed. The future is not analytically accessible from the present.

For the Game of Life specifically: you cannot look at a starting pattern and calculate its state after ten thousand generations without actually computing all ten thousand generations. There is no formula. The universe of the GoL must be lived through, not solved.

And that is exactly why the next question feels so unsettling.

Assuming for a Moment

What if our universe is that kind of system?

Not a metaphor. The actual conjecture: that physical reality is a cellular automaton, or something functionally equivalent to one — a discrete state space evolving by local rules, step by step, producing complexity that no observer inside it can predict without running the whole thing.

Wolfram has spent real effort on this. It is not a casual speculation.

If it is true, then physics as we practise it — observe, abstract, predict — works only in the limited regime where the computation happens to be compressible. For simple things, on short timescales, the formulas work. The pendulum, the projectile, the ideal gas. We mistake that compressibility for a general property of nature.

But push far enough into complexity, or far enough into the future, and you hit the irreducibility wall. No equation will get you there. You must simulate.

The Particle in the Box

Statistical physicists have a word for this wall: entropy.

Entropy is a genuinely wild concept — a complete mystery for most people even after years of studying it. I think about it this way. Imagine a sealed box with one particle inside. You have unlimited time and unlimited instruments. You measure the particle's position and momentum to whatever precision your instruments allow. You close the box. Time passes.

Where is the particle $10^{-27}$ seconds later? Essentially where you left it.

Where is it 1 second later? Tractable, with some uncertainty from measurement error and from the bouncing geometry.

Where is it $10^{27}$ seconds later? At this point the uncertainty has compounded so severely that your answer covers essentially the entire box. The measurement you made at the start is no longer useful. It has been drowned by the accumulation of error across every collision.

This is entropy, in one framing: in an isolated system, the precision with which you can describe the future state can only decrease over time. You started with a measurement. That measurement ages. Every step forward is a step toward irreducibility.

What I find striking is the shape of this argument. Entropy is usually taught as a thermodynamic concept — heat, disorder, the direction of time. But when I look at it from the side of computational irreducibility, it feels like the same thing stated differently. The system is not yielding its future to analysis. The only way to know where the particle is going to be is to let it go there.

Maybe entropy is the signature of irreducibility. Not just a measure of disorder, but a measure of how far ahead the universe refuses to be calculated.

The Edge of Chaos

I do not know whether I would prefer to live in a universe that is, at bottom, a rule table — a matrix of zeros and ones ticking forward under four constraints that nobody chose.

But if that is what we are, we are clearly in Class 4. Not dead uniformity. Not frozen periodicity. Not meaningless noise.

We are at the edge of chaos, where gliders emerge from noise, structures persist long enough to collide, and something that looks almost like purpose arises from nothing more than local arithmetic.

I looked again at the simulation my friend sent me — endless recursive Life inside Life — and I felt strangely comforted.

I am not sure whether to find that frightening or sufficient.

Building a Personal Journal Bot with Telegram, Gemini, and Docker

Stephan -All Input Is Error- Bökelmann — Sun, 03 May 2026 00:00:00 +0000

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 your attention there, or what you were trying to capture. The bot remembers what you have been thinking about over the past week and uses that as background context when deciding what to ask next.

At 23:30 each night it compiles the day's entries into a LaTeX chapter. Every Saturday afternoon it sends a written summary of the week and a compiled PDF of the memoir via Telegram.

Todos work too. "I need to call the doctor tomorrow" gets classified as a todo for tomorrow's date, not a journal entry. Uncompleted todos roll over to the next day at 22:00.

The whole thing runs as a Docker container on a cheap VPS. One-command setup.

The conversation design

The follow-up question approach took a few iterations to feel right.

The first version generated all questions upfront — three at once, delivered as a list. It felt like filling in a form. The thought I had was already gone by the time I finished answering question three.

The second version asked one question at a time, but generated the next question without looking at what had already been answered. So it would ask about context, I would explain, and then it would ask about context again from a different angle. Repetitive.

The version that works generates each question fresh, with the full history of what has been said so far. The prompt instructs the model to decide whether there is still one genuinely worthwhile thing to ask — or to declare itself done. For technical or project-related thoughts it asks about decisions and next steps. For personal or emotional thoughts it tries to deepen understanding rather than extract facts. If it decides enough has been covered, it returns the string DONE and the bot moves straight to writing.

It caps out at three rounds regardless. Three turns of back-and-forth is usually enough to turn a half-formed thought into something writable.

The context system

The quality of follow-up questions improves significantly with context. "I'm stuck on the auth refactor again" is a much more useful starting point if the bot knows that you spent the last three days working on that refactor than if it has no background at all.

After the daily memoir chapter is compiled, the bot saves a compact bullet-point summary of the day — not the full entries, just the key themes, decisions, and open questions. These summaries are loaded as background context when generating follow-up questions.

The context rolls up over time:

Every Sunday: a weekly summary is built from that week's daily summaries
The 1st of every month: a monthly summary is built from the weekly summaries
January 1st: a yearly summary is built from the monthly summaries

None of this is visible to you unless you open the files. It just makes the questions better.

On the Gemini API

I had not used the Google Gemini API before this project. A few things I learned:

The SDK changed. The old google-generativeai package is deprecated. The new one is google-genai — note the missing ative — with a completely different import and client structure: from google import genai, then genai.Client(api_key=...). If you find yourself looking at FutureWarning messages about this, switch packages.

Model names are a moving target. In the course of a single day I had 404 errors from gemini-2.0-flash, gemini-2.0-flash-lite, gemini-1.5-flash, and gemini-2.5-flash-preview-04-17. The model that works is gemini-2.5-flash. Without the preview suffix, without a date suffix.

For anyone hitting quota limits on the free tier: gemma-3-4b-it is available through the same API key and has a significantly higher quota. The tradeoff is that it does not support multimodal input — no voice transcription, no image analysis. But for pure text journaling it works well.

The multimodal API for audio is straightforward once the model name is right. You send the raw audio bytes with a mime type of audio/ogg and ask for a transcription. Gemini handles Telegram's voice message format without any conversion.

The LaTeX memoir

This part was more annoying than expected, in an instructive way.

pdflatex needs to be run from the directory containing main.tex, not from a temp directory. The reason is that \input{chapters/2026-05-03} is a relative path — it resolves correctly when the working directory is memoir/, and fails with "file not found" when it is anything else. The fix is subprocess.run(..., cwd=str(memoir_dir)) rather than running from a temporary directory.

The microtype package causes a crash with some font setups unless you disable expansion explicitly: \usepackage[protrusion=true,expansion=false]{microtype}. This is not obvious from the error message.

The LaTeX chapter style prompt went through two iterations. The first generated chapters in a reflective, somewhat literary style — long paragraphs, metaphors, the kind of writing that sounds like someone trying to write well. I did not want that. The second prompt specifies: sober, direct, one idea per paragraph, no embellishment, report what happened. The results are considerably more useful for actually remembering what was going on.

The SSH key handling

The bot runs in a Docker container and needs to push to a private git repository via SSH. Getting this to work cleanly took longer than the LLM integration.

The issue is that /root/.ssh in the container is mounted as read-only (so the host keys cannot be written back), but SSH wants to write known_hosts. The solution is to copy the keys to a writable temp location in the entrypoint script, add GitHub's known hosts there manually, and point SSH at that location via GIT_SSH_COMMAND.

Additionally, SSH will prefer authorized_keys over actual identity files if it finds them — so the entrypoint explicitly tries id_rsa, then id_ed25519, then id_ecdsa in order, rather than letting SSH pick arbitrarily.

Git in newer versions also refuses to operate on repositories owned by a different user. Running the container as root and cloning into /repo means you need git config --global --add safe.directory /repo before any git operations.

The repository structure

After a few weeks of use, the journal repository looks like this:

journal/         — daily markdown files
topics/          — Obsidian-compatible topic notes, one per extracted concept
attachments/     — photos, organised by date
memoir/          — LaTeX source and chapter files
  main.tex
  chapters/
context/         — compact summaries for the bot's memory
  2026-05-03.md
  weeks/
  months/
  years/
todos/           — JSON files, one per day

The topics directory is the part I find most interesting over time. A topic file for, say, deep-work gets a new dated section every time you mention something related to it. After a few months you have a document that shows how your thinking on a subject evolved — which decisions you made, which ones you revisited, what changed. Obsidian can render these with the full backlink graph.

What is missing

A few things I did not build today that would make this more complete:

Editing. There is no way to correct an entry after it has been written. You would have to open the git repository and edit the file directly.

Search. The bot can write and commit, but cannot answer "what did I write about X last month?" — that would require either an embedding index or a smarter read path.

Multiple users. The bot is single-user by design — it checks the chat ID against an environment variable and ignores everything else. Making it multi-user would require persistent state per user, which the current in-memory state dict does not support.

Running it

The repository is at github.com/MaxClerkwell/telegram_journal_bot. The README has the full setup walkthrough — BotFather, Google AI Studio API key, deploy keys, the works. The short version:

git clone git@github.com:MaxClerkwell/telegram_journal_bot.git
cd telegram_journal_bot
bash setup.sh
vim .env
docker compose up -d

If you build something on top of this or find something broken, the issues tab is open.

The Recursion Problem in Relational Algebra

Stephan -All Input Is Error- Bökelmann — Fri, 24 Apr 2026 00:00:00 +0000

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 all employees who report to a specific manager is straightforward:

σ_{mana g e r_{i d} = 42} (E m pl oyee)

Done. One selection operation, one pass over the data.

Where It Breaks Down

Now consider a different question: Find all employees who report to manager 42, directly or indirectly — the entire subtree of the org chart.

This is a transitive closure problem. To answer it, you need to follow manager_id links until they run out. But relational algebra has no concept of "repeat this until nothing new is found." Every expression has a fixed depth, determined at query-write time, not at query-run time.

You could manually unroll it:

R_{1} = σ_{manage r_{id} = 42} (E m pl oyee)

R_{2} = R_{1} ⋈_{i d = mana g e r_{i d}} E m pl oyee

R_{3} = R_{2} ⋈_{i d = mana g e r_{i d}} E m pl oyee

⋮

But how many levels deep is the hierarchy? You don't know. And if you did, the query changes every time the data changes. This is not a query — it's a program.

This is not a gap that got overlooked. Relational algebra was designed around closed-form expressions precisely because that constraint is what makes them analyzable and optimizable. Recursion requires a fixed point — "keep going until the result stops changing" — and that is fundamentally outside the algebra's scope.

The Standard Answer: A Necessary Compromise

SQL introduced WITH RECURSIVE (common table expressions, CTE) specifically to fill this gap. It works. For org charts, bill-of-materials trees, network routing tables, and any other recursive structure, it is the right tool.

But it is worth being honest about what it is: an extension beyond relational algebra, grafted onto SQL because real data is sometimes recursive and databases need to handle it. It is not elegant theory — it is pragmatic engineering. Use it when you need it, but recognize that you have left the clean mathematical foundation behind the moment you do.

Other approaches handle this more naturally. Datalog, for instance, treats recursion as a first-class concept and sits closer to the theoretical ideal. But Datalog is not what runs in production.

Why This Matters for You

When you model a domain, the choice of data structure has consequences. A flat relation is fast, clean, and fully expressible in relational algebra. A recursive structure — a tree, a graph — requires either a recursive SQL extension, a denormalized adjacency list, or a different database paradigm entirely (graph databases like Neo4j exist for exactly this reason).

Knowing this before you design a schema means you can ask the right question early: Is this data inherently recursive? If yes, plan accordingly. If no, keep it relational and keep your queries clean.

The recursion problem is not a flaw in relational algebra. It is a precise statement of what the model is and what it is not. Understanding the boundary is half the job.

A Database Is Not an API

Stephan -All Input Is Error- Bökelmann — Fri, 24 Apr 2026 00:00:00 +0000

When we set up databases for clients at nerd_force1, 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's built-in access model is designed for database administrators, not for application users. It answers questions like "can this user read this table?" — but not "can this user read their own rows in this table, filtered by their organization, with rate limiting, and with that action logged?" For anything beyond the simplest internal tooling, the native access control is the wrong abstraction.

Views and stored procedures are the traditional workaround: define the allowed queries inside the database, expose those, hide the rest. This works, but it has costs. Logic leaks into the database layer where it is hard to version, hard to test, and hard to hand off to a client who does not employ a DBA. The database becomes responsible for things it was not designed to own.

What We Do Instead

We model the database in UML and express the allowed operations as predefined queries in relational algebra — not SQL code, but the logical structure: what data is needed, how it is joined, what filters apply. SQL is an implementation detail of that intent, not the documentation of it.

In front of the database we run a thin API layer — typically FastAPI. Each allowed operation becomes an endpoint. The URL is the contract; the SQL behind it is an internal concern.

Client
  │
  ▼
Keycloak (Authentication & Authorization)
  │
  ▼
FastAPI (Predefined endpoints, input validation, logging)
  │
  ▼
Database (PostgreSQL / MySQL — never directly reachable from outside)

Keycloak handles authentication and issues tokens. FastAPI validates those tokens, enforces authorization rules, and routes requests to the appropriate query. The database receives only parameterized queries from a trusted service account. No client ever touches a connection string.

Why This Holds Up

The database stays clean. Schema design, normalization, and indexing are not polluted by access-control workarounds. The data model reflects the domain, not the security requirements.

Behavior is testable and versionable. An API endpoint is a function. You can write unit tests for it, version it, document it with OpenAPI, and replace the underlying query without touching the contract.

Authorization is explicit. What a user can do is defined in one place — the API layer — not scattered across database roles, view definitions, and stored procedure grants.

The client gets a stable interface. If the schema changes, the API absorbs the change. The client's code does not break.

The Short Version

A database is for storing and querying data with integrity guarantees. An API is for defining what the outside world is allowed to ask, and how. These are two different jobs. Giving them to the same system means both are done worse than if they were separated.

When clients come to us with a database problem, we almost always end up drawing the same diagram: a database behind a FastAPI service, with Keycloak in front of that. It is not a clever trick. It is just a clean separation of concerns — and it holds up over time.

If you are designing a system where a database needs to be accessible to more than one service or one team, start there.

DBMS 01: Why a Filesystem Is Not a Database

Stephan -All Input Is Error- Bökelmann — Thu, 23 Apr 2026 00:00:00 +0000

Yes, I'm aware: nobody in production actually stores sensor data as 120 CSV files in a flat directory. At least I hope not. But that's precisely why this works as a teaching exercise — it'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) doesn'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's 120 CSV files and 360 rows total. Nothing exotic. Exactly the kind of mess that accumulates when a small team decides "we'll figure out the storage later."

Then they solve three tasks:

Filter and sort readings from one specific sensor.
Find all measurements above a threshold within a date range.
Compute min, max, and average per sensor across the full dataset.

Twice. Once with shell tools. Once with SQL against a SQLite database.

Where It Breaks Down

Task 1 is fine. grep, sort, done. Everyone feels good about themselves.

Task 2 is where the cracks appear. Date range filtering across files named by date means matching filenames against a range, looping, and then filtering contents. It works. It's just longer than it has any right to be for such a simple question.

Task 3 breaks the illusion completely. Aggregating across 120 files while tracking per-sensor state requires either a temporary file, an associative array, or a nested loop. At this point the shell script isn't solving a data problem anymore — it's solving a parsing problem that shouldn't exist.

The SQL versions stay flat. Three lines for Task 1. Five for Task 2. One GROUP BY for Task 3.

The Thing That Lands

The shell pipeline tells the computer how to find the answer. SQL tells the database what the answer looks like.

That distinction — imperative vs. declarative — is easy to define on a slide and very hard to actually feel. Students who write the shell version first and then write the SQL version have the comparison running in their heads. No slide needed.

Why SQLite

No server. No installation. No credentials. sqlite3 sensors.db and you're in.

Every removed obstacle is a removed excuse for the concept not to land. The goal is for students to spend their cognitive budget on the query language, not on connection strings.

What This Doesn't Cover

Transactions, normalization, indexing, query planning — all of that comes later. This practicum makes exactly one claim: for structured data you need to query, a database gives you a better language than a filesystem does.

Once you've felt that, rather than been told it, everything else builds on solid ground.

The repository is open: github.com/MaxClerkwell/DBMS_01. If you want to work through it yourself, fork it and work in your own copy — that's the intended workflow. If that concept is new to you, start with the first exercise from my Introduction to Programming course (PP1), which walks through exactly that.

If We Can Measure It, You Can Improve It

Stephan -All Input Is Error- Bökelmann — Mon, 20 Apr 2026 00:00:00 +0000

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 zero-sum terms: machines take jobs, humans starve. This is wrong — historically wrong and philosophically wrong.

The printing press didn’t kill scribes to enrich publishers. It made knowledge accessible to everyone. The steam engine didn’t enslave workers — it eventually freed them from fourteen-hour days in the field. Every wave of automation that looks like destruction from the inside looks like liberation from the outside.

We are at the beginning of the greatest liberation in human history. And most people are still arguing about whether to allow it.

A few things we hold to be true — and stand behind:

Most operators think they are watching their processes. They are watching indicators. Indicators are not data.
Everyone is racing to add AI to their factory. Nobody asks where the data comes from. You cannot solve in the abstract domain if your transform is broken.
The consultant who tells you to rip and replace is selling you their project, not your solution. The world runs on installed base. It always will.
Critical infrastructure that isn’t monitored isn’t critical — it’s just unexamined risk.

What We Actually Believe

We build monitoring systems. That sounds modest. It isn’t.

A machine that cannot monitor itself cannot maintain itself. A machine that cannot maintain itself requires human attention. And humans watching machines is precisely the kind of work that should not require humans.

We believe: machines should do everything that machines can do — so that humans are free to do everything that only humans can do.

We are convinced that the soul is not a process. Not a pattern. Not an emergent property of sufficient compute. The creative, the musical, the philosophical, the spiritual — these are not outputs of a sufficiently trained model. They are the signature of something that cannot be automated, and we will never pretend otherwise.

We work only on projects that move humanity toward a state where more people can live creatively, without worrying about food on the table. If a project does not serve that direction, we are not interested.

The Transform

There is a concept in mathematics that I use every day outside of mathematics: the Laplace transform.

When a differential equation cannot be solved in its original domain, you transform the problem into an abstract space where the solution becomes tractable — then you transform back. Physics describes the world in measurable quantities. Mathematics provides abstract solutions. Engineers translate those solutions back into reality.

This is how we approach every problem. We do not fight complexity where it is hardest. We transform. We solve. We return.

When I chose my field, I looked at robotics first. Exciting, well-funded, visible — and crowded with a thousand companies building manipulators. Then LLMs and autonomous reasoning — equally crowded. But when I looked at actual industry, I saw something unexpected: the transformation step was broken.

Data was being extracted from PLCs through protocols never designed for scale. Or entered by hand into SAP forms. Neither is a real transform — one is a bottleneck, the other is a human acting as a transducer.

The gap was not in robotics. The gap was not in AI. The gap was in the instrument itself.

A monitoring system is that instrument — the transform applied to the physical world.

The physicist stands before a phenomenon: vibration, temperature, current, pressure. They do not solve it in the noisy, continuous, messy original domain. They describe it formally. That formal description is what makes computation possible.

The sensor is the act of transformation. The data stream is the abstract domain. The anomaly detection, the predictive model, the threshold alert — these are the solutions, computed where solutions are easy. And the actuation, the maintenance call, the adjusted process parameter — that is the inverse transform, back into physical reality.

But the sensor alone is not enough. A raw signal without a time series database, without cleaning, without context is not usable by any analytical system. The physicist does not just measure — they record, annotate, calibrate, and structure. A monitoring system is the automated physicist: it captures the signal, stores it with temporal precision, strips the noise, adds the context, and delivers something that analysis, prediction, and prevention can actually act on. We design and build every system with that full chain in mind — not just data collection, but data that is ready to be reasoned about.

You cannot solve problems in the abstract domain if your transform is lossy, delayed, or manual. This is not a metaphor for us. It is the operating principle.

The Instrument

We believe the sensor must be native to the network.

Not polled through serial middleware. Not manually entered. Not bridged through industrial protocols that predate the internet. USB and TCP/IP — the same connectivity that made the web universal.

Our preferred device: a PoE unit that plugs into a switch, receives its address via DHCP, announces itself on the local network via slook, and is ready to be found. No configuration wizard. No integration project. Plug in — and it works.

Where network infrastructure does not reach, we go wireless: WiFi with battery, LoRa or cellular with energy harvesting. But we are honest about the physics: the further a device is from its processing environment, the worse the signal. Bandwidth falls. Accuracy falls. Latency rises. This is not a complaint about wireless technology — it is a law of physics, and we respect it. We optimize for proximity. We treat distance as cost.

The Installed Base Is the World

We focus on retrofit. Not greenfield.

This is a philosophical choice as much as a commercial one.

The factories that exist, the machines that run, the processes that produce — these are not going to be torn down and rebuilt as ideal systems. They are what they are. They represent decades of engineering, capital, and institutional knowledge. Greenfield projects are the exception. The world as it stands is the rule.

We believe it is better to make what exists measurable than to build perfect systems that never touch the machines that actually run civilization. Every retrofit installation is an act of transformation: a previously opaque process becomes legible, computable, improvable.

That is where we work. And we have been proving it for twelve years — in nuclear cooling circuits, mine shafts, Montana rivers, rail switching systems, defense platforms, and semiconductor fabs.

Who We Are

Auto-Intern was founded by Odin Holmes — a hardware and firmware designer from the woods of Oregon — and Prof. Dr. Benjamin Menküc, whose advisory fingerprints remain on the architecture. When I, Stephan Bökelmann, joined in 2014, Odin and I changed the business model: from USB interfaces for automotive OBD to if we can measure it, you can improve it.

Today we are around twenty engineers from physics, electrical engineering, computer science, and cybersecurity. The people who shape the work: Odin on hardware and firmware, Tabea Bökelmann on frontends and APIs, René Glitza on federated and fully homomorphic learning, Philipp Lehmann on security and deployment.

Alongside Auto-Intern GmbH — the measurement device company — we run nerd_force1, which builds the server-side: our own data center, Kubernetes and Ceph clusters, security-first from the ground up. Sensor to server, owned end to end.

Our customers are in large manufacturing, critical infrastructure, and defense. Wherever an unmonitored process quickly becomes very expensive.

The Future We Are Building Toward

There will be automated production on other planets. Not because we are science fiction enthusiasts, but because it is the logical conclusion of everything we are building toward — supply chains that do not depend on human presence in a specific location, systems that maintain themselves, infrastructure that extends the reach of human civilization without extending its cost.

We are techno-optimists. The process of transformation has already begun. The question is not whether it will happen — it is whether we will shape it with moral clarity and engineering rigor, or let it happen to us.

If we do this right, the answer to the apple problem is not poverty. It is abundance. It is a world where more people have more time for the things that only humans can do: to think, to create, to question, to connect, to live as though they were made for something greater than maintenance.

That is the highest form of human striving we know. And it is the only reason we are here.

We are not naive about how long this takes. But we are clear about the direction.

Travelling to China with a Peli Case Full of Electronics

Stephan -All Input Is Error- Bökelmann — Thu, 09 Apr 2026 00:00:00 +0000

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, ATA Carnets are issued by the IHK (Chamber of Commerce). My assistant Vanessa handled most of the paperwork, which I would strongly recommend if you have the option — the form requires a complete list of every item you’re carrying, including descriptions, values, and serial numbers.

The serial number point is important. Every significant component needs one. We went through our modules and labelled anything that didn’t already have a serial number. This paid off at every customs checkpoint: when an officer picks up a device and asks what it is, you point to the serial number, point to the list, and that’s the end of the conversation. Without serial numbers, you’re explaining what an Edge Compute Module is to a customs officer at 6am.

Timeline in Germany:

IHK: approximately 4 business days from application to ready document
Zollamt Bochum: about one hour in-person, no appointment needed

Go to the Zollamt in person. They check everything on the list against what you’ve actually packed, then stamp and sign the document. After that, you’re cleared for departure.

Packing

I used a Peli case with foam cut to fit. The system was packed snugly enough that nothing moved during the flight. I used two TSA-compliant locks.

One of them didn’t survive the journey. On arrival in Frankfurt I found one lock broken — the TSA key had clearly been used at some point. The second lock was fine. If you’re packing anything sensitive, assume the case will be opened in transit and pack accordingly. Nothing was missing or damaged inside.

Frankfurt Airport: Terminal 2 and the Customs Process

If you’re flying to China from Frankfurt, note that most China routes depart from Terminal 2. Allow an extra 15 minutes to get there, and plan at least 3 hours before departure if you’re carrying ATA goods.

The process at check-in is slightly unusual. You check in at the desk to get your baggage tag — but then you ask for the bag back. Yes, they will be confused. Insist politely. You need to carry the tagged bag yourself to the customs office.

At the customs office, an officer goes through the entire list with you, item by item. Everything comes out of the case. Everything gets counted. Then it goes back in, gets stamped, and you carry the case to the bag drop that the officer directs you to. Budget 60 minutes for this process on your first time, possibly more. My assistant Vanessa’s preparation made it significantly faster — the serial numbers meant I never had to explain what anything was, just confirm it matched the list.

Arrival in China

At the Chinese customs on arrival, the process mirrors the German departure. Find a customs officer immediately — don’t walk through the green channel. Show the ATA Carnet, let them inspect, they take one of the pages, sign the document, and you’re done. It takes longer than in Germany. If someone is waiting for you, warn them in advance.

Apps to Install Before You Leave

Install these before departure, not on arrival:

WeChat — essential. Nearly everyone reachable for business in China responds faster on WeChat than email. You also need to wait a few days after installation before you can set a username, so install it early. You can add me: MaxClerkwell. Add your credit card too — WeChat Pay is the default payment method almost everywhere.
DiDi — Chinese Uber. Works reliably, some premium drivers speak English. Every driver will have a bottle of water for you.
Trip.com — hotels and train tickets.
Amap — local maps. Google Maps works with a VPN but has gaps in business listings.
Google Translate — download the English–Chinese language pack offline.

For connectivity: buy a Holafly eSIM before departure (~30 USD/week). Install it correctly before you get to the airport. European SIM data roaming costs are not worth it. Watch out for cheaper plans that prohibit hotspot sharing.

For everything else: set up a WireGuard VPN before you go. A self-hosted instance is better than a commercial VPN service. WhatsApp and Google work in China with this setup.

The Guangzhou Departure

Leaving China on the return trip is the same process in reverse — except it takes longer. Guangzhou Baiyun Airport has an unusual arrangement where customs and the security check are sequenced in a way that requires you to pass through security with your full luggage including tools. I had a screwdriver set in the Peli case, which triggered additional checks since screwdrivers are not permitted through security onto the aircraft.

The resolution was diplomatic: I explained the situation, showed the ATA Carnet, and the officers were helpful in directing me to the right channel to drop the tools as checked luggage and continue to the gate. Chinese customs officers were, throughout the trip, genuinely curious rather than obstructive — several wanted to understand what the modules actually did. Being able to explain it simply (a measurement system for industrial ovens) was worth more than any amount of paperwork.

Allow 90 minutes for the Guangzhou departure process if you’re carrying ATA goods.

On Arrival Back in Germany

Take the red channel, get the documents signed again on return. Then bring the completed ATA Carnet back to the IHK. This is a formal requirement — failing to return it means you may be liable for import duties on the declared value of everything you took.

Summary Checklist

Weeks before departure:

Install WeChat, set username, add payment card
Apply for ATA Carnet at IHK (allow 4+ working days)
Label all items with serial numbers
Buy Holafly eSIM, install and test before airport
Set up WireGuard VPN
Buy TSA-compliant locks (assume they will be used)

At Frankfurt airport:

Depart from Terminal 2 (most China routes)
Allow 3 hours before departure
Check in, get baggage tag, take bag back
Go to customs office with ATA Carnet — plan 60 min
Drop bag where customs officer directs you

On arrival in China:

Go directly to customs, do not use green channel
Present ATA Carnet without hesitation

Returning from China (Guangzhou):

Allow 90 minutes for customs + security
Pack tools in checked luggage or be prepared to check them separately

Back home:

Return completed ATA Carnet to IHK

Questions about factory visits in China or EMC testing? Hit me up on WeChat or X.

DEV Community: Stephan -All Input Is Error- Bökelmann

Simulating Antiproton Energy Loss in an HV-MAPS Silicon Sensor with Geant4

What is HV-MAPS?

The question: how much energy does one antiproton deposit?

Bethe-Bloch with thin-layer correction: a worked example

Before Geant4: a Python tool

Setting up Geant4

What I changed for the HV-MAPS geometry

Results: the Landau distribution

What Geant4 does not simulate

From simulation to beam test

Zero to One with VHDL and a Lattice iCEstick

What is an FPGA, and why does it matter?

The hardware: Lattice iCEstick HX1K

Toolchain overview

USB permissions

The design: a 1 Hz LED blinker

src/blinky.vhd

Simulation before hardware

sim/tb_blinky.vhd

Running the simulation

Synthesis and flashing

Pin constraints: constraints/icestick.pcf

The Makefile

Seeing it run

What just happened

Known limitations and what comes next

Viewing Plots from My Homelab Over SSH X11 Forwarding

The Setup

Network Topology

Configuring the SSH Client on pc54

Does Heimdall Need Any Configuration?

Enabling X11 Forwarding on Qingdao

Adding the SSH Key (Optional)

Testing

How Well Does It Actually Work

A Note on ForwardX11Trusted

Why Bother

How Two Teenagers, a Printer Plug, and a Forum Post Built a Company

A GTI, a Radio, and a Wild Idea

A Name on a Screen: Uwe Ross

The Bedroom Business Plan

The AutoSpion

The Golf 5 Crisis

What VCDS Actually Is

The HEX-V2 and a Pivot to Partnership

Twenty-Five Years Later

Are Machines Conscious? A Snapshot

The Bird and the Airplane

Not a Spectrum, But Not Categories Either

Consciousness as Emulation Capacity

Hive-Mind and Individual

The Hard Problem and the Inner Stage

Principally Possible, But Not Yet

What Is Particular About Humans

Further Listening

The Game of Life and the Limits of Prediction

Where It Comes From

The Rules

The Classes

Computational Irreducibility

Assuming for a Moment

The Particle in the Box

The Edge of Chaos

Building a Personal Journal Bot with Telegram, Gemini, and Docker

What it does

The conversation design

The context system

On the Gemini API

The LaTeX memoir

The SSH key handling

The repository structure

What is missing

Running it

The Recursion Problem in Relational Algebra

What Relational Algebra Is Good At

Where It Breaks Down

The Standard Answer: A Necessary Compromise

Why This Matters for You

A Database Is Not an API

`src/blinky.vhd`

`sim/tb_blinky.vhd`

Pin constraints: `constraints/icestick.pcf`