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

EMC in Dongguan: 2.5 Years of Work, 4 Days in a Test Chamber

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

In March I flew to Dongguan, China for four days of EMC testing. It was the last major milestone before our reflow oven monitoring system goes into production. After two and a half years of development, the question was simple: does this thing radiate, and can it take a hit?

It passed. But the story is more interesting than that.

The Project

The system was commissioned by GlobalPoint GmbH , now part of Kurtz Ersa GmbH & Co. KG , one of the leading manufacturers of reflow soldering equipment. The brief: build a monitoring system that attaches to Ersa’s reflow ovens and gives operators real-time insight into what is actually happening inside the machine — not what the oven thinks is happening, but what the physics says.

The development was handled by skainet.io, the engineering office of Auto-Intern GmbH. I served as system architect. Odin Holmes owned firmware and PCB layout, and Tabea Bökelmann designed and built the frontend. Two and a half years. A lot of iteration.

What the System Does

The core of the system is a central compute module — a compact Linux box with a quad-core processor and more RAM than you would expect for its size. It has two separate Ethernet interfaces: one dedicated WAN uplink, and one connected to an integrated switch chip that exposes seven downstream ports, all of them Power over Ethernet.

Every downstream device is powered and communicated with over those PoE ports. At minimum, the system ships with:

A temperature measurement module — our own design, with custom-made temperature measurement snakes that take in-situ readings at up to 36 points directly inside the solder oven, streaming live to the compute module.
A digital I/O module — reads up to 7 IO-Link sensors and drives a stacklight for at-a-glance status indication.

In the drawer we have further modules in various stages of readiness: vibration, IR camera, temperature/humidity, residual O₂, and ultrasonic structure-borne sound. They weren’t part of this certification run, but the architecture is ready for them.

The compute module auto-detects whatever is connected, loads the calibration files, and exposes the data via REST, WebSocket, and MQTT. On the Ersa machine PC, an Electron frontend consumes those APIs to display profile predictions and process quality indices — CPK and several others.

Travelling with professional electronics across borders comes with its own paperwork. I covered the Peli case setup and the ATA Carnet process in a separate post.

The Test Setup

The lab was NTC — Nore Detection Technology Co., Ltd in Dongguan. We tested against three regulatory frameworks: CE (Europe), FCC (USA), and CCC (China). The full test sequence ran over four days:

Burst (EFT)
Surge
5-second power interruption
Radiated emissions
Radiated immunity
Conducted emissions
Conducted immunity
Magnetic field
ESD

We were not going in blind. We had done preliminary testing in Germany, and we have accumulated a fair amount of PoE-specific EMC experience over the years. All our housings are aluminium. The cables are M12 Cat5e SF/UTP — shielded foil, unshielded twisted pair — which behaves predictably in a test chamber if the mechanical coupling is done correctly.

Everything came back green.

The One Finding

During the test we noticed that the M12 connectors on the downstream devices did not have adequate coupling to their aluminium housings. The anodized surface was acting as an insulator between the connector shell and the enclosure — not ideal when you are trying to maintain a continuous shielded path.

The fix is straightforward: serrated lock washers (Fächerscheiben) under the M12 connector nut. The teeth cut through the anodizing and create a reliable metal-to-metal bond. We did not need to retest, but this goes into the production build as a specification change.

It is exactly the kind of thing you catch when you are in a proper chamber with someone experienced watching the traces.

The Lab, and Jees

I was expecting a language barrier and I found one — very few people in and around the lab spoke English. But my project manager, 熊伟 , who goes by Jees, spoke excellent English and was present throughout all four days. Attentive, knowledgeable, flexible in how we sequenced the tests. He also handed me several EMC tips that I had not encountered before, which alone made the trip worthwhile.

What surprised me most was the scale of the facility. NTC had far more test chambers than I anticipated — you could run multiple concurrent certifications across different standards without ever waiting for a chamber. The whole operation felt more fluid than equivalent labs I have used in Germany.

I will be back.

Beyond the Lab

Dongguan is not just a testing stop. While I was there I also sat down with a cable manufacturer, visited Faytech and NextPCB, and met with a handful of engineers who had been passed along to me through various contacts. Each of those conversations produced at least one useful lead or piece of information.

My hotel was next to a sports park. Every morning I ran laps with a group of elderly locals who were entirely unbothered by the foreign engineer in their midst and very friendly once I stopped looking lost. I spent several evenings with Chinese acquaintances — KTV, good restaurants, the kind of conversations that only happen when you are somewhere unfamiliar and have to pay attention.

Getting around on Didi was seamless. Dongguan is a serious manufacturing city and it moves accordingly.

What Comes Next

The certification results go back to Kurtz Ersa. Production planning can start. After two and a half years of development it is a strange feeling — not relief exactly, more like the moment when a long measurement finally stabilises and you can read off the value.

The extended sensor suite (vibration, IR, rest-O₂, ultrasonic) will follow in a subsequent version. The architecture is already there. It just needs time.

The team: Odin Holmes (firmware, PCB layout), Tabea Bökelmann (frontend). Developed at skainet.io for Kurtz Ersa GmbH & Co. KG.

Ten Years of Conferences: What They're Actually For

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

In 2015 I went to my first real conference. I came back a different engineer. That sounds dramatic, but it's accurate, and it took me a while to understand why. This post is an attempt to write that down — both for myself, after ten years, and for the companies, universities, and open-source projects that keep asking us at Open Skunkforce e.V. how we think about this.

Meeting C++, 2015

I went to Meeting C++ 2015 with my colleague Odin Holmes. At that point I thought I was a reasonably competent programmer. I was wrong — not in the way that's demoralising, but in the way that only becomes visible when you're suddenly in a room full of people who have been thinking deeply about problems you haven't encountered yet.

I didn't know what I didn't know. I heard talks on topics I had no idea existed. I had conversations in corridors that reframed things I thought I understood. Some of those conversations turned into projects. Some turned into friendships that are still going today.

That's the thing about conferences that doesn't translate into any other format: you cannot Google your way to the questions you haven't thought to ask yet. A talk puts an idea in front of you. A conversation in the hallway afterwards tells you what that idea means in your situation. You go home with a list of things to learn that you didn't know you needed to learn.

