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

  <title>Stephan Bökelmann — Tech</title>
  <subtitle>FPGA and embedded bring-up, PCB and chip-on-board, decentralised DAQ, embedded Linux, networking and databases.</subtitle>
  <link href="https://maxclerkwell.tech/feed-tech.xml" rel="self" type="application/atom+xml"/>
  <link href="https://maxclerkwell.tech/tech/" rel="alternate" type="text/html"/>
  <id>https://maxclerkwell.tech/tech/</id>
  <updated>2026-09-19T23:52:16+02:00</updated>
  <author>
    <name>Stephan Bökelmann</name>
    <email>stephan@boekelmann.net</email>
    <uri>https://maxclerkwell.tech</uri>
  </author>
  <generator uri="https://jekyllrb.com/">Jekyll</generator>

  














  

  
  <entry>
    <title>open.cob.json: One File Between the Chip Designer and the PCB Designer</title>
    <link href="https://maxclerkwell.tech/posts/open-cob-json-september-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/open-cob-json-september-2026/</id>
    <published>2026-09-17T00:00:00+02:00</published>
    <updated>2026-09-17T00:00:00+02:00</updated>
    
    <summary>For years I kept my chip-on-board bonding notes in private JSON files. A conversation with wafer.space made me publish them as a format. This is the story of the decisions that were hardest to make: none versus unspecified, why pad shapes are their own files, and what a real padframe taught the parser.</summary>
    
    
    <category term="electronics"/>
    
    <category term="asic"/>
    
    <category term="kicad"/>
    
    <category term="open-source"/>
    
    <category term="engineering"/>
    
    <category term="chip-on-board"/>
    
    <content type="text">Wedge bonds on the pad row of a pixel readout chip. Every one of these wires was once a line in a spreadsheet, a color on a slide and a number in a PDF. I have a folder that has been growing since my time at the Chair of Experimental Physics I in Bochum. It holds pad geometries that bonded well, force and time settings per wire and metal, a few SVGs of bonding plans, and the same three rules I have explained to every PCB designer I have worked with: no mask where the wire lands, no via under the die, keep the wire short and the angle sane. At some point I started writing this down as JSON, one file per chip, mostly so I would stop re-deriving it. That folder was never in one place and never public. On 15 September I had a long call with Stuart Childs of wafer.space, whose customers are ...</content>
  </entry>
  
  <entry>
    <title>ALINX AX7020, Stage 5 Complete: Cold Power-On to a Bitstream API, Nobody Logged In</title>
    <link href="https://maxclerkwell.tech/posts/alinx-ax7020-cold-boot-to-bitstream-api-september-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/alinx-ax7020-cold-boot-to-bitstream-api-september-2026/</id>
    <published>2026-09-15T00:00:00+02:00</published>
    <updated>2026-09-15T00:00:00+02:00</updated>
    
    <summary>The open bitstream pipeline for the ALINX AX7020 is finished: power on, the maintenance Linux in QSPI fetches the full image from a company-internal URL, kexecs into it, systemd starts the FastAPI service, and a curl loads a Yosys/nextpnr bitstream into the FPGA. No SD card, no vendor tool, no hand on the board; plus the detours, including a JTAG adapter that quietly powered the flash chip through a power cycle.</summary>
    
    
    <category term="fpga"/>
    
    <category term="alinx"/>
    
    <category term="zynq"/>
    
    <category term="yocto"/>
    
    <category term="systemd"/>
    
    <category term="kexec"/>
    
    <category term="fastapi"/>
    
    <category term="rest-api"/>
    
    <category term="linux"/>
    
    <category term="u-boot"/>
    
    <category term="qspi"/>
    
    <category term="nginx"/>
    
    <category term="embedded"/>
    
    <category term="bring-up"/>
    
    <category term="deployment"/>
    
    <content type="text">The last article ended with a working chain and an honest caveat: every piece had been exercised once, by hand, and the next power cycle would take it all away. This one removes the caveat. Since yesterday evening the board does the whole thing on its own. 20:44:22 U-Boot: DHCP client bound to address 10.42.100.153 20:44:32 U-Boot: ## Loading kernel (any) from FIT Image at 02000000 ... maintenance system (systemd) -&amp;gt; ax7020-update.service -&amp;gt; image server -&amp;gt; kexec API image: GET http://10.42.100.156:8000/state -&amp;gt; {&quot;state&quot;:&quot;unknown&quot;,...} POST blinky.bit -&amp;gt; operating, LEDs blinking That is a cold power-on with the JTAG adapter unplugged and nobody logged in. From the plug going into the socket to a REST endpoint answering took about a minute, and the endpoint then accepted a...</content>
  </entry>
  
  <entry>
    <title>ALINX AX7020, Stages 4 &amp; 5: An Open Bitstream Over REST, and the One Missing Line That Hangs Both Cores</title>
    <link href="https://maxclerkwell.tech/posts/alinx-ax7020-open-bitstream-rest-api-september-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/alinx-ax7020-open-bitstream-rest-api-september-2026/</id>
    <published>2026-09-14T00:00:00+02:00</published>
    <updated>2026-09-14T00:00:00+02:00</updated>
    
    <summary>Stages 4 and 5 of the open bitstream pipeline: a Yosys/nextpnr bitstream loaded into the ALINX AX7020 through the kernel&apos;s FPGA manager, a kexec updater that finally runs, and a FastAPI service that accepts bitstreams over HTTP, all without a single vendor tool; then the detours, including a PL design that silently drowned both Cortex-A9 cores in FIQs.</summary>
    
    
    <category term="fpga"/>
    
    <category term="alinx"/>
    
    <category term="zynq"/>
    
    <category term="yosys"/>
    
    <category term="nextpnr"/>
    
    <category term="prjxray"/>
    
    <category term="openxc7"/>
    
    <category term="fpga-manager"/>
    
    <category term="kexec"/>
    
    <category term="fastapi"/>
    
    <category term="rest-api"/>
    
    <category term="yocto"/>
    
    <category term="linux"/>
    
    <category term="jtag"/>
    
    <category term="openocd"/>
    
    <category term="embedded"/>
    
    <category term="bring-up"/>
    
    <content type="text">Stages 2 and 3 ended with a self-built Linux resident in QSPI flash, an FPGA manager registered in the kernel, and a promise: the next post would put a bitstream from the open toolchain into that FPGA over SSH. This is that post, and it goes further than promised. By the end of it the board accepts a bitstream over HTTP, checks it, loads it, and answers with the FPGA’s state; the LEDs blink; and nothing from Xilinx has run at any point between the Verilog file and the configured silicon. It also contains, true to form, a bitstream that was perfectly valid and still killed the board without a single log line, a kexec that will happily jump into a device tree blob, and a flash chip that survives a processor reset in a mode the boot ROM cannot read. This covers Stages 4 and 5 of the bitstr...</content>
  </entry>
  
  <entry>
    <title>KiCon Europe 2026: Trip Report without the Trip</title>
    <link href="https://maxclerkwell.tech/posts/kicon-europe-2026-trip-report-without-the-trip/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/kicon-europe-2026-trip-report-without-the-trip/</id>
    <published>2026-09-11T00:00:00+02:00</published>
    <updated>2026-09-11T00:00:00+02:00</updated>
    
    <summary>Three days of KiCon Europe 2026 at Gleis 9 in Bochum from the organiser&apos;s chair: KiCad 11 previews from Wayne Stambaugh, ngspice 47, open source test rigs, rigid-flex in space, a browser KiCad I am not sold on, and Seth Hillbrand&apos;s eight-hour training. Plus what changes for 2027.</summary>
    
    
    <category term="kicad"/>
    
    <category term="conferences"/>
    
    <category term="open-source"/>
    
    <category term="pcb"/>
    
    <category term="bochum"/>
    
    <category term="skunkforce"/>
    
    <content type="text">In April 2019 I flew to Chicago for the very first KiCon and wrote a brief trip report on the way home. It ended with the sentence “It almost looks like we will be organizing some sort of event like this in Germany.” Seven years later I no longer have a trip to report on. The conference comes to me. From 7 to 9 September 2026 KiCon Europe took place at Gleis 9 in Bochum, organised by KiCad Services Corporation together with Open Skunkforce e.V., which in practice means Seth Hillbrand and me. Organiser&apos;s view from the back row of the main hall at Gleis 9. What KiCad is, for the people who landed here by accident KiCad is a free and open source suite for electronic design automation. You draw a schematic, assign footprints, lay out the printed circuit board, run design rule checks, simula...</content>
  </entry>
  
  <entry>
    <title>Counting Raindrops with a Capacitor: The 25square Sensor, Its STM32, and the Patent Behind It</title>
    <link href="https://maxclerkwell.tech/posts/25square-capacitive-rain-sensing-september-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/25square-capacitive-rain-sensing-september-2026/</id>
    <published>2026-09-02T00:00:00+02:00</published>
    <updated>2026-09-02T00:00:00+02:00</updated>
    
    <summary>How Auto-Intern built the street-level rain sensors for the 25square heavy-rain nowcasting project: a capacitive impact plate instead of a piezo, an STM32 with lwIP over PoE, a LoRa variant for the lampposts, and the jointly held patent DE 10 2020 119 488 B4 with Okeanos.</summary>
    
    
    <category term="daq"/>
    
    <category term="measurement"/>
    
    <category term="stm32"/>
    
    <category term="lwip"/>
    
    <category term="poe"/>
    
    <category term="mqtt"/>
    
    <category term="lora"/>
    
    <category term="sensors"/>
    
    <category term="patent"/>
    
    <category term="mfund"/>
    
    <category term="bochum"/>
    
    <category term="edge-compute"/>
    
    <content type="text">When people talk about AI-based heavy-rain forecasting, the conversation usually starts at the model: data fusion, neural networks, nowcasting. It rarely starts where the water actually hits: at the sensor. But a model is only as good as its ground truth, and for street-level rain nowcasting in a city, that ground truth simply did not exist in 2020. Weather radar sees clouds from above; a municipal network of one or two calibrated gauges sees almost nothing of a convective cell that dumps its load on six street blocks and misses the rest of the city entirely. 25square set out to fix that: a research project funded through the mFUND programme of the German federal ministry of transport (our sub-project at Auto-Intern ran under grant 19F1064B), started in August 2020 together with Okeanos...</content>
  </entry>
  
  <entry>
    <title>skAInet Edge-Compute: The Box We Kept Rebuilding Now Has a Product Page</title>
    <link href="https://maxclerkwell.tech/posts/skainet-edge-compute-september-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/skainet-edge-compute-september-2026/</id>
    <published>2026-09-01T00:00:00+02:00</published>
    <updated>2026-09-01T00:00:00+02:00</updated>
    
    <summary>Auto-Intern&apos;s skAInet Edge-Compute is now a product with its own site: a sealed M12-PoE switch, router and 8-core Linux compute module for industrial edge data acquisition. What it is, where it came from, and where I fit in.</summary>
    
    
    <category term="electronics"/>
    
    <category term="embedded"/>
    
    <category term="linux"/>
    
    <category term="monitoring"/>
    
    <category term="engineering"/>
    
    <content type="text">For about ten years, every monitoring system I helped build at Auto-Intern had the same thing sitting in the middle of it: a small Linux box with one uplink, a handful of PoE ports, and enough compute to make sense of the sensors hanging off it. It was never the product. The product was the PowerSense, or the reflow oven monitor, or whatever the customer had actually asked for. The box was the thing we rebuilt each time to make the product work. That box now has a name, a version number, and its own website: skAInet Edge-Compute v1.5. One block of anodized aluminium, every port sealed. Photo: Auto-Intern GmbH. What it is In one sentence: a programmable M12-PoE switch, router, and compute module for industrial edge applications, built in Germany by Auto-Intern GmbH. The parts that matter...</content>
  </entry>
  
  <entry>
    <title>ALINX AX7020, Stages 2 &amp; 3: A Yocto Linux in QSPI Flash That Fetches Its Own Updates</title>
    <link href="https://maxclerkwell.tech/posts/alinx-ax7020-yocto-linux-qspi-august-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/alinx-ax7020-yocto-linux-qspi-august-2026/</id>
    <published>2026-08-31T00:00:00+02:00</published>
    <updated>2026-08-31T00:00:00+02:00</updated>
    
    <summary>Stages 2 and 3 of the open bitstream pipeline: a self-built Yocto Linux for the ALINX AX7020, resident in QSPI flash, discoverable on the company network, key-only SSH: the walkthrough that works, followed by the nine detours it took to get there.</summary>
    
    
    <category term="fpga"/>
    
    <category term="alinx"/>
    
    <category term="zynq"/>
    
    <category term="yocto"/>
    
    <category term="linux"/>
    
    <category term="u-boot"/>
    
    <category term="kexec"/>
    
    <category term="dropbear"/>
    
    <category term="fit-image"/>
    
    <category term="qspi"/>
    
    <category term="embedded"/>
    
    <category term="bring-up"/>
    
    <content type="text">Stage 1 ended with mainline U-Boot booting from QSPI flash and answering over the network, and I closed that article by saying the Linux build gets its own post. This is that post, and true to form it contains a flash chip that verified every checksum while storing everything one byte off, a bootloader that goes mute the moment you plug it into a real switch, and a real-time clock that turns out to be physically unreachable until the FPGA is configured. This covers Stages 2 and 3 of the bitstream pipeline plan for the AX7020 that ALINX sent me: a self-built Yocto Linux that boots from QSPI flash on its own, shows up on the company network under its own hostname, accepts SSH logins only with a key, and carries the tooling to fetch and kexec fresh development images from a server: no Peta...</content>
  </entry>
  
  <entry>
    <title>ALINX AX7020 Bring-up: Mainline U-Boot Over JTAG, No FSBL, No Serial Cable</title>
    <link href="https://maxclerkwell.tech/posts/alinx-bring-up-jtag-detected-without-power-august-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/alinx-bring-up-jtag-detected-without-power-august-2026/</id>
    <published>2026-08-30T00:00:00+02:00</published>
    <updated>2026-08-30T00:00:00+02:00</updated>
    
    <summary>Stage 1 of the open bitstream pipeline: putting mainline U-Boot on an ALINX AX7020 over JTAG and Ethernet only: a clean walkthrough of what works, followed by the nine detours it took to find out.</summary>
    
    
    <category term="fpga"/>
    
    <category term="alinx"/>
    
    <category term="zynq"/>
    
    <category term="jtag"/>
    
    <category term="openocd"/>
    
    <category term="u-boot"/>
    
    <category term="spl"/>
    
    <category term="device-tree"/>
    
    <category term="netconsole"/>
    
    <category term="bring-up"/>
    
    <category term="linux"/>
    
    <content type="text">I thought this would be an afternoon. Load a bootloader over JTAG, poke it a bit, write it into flash: how hard can it be? It took the better part of a day and nine distinct detours, from cache lines silently corrupting a loaded image to a QSPI controller that reads everything three bytes off, but only in SPL, and only in quad mode. This post is Stage 1 of the bitstream pipeline plan: an ALINX AX7020 (Zynq-7000, XC7Z020) that powers on and boots mainline U-Boot out of QSPI flash by itself: no Xilinx FSBL, no vendor U-Boot fork, no JTAG adapter attached, and no serial cable ever connected. The console is U-Boot’s netconsole over UDP; the whole board is operated from the workstation over Ethernet. The structure follows how I wish someone had written it for me: first the walkthrough that a...</content>
  </entry>
  
  <entry>
    <title>Deploying Hardware Like Software: A Bitstream Pipeline for the Zynq</title>
    <link href="https://maxclerkwell.tech/posts/zynq-bitstream-deployment-concept-august-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/zynq-bitstream-deployment-concept-august-2026/</id>
    <published>2026-08-23T00:00:00+02:00</published>
    <updated>2026-08-23T00:00:00+02:00</updated>
    
    <summary>Alinx sent me an AX7020 board. Here is the plan: an open-source path from JTAG bring-up to a REST API that accepts a bitstream and loads it onto the FPGA, no vendor tools in the loop.</summary>
    
    
    <category term="fpga"/>
    
    <category term="embedded"/>
    
    <category term="linux"/>
    
    <category term="open-source"/>
    
    <content type="text">A while ago, Alinx reached out and asked whether I would like one of their boards for my content work. I said yes, and a few days later an AX7020 arrived on my desk. Full disclosure up front: the board is a sponsorship gift. Alinx has no say in what I write about it, and as you will see below, my plan involves ignoring most of the vendor-recommended workflow anyway. This article is not a tutorial. It is the concept post for a small series: what I want to build, why I want to build it that way, and where I expect things to get uncomfortable. The follow-up articles will document each stage as it actually happens, including the parts that fail. All of them, in order, are collected on the series page. The Board The AX7020 is built around a Xilinx Zynq-7020, which is a curious kind of chip. ...</content>
  </entry>
  
  <entry>
    <title>Why Does Copper Conduct? A Tour for Non-Physicists</title>
    <link href="https://maxclerkwell.tech/posts/orbitals-to-bands-august-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/orbitals-to-bands-august-2026/</id>
    <published>2026-08-21T00:00:00+02:00</published>
    <updated>2026-08-21T00:00:00+02:00</updated>
    
    <summary>Copper conducts, diamond doesn&apos;t, yet both are packed with electrons. A walk from single atoms to energy bands that explains why, ending with a back-of-the-envelope number that lands within ten percent of the measured conductivity of copper.</summary>
    
    
    <category term="physics"/>
    
    <category term="education"/>
    
    <content type="text">I recently finished a small paper that derives the electronic structure of solids step by step, aimed at first-year physics students. This post is the version without the mathematics: the story you can follow on a train ride. If you want the full derivations, the paper is linked at the end. A Question That Sounds Trivial Why does copper conduct electricity and diamond doesn’t? The answer you probably learned in school, “metals have free electrons”, is not wrong, but it quietly dodges the real question. A gram of diamond contains roughly as many electrons as a gram of copper. Nobody nailed them down. So why are the electrons in copper “free” and the ones in diamond not? What, physically, is the difference? It turns out the answer has nothing to do with electrons being loose or stuck. It ...</content>
  </entry>
  
  <entry>
    <title>Digital Communication: Getting a Thought Out of One Head and Into Another</title>
    <link href="https://maxclerkwell.tech/posts/digital-communication-august-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/digital-communication-august-2026/</id>
    <published>2026-08-21T00:00:00+02:00</published>
    <updated>2026-08-21T00:00:00+02:00</updated>
    
    <summary>Communication has one job: move the internal state of one system into another. This is a walk from a thought in your head to a wave on a wire, through the four sides of a message, a water canal, a push-pull driver, Shannon&apos;s channel, and the eye diagram that measures it all.</summary>
    
    
    <category term="electronics"/>
    
    <category term="embedded"/>
    
    <category term="information-theory"/>
    
    <category term="education"/>
    
    <content type="text">Communication has exactly one job. Everything else about it, the words, the wires, the protocols, the noise, is machinery in service of that one job. The Mandate You have a model in your head. It has no clean shape. It is made of pictures, feelings, memories, half-formed intentions, a smell from last summer, a plan for tomorrow. It is entirely yours, and as long as it stays inside you it is useless to anyone else. The moment you want to cooperate, that changes. Cooperation means two systems acting on a shared understanding, and a shared understanding requires that the model in your head somehow also come to exist in someone else’s. If we rule out telepathy for the moment, the only thing you can do is take that internal, shapeless state and push it out through whatever channels you have ...</content>
  </entry>
  
  <entry>
    <title>Dual Uplink, Part Two: From Failover to Load Balancing (and the Two Bugs That Broke It)</title>
    <link href="https://maxclerkwell.tech/posts/dual-uplink-load-balancing-july-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/dual-uplink-load-balancing-july-2026/</id>
    <published>2026-07-12T00:00:00+02:00</published>
    <updated>2026-07-12T00:00:00+02:00</updated>
    
    <summary>The follow-up to our dual-uplink failover setup: weighted multipath load balancing, source-based policy routing, pinning a host to one link, and the two persistence bugs that silently killed it on every reboot.</summary>
    
    
    <category term="networking"/>
    
    <category term="linux"/>
    
    <content type="text">Back in February, Philipp and I put a second uplink into the office and built dual-uplink failover on AI-heimdall: two default routes in the main table, separated by metric, DSL preferred and Starlink as a hot standby. That article ended on a promise. Two named routing tables, starlink (200) and dsl (201), were already registered in /etc/iproute2/rt_tables, sitting there unused, “as preparation for proper policy routing.” This is the article where they get used. The move from failover to load balancing sounds like a small config change. It is not. Failover is one route winning; load balancing is every layer of the stack agreeing on which uplink a given packet leaves through. And getting it to survive a reboot turned out to hinge on two bugs that had nothing to do with routing at all. Fa...</content>
  </entry>
  
  <entry>
    <title>From Bitstream to Idea: An Inverse Guide to FPGAs</title>
    <link href="https://maxclerkwell.tech/posts/from-bitstream-to-idea-inverse-fpga-guide-july-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/from-bitstream-to-idea-inverse-fpga-guide-july-2026/</id>
    <published>2026-07-08T00:00:00+02:00</published>
    <updated>2026-07-08T00:00:00+02:00</updated>
    
    <summary>The ghdl-yosys-nextpnr toolchain for an iCE40, walked backward: starting from a blinking LED and tracing every transformation back to the idea that caused it.</summary>
    
    
    <category term="fpga"/>
    
    <category term="open-source"/>
    
    <content type="text">Most FPGA tutorials, including my own, go forward: idea, block diagram, VHDL, simulate, synthesize, place and route, flash, done. That order makes sense for building something. It makes less sense for understanding the toolchain, because forward explanations tend to gloss over exactly the step you are standing on. You are told “now run synthesis” and you run it, and the tool produces a file, and you move to the next command. This post goes the other direction. I want to start at the thing you can actually observe, an LED blinking on a Lattice iCEstick, and walk backward through every transformation until we arrive at the idea that caused it. Every program in this chain is a transformer: it takes a dataset and a configuration, and it produces a different dataset. Nothing in the chain doe...</content>
  </entry>
  
  <entry>
    <title>What AI Actually Is</title>
    <link href="https://maxclerkwell.tech/posts/what-ai-actually-is-july-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/what-ai-actually-is-july-2026/</id>
    <published>2026-07-03T00:00:00+02:00</published>
    <updated>2026-07-03T00:00:00+02:00</updated>
    
    <summary>Running a chat model is not AI. The training process is. Everything else follows from that distinction, including where the human niche survives.</summary>
    
    
    <category term="ai"/>
    
    <category term="philosophy"/>
    
    <category term="education"/>
    
    <content type="text">The previous two articles built up a chain. The first ran from Aristotle’s two-valued logic through Leibniz, Boole, Gauss, and Shannon to the bit as a unit of information. The second ran from Hilbert’s decision problem through Turing, the Universal Approximation Theorem, and Banach’s convergence guarantee to the modern neural network. This article asks what to make of all of it: what is the thing we are actually calling AI, and where does it leave the human? I want to start with something I find useful to keep in front of me, because it clarifies almost every confused conversation about AI I have ever had. Blackboxes and the Manual Way Think of a real-world function as a black box. Something goes in, something comes out, according to some rule. The box does not care what you think is in...</content>
  </entry>
  
  <entry>
    <title>From the UAT to the Modern Neural Network</title>
    <link href="https://maxclerkwell.tech/posts/from-the-uat-to-the-modern-neural-network-july-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/from-the-uat-to-the-modern-neural-network-july-2026/</id>
    <published>2026-07-03T00:00:00+02:00</published>
    <updated>2026-07-03T00:00:00+02:00</updated>
    
    <summary>We have the bit. Now the question is what we can compute with it, and whether a machine can learn to compute things nobody explicitly programmed. The answer runs from Hilbert through Turing to a theorem most engineers have never heard of.</summary>
    
    
    <category term="ai"/>
    
    <category term="information-theory"/>
    
    <category term="history"/>
    
    <category term="education"/>
    
    <content type="text">The previous article ended with a precise unit: the bit, as Shannon defined it, measures how much uncertainty a message resolves. We have a way to represent information. We have a way to build logical operations from switches. We know, from Gauss and Weber, that a wire can carry two distinguishable states. The question this article asks is the next one in the chain: what can we actually compute with all of this, and is there a limit? That question turns out to be older than the computer. It starts with a mathematician who wanted to mechanise all of mathematics, runs through a logician who showed that was impossible, and ends with a computer scientist who redefined what “mechanical” even means. Hilbert’s Question: Can a Machine Decide Everything? In 1928, David Hilbert posed what he call...</content>
  </entry>
  
  <entry>
    <title>From Aristotle to the Bit</title>
    <link href="https://maxclerkwell.tech/posts/from-aristotle-to-the-bit-july-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/from-aristotle-to-the-bit-july-2026/</id>
    <published>2026-07-03T00:00:00+02:00</published>
    <updated>2026-07-03T00:00:00+02:00</updated>
    
    <summary>The bit did not fall from the sky in 1948. It is the last step in a chain that starts with a Greek philosopher arguing about sea battles and ends with Claude Shannon measuring surprise.</summary>
    
    
    <category term="information-theory"/>
    
    <category term="philosophy"/>
    
    <category term="history"/>
    
    <category term="education"/>
    
    <content type="text">I want to tell you about a chain of ideas that took roughly 2300 years to complete. It starts with Aristotle sitting in Athens arguing about whether a statement like “there will be a sea battle tomorrow” is true or false right now. It ends with Claude Shannon (Fig. 1), in a small office at Bell Labs in 1948, writing down a formula that tells you exactly how much information is contained in a message. The distance between those two moments is the distance between informal common sense and a mathematically precise engineering tool. Understanding that distance, how each step in the chain was necessary and what each step actually contributed, is one of the most clarifying things you can do if you are trying to understand how digital technology actually works at its root. So let me walk thro...</content>
  </entry>
  
  <entry>
    <title>Zero to One: Python Libraries, Environments, and Working Like You Mean It</title>
    <link href="https://maxclerkwell.tech/posts/zero-to-one-python-libraries-environments-june-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/zero-to-one-python-libraries-environments-june-2026/</id>
    <published>2026-06-16T00:00:00+02:00</published>
    <updated>2026-06-16T00:00:00+02:00</updated>
    
    <summary>You do not have to write everything from scratch. Python has thousands of libraries. But the way you pull them in matters, and most introductions get that part wrong.</summary>
    
    
    <category term="python"/>
    
    <category term="education"/>
    
    <category term="zero-to-one"/>
    
    <content type="text">Python and the Python logo are trademarks of the Python Software Foundation. You have heard of Python. Maybe someone mentioned it in passing, maybe you saw a snippet online and thought it looked approachable. You are not sure where to start. This article is for you. The goal is not to teach you the language. It is to show you the three things that matter before you write a single function: how to explore interactively, where to find code that already exists, and how to manage dependencies without making a mess of your machine. By the end, you will have a working Python script, a proper project structure, and an understanding of why each piece is there. One thing before we start: this article assumes Linux. If you are serious about programming and you are not on Linux yet, fix that first...</content>
  </entry>
  
  <entry>
    <title>WTF are FPGAs: A Beginner&apos;s Overview of Field-Programmable Gate Arrays</title>
    <link href="https://maxclerkwell.tech/posts/wtf-are-fpgas-june-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/wtf-are-fpgas-june-2026/</id>
    <published>2026-06-15T00:00:00+02:00</published>
    <updated>2026-06-15T00:00:00+02:00</updated>
    
    <summary>FPGAs are not microcontrollers with more pins. They are a fundamentally different category of IC, and understanding what lives inside one changes how you think about digital hardware entirely.</summary>
    
    
    <category term="fpga"/>
    
    <category term="electronics"/>
    
    <category term="education"/>
    
    <content type="text">📺 Companion video: If you hang around electronics forums long enough, someone will eventually ask whether they should use a microcontroller or an FPGA for their project. The question itself reveals a misunderstanding. FPGAs do not compete with microcontrollers. They occupy a different region of the design space entirely, and conflating them obscures what makes each tool genuinely useful. This article is a ground-up introduction to what FPGAs actually are, where they come from, what lives inside them, and what it takes to put one to work. A Brief History: From 74-Series to Field-Programmable When I started building digital circuits in the mid-nineties, the standard approach was to wire up 74-series logic ICs on a breadboard. These are small, cheap packages, each containing a handful of l...</content>
  </entry>
  
  <entry>
    <title>A Hill I Am Willing to Die On: HDL for PCB Netlists</title>
    <link href="https://maxclerkwell.tech/posts/hdl-for-netlists-june-2026/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/hdl-for-netlists-june-2026/</id>
    <published>2026-06-08T00:00:00+02:00</published>
    <updated>2026-06-08T00:00:00+02:00</updated>
    
    <summary>Schematics are not where PCB design should start. Netlists should be generated from a structured hardware description language, and that changes everything about how AI fits into the picture.</summary>
    
    
    <category term="pcb"/>
    
    <category term="engineering"/>
    
    <category term="ai"/>
    
    <content type="text">This afternoon someone replied to one of my posts on X. The reply was from @blind_via and made the point that what I was describing already exists as a netlist, that schematics come from human creativity, and that removing humans from the loop leads to the same place as vibe coding. Fair points, all of them. But they did not change my mind. What pushed me to write this out properly is something I keep hearing from people at university: AI will take a very long time to solve PCB design. Routing is too hard. Schematics require real engineering intuition. The problem is fundamentally different from software. I disagree. Not because I think AI is magic, but because I think the problem is being misidentified. Schematics Are Not the Ground Truth I have written before about why PCB design shou...</content>
  </entry>
  
  <entry>
    <title>KiCon 2019: A Brief Trip Report</title>
    <link href="https://maxclerkwell.tech/posts/kicon-2019-a-brief-trip-report/" rel="alternate" type="text/html"/>
    <id>https://maxclerkwell.tech/posts/kicon-2019-a-brief-trip-report/</id>
    <published>2019-04-29T00:00:00+02:00</published>
    <updated>2019-04-29T00:00:00+02:00</updated>
    
    <summary>Chicago, April 2019: the first KiCon ever, organised by Chris Gammell at mHub. A week of hackerspaces, breakfast burritos, KiCad workshops and the moment the idea of a KiCon in Germany was born. Republished unchanged from my old Blogspot.</summary>
    
    
    <category term="kicad"/>
    
    <category term="conferences"/>
    
    <category term="open-source"/>
    
    <category term="pcb"/>
    
    <category term="chicago"/>
    
    <content type="text">Editor’s note (September 2026): This is the trip report I wrote on 29 April 2019, the day we flew home from the very first KiCon in Chicago. It was originally published on my old Blogspot at bjoekeldude.blogspot.com and is republished here word for word, typos and all. The last paragraph turned out to be a promise: two years later we ran the first KiCon in Bochum, and since 2024 the city hosts KiCon Europe. The later chapters have their own write-ups: KiCon Europe 2024, KiCon Asia 2025 and KiCon Europe 2026: Trip Report without the Trip. KiCad, spoken “Key-Cat”, is one of numerous Open-Source projects started by the European Organization for Nuclear Research (CERN). KiCad is widley used throughout industry and science to design printed circuit boards, PCBs. To be fair, KiCad is more tha...</content>
  </entry>
  

</feed>