The List

Over the past ten years, roughly:

As attendee or speaker:

Meeting C++ — 2015, the beginning
code:dive, Wrocław — many years in a row
FOSDEM, Brussels — regularly for eight years
KiCon US, Chicago 2019 — organised by Chris Gammel
ISO C++ Committee Meeting, Kona 2019
ISO C++ Committee Meeting, Prague 2020
PANDA and GSI collaboration meetings — multiple
NVIDIA C++ Meetup, Silicon Valley
KiCon Asia 2025, Shenzhen — as speaker
Various smaller conferences and user groups in Germany and the Netherlands

As organiser (with Open Skunkforce e.V.):

emBO++ — embedded C++ conference, Bochum, every year since 2015
OpenTapeout — open-source chip design, first edition 2021
Practical Datascience Conference (PDSC)
KiCon Germany — four editions from 2020
KiCon Europe 2024 — Rotunde Bochum, 150 attendees
CPPP, Paris — marketing and video production, on invitation from Fred Tingaud

That is a lot of rooms. A lot of evenings. A lot of hallways.

The Moments That Stay

Three moments from the past decade stand out when I try to articulate what conferences are actually for.

Kona, 2019. I was at the ISO C++ Committee meeting — not as a voting member (I don't hold a DIN seat, so I could participate actively in discussions but not vote), but as a working participant. The Pacific coast outside the venue looked like this every morning:

One evening I found myself at dinner with Bjarne Stroustrup and Herb Sutter. The conversation was direct, curious, practical. The kind of exchange that only happens when everyone at the table has decided to take the time seriously.

Wrocław, code:dive. Sean Parent and Bartosz Milewski ended up with Odin, Tabea, and me in a bar until well past any sensible hour. The conversation went everywhere — category theory, compiler internals, what it means to write software that is honest about what it does. I've learned more in evenings like that than in entire conference days.

Silicon Valley. Tabea and I were at an NVIDIA C++ meetup when Barbara Gellar and Ansel Sermersheim — authors of the CopperSpice GUI framework — walked up and asked if we were the people who organised emBO++. That conversation turned into an invitation to stay at their home for four days. We spent those days talking about C++, software design, and what it means to build tools that last. We're still in regular contact today.

None of these moments were scheduled. None of them appear on any programme. They happened because people who care about the same things ended up in the same place, with time to talk.

emBO++: Eleven Years

The arc of emBO++ is the clearest illustration I have of how this compounds over time.

The first edition, 2015: four people in a room. The second: speakers from Russia to San Francisco, 40 attendees. It felt unreasonably large at the time. By 2020 we had 250 people in Bochum — the last edition before COVID.

Going online during the pandemic worked, technically. But something was missing. The talks were fine. The questions-and-answers were fine. What you cannot replicate over video is the moment after the talk ends, when someone turns to the person next to them and says "did you notice that detail he mentioned in passing?" — and that becomes a two-hour conversation over dinner.

Conferences have not fully recovered since COVID. That's the honest picture. Attendance is lower than it was. The habit broke. This bothers me most when I think about students and people early in their careers — the ones who would benefit most from being in a room where the level is higher than anything they've encountered before.

The Broader World

Conferences are not only about software. Some of the most formative meetings I've attended were PANDA and GSI collaboration meetings at GSI Helmholtzzentrum für Schwerionenforschung in Darmstadt — particle physics, large-scale detector hardware, international teams building instruments that take decades to complete.

The dynamics are different from a software conference, but the core is the same: the real work happens in the corridors, at the dinner table, in the conversations that drift far from the official agenda.

At KiCon Europe 2024 in Bochum, the same pattern held. 150 people, two days, the Rotunde. Lukas Hartmann's talk on open hardware CPU modules set off conversations that continued well past the venue closing.

Open Skunkforce also runs smaller, focused events throughout the year — user groups, workshops, single-topic evenings — where the same principles apply at a smaller scale.

What a Good Conference Actually Is

Here is what we have learned from organising events for a decade:

Talks set the agenda. Conversations are the output. A good talk gives the audience something to argue about. The argument happens in the hallway, at dinner, at the bar. If people leave immediately after the last session, the conference has half-succeeded.

The pre-event evening is not optional. Every conference we run includes a social the evening before the programme starts. People arrive, meet each other without the structure of sessions, and come to day one already knowing who they want to talk to.

Dinner outside the venue belongs in the programme. Not a sponsored cocktail reception in the conference hall. A table at a restaurant, with speakers and attendees mixed. The conversations that happen there are the ones people mention years later.

100–200 people is the sweet spot. Large enough for real diversity — different industries, backgrounds, experience levels. Small enough that you can find the people you want to talk to, and that the speakers are genuinely accessible. Beyond 300, a conference starts to become a trade fair.

Staying in the hotel room after the conference is the biggest mistake you can make. I have made it. Everyone has made it. It is always a mistake.

What We Offer

Open Skunkforce e.V. organises technical conferences in and around Bochum. We handle everything:

Programme design and speaker acquisition
Marketing and public communications
Venue booking and logistics
Catering, including the pre-event social and the dinner
Video recording and post-production
Publishing recordings openly after the event

We have been doing this for ten years. We have the speaker network, the sponsor relationships, the venue contacts, and — most importantly — the experience of what goes wrong and how to fix it before it matters.

The format we know best is two days, 100–200 attendees. That maps well to a focused technical community: an open-source project that wants to bring its contributors together, a company that wants to build a developer community around its tools, a university group that wants to connect its research with practitioners in industry.

If you have been thinking about running a conference but don't know where to start — or have tried and found the logistics overwhelming — that is exactly the problem we exist to solve. Get in touch.

Open Skunkforce e.V. is a registered non-profit based in Bochum. Find us at skunkforce.org or reach out directly via the contact on this site.

Dual Uplink for 15 People: Starlink, Heimdall, and Linux Routing

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

At some point, one internet connection isn’t enough. We hit that point when 15 people were working in the office simultaneously and the line was noticeably sluggish — video calls, git pushes, remote access, all sharing a single uplink. Philipp and I tackled it in February.

Philipp is our server administrator — still working on his bachelor’s degree, but already operating at a level that leaves many professional admins behind. Together we’ve set up mesh backhauls, VPNs, intranets, a Kubernetes cluster, Ceph storage, Keycloak for all our internal services — and quite a bit more. If a service runs in our office, Philipp either built it or knows every corner of it. The network upgrade in February was one more chapter in a long list.

The Starting Point

Our existing network was a standard setup: one uplink, backbone switches behind it, everything running over that single path. It works — until it doesn’t. Either because bandwidth runs out, or because the provider has a bad day. We’d had both.

The fix was obvious: add a second uplink. We went with Starlink — quick to install, independent of our DSL provider, and well-suited to our location.

The actual goal was resilience: if one link goes down, the office keeps running without anyone having to intervene.

Heimdall

Between the two uplinks and the existing backbone switches we added a small new rack. Inside: a Debian rack PC, hostname AI-heimdall.

The name is not accidental. Odin Holmes — a close collaborator I’ve worked with for years — established the tradition of giving some of our projects and machines names from Norse mythology. The first library Odin and I wrote together was called Kvasir. The habit stuck. Heimdall — the watchman of the gods, who observes all nine worlds and misses nothing — was too fitting for the gateway into our network to pass up.

AI-heimdall has the two uplinks coming in as separate interfaces: eno1 for DSL (static IP into the modem), eno2 for Starlink via DHCP. The internal network runs on eno4 with the 10.42.0.0/16 address space towards the backbone switches.

The routing configuration uses two default routes in the Linux main routing table, differentiated by metric: DSL runs with a lower metric and is preferred, Starlink sits alongside it with metric 1003. As long as the DSL gateway is reachable, all traffic goes that way. If DSL drops, Starlink takes over automatically — no manual intervention, no visible outage for anyone in the office.

For the future, two named tables are already registered in /etc/iproute2/rt_tables — starlink (200) and dsl (201) — as preparation for proper policy routing that directs individual connections over a specific uplink. For now, the failover model is exactly what we need.

The Dashboard

To see what is actually going over which link at any given moment, I wrote a small Python dashboard. It reads the interface statistics for both uplinks and displays throughput and utilisation in real time — simple enough to leave running on a screen in the office.

It also served as a practical sanity check: the dashboard makes it immediately obvious if everything is routing over one link when it shouldn’t be, or if something is wrong.

What It Changed

The bottlenecks are gone — and when the DSL line has a hiccup, nobody in the office notices. That’s the real gain: not more bandwidth on paper, but reliability in practice.

The actual work was the clean integration on AI-heimdall: two interfaces, correct metric configuration, making sure the Starlink DHCP lease doesn’t write a default route into the main table that displaces DSL. Philipp handled the Starlink installation and the physical setup, and knows every layer of the existing network that AI-heimdall now sits in front of; the routing configuration was my part.

If you’re building something similar: two default routes with different metrics in /etc/network/interfaces is enough for clean failover. Per-host load balancing requires additional ip rule entries pointing to named routing tables — that’s the next step we’ll take with the starlink and dsl tables already in place.

Ten Years of PowerSense: Blood, Sweat, and Ferrite Cores

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

January 2016. A call came in through a mutual contact — Steffen Scholle, at the time an Ex-inspector at DEKRA and today a respected Ex-consultant — connecting us with DB Netz AG. They had a problem: they needed a smarter way to monitor the power supply of their railway switching systems. Three-phase, 16A lines, 1.5mm² cross-section. And they needed it non-intrusively, clip-on, retrofit. No rewiring. No outages. No excuses.

All the pieces already existed internally — E-field sensing, Hall probes, PoE prototypes — and the moment we heard the requirement, we knew exactly what to assemble. January 2016 was the moment it became real. A customer with a real problem, a real network, and real consequences if the measurements were wrong.

Ten years later, that call is still one of the most consequential things that ever happened to this company.

The First Meeting

We met the DB Netz team in Frankfurt. Their initial idea: an RS-485-connected sensor, daisy-chained across the installation. We declined. Not out of arrogance — out of conviction. RS-485 was the wrong answer to the wrong question. You don't build the future of industrial monitoring on a serial bus from 1983.

After several conversations, we landed on Power over Ethernet. PoE. We had already used it in smaller projects, already understood its potential. But this was the first time we had the chance to apply it at scale, in a critical infrastructure context, with a customer willing to push it through qualification together with us.

All the components were there. What could possibly go wrong?

The Four Problems Nobody Warned Us About

Quite a lot, as it turned out. As the requirements crystallized, four challenges emerged that would define the next five years:

Ultra-low power consumption — under 2W total, including all measurement and communication
Extreme EMC conditions — railway certification standards, high demands on dielectric strength and touch safety
Ultra-fast installation — clip-on, no tools beyond what a technician carries, seconds per unit
Non-contact voltage measurement — no galvanic connection to the conductors

The first three were hard. The fourth was the one that kept us up at night.

The Problem of Voltage Without Contact

Here is something most engineers don't think about carefully enough: voltage is always a potential difference between two points. There is no such thing as an absolute voltage. You measure it between two references.

So how do you measure voltage when you have three phase conductors inside an IT network and you are not galvanically connected to any of them?

The short answer: you don't measure voltage directly. You measure the time-varying electric field each conductor produces, capture its influence on an antenna, and reconstruct the voltage waveform from there.

We had built E-field sensing circuits before — that prior work saved us. Our approach: three pairs of flat patch antennas, one pair per phase, placed on the top and bottom surfaces of a thick PCB. The board's normal vector aligned radially to the conductors. Through the 2mm PCB thickness, the electric field decreases with distance as 1/r (long straight conductor approximation), so the two antenna surfaces see slightly different field strengths — and the differential between them scales as 1/r².

That differential — tiny, noisy, deeply buried in interference — is what we amplified with a carefully tuned op-amp circuit and fed into an ADC. Get the gain and filtering right, and you see clean 50Hz sinusoidal waveforms from three conductors that you have never electrically touched.

To recover absolute voltage values, we added a single galvanically connected voltage reference measurement per switching station — one point in the network where we knew the actual supply voltage. That scalar reference, combined with our normalized E-field measurements, gave us calibrated voltage readings across the entire installation.

The current measurements, by comparison, were trivial. Hall sensors, standard technique. Or so we thought — until the housing changed everything.

The Housing Problem

On the bare PCB, everything worked. Beautiful signals, clean data, happy engineers.

Then we put it in a housing.

Together with Christian Czayka, we developed three different enclosure concepts in 3D CAD, printed the first variants, and assembled prototypes: elegant, compact, tool-free installation. The kind of device you look at and immediately understand how to fit it.

But when the PCB moved inside the housing and the conductors moved further from the antennas, the E-field signals weakened. For voltage sensing, we compensated with higher gain and a tighter frequency filter — manageable.

For current, the situation was different. We needed to see harmonics — the full spectral content of the current waveform, not just the fundamental. Brute-force amplification destroys that. Filtering kills it. We needed a different approach.

The solution: B-field collecting ferrite cores embedded directly into the clamping clips that hold the conductors. The geometry was non-trivial. Getting the ferrite dimensions, permeability, and positioning right required weeks of field calculations and FEM simulations — work that fell to Tabea Bökelmann, who I had met during our physics studies and who is, without qualification, significantly better at mathematics than I am.

The ferrites were custom-manufactured for us, embedded into the prototype clips, and the signals came back. Clean harmonics. Full spectral resolution. A device that worked not just in the lab, but as an actual product that could be assembled by a technician in the field.

Young, Naive, and Almost There

At this point — roughly two years in — we genuinely believed we were almost done. The physics worked. The electronics worked. The housing looked right. We had a team that knew what it was doing.

We were in our early-to-mid twenties, which explains a lot. Odin was already thirty, which in Oregon hippie years is basically a senior engineer — though it did not appear to grant him any additional realism about the timeline either.

What followed was two more years of EMC certification at CETECOM, transitioning the housing from 3D-printed prototypes to injection-molded production parts together with LB Kunststoff, and the full qualification cycle under railway standards. Dielectric strength. Touch safety. Vibration. Temperature cycling. The kind of testing that finds every corner you cut and every assumption you made.

We finished. It took longer than we planned. It always does.

What This Project Taught Us

Looking back now, a decade later, the skAInet-PowerSense was not just a product. It was an education.

PoE first. Always. If you commit to PoE, you get TCP/IP, power, and a standards-compliant physical layer in a single cable. Everything the network has to offer becomes accessible to your device. We have not seriously considered an alternative since 2016.

Digitize as close as possible to the source. The moment you convert a physical signal to bits, you can apply error correction, checksums, timestamps, and all the reliability mechanisms that decades of networking research have produced. Analog signals degrade. Digital packets either arrive or they don't.

A working PCB is not a finished product. This is perhaps the hardest lesson for hardware engineers to internalize. The electronics are phase one. What follows is a product development process that is at least as demanding. Today, we structure our projects accordingly:

PoC (3–6 months): Looks nothing like the product. Integrates all the physical measurement principles. Validates that the science works.
Prototype (6–9 months): Looks like the product. Manufactured by hand. Proves the form factor and installation concept.
Prototype of Product (~12 months): Manufactured using the same processes as eventual series production. The first object you can genuinely call a device.

We estimate wrong every time. We estimate less wrong than we used to.

The skAInet-PowerSense is still in service across DB Netz switching stations. It monitors power supply quality in infrastructure that moves millions of people every day, without anyone on the platform knowing it exists.

That is what good monitoring looks like.

There Is More

This post barely scratches the surface. What I have not covered: inter-channel crosstalk and how we characterized and compensated it, PoE shutdowns caused by drawing too little current (yes, that is a real problem — the standard assumes you need power, not that you are carefully conserving it), the sensitivity of every measurement to the exact relative positioning of conductors and PCB, and the full calibration workflow that ties all of it together into a number you can trust.

Every one of those deserves its own post. Maybe one day.

The People Behind the People

None of this would have been possible without the continuous support of people who believed in the work before it was finished.

Lukas Jakubczyk and Prof. Gereon Kortenbruck at the PROLAB — Laboratory for Product and Production at THGA Bochum — were there throughout. Prof. Benjamin Menküc, co-founder of Auto-Intern and by this point already a professor for EMC and medical engineering at FH Dortmund, kept advising from the sidelines even after stepping back from day-to-day operations. And Dr. Florian Feldbauer of the EP1 chair at the Faculty of Physics, Ruhr-Universität Bochum, provided the kind of rigorous physics perspective that keeps engineers honest.

We are genuinely grateful to have RUB, THGA, and FH Dortmund as partners — reliable, deeply professional, and always willing to push back when we need it.

Our real secret superpower is not the hardware. It is that we take these relationships seriously and keep the conversation going. Regularly, honestly, and without agenda. That is rarer than it sounds.

If any of this is relevant to something you are building — or if you just want to go deep on non-contact sensing, EMC in rail environments, or PoE power budgeting — come find me on Discord. I enjoy talking about this stuff more than I probably should.

Discord — Full Stack EngineeringDirect access to me and my colleagues. Webinars, live Q&A, and community discussions for engineers across the full stack.Join the server →

PCB Design Starts With a README

Stephan -All Input Is Error- Bökelmann — Wed, 10 Dec 2025 00:00:00 +0000

The most expensive mistake you can make in PCB design is building the wrong board. The second most expensive is building a board whose purpose nobody on the team agrees on, because you never wrote it down.

Both mistakes are preventable with the same tool: a plain text file in a version-controlled repository, written before any schematic work begins.

The Workflow

The process is simple enough to describe in a few steps, but the discipline behind it takes some practice.

Step 1 — Create a new repository. A fresh repo on GitHub, cloned locally. This is where the design intent lives, separate from any KiCad project or firmware repo. The design intent should be version controlled on its own terms.

Step 2 — Write a README. Not notes. Not bullet points in a chat message. A structured document that explains what the board does, what connects to it, how it gets its power, and what you have not decided yet. More on the structure below.

Step 3 — Paste the README into an LLM and ask for a block diagram. The prompt is exactly that simple: paste the whole document, ask for a PlantUML component diagram. The LLM has enough context from the README to produce something architecturally correct in the first pass — not because it knows your project, but because you do, and you wrote it down clearly.

Step 4 — Commit the .puml file. The diagram source file goes into the repository alongside the README. Not the rendered image — the source. This way, the diagram is editable, diffable, and improvable over time in the same way the README is.

Step 5 — Render locally with the PlantUML CLI. A single command:

plantuml stm32f7-adc-board.puml -tsvg

This produces an SVG you can embed in the README, open in a browser, or share with a colleague without them needing any tooling installed. If you want rendering to happen automatically on push, a short GitHub Actions workflow handles it — one YAML file, no external services.

Step 6 — Iterate. The LLM gets it mostly right, but not completely right. That is expected and fine. The .puml file is a plain text format — editing it manually is quick, and the structure of PlantUML component diagrams is easy to learn in an afternoon. You can also feed the LLM a corrected version and ask it to extend or refine specific sections. Because the whole conversation context is anchored to a written document, the iterations are precise rather than speculative.

Why This Order Matters

Writing the README first is not about documentation. It is about thinking.

If you will not invest the time to write down what the board should do, you probably will not invest the time to build it correctly either. The act of writing filters out the ideas that sound good in your head but fall apart on paper — which is exactly where you want them to fall apart, before you spend any money.

It also creates something tangible to discuss. Before presenting a schematic to a colleague, a customer, or a review meeting, there is a block diagram that fits on one screen. The diagram does not require electronics expertise to read. It answers the question "what is this thing" in thirty seconds. That is the first thing any technical conversation needs to establish before it can go anywhere useful.

At Auto-Intern and Open Skunkforce, we use this process for every board we build. The block diagram is the entry point. The schematic is what follows after everyone agrees on the entry point.

What the README Should Contain

Seven chapters cover the design intent at the right level of detail for the first-pass diagram:

1. Purpose — one paragraph. What problem does this board solve? For whom? In what environment? Everything else in the document flows from this.

2. External Interfaces — a table. What physically connects to this board from the outside? USB, CAN, SPI, analog inputs, power connectors. Include the protocol, the connector type, and the direction.

3. Functional Blocks — a numbered list of subsystems. Each block gets two or three sentences: what it is, what it does, why it exists. This is the section the LLM turns most directly into diagram nodes.

4. Power Architecture — a small ASCII diagram plus a current budget estimate. Where does power come in? What rails does it produce? What does each rail power? A short budget (mA per rail) catches overloaded regulators before any simulation is run.

5. Signal Chain — a linear description of how data or signals move through the board from input to output. For a sensor board: physical quantity → conditioning → conversion → processing → output. This section forces you to think about the end-to-end path, not just individual blocks.

6. Known Constraints — hard limits. Form factor, cost ceiling, operating temperature, regulatory requirements. These are the things that rule out design choices before the schematic opens.

7. Open Questions — a checklist of everything not yet decided. Part selection, firmware protocol, power sequencing, whether an external reference is needed. These become the agenda for the first design review.

A Worked Example

Here is what this looks like for a real board we built: an STM32F7 with a USB-C interface, an I2C-controlled analog multiplexer switching ten ADC channels, with identical differential frontend electronics on each channel, and a power supply generating 3.3 V and 1.7 V from USB 5 V.

The README for that board is here. The PlantUML source is here. The rendered block diagram:

See original svg here.

The diagram shows the complete signal chain: differential analog inputs through an EMC filter, a low-pass filter, and a diff-to-single converter, into a 10:1 analog mux controlled over I2C, and finally into the STM32F7 ADC. USB on the left. Power supply at the top with the two output rails. The STM32F7 on the right with its internal functional sections laid out.

This took two LLM iterations to get right. The first pass placed the mux inside the frontend group, which was structurally wrong — the mux is a separate IC with its own power domain. A one-sentence correction fixed it. The third and later passes were manual edits to the .puml file: adjusting labels, correcting the power annotation, adding the internal section dividers to the MCU block.

That is the correct way to think about the LLM's role here: it drafts, you correct. The written document is what makes the correction precise. You are not redescribing the board — you are pointing at a specific node in a diagram whose structure the LLM already understands from your README.

The PlantUML Source

The full source file is committed to the repository at assets/stm32f7-adc-board.puml. A few things worth noting about the structure:

left to right direction

package "Analog Frontend  ×10 identical channel instances" #F3E5F5 {
    component "EMC Filter\n(per channel)"   as CHFILT
    component "Low-Pass\nFilter"            as LPF
    component "Diff-to-Single\nConverter"   as D2S
    CHFILT --> LPF
    LPF    --> D2S
}

The package keyword creates the group boundary. The ×10 annotation is in the label, not in the component count — PlantUML does not have a repetition primitive, but the label is unambiguous. Dashed arrows for power, solid arrows for signal, the .[#FFA000].> syntax for coloured dashed connections. None of this requires reading a manual; it is learnable by example in under an hour.

Version Control of Design Intent

Once the .puml file is committed, a git diff on it is meaningful. If the block diagram changes between commits, the diff shows exactly which connections were added, removed, or renamed. That is something a KiCad schematic diff cannot give you at the block level.

Over the course of a project, the README and the diagram evolve together. The open questions get resolved and moved to the relevant functional block. New constraints appear and get documented. The diagram grows detail — individual components appear, bus widths get annotated, power domain boundaries become explicit.

By the time the schematic review happens, everyone has been looking at the same diagram for weeks. The schematic is a confirmation of something already agreed, not a surprise.

The PlantUML CLI is available at plantuml.com. Rendering in CI requires Java; the Docker image plantuml/plantuml avoids a local Java dependency. The example files linked above are free to use as a starting point.

Biofilms in Rivers: EIS at the Clark Fork

Stephan -All Input Is Error- Bökelmann — Fri, 28 Nov 2025 00:00:00 +0000

In the summer of 2023, Tabea, Odin Holmes, and I were in Montana for a series of meetings. We had been introduced to the state's network by Frederick van den Abbeel, who had arranged conversations with Scott Osterman and — unexpectedly — with Governor Greg Gianforte. We were even invited to the reception of the Governor's golf cup in Kalispell. None of us had anticipated that a research instrument would come out of any of this.

Those conversations pointed us toward Montana State University in Bozeman, and through MSU to Prof. Stephan Warnat — an electrical engineer from Schleswig-Holstein who had ended up teaching in Montana, which is not the most obvious career trajectory for someone from the German-Danish borderland. We visited his lab that summer.

Electrochemical Impedance Spectroscopy

Warnat's work centres on microfabricated electrochemical sensors — small chips with precisely patterned electrode arrays that can detect what is growing on their surface. The target: biofilms. Specifically, the kind produced by bacteria like E. coli, which form dense extracellular matrices that coat surfaces in contact with water. Standard approaches to monitoring these require lab analysis. Warnat's approach was to push the detection into the field, directly into the water.

The method is Electrochemical Impedance Spectroscopy (EIS): apply a small alternating signal across a frequency sweep, measure how the impedance changes, and infer the state of the biofilm from the spectral response. A biofilm changes the dielectric properties of the interface between electrode and water. The change is detectable, quantifiable, and — with the right instrument — automatable.

Warnat walked us through the setup: the ASIC-driven measurement boards, the electrode chips, the cell culture work used to grow controlled biofilm samples for calibration. It was the kind of lab visit where you come in thinking you will stay an hour and leave three hours later.

Building the Datalogger

The problem with taking EIS into the field is that the instrument that does it in a lab — an impedance analyser — is bulky, mains-powered, and expensive. For continuous monitoring of a river site, you need something that runs on a battery or solar panel, survives temperature swings and humidity, logs reliably over weeks without intervention, and costs less than a car.

Over the following year, we developed exactly that: a portable datalogger with an integrated spectrum analyser capable of running EIS autonomously in the field. The hardware design, firmware, and enclosure all went through multiple iterations. Tabea drove much of the practical engineering. The system had to pass data back reliably and handle partial failures without losing the measurement record.

By early September 2024 we were in Bozeman again, this time for the deployment.

Clark Fork, September 2024

The target site was the Clark Fork River north of Butte — a river with a complex history of mining contamination and ongoing remediation work, and therefore exactly the kind of environment where a sensitive biofilm monitoring system is scientifically interesting.

The day before deployment, we were in Prof. Warnat's lab running final checks, calibrating the system, and loading the firmware build we intended to run in the field.

On the morning of September 4th we loaded the gear into a rented Ram Rebel and drove north.

The site was a bridge crossing with a small existing measurement hut — used previously by other monitoring equipment — close enough to the water to run cabling down to the sensor without excessive cable runs. The team from MSU was already there when we arrived. Under a canopy tent that served as a field workshop, we spread out the equipment and started working through the installation checklist.

The sensor housing — a machined PVC tube with the electrode chip mounted inside and flow apertures to let water circulate over the sensing surface — went into the water first.

Getting the cabling from the water up to the measurement hut involved some improvisation. The hut had not been designed with this use case in mind.

The electrode array was positioned against the bridge footing below the waterline, with the cable run secured against the structure.

While one part of the team handled the hardware at the water, the coordination happened under the canopy.

The final step was commissioning the software in the hut itself. The space was not designed for comfort — keyboard on knees, monitor at eye level, no chair. The terminal output scrolling across the screen confirmed what we needed to see: the system was acquiring data and writing it to disk.

The system ran. The first dataset came in clean.

What the Data Showed

The dataset collected at the Clark Fork made an impression on the funding agencies reviewing the project. The combination of a working outdoor instrument, real river data, and a clear correlation between the EIS signal and known conditions at the site was enough to secure the next phase of the project.

In November 2025, Prof. Warnat's postdoc Michael Neubauer presented the project's findings at a conference: Microfabricated Electrochemical Sensors as a Sentinel System to Detect Biofilms in River Systems. The work covers the sensor design, the EIS methodology applied to biofilm detection in open-water environments, and the field validation data from the Clark Fork deployment.

The EIS sensor project is a collaboration between skAInet.io and the Warnat Lab at Montana State University, Bozeman.

KiCon Asia 2025: Speaking on Wire Bonding in Shenzhen

Stephan -All Input Is Error- Bökelmann — Sat, 15 Nov 2025 00:00:00 +0000

KiCon Asia 2025 took place in Shenzhen on November 13–15, co-organised by the KiCad project and Huaqiu PCB. I was there as a speaker — and spent the rest of the time walking around one of the most interesting manufacturing cities in the world.

The Talk: A Poor Man's Intro to Wire Bonding

My talk was called "A poor man's intro to wire bonding" — and that title is exactly right. This wasn't a talk about having the right equipment and a controlled process. It was about what you actually learn when you try to bond real detector chips onto PCBs over two years, with limited resources, and have to figure out most of it by doing.

The chips involved were CLICpix v3, MuPix8, and MuPix10 — pixel detector ASICs developed in the context of high-energy physics detector R&D. MuPix8 and MuPix10 belong to the family of HV-MAPS (High Voltage Monolithic Active Pixel Sensors): monolithic pixel detectors where the sensor and the readout electronics are fabricated on the same silicon die, with a high bias voltage applied to create a fast depletion zone directly beneath the pixel cell. This combination of thin sensitive volume, fast charge collection, and full CMOS integration makes them attractive for tracking detectors in particle physics experiments, where minimising material budget and withstanding high radiation doses are both critical constraints. The KIT Application Detector Lab at IPE Karlsruhe is one of the groups driving MuPix development. These are not hobbyist components. They're small, the pads are tiny, and the bonding tolerances are unforgiving. We used a Delvotec wire bonder throughout.

Two years of work compresses surprisingly well. The core of the talk was about the learnings that don't appear in datasheets or application notes: what the bonder parameters actually mean in practice, how pad metallisation affects bond reliability, what a bad bond looks like before it fails, and how you build intuition for a process that is fundamentally tactile.

The laptop slide below shows where the talk lived — somewhere between a particle physics lab and a PCB assembly problem.

Slides

The slides are available openly. You can view them here.

Wire Bonding on Video

If you want to see what the actual bonding process looks like — this is a short clip from the lab, bonding one of the detector chips:

I also gave a version of this talk at KiCon Europe earlier in the year. The content overlaps, but the European version goes into more depth on some of the failure modes:

The Conference

KiCon Asia was genuinely different from European conferences — denser, more commercially oriented, with a much higher proportion of hardware people who are adjacent to manufacturing at scale. The Huaqiu co-organisation showed in the programme: several talks touched on the bridge between design and production in ways that feel abstract at European events but are immediate here.

The koala came home with me — not as swag, but as a prize. Peter Dalmaris gave a talk titled "One Tool, One Journey", arguing that KiCad should accompany an engineer across their entire career and proposing a "Learner Mode" to ease the entry for beginners. I asked a question that apparently landed well enough to win the raffle prize at the end: an unbranded koala plush sitting on a KiCad × Huaqiu conference folder.

Peter is the author of KiCad Like a Pro (Elektor, multiple editions including a KiCad 9 update), which is the go-to book for anyone wanting a structured path through KiCad beyond the official documentation. He has also written Raspberry Pi: Full Stack, Node-RED and Raspberry Pi Pico W, and Maker Education Revolution — all published through Elektor. If you are learning KiCad seriously, the book is worth having on your desk.

Shenzhen

It wouldn't be my last time in China — a few months later I was back in Dongguan for EMC testing. Shenzhen stands on its own regardless: more polished than its neighbour city, more international, the skyline is genuinely impressive at night.

KiCon Bochum

I'm also involved on the organisational side of KiCon in Germany. Together with Open Skunkforce e.V., we run KiCon Bochum — a local German instance of the KiCon format. If you're in the area and use KiCad, keep an eye on what we announce.

Slides are openly available. Video from the bonding lab: YouTube. KiCon Europe recording: YouTube.

OmnAIScope: A USB Oscilloscope for Automotive Diagnostics

Stephan -All Input Is Error- Bökelmann — Thu, 28 Aug 2025 00:00:00 +0000

The OmnAIScope is a single-channel USB oscilloscope designed for automotive diagnostics. It started as a prototype within the autowerkstatt4null project — a three-year, federally funded initiative to bring AI-driven diagnostics to independent car workshops. This post covers what it is, how the synchronisation works, and where it's going.

The Hardware

The current prototype is built around an RP2040 microcontroller. The specs are deliberately modest:

500 kSa/s, single channel
Anodised aluminium housing, epoxy-sealed after assembly — fully waterproof
BNC on one end, USB-C on the other
No buttons, no screen, no moving parts

That's it. From the outside it looks like a chunky BNC barrel adapter. The simplicity is intentional: the electronics in a car workshop get dropped, kicked, and splashed. Everything that can break has been moved either into firmware or into the server software on the connected computer.

All PCB designs were done in KiCad. That workflow held up well throughout the project.

The scope has no revision designation yet — this is still beta hardware. It is, however, already available: order it directly from Auto-Intern.

Multi-Channel Synchronisation Without a Hardware Trigger

Single-channel at 500 kSa/s sounds limiting until you understand the synchronisation approach.

USB generates a Start-of-Frame (SOF) packet every millisecond on full-speed connections, timed by the host controller. Every OmnAIScope captures this SOF timestamp alongside its ADC samples and embeds both in the data packet sent to the host. The server on the PC then reconstructs a common time axis across all connected scopes by aligning them on their respective SOF timestamps.

The result: arbitrary numbers of scopes synchronised to ±half a USB frame — without a single wire between them, without a hardware trigger line, and without any external clock distribution. For automotive diagnostic use — compression cycles, fuel pump waveforms, CAN signals — this resolution is more than sufficient.

There is a small latency between measurement and display while the server assembles and aligns the packets, but it remains imperceptible in normal use.

The Server Layer

Each OmnAIScope connects via USB to a host machine running a local server process. That server:

ingests the raw ADC + SOF data from each connected scope
performs the SOF-based time alignment
exposes the synchronised, calibrated waveform data via REST and WebSocket APIs

This means the frontend — or any other application — doesn't speak directly to the hardware. It speaks to the server. You can build your own tooling, your own analysis pipeline, your own visualisation on top of that API without touching the firmware or the hardware at all.

Real Measurements

The system has been used for real diagnostic measurements, stored in a CEPH cluster operated jointly with THGA Bochum. Signals captured so far include compression cycles, fuel pre-feed pump waveforms, and common-rail pressure signals. The data has been used to evaluate various classification and analysis approaches. That analysis is out of scope for this post — the point here is that the hardware and server layer work, and the data is useful.

The Paper

The full context — the automotive diagnostic landscape, the federated architecture, the data flow from scope to AI service to technician UI — is written up in the autowerkstatt4null overview paper. It is available on GitHub and ResearchGate, and nowhere else. No journal paywall, no publisher fee.

I'm a fan of open access. The paper exists to be read and built upon, not to sit behind a subscription.

Authors: Stephan Bökelmann (Ruhr University Bochum), René Glitza (Ruhr University Bochum), Meihui Huang / 黄美慧 (nabla B engineering UG), Odin Holmes (Auto-Intern GmbH), Lukas Jakubczyk (THGA Bochum), Tabea Röthemeyer (Auto-Intern GmbH).

What's Next

The immediate priority is the software suite. A new frontend release is in the works — it's going to be substantially better than what's currently shipping. That said, the server API means you don't have to wait for the official frontend to do useful things with the hardware.

A new hardware iteration will follow once the software is in better shape.

I'm also watching @jlcjak on X closely — he's working on an oscilloscope project that I'm genuinely excited about, and it deserves attention from anyone interested in this space.

OmnAIScope beta is available at auto-intern.de. The paper is at github.com/nabla-B/paper_aw4null-overview.

Getting Started: From Tape-Out to TypeScript

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

This is the first post on this blog. It won't be the most technically dense — that comes later.

Why a blog?

Every platform I post on is rented ground. Algorithms change. Accounts get suspended. Platforms rise and fall. This blog is the one place I own outright.

The plan: one longform post per week. Everything else — threads on X, LinkedIn posts, YouTube videos, Instagram carousels — is derived from what's written here first. The blog is the source of truth.

What I'll be writing about

Three pillars, based on where I actually spend my time:

Monitoring systems in production. I've been building and running measurement infrastructure since 2007 — from oscilloscope-based diagnostics in automotive workshops to telemetry stacks for critical rail infrastructure and particle physics experiments. There's a lot of hard-won knowledge here that doesn't exist in any single book or documentation page.

University lecture material. I teach at THGA Bochum. The courses cover programming fundamentals, object-oriented design, and databases. I'll publish supplementary material here — worked examples, extended explanations, things that didn't fit into the lecture slot.

Company visits. I travel to electronics manufacturers, fabs, and engineering shops around the world. I want to document what I see — not the PR version, the real version. Factory floors, supply chains, engineering culture.

The handle

The username MaxClerkwell is a wordplay on James Clerk Maxwell — the Scottish physicist who unified electricity, magnetism, and light into a single theory. Rearrange the syllables slightly and you get MaxClerkwell. Seemed appropriate for someone who spends their days connecting layers of the stack that aren't supposed to know about each other.

The tagline — From tape-out to TypeScript — is meant to be taken literally. I've worked at every layer: silicon characterization, bare-metal firmware, ASIC test systems, embedded Linux, monitoring daemons, REST APIs, frontend dashboards. The interesting problems usually live at the boundaries between layers.

How to follow along

Blog: canonical, weekly
This DEV.to page: mirrored posts and discussion
Discord: the community layer — join the Full Stack Engineering server
YouTube: longform videos derived from blog posts
X / Twitter: threads, quick takes

Links to everything are on the home page.

More soon.

KiCon Europe 2024: Bochum Goes International

Stephan -All Input Is Error- Bökelmann — Fri, 20 Sep 2024 00:00:00 +0000

KiCon Europe 2024 took place on September 19–20 in the Rotunde Bochum, organised by Open Skunkforce e.V. together with the KiCad project. Around 150 people came — designers, engineers, developers, hobbyists — from across Europe and beyond. It was the largest KiCon we had run in Bochum.

From KiCon Germany to KiCon Europe

The conference didn't appear out of nowhere. In 2020, I organised the first KiCon Germany — a small, informal gathering of KiCad users in Bochum. We ran it four more times, each edition a little bigger, a little more polished. In 2024 we made the leap to a proper European edition: new venue, full two-day programme, workshops, international speakers.

The evening before the conference started with a social dinner. These informal evenings before the programme begins are often where the most useful conversations happen — and this one was no exception.

The Venue Setup

The Rotunde is a converted industrial building in Bochum-Langendreer. Great atmosphere, brick walls, good acoustics. Getting it ready was a different story.

The setup was a production in itself. Everything that could go wrong did, at least once. Tabea Bökelmann (@tabeatheunicorn) held most of it together — without her, the logistics would have collapsed on day one.

Wayne, Seth, and What That Meant

For both days, Wayne Stambaugh and Seth Hilbrand — the two people most responsible for where KiCad is today — were present in Bochum. It was the first time either of them had come here.

I had met Wayne once before, at the original KiCon 2019 in Chicago, which was organised by Chris Gammel of Contextual Electronics. That was a much smaller event, but it planted the idea that a regular European equivalent was worth building. Five years later, here we were.

Highlights from the Programme

Lukas Hartmann — How KiCad Enables the Open Hardware Future

Lukas Hartmann builds open hardware laptops — the MNT Reform and Pocket Reform are entirely open-source, down to the schematics and PCB files. His talk showed how KiCad is not just a design tool but the foundation that makes open hardware reproducible and auditable by anyone. The "CPU Modules" slide alone — showing actual PCBs of compute modules he designed — made the point better than any abstract argument could.

Odin Holmes — Edgy

Odin Holmes presented Edgy — a framework for source-controlled, modular PCB reference designs. The core idea: treat PCB subsystems like software libraries, version them properly, compose them. For anyone who has copy-pasted the same power section into the fifth board in a row, the talk hit.

cpresser — Become a KiCad Librarian

One of the workshops that generated the most discussion was cpresser's session on becoming a KiCad librarian — how the official symbol and footprint libraries are maintained, what the contribution process looks like, and what it actually takes to get a part merged. Practical, hands-on, and overdue: a lot of people use the libraries without knowing how they work or how to improve them.

The Programme in Full

All talks are recorded and available in the KiCon Europe 2024 playlist on YouTube. A few other sessions worth watching:

How to build awesome KiCad plugins — Joel Schulz-Andres
Managing PCB Assembly Variants with KiVar — Mark Hämmerling
CE For makers — Leveraging KiCad — Clemens Mayer
Speed up your Hand Assembly with the Pixel Pump — Thea (workshop)
Clearance and creepage for safety — Fabien Corona
The KiCon Electronic Badge — Michael MSvB

What Struck Me

The breadth of the crowd was the thing I hadn't fully anticipated. Hobbyists who build one board a year sat next to engineers running production lines. People came from well outside Germany — some from places where there's no local KiCad community at all. The programme reflected that: there was something for someone picking up KiCad for the first time and something for people filing bug reports against the routing engine.

The KiCad project itself is in a strong place. Having Wayne and Seth in the room for two days, available for questions and conversations in the hallway, made that concrete in a way that watching release videos doesn't.

Open Skunkforce e.V.

KiCon is one of several conferences Open Skunkforce e.V. runs out of Bochum. The others:

emBO++ — embedded C++ conference, running since 2016
OpenTapeout — open-source chip design, first edition 2021
Practical Datascience Conference (PDSC) — applied data science for practitioners

The thread connecting all of them is the same: bring people who are actually building things into the same room, keep it affordable, and let the programme be driven by what the community finds worth talking about.