Publish git migration note and pre-write project announcements

Add pixacao project blog post
Fix kicoil blog post formatting
2026-05-30 11:44:14 +02:00 · 2026-05-30 10:30:31 +02:00 · 2026-05-30 10:29:42 +02:00 · 2026-05-17 13:46:09 +02:00 · 2026-04-24 21:57:21 +02:00 · 2025-12-29 12:04:20 +01:00
365 changed files with 19830 additions and 3429 deletions
--- a/.gitignore
+++ b/.gitignore
@ -0,0 +1 @@
 public
--- a/.gitmodules
+++ b/.gitmodules
--- a/404.html
+++ b/404.html
@ -1,77 +0,0 @@
 <!DOCTYPE html>
 <html lang="en-us">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>404 Page not found | jaseg.de</title>
    <link rel="stylesheet" href="/css/style.css" />
    <link rel="stylesheet" href="/css/fonts.css" />
    <header>
  <link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/atom-one-light.min.css">
  <script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js"></script>
  <script>hljs.initHighlightingOnLoad();</script>
  <nav>
    <ul>
      <li class="pull-left ">
        <a href="https://blog.jaseg.de/">/home/jaseg.de</a>
      </li>
    </ul>
  </nav>
 </header>
  </head>
  <body>
    <br/>
 404 NOT FOUND
    <footer>
 <script>
 (function() {
  function center_el(tagName) {
    var tags = document.getElementsByTagName(tagName), i, tag;
    for (i = 0; i < tags.length; i++) {
      tag = tags[i];
      var parent = tag.parentElement;
      if (parent.childNodes.length === 1) {
        if (parent.nodeName === 'A') {
          parent = parent.parentElement;
          if (parent.childNodes.length != 1) continue;
        }
        if (parent.nodeName === 'P') parent.style.textAlign = 'center';
      }
    }
  }
  var tagNames = ['img', 'embed', 'object'];
  for (var i = 0; i < tagNames.length; i++) {
    center_el(tagNames[i]);
  }
 })();
 </script>
      <div id="license-info">
           &#169;2020 by Jan Götte. This work is licensed under
           <a href="https://creativecommons.org/licenses/by-nc-sa/4.0/">CC-BY-NC-SA 4.0</a>.
      </div>
      <div id="imprint-info">
           <a href="/imprint">Impressum und Haftungsausschluss und Datenschutzerklärung</a>.
      </div>
    </footer>
  </body>
 </html>
--- a/about/index.html
+++ b/about/index.html
@ -1,97 +0,0 @@
 <!DOCTYPE html>
 <html lang="en-us">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>About jaseg | jaseg.de</title>
    <link rel="stylesheet" href="/css/style.css" />
    <link rel="stylesheet" href="/css/fonts.css" />
    <header>
  <link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/atom-one-light.min.css">
  <script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js"></script>
  <script>hljs.initHighlightingOnLoad();</script>
  <nav>
    <ul>
      <li class="pull-left ">
        <a href="https://blog.jaseg.de/">/home/jaseg.de</a>
      </li>
    </ul>
  </nav>
 </header>
  </head>
  <body>
    <br/>
 <div class="article-meta">
 <h1><span class="title">About jaseg</span></h1>
 <p class="terms">
 </p>
 </div>
 <main>
 <div class="document" id="about">
 <h1 class="title">About</h1>
 </div>
 </main>
    <footer>
 <script>
 (function() {
  function center_el(tagName) {
    var tags = document.getElementsByTagName(tagName), i, tag;
    for (i = 0; i < tags.length; i++) {
      tag = tags[i];
      var parent = tag.parentElement;
      if (parent.childNodes.length === 1) {
        if (parent.nodeName === 'A') {
          parent = parent.parentElement;
          if (parent.childNodes.length != 1) continue;
        }
        if (parent.nodeName === 'P') parent.style.textAlign = 'center';
      }
    }
  }
  var tagNames = ['img', 'embed', 'object'];
  for (var i = 0; i < tagNames.length; i++) {
    center_el(tagNames[i]);
  }
 })();
 </script>
      <div id="license-info">
           &#169;2020 by Jan Götte. This work is licensed under
           <a href="https://creativecommons.org/licenses/by-nc-sa/4.0/">CC-BY-NC-SA 4.0</a>.
      </div>
      <div id="imprint-info">
           <a href="/imprint">Impressum und Haftungsausschluss und Datenschutzerklärung</a>.
      </div>
    </footer>
  </body>
 </html>
--- a/archetypes/default.md
+++ b/archetypes/default.md
@ -0,0 +1,6 @@
 ---
 title: "{{ replace .Name "-" " " | title }}"
 date: {{ .Date }}
 draft: true
 ---
--- a/categories/index.html
+++ b/categories/index.html
@ -1,81 +0,0 @@
 <!DOCTYPE html>
 <html lang="en-us">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Categories | jaseg.de</title>
    <link rel="stylesheet" href="/css/style.css" />
    <link rel="stylesheet" href="/css/fonts.css" />
    <header>
  <link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/atom-one-light.min.css">
  <script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js"></script>
  <script>hljs.initHighlightingOnLoad();</script>
  <nav>
    <ul>
      <li class="pull-left ">
        <a href="https://blog.jaseg.de/">/home/jaseg.de</a>
      </li>
    </ul>
  </nav>
 </header>
  </head>
  <body>
    <br/>
 <h1>Categories</h1>
 <ul class="terms">
 </ul>
    <footer>
 <script>
 (function() {
  function center_el(tagName) {
    var tags = document.getElementsByTagName(tagName), i, tag;
    for (i = 0; i < tags.length; i++) {
      tag = tags[i];
      var parent = tag.parentElement;
      if (parent.childNodes.length === 1) {
        if (parent.nodeName === 'A') {
          parent = parent.parentElement;
          if (parent.childNodes.length != 1) continue;
        }
        if (parent.nodeName === 'P') parent.style.textAlign = 'center';
      }
    }
  }
  var tagNames = ['img', 'embed', 'object'];
  for (var i = 0; i < tagNames.length; i++) {
    center_el(tagNames[i]);
  }
 })();
 </script>
      <div id="license-info">
           &#169;2020 by Jan Götte. This work is licensed under
           <a href="https://creativecommons.org/licenses/by-nc-sa/4.0/">CC-BY-NC-SA 4.0</a>.
      </div>
      <div id="imprint-info">
           <a href="/imprint">Impressum und Haftungsausschluss und Datenschutzerklärung</a>.
      </div>
    </footer>
  </body>
 </html>
--- a/categories/index.xml
+++ b/categories/index.xml
@ -1,10 +0,0 @@
 <?xml version="1.0" encoding="utf-8" standalone="yes"?>
 <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Categories on jaseg.de</title>
    <link>https://blog.jaseg.de/categories/</link>
    <description>Recent content in Categories on jaseg.de</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language><atom:link href="https://blog.jaseg.de/categories/index.xml" rel="self" type="application/rss+xml" />
  </channel>
 </rss>
--- a/config.toml
+++ b/config.toml
@ -0,0 +1,76 @@
 baseURL = "http://jaseg.de/"
 languageCode = "en-us"
 title = "Home"
 copyright = "Jan Sebastian Götte"
 theme = "conspiracy"
 enableRobotsTXT = true
 [outputs]
 home = ['html', 'rss']
 taxonomy = ['html', 'rss']
 [params]
 fediverse_account = "@jaseg@chaos.social"
 [taxonomies]
 category = "Categories"
 blog = "Posts"
 [[menu.main]]
 name = "Home"
 url = "/"
 weight = 1
 [[menu.main]]
 name = "Blog"
 url = "/blog/"
 weight = 2
 [[menu.main]]
 name = "Projects"
 url = "/projects/"
 weight = 3
 [[menu.main]]
 name = "About"
 url = "/about/"
 weight = 4
 [[params.profile_links]]
 name = "cgit"
 url = "https://git.jaseg.de/"
 weight = 1
 [[params.profile_links]]
 name = "Github"
 url = "https://github.com/jaseg"
 weight = 2
 [[params.profile_links]]
 name = "Gitlab"
 url = "https://gitlab.com/neinseg"
 weight = 3
 [[params.profile_links]]
 name = "Mastodon"
 url = "https://chaos.social/@jaseg"
 weight = 4
 [[params.footer_links]]
 name = "About"
 url = "/about/"
 weight = 1
 [[params.footer_links]]
 name = "Imprint"
 url = "/imprint/"
 weight = 2
 [[params.homepage_categories]]
 title = "Blog"
 key = "blog"
 weight = 2
 count = 10
 [security.exec]
 allow = ["^dart-sass-embedded$", "^go$", "^npx$", "^postcss$", "^rst2html$"]
--- a/content/_index.rst
+++ b/content/_index.rst
@ -0,0 +1,9 @@
 ---
 title: jaseg.de
 ---
 Hi there, and welcome to my personal website.
 I'm jaseg, and I write about my projects here. You can find long-form articles in the blog, and links to my open-source
 projects on the projects page. On the top right of this page, there are links to my git repositories and social media
 pages. If you want to learn more about me, head over to the about page.
--- a/content/about/index.rst
+++ b/content/about/index.rst
@ -0,0 +1,65 @@
 ---
 title: "About jaseg"
 ---
 About 
 -----
 Hej, I'm Jan, or jaseg. At the moment I'm doing a PhD (Dr.-Ing.) at TU Darmstadt in Computer Science, specializing on
 Hardware Security. This is my personal website where I publish things that I find interesting.
 I self-host my code at `git.jaseg.de <https://git.jaseg.de/>`__, but I am also on `github <https://github.com/jaseg>`__
 and on `gitlab <https://gitlab.com/neinseg>`__. I use github for issue tracking for some of my projects such as
 `gerbolyze <https://github.com/jaseg/gerbolyze>`__ and `python-mpv <https://github.com/jaseg/python-mpv>`__. I maintain
 the `python-mpv <https://pypi.org/project/python-mpv/>`__ and `gerbolyze <https://pypi.org/project/gerbolyze/>`__ python
 packages on PyPI. Release tags on these two repositories are signed with the release signing key found `on github
 <https://github.com/jaseg.gpg>`__ and below.
 I am not on any social network, but feel free to write me an email at `hello@jaseg.de
 <mailto:hello@jaseg.de?subject=About\ page\ on\ blog.jaseg.de>`__.
 I do not use application-level email encryption such as S/MIME or PGP. If you need a higher level of secrecy than
 regular old email provides, please ask around for my signal contact or email me a file encrypted using `age
 <https://github.com/FiloSottile/age>`__ with one of the SSH keys listed `on my github
 <https://github.com/jaseg.keys>`__.  You can find both PGP and other SSH keys that I have used in the past on the
 internet, but please consider these keys revoked, and do not use them to encrypt anything you send me.
 Python package release signing key
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 I use this GPG key (key ID ``ED7A208EEEC76F2D``) to sign git release tags of both `gerbolyze <https://github.com/jaseg/gerbolyze>`__ and `python-mpv
 <https://github.com/jaseg/python-mpv>`__:
 .. code::
    -----BEGIN PGP PUBLIC KEY BLOCK-----
    mDMEXom49xYJKwYBBAHaRw8BAQdA/KrWMt2MKGIZUvlQZnWjNd6i8/ZYjRsBQqEf
    PJ8pJ+20NHB5dGhvbi1tcHYgUmVsZWFzZSBTaWduaW5nIEtleSA8cHl0aG9uLW1w
    dkBqYXNlZy5kZT6IlgQTFggAPhYhBONvdTB/Cg7C0UX/XO16II7ux28tBQJeibj3
    AhsDBQkSzAMABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEO16II7ux28thRYA
    /3Yl1RdeUGor6K0RTxce9TIBB+DpLNupJgB9f6onuocpAQC614zQ/RQ6rkGTHCwA
    ElFClWRQ5eppj0jpAuH15udqAbg4BF6JuPcSCisGAQQBl1UBBQEBB0A0mrXSv6rj
    ajCmZR4H4OtowAx477YS+yWARqo1NtdgJwMBCAeIfgQYFggAJhYhBONvdTB/Cg7C
    0UX/XO16II7ux28tBQJeibj3AhsMBQkSzAMAAAoJEO16II7ux28tMZwBAIUpHHvP
    gRW2jQuzdw1r06kItfFk/0t+mgNUQ2+vtbhzAP98BoWx7lv+bvlIbBaVgLldusj0
    pHnZI/0y3ksMBkdbBw==
    =Mr6G
    -----END PGP PUBLIC KEY BLOCK-----
 About this site
 ---------------
 This site is made with the hugo static site generator. I made the theme myself, feel free to grab a copy at
 `git.jaseg.de <https://git.jaseg.de/blog.git/tree/themes/conspiracy?h=main>`__. The nifty auto-reflowing code embeds are
 made with some CSS magic I made that you can find in `style.css
 <https://git.jaseg.de/blog.git/tree/themes/conspiracy/assets/css/style.css?h=main&id=2fd22e30ce176d8d8a641fd371ad1623b082eaaf#n367>`__.
 The body text is typeset in Roboto Slab, created by `Christian Robertson <https://christianrobertson.com/>`__ while
 working at Google. The headlines are set in Nyght Serif, a font by `Maksym Kobuzan <https://linktr.ee/mkobuzan>`__.
 Check out their other fonts, their work is beautiful! Source code is typeset in Fira Code, a derivate by ... from
 Mozilla's `Fira Mono <https://github.com/mozilla/Fira>`__ font, designed by `Erik Spiekermann
 <https://spiekermann.com/>`__, `Ralph du Carrois <https://carrois.com/>`__, `Anja Meiners
 <https://anjameiners.com/de/hallo/>`__ and Botio Nikoltchev of Carrois Type Design, now succeeded by `bBoxType
 <https://bboxtype.com/typefaces/FiraMono/#!layout=specimen>`__ , and Patryk Adamczyk of Mozilla. The photo of mountains
 that's used in the background of this site is by `Fabrizio Conti <https://www.conti.photos/>`__ and can be found on
 `Unsplash <https://unsplash.com/photos/TUmjK7ZJgbI>`__.
--- a/content/blog/8seg/8seg-digit-circuit.png
+++ b/content/blog/8seg/8seg-digit-circuit.png
--- a/content/blog/8seg/index.rst
+++ b/content/blog/8seg/index.rst
@ -0,0 +1,203 @@
 ---
 title: "8seg Technical Overview"
 date: 2023-12-26T15:26:00+01:00
 summary: >
    8seg is a large-scale LED light art installation that displays text on a 1.5 meter high, 30 meter wide
    8-segment display made from cheap LED tape.
 ---
 Prologue
 --------
 German hacker culture has this intense love for things that light up in colorful ways. Like for many others in this
 community, I have always been fascinated by LEDs. One of the first things on my pile of unfinished projects was to build
 my own LED matrix and use it to display text. When I started that project, I was still new to electronics. Back then,
 commercial LED matrices were limited to red or green color only, and were very expensive, so there was an incentive to
 build your own. At the same time, while individual LEDs were'nt expensive anymore, they hadn't started to be cheap yet,
 either. On top of the material cost, back then there were no PCB fabs, and especially no PCB assembly houses that a
 hobbyist could afford. Ultimately, I ended up never finishing this project because I felt it was more of a feat of
 material wealth than of technical prowess.
 Over time, LEDs came down in price, and peoople started using them in all sorts of fun things. Around the mid-2010s,
 cheap-ish, ready-made tapes and chains of RGB LEDs that included WS2811 or similar digitally controllable driver chips
 led to a cambrian explosion in projects involving large amounds of colorful LEDs since suddenly, all you needed was an
 arduino and a beefy power supply to individually control an almost unlimited number of these LEDs.
 Today, LED technology has advanced even furhter, to a point where now you can buy staggering quantities of the second
 generation of these controllable LEDs that provides better color rendering embedded in all sorts of shapes, from tapes
 through rings to grids. When I built the first matelight_ in 2013, the matelight's 640 individually-controllable LEDs
 were *a lot*. Today, you can buy a roll with several thousand channels for about the price of a nice pizza.
 The idea behind 8seg
 --------------------
 Living through this amazing escalation of LED technology, in 2018, I looked at a then-obsolete piece of single-color,
 dumb, non-controllable LED tape with a simple question in mind: Taking this unsophisticated artifact of yesterday's
 technology, what would be the coolest thing I could build from it? Can I buld something that not only rivals, but
 outmatches the modern controllable LED stuff? From that question, I set myself two goals. First, I wanted to keep the
 project's use of financial and labor resources reasonable. A lot of art consists of taking a simple idea, and simply
 extrapolating its implementation to a ridiculous scale at the expense of the artist's time and wallet. That wasn't the
 point I wanted to make. I wanted to make something cool from an obsolete technology, not prove how much patience I had
 soldering. My second goal was to create something that is meaningfully controllable. Controllability is much harder with
 these dumb LED tapes, but it is possible nontheless, and I wanted to test out how far you could go with it.
 After thinking through a number of possibilities, I settled on the basics of the 8seg design I ended up realizing. The
 installation would be a banner-style display consisting of a series of characters made from non-controllable LED tape.
 The banner can be rigged up in any convenient air space, bending and folding to conform to the space's shape and size.
 The key idea behind 8seg is that it makes up for it's lack of control fidelity with sheer size. If nothing else, this
 non-controllable LED tape is *cheap*.
 The design of a single 8seg character
 -------------------------------------
 Each 8seg character consists of 8 *segments* of LED tape that are inter-connected through small circuit boards, four in
 the corners, and one in the center. As it turns out, 8 segments arranged in this shape are enough to display all of the
 English language's alphabet as well as numbers in a weird, but readable form.
 The electrical design of an 8seg character has one weird trick at its core. To avoid having to run a bunch of wires from
 some kind of driver circuit board to each of the eight segments, I thought, why not use the LED tape itself instead for
 power and data transmission? Wires are heavy, expensive, and annoying to solder, so if I could find a way to
 interconnect the LED tape so that it can all be driven from a driver circuit located at one of the character's
 junctions while simultaneously powering that driver circuit, an 8seg character wouldn't need any wires at all anymore.
 8seg achieves this feat using a circuit as shown in the diagram below. Interconnections between the LED tape segments
 are done with a small circuit board in each of the four corners. The design is rotationally symmetric, and all four of
 these boards are identicaly. The top right and bottom left corners simply use the back side of the same circuit board
 used in the top left and bottom right corners.
 .. image:: 8seg-digit-circuit.png
 The driver circuit sits at the center of the character and directly connects to the four diagonal segments. The key
 thought behind 8seg's driving scheme is that there are two common phases wound through the display in a zig-zag pattern
 as shown in red and blue in the schema below. These phases alternate their polarity at a high frequency. Each segment
 has its negative pole connected to one of these two phases, and can be turned on by the driver while that phase is low
 and the other phase is high. While a phase is high, the LEDs on all segments connected to that phase are reverse-biased,
 and thus these segments remain dark.
 The positive poles of all segments are connected to the driver circuit in the center through a spiral pattern. Each arm
 of the spiral is made up of two segments, one diagonal on the inside, and one horizontal or vertical on the outside.
 The two segments on each spiral arm are on different phases, one on each of the two phases. Thus, during a single cycle
 of the two phases alternating polarity, first one of the two segments has its polarity the right way around, then the
 other. The driver can turn on the active segment by connecting the spiral control line to the positive LED supply
 voltage. 
 Both phases cross at the center where the driver circuit is located, so the driver can power itself from the two phases
 using a simple full bridge rectifier.
 Saving copper with point of load regulation
 -------------------------------------------
 In the beginning, I experimented with the design above, putting 12V AC on the two phases, and letting the driver switch
 its derived LED supply using some cheap MOSFETs. This simple design totally works, but it has an important shortcoming.
 8seg is designed to be physically *very* large. This means that not only does it have a large number of LEDs that
 together need a lot of current, it also has to transmit all of that current across significant physical distances. The
 consequence of this was that in the initial design, I was looking at either needing hundreds of Euros worth of copper
 cables, or burning hundreds of Watts of electricity into heat if I were to use thinner cables. In this case, cables act
 like resistors. In a resistor, power dissipation rises with the square of the current inside the cable. This is bad for
 8seg since it means halving the amount of copper in those wires increases power dissipation in these wires fourfold.
 Despite that downside, this square law does come with an upside, too. If we assume we have wires of a particular fixed
 diameter, if we can halve the current through those wires, we can quarter the wires' power dissipation. If we want to
 deliver the same amount of power to the LEDs as before, to halve wire current, we have to double the voltage, and add
 some circuitry on the drivers to convert that increased voltage back down to close to our LED tape's nominal 12V.
 Alas, simply doubling the voltage leads to one question: How is it that we can pass double the voltage through our LED
 tape to the center control circuit? Isn't the LED tape made for 12V operation only, not 24V? The answer to this
 apparent problem is that the center is connected to the AC bus voltage only through the negative side of the LED tapes,
 and controls their positive sides to turn them on or off. The AC bus voltage never appears directly across any single of
 the eight segments. At the same time, a simple buck converter stepping down our new 24V bus voltage to 12V, and feeding
 the segment control transistors with that instead of feeding them straight from the rectified AC bus allows us to feed
 the segments with 12V. The only difference between this circuit and the straight 12V variant is that now, during OFF
 times, the LED tapes see a negative 24 v across them. To make sure that's not a problem, I tested a number of them with
 different LED colors and from different manufacturers, and all of them held up past the 50 V I could easily generate
 with my lab power supply.
 Synchronous rectification
 -------------------------
 I implemented the point-of-load regulation in a new revision of the center circuit, and built a prototype digit. When I
 tested this prototype, to my dismay, I noticed some really strange behavior. In my tests, the LED tape did not properly
 light up, and when I checked the voltages with my oscilloscope, I noticed that the center circuit's ground was floating
 several volts *below* the AC bus voltage's negative phase. How come?
 After some head-scratching, I found that this problem was due to a simple instance of Kirchhoff's current law. Consider
 the point where the AC bus voltage's currently negative phase enters the center circuit board. Let's say that we
 dissipate 24 Watts in the segments' LEDs. In this case, at 24 Volts, 1 Ampère will flow into the center circuit's
 terminal connected to the currently positive phase, and out from the center circuit's terminal connected to the
 currently negative phase.
 Now consider the current through the LED tape. During one half-cycle of the AC bus, the center circuit can only address
 the four segments that have their negative rail connected to the currently negative phase of the AC bus. If one of these
 four segments is currently on and dissipating our 24 Watts, that segment will be fed 2 Ampère of current from the center
 circuit through its positive rail. My mistake was that I did not consider what happened to the return current here.
 The corresponding 2 Ampère return current of course flows back through the segment's negative rail into the center
 circuit, and herein lies the issue: That negative rail is where our center circuit's supply current comes from! This
 means that according to Kirchhoff's current law, the 1 A flowing out from the center circuit at its input are adding up
 with the 2 A flowing into it. The result of this is that in the currently positive phase's connection, we get 1 A
 flowing into the center circuit, while in the negative phase connection, we get (-1) + (+2) resulting in another 1 A
 flowing into it! The only terminal where current flows *out* of the center circuit is the positive terminal connected to
 the active segment, out of which 2 A of current are flowing.
 The big problem with this confusing scenario is that this means the bridge recitifier in our center circuit cannot work,
 since its negative-side diodes are reverse biased while any of the segments are on. We can't just add more diodes here,
 since that would just short both AC bus rails together. Instead, the solution is to add one rather chonky MOSFET in
 parallel with each of the two negative-side diodes of the bridge rectifier that are controlled by the center circuit to
 act as a sort of synchronous rectifier. When we turn on one of the segments, we have to turn on the MOSFET on the
 currently negative rail to allow the segment's return current to bypass the bridge rectifier's negative-side diode. Fun
 fact: If we turn on the wrong MOSFET out of the pair, we short the AC bus, resulting in a very quick end of life for that
 poor MOSFET.
 Power line data communication
 -----------------------------
 As we saw above, the driver providing power to a string of digits has to continuously alternate the polarity of its
 output voltage to provide one part of the digit circuits' multiplexing. Since we want to provide the control information
 to the center circuits through those same two wires, we can choose between a number of viable power line communication
 schemes. These schemes usually require a beefy transmitter adding a modulation at a frequency much larger than the
 underlying bus frequency, and a filter circuit at each receiver to filter that signal from the much stronger fundamental
 AC waveform. In our application, I saw two issues with these classical approaches. First, they require fairly complex
 circuitry, especially the beefy transmitter at the driver. Second, they are susceptible to attenuation with either
 changing load or over long distances, which could potentially be a problem with the high currents and long(ish) wiring
 runs 8seg needs.
 Because of these disadvantages, I decided on another approach entirely. Instead of modulating our control signal on top
 of the AC power waveform, we modulate our control data *into* the AC power waveform. To not interfere with the display
 and cause outages or flicker, and to avoid having to blank the display during transmissions, we choose a modulating
 technique that leaves the proportions of negative and positive half-waves undisturbed. The practical realization of this
 is that instead of alternating positive and negative half-waves, we send a positive half wave for each "one" bit, and a
 negative half wave for each "zero" bit, effectively creating a phase shift keyed signal with two states with an
 180-degree phase shift, with the transmitted bit rate synchronized to twice the underlying carrier frequency.
 The remaining question is how one can encode arbitrary binary data into a continuous stream of ones and zeros that is
 precisely 50 % ones and 50 % zeros across any time span longer than a few dozen bits. There exists a near-optimal
 solution to this question from ethernet over copper twisted pairs. In ethernet, the encoded and modulated signal passes
 through an isolation transformer to protect the ethernet transceiver from interference or dangerous voltages coming in
 through the ethernet port. For this isolation transformer to work, the modulated ethernet signal must be exactly
 balanced to avoid saturating the transformer's core with a DC offset. Ethernet solves this issue by using an encoding
 known as `8b/10b encoding`_. 8b/10b encoding is named like that because it specifies a way to produce a 10 bit codeword
 from any 8 bit input data word while guaranteeing that the resulting codewords are always precisely balanced when
 looking at two or more consecutively.
 Framing
 -------
 Since 8b/10b encoding maps a space of 256 data words to 1024 code words, there necessarily are a number of unused code
 words. While for some of them, leaving them unallocated is beneficial because it improves error tolerance by decreasing
 the probability of one code word turning into another undetectably when a single one of its bits is flipped, even
 accounting for that it leaves some room for other uses. In 8b/10b, these leftover code words are used for synchronizing
 the receiver to the transmitter, and for framing transmissions. Synchronization is necessary for the receiver to know
 where a code word stards, and 8b/10b has a handful of special "comma" code words that can be uniquely identified in a
 continuous stream of received ones and zeros, because no other combination of 8b/10b code words could produce the same
 sequence of ones and zeros of the comma code word anywhere.
 The leftover code words that are not commas are useful, too. They can be used, for instance, as filler code words
 betwene actual data transmissions, or to act as framing markers denoting things like the end of a protocol message.
 The 8seg driver produces its modulation waveform by translating all data to be transmitted into 8b/10b codes, padding
 the result with framing markers and filler codes, and copy-pasting together the corresponding AC waveform from a small
 set of pre-programmed waveform transitions.
 .. _matelight: https://github.com/jaseg/matelight
 .. _`8b/10b encoding`: https://en.wikipedia.org/wiki/8b/10b_encoding
--- a/content/blog/_index.rst
+++ b/content/blog/_index.rst
@ -0,0 +1,3 @@
 ---
 title: Blog
 ---
--- a/content/blog/ashen-yanartas/ashen-logo-text-dark-plain.svg
+++ b/content/blog/ashen-yanartas/ashen-logo-text-dark-plain.svg
@ -0,0 +1,37 @@
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <!-- Created with Inkscape (http://www.inkscape.org/) -->
 <svg
   width="60mm"
   height="18mm"
   viewBox="0 0 60 18"
   version="1.1"
   id="svg1"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg">
  <defs
     id="defs1">
    <rect
       x="73.275604"
       y="7.5154462"
       width="82.669907"
       height="60.687229"
       id="rect1" />
  </defs>
  <g
     id="layer1"
     transform="translate(-60.324998,-47.365882)">
    <path
       id="path4-6"
       style="fill:#ececec;stroke-width:0.105392;stroke-linecap:round;stroke-linejoin:round;fill-opacity:1"
       d="m 69.324799,48.865886 a 7.5,7.5 0 0 0 -7.499801,7.499801 7.5,7.5 0 0 0 3.273185,6.195487 c -0.913481,-0.983452 -1.40067,-2.340488 -1.315165,-3.825089 0.198575,-3.447783 1.631942,-4.848283 1.631942,-4.848283 l 1.590084,3.588411 c -0.48406,-2.540144 -0.201121,-4.995971 2.766756,-8.596891 a 7.5,7.5 0 0 0 -0.447001,-0.01344 z m 1.328084,0.118339 c 0.310055,1.43067 1.013609,4.202913 2.107882,5.883879 1.029143,1.580919 1.930339,2.092129 1.865519,4.55166 -0.03918,1.486422 -0.657454,2.712199 -1.732194,3.542419 a 7.5,7.5 0 0 0 3.931026,-6.596496 7.5,7.5 0 0 0 -6.172233,-7.381462 z" />
    <text
       xml:space="preserve"
       transform="matrix(0.67004375,0,0,0.67004375,30.304048,47.575216)"
       id="text1"
       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:21.3333px;line-height:13.9843px;font-family:Equateur;-inkscape-font-specification:Equateur;text-decoration-color:#000000;writing-mode:lr-tb;direction:ltr;white-space:pre;shape-inside:url(#rect1);display:inline;fill:#f9f9f9;fill-opacity:1;stroke-width:0.755906;stroke-linecap:round;stroke-linejoin:round"><tspan
         x="73.275391"
         y="19.8411"
         id="tspan2">ashen</tspan></text>
  </g>
 </svg>
--- a/content/blog/ashen-yanartas/ashen-logo-text-light-plain.svg
+++ b/content/blog/ashen-yanartas/ashen-logo-text-light-plain.svg
@ -0,0 +1,37 @@
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <!-- Created with Inkscape (http://www.inkscape.org/) -->
 <svg
   width="60mm"
   height="18mm"
   viewBox="0 0 60 18"
   version="1.1"
   id="svg1"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg">
  <defs
     id="defs1">
    <rect
       x="73.275604"
       y="7.5154462"
       width="82.669907"
       height="60.687229"
       id="rect1" />
  </defs>
  <g
     id="layer1"
     transform="translate(-60.324998,-47.365882)">
    <path
       id="path4-6"
       style="fill:#000000;stroke-width:0.105392;stroke-linecap:round;stroke-linejoin:round"
       d="m 69.324799,48.865886 a 7.5,7.5 0 0 0 -7.499801,7.499801 7.5,7.5 0 0 0 3.273185,6.195487 c -0.913481,-0.983452 -1.40067,-2.340488 -1.315165,-3.825089 0.198575,-3.447783 1.631942,-4.848283 1.631942,-4.848283 l 1.590084,3.588411 c -0.48406,-2.540144 -0.201121,-4.995971 2.766756,-8.596891 a 7.5,7.5 0 0 0 -0.447001,-0.01344 z m 1.328084,0.118339 c 0.310055,1.43067 1.013609,4.202913 2.107882,5.883879 1.029143,1.580919 1.930339,2.092129 1.865519,4.55166 -0.03918,1.486422 -0.657454,2.712199 -1.732194,3.542419 a 7.5,7.5 0 0 0 3.931026,-6.596496 7.5,7.5 0 0 0 -6.172233,-7.381462 z" />
    <text
       xml:space="preserve"
       transform="matrix(0.67004375,0,0,0.67004375,30.304048,47.575216)"
       id="text1"
       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:21.3333px;line-height:13.9843px;font-family:Equateur;-inkscape-font-specification:Equateur;text-decoration-color:#000000;writing-mode:lr-tb;direction:ltr;white-space:pre;shape-inside:url(#rect1);display:inline;fill:#000000;fill-opacity:1;stroke-width:0.755906;stroke-linecap:round;stroke-linejoin:round"><tspan
         x="73.275391"
         y="19.8411"
         id="tspan2">ashen</tspan></text>
  </g>
 </svg>
--- a/content/blog/ashen-yanartas/index.rst
+++ b/content/blog/ashen-yanartas/index.rst
@ -0,0 +1,59 @@
 ---
 title: "Project Announcement: Ashen and Yanartas"
 date: 2026-05-31T08:00:00+02:00
 summary: >
    There are exciting things ahead for the next year: I have been granted funding by both nlnet and by prototype fund
    for open-source work on an open source hardware Hardware Security Module. As a vessel for this project, I created a
    consulting company, yasec.
 ---
 I'm currently in the last days of finishing my PhD (Dr.-Ing.) in Electrical Engineering. To make sure things don't get
 boring afterwards, I've been busy looking for new opportunities. As a result, there are exciting things ahead for the
 next year: I have been granted funding by both nlnet *and* by Prototype Fund for open-source work on an Open Source
 Hardware Hardware Security Module. As infrastructure for these projects, I created a consulting company, `yasec
 <https://yasec.de>`__.
 Prototype Fund supports Ashen, the OS for open-source HSMs
 ----------------------------------------------------------
 .. raw:: html
    <picture style="max-width: 10em; margin: 1em auto 1em auto">
      <source media="(prefers-color-scheme: light)" srcset="ashen-logo-text-light-plain.svg">
      <img src="ashen-logo-text-dark-plain.svg alt="Ashen project logo showing a stylized flame in a circle">
    </picture>
 Starting June 2026, I will be working on Ashen_, an open-source software stack that provides the operating system layer
 for open-source HSMs. The project is funded as part of `Prototype Fund`_'s Class 02.
 Compared to existing open-source HSM software that work at the application level and that don't
 consider physical attacks, this stack will provide the underlying operating system services to protect such systems from
 physical attacks. A key component of this stack will be a portable mechanism to connect hardware tamper sensors to a
 system. The stack will enable deterministic guarantees of the maximum latency until secrets are destroyed after a tamper
 alarm was raised.
 .. _Ashen: https://yasec.de/projects/ashen/
 .. _`Prototype Fund`: https://www.prototypefund.de/
 nlnet supports Yanartas, the OSHW HSM platform
 ----------------------------------------------
 After work on the Ashen software stack is completed, I will continue by creating Yanartas_, an Open Source Hardware
 design for a complete open-source Hardware Security Module that provides protection against advanced physical attacks
 using a security mesh based on the `Inertial HSM`_ technology I developed during my PhD. The design will be customizable
 to different use cases and payload sizes from microcontrollers to whole servers.
 .. _Yanartas: https://yasec.de/projects/yanartas/
 .. _`Inertial HSM`: https://tches.iacr.org/index.php/TCHES/article/view/9290
 Let's talk!
 -----------
 In case you're interested to talk about hardware security engineering or open-source hardware, feel free to reach out
 through email or on mastodon. The projects are in an early stage, and I'm looking both for collaborators for these
 projects, and for opportunities once these projects have been completed. At this time, I only have a small amount of
 spare capacity outside of these projects, but that will change with time. I'd love to hear about *your* projects and
 your needs for specialist work in case you're interested.
 Follow this blog's `RSS <https://jaseg.de/index.xml>`__ and follow me `on mastodon <https://chaos.social/@jaseg>`__ for
 updates!
--- a/content/blog/ashen-yanartas/yasec-logo-v1-dark-plain.svg
+++ b/content/blog/ashen-yanartas/yasec-logo-v1-dark-plain.svg
@ -0,0 +1,31 @@
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <!-- Created with Inkscape (http://www.inkscape.org/) -->
 <svg
   width="35mm"
   height="17.549mm"
   viewBox="0 0 35 17.549"
   version="1.1"
   id="svg1"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg">
  <defs
     id="defs1">
    <rect
       x="33.844814"
       y="193.19748"
       width="593.69446"
       height="361.01135"
       id="rect1" />
  </defs>
  <g
     id="layer1"
     transform="translate(-30.000001,-82.703)">
    <path
       style="font-size:21.3333px;line-height:13.9843px;font-family:Equateur;-inkscape-font-specification:Equateur;white-space:pre;fill:#e0e0e0;stroke-width:0.755906;stroke-linecap:round;stroke-linejoin:round"
       d="m 33.611037,211.68229 v 0.10667 h 3.583994 l 7.082656,-15.33865 1.87733,-0.55466 v -0.10667 h -5.503991 v 0.10667 l 2.111996,0.53333 -2.218663,6.82666 -3.135995,-6.84799 2.239997,-0.512 v -0.10667 h -6.549323 v 0.10667 l 1.68533,0.512 4.543993,9.66398 c -1.727997,2.816 -3.135995,4.416 -5.717324,5.61066 z m 14.762647,-5.11999 c 1.151998,0 1.834664,-0.74667 2.794662,-1.45067 0.277333,0.78934 0.853332,1.42934 1.642664,1.42934 1.087999,0 1.941331,-1.216 2.474663,-2.112 l -0.08533,-0.0853 c -0.256,0.256 -0.874665,0.76799 -1.237331,0.76799 -0.341333,0 -0.490666,-0.46933 -0.490666,-1.13066 v -5.63199 c 0,-1.408 -1.130665,-2.816 -2.51733,-2.816 -1.62133,0 -5.205325,1.94133 -5.205325,2.83733 0,0.66133 1.919997,1.81333 3.093329,2.368 l 0.08533,-0.10667 c -0.511999,-0.704 -1.045332,-1.83466 -1.045332,-2.53866 0,-0.896 0.895999,-1.536 1.727997,-1.536 1.066665,0 1.471998,1.024 1.471998,2.24 v 2.21866 l -4.906659,1.25867 c 0,0 -0.447999,0.85333 -0.447999,1.79199 0,1.68533 1.450664,2.496 2.645329,2.496 z m -0.362666,-3.05066 c 0,-0.384 0.08533,-0.85334 0.08533,-0.85334 l 2.986662,-1.13066 v 3.072 c -0.554666,0.31999 -0.981332,0.61866 -1.578664,0.61866 -0.895999,0 -1.493331,-0.704 -1.493331,-1.70666 z m 11.818665,3.09333 c 1.727997,0 4.053327,-1.088 4.053327,-3.37067 0,-0.95999 -0.405333,-1.91999 -1.535998,-2.47466 l -2.794662,-1.38666 c -0.725332,-0.36267 -1.194665,-0.832 -1.194665,-1.536 0,-0.896 0.746666,-1.62133 1.813331,-1.62133 1.578664,0 2.19733,1.62133 2.090663,3.11466 l 0.128,0.0427 1.301331,-2.88 c -0.639999,-0.49066 -2.090663,-0.87466 -3.199995,-0.87466 -1.770663,0 -3.839994,0.98133 -3.839994,3.22132 0,0.896 0.341333,1.92 1.450665,2.45333 l 2.794662,1.344 c 0.746666,0.36267 1.151998,0.85333 1.151998,1.55733 0,1.00267 -0.810665,1.83467 -1.919997,1.83467 -1.855997,0 -3.007995,-2.38933 -2.794662,-4.11733 l -0.106666,-0.0427 -1.514665,3.28533 c 0.810666,0.74667 2.709329,1.45067 4.117327,1.45067 z m 9.96266,0 c 2.111996,0 3.221328,-1.152 4.245326,-2.688 L 73.90967,203.8103 c -0.938666,0.96 -1.813331,1.42933 -2.922662,1.42933 -2.51733,0 -3.669328,-2.43199 -3.669328,-4.69332 0,-0.17067 0,-0.32 0.02133,-0.46933 l 6.186657,-0.68267 c 0,-2.09066 -0.725332,-3.83999 -3.157328,-3.83999 -2.346663,0 -4.415993,1.94133 -5.077325,4.37332 l -1.407998,0.384 0.02133,0.128 1.279998,-0.14933 c -0.08533,0.42666 -0.128,0.85333 -0.128,1.28 0,2.92266 1.855997,5.03466 4.735993,5.03466 z m -2.38933,-7.25333 c 0.256,-1.94133 1.194665,-3.02933 2.431996,-3.02933 0.895999,0 1.493331,0.93867 1.557331,1.92 z m 12.181323,7.25333 c 1.919997,0 3.498661,-1.00267 4.586659,-2.688 l -0.128,-0.10667 c -0.895998,0.896 -2.00533,1.42933 -3.221328,1.42933 -2.751996,0 -3.797327,-2.73066 -3.797327,-4.86399 0,-2.23999 1.173331,-3.98933 2.837329,-3.98933 1.130665,0 1.87733,0.98134 1.87733,2.176 0,0.832 -0.234666,1.77067 -0.511999,2.41066 l 0.106666,0.0853 c 0.810666,-0.85333 2.495996,-2.41067 2.495996,-3.456 0,-1.06666 -1.151998,-2.06933 -2.986662,-2.06933 -3.370661,0 -6.165323,2.41067 -6.165323,5.84533 0,2.87999 1.962663,5.22666 4.906659,5.22666 z"
       id="text1"
       transform="matrix(0.58740671,0,0,0.58740671,12.90413,-25.337712)"
       aria-label="yasec" />
  </g>
 </svg>
--- a/content/blog/ashen-yanartas/yasec-logo-v1-light-plain.svg
+++ b/content/blog/ashen-yanartas/yasec-logo-v1-light-plain.svg
@ -0,0 +1,31 @@
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <!-- Created with Inkscape (http://www.inkscape.org/) -->
 <svg
   width="35mm"
   height="17.549mm"
   viewBox="0 0 35 17.549"
   version="1.1"
   id="svg1"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg">
  <defs
     id="defs1">
    <rect
       x="33.844814"
       y="193.19748"
       width="593.69446"
       height="361.01135"
       id="rect1" />
  </defs>
  <g
     id="layer1"
     transform="translate(-30.000001,-82.703)">
    <path
       style="font-size:21.3333px;line-height:13.9843px;font-family:Equateur;-inkscape-font-specification:Equateur;white-space:pre;stroke-width:0.755906;stroke-linecap:round;stroke-linejoin:round"
       d="m 33.611037,211.68229 v 0.10667 h 3.583994 l 7.082656,-15.33865 1.87733,-0.55466 v -0.10667 h -5.503991 v 0.10667 l 2.111996,0.53333 -2.218663,6.82666 -3.135995,-6.84799 2.239997,-0.512 v -0.10667 h -6.549323 v 0.10667 l 1.68533,0.512 4.543993,9.66398 c -1.727997,2.816 -3.135995,4.416 -5.717324,5.61066 z m 14.762647,-5.11999 c 1.151998,0 1.834664,-0.74667 2.794662,-1.45067 0.277333,0.78934 0.853332,1.42934 1.642664,1.42934 1.087999,0 1.941331,-1.216 2.474663,-2.112 l -0.08533,-0.0853 c -0.256,0.256 -0.874665,0.76799 -1.237331,0.76799 -0.341333,0 -0.490666,-0.46933 -0.490666,-1.13066 v -5.63199 c 0,-1.408 -1.130665,-2.816 -2.51733,-2.816 -1.62133,0 -5.205325,1.94133 -5.205325,2.83733 0,0.66133 1.919997,1.81333 3.093329,2.368 l 0.08533,-0.10667 c -0.511999,-0.704 -1.045332,-1.83466 -1.045332,-2.53866 0,-0.896 0.895999,-1.536 1.727997,-1.536 1.066665,0 1.471998,1.024 1.471998,2.24 v 2.21866 l -4.906659,1.25867 c 0,0 -0.447999,0.85333 -0.447999,1.79199 0,1.68533 1.450664,2.496 2.645329,2.496 z m -0.362666,-3.05066 c 0,-0.384 0.08533,-0.85334 0.08533,-0.85334 l 2.986662,-1.13066 v 3.072 c -0.554666,0.31999 -0.981332,0.61866 -1.578664,0.61866 -0.895999,0 -1.493331,-0.704 -1.493331,-1.70666 z m 11.818665,3.09333 c 1.727997,0 4.053327,-1.088 4.053327,-3.37067 0,-0.95999 -0.405333,-1.91999 -1.535998,-2.47466 l -2.794662,-1.38666 c -0.725332,-0.36267 -1.194665,-0.832 -1.194665,-1.536 0,-0.896 0.746666,-1.62133 1.813331,-1.62133 1.578664,0 2.19733,1.62133 2.090663,3.11466 l 0.128,0.0427 1.301331,-2.88 c -0.639999,-0.49066 -2.090663,-0.87466 -3.199995,-0.87466 -1.770663,0 -3.839994,0.98133 -3.839994,3.22132 0,0.896 0.341333,1.92 1.450665,2.45333 l 2.794662,1.344 c 0.746666,0.36267 1.151998,0.85333 1.151998,1.55733 0,1.00267 -0.810665,1.83467 -1.919997,1.83467 -1.855997,0 -3.007995,-2.38933 -2.794662,-4.11733 l -0.106666,-0.0427 -1.514665,3.28533 c 0.810666,0.74667 2.709329,1.45067 4.117327,1.45067 z m 9.96266,0 c 2.111996,0 3.221328,-1.152 4.245326,-2.688 L 73.90967,203.8103 c -0.938666,0.96 -1.813331,1.42933 -2.922662,1.42933 -2.51733,0 -3.669328,-2.43199 -3.669328,-4.69332 0,-0.17067 0,-0.32 0.02133,-0.46933 l 6.186657,-0.68267 c 0,-2.09066 -0.725332,-3.83999 -3.157328,-3.83999 -2.346663,0 -4.415993,1.94133 -5.077325,4.37332 l -1.407998,0.384 0.02133,0.128 1.279998,-0.14933 c -0.08533,0.42666 -0.128,0.85333 -0.128,1.28 0,2.92266 1.855997,5.03466 4.735993,5.03466 z m -2.38933,-7.25333 c 0.256,-1.94133 1.194665,-3.02933 2.431996,-3.02933 0.895999,0 1.493331,0.93867 1.557331,1.92 z m 12.181323,7.25333 c 1.919997,0 3.498661,-1.00267 4.586659,-2.688 l -0.128,-0.10667 c -0.895998,0.896 -2.00533,1.42933 -3.221328,1.42933 -2.751996,0 -3.797327,-2.73066 -3.797327,-4.86399 0,-2.23999 1.173331,-3.98933 2.837329,-3.98933 1.130665,0 1.87733,0.98134 1.87733,2.176 0,0.832 -0.234666,1.77067 -0.511999,2.41066 l 0.106666,0.0853 c 0.810666,-0.85333 2.495996,-2.41067 2.495996,-3.456 0,-1.06666 -1.151998,-2.06933 -2.986662,-2.06933 -3.370661,0 -6.165323,2.41067 -6.165323,5.84533 0,2.87999 1.962663,5.22666 4.906659,5.22666 z"
       id="text1"
       transform="matrix(0.58740671,0,0,0.58740671,12.90413,-25.337712)"
       aria-label="yasec" />
  </g>
 </svg>
--- a/content/blog/css-only-code-blocks/index.rst
+++ b/content/blog/css-only-code-blocks/index.rst
@ -0,0 +1,209 @@
 ---
 title: "Code listings with nice line wrapping and line numbers from plain CSS"
 date: 2025-07-23T23:42:00+01:00
 summary: >
    Code listings in web pages are often a bit of a pain to use. Usually, they don't wrap on small screens. Also,
    copy-pasting code from a code listing often copies the line numbers along with the code. Finally, many
    implementations use heavyweight HTML and/or javascript, making them slow to render. For this blog, I wrote a little
    CSS hack that renders nice, wrapping code blocks with line continuation markers in plain CSS without any JS.
 ---
 Code listings in web pages are often a bit of a pain to use. Often, they don't wrap on small screens. Also, copy-pasting
 code from a code listing often copies the line numbers along with the code. Finally, many implementations use
 heavyweight HTML and/or javascript, making them slow to render (looking at you, gitlab).
 For this blog, I wrote an implementation that renders HTML code listings entirely without JavaScript, renders line
 numbers using plain CSS such that they don't get selected with the code, and that works with the browser to wrap in a
 natural way while still supporting the little line continuation arrows that are used to show that a line was soft
 wrapped in text editors.
 This blog is rendered as a static site using Hugo_ from a pile of RestructuredText_ documents. RestructuredText renders
 code listings using Pygments_ by default. Pygments hard-bakes the line numbers into the generated HTML, so I am using a
 `monkey-patched`_ hook that changes the line number rendering to just a bunch of empty ``<span>`` elements. The resulting
 HTML for a code block then looks like this:
 .. code:: html
    <pre class="code [language] literal-block">
        <span class="lineno"></span>
        <span class="line">
            <span class="[syntax highlight token]">The </span><span class="[other syntax highlight token]">code!<span>
        </span>
        <!-- ... repeat once for each source line. -->
    </pre>
 You can find the (rather short) source of the ``rst2html`` wrapper `below <#rst2html-wrapper>`_.
 The CSS
 -------
 This modified HTML structure of the code listing gets accompanied by some CSS to make it flow nicely. Here is a listing
 of the complete CSS controlling the listing. The only bit that isn't included here is the actual syntax styling rules
 for the pygments tokens.
 .. code:: css
    /*****************************************************/
    /* Code block formatting / syntax highlighting rules */
    /*****************************************************/
    .code {
        font-family: "Fira Code";
        font-size: 13px;
        text-align: left; /* Override default content "justify" alignment */
        white-space: pre-wrap;
        word-wrap: break-word;
        overflow-x: auto;
        display: grid;
        align-items: start;
        grid-template-columns: min-content 1fr;
    }
    .code > .line {
        padding-left: calc(2em + 5px);
        text-indent: -2em;
        padding-top: 2px;
        min-width: 15em;
    }
    /* Make individual syntax tokens wrap anywhere */
    .code > .line > span {
        overflow-wrap: anywhere;
        white-space: pre-wrap;
    }
    /* We render line numbers in CSS! */
    .code > .lineno {
        counter-increment: lineno;
        word-break: keep-all;
        margin: 0;
        padding-left: 15px;
        padding-right: 5px;
        overflow: clip;
        position: relative;
        text-align: right;
        color: var(--c-text-muted);
        border-right: 1px solid var(--c-fg-highlight);
        align-self: stretch;
    }
    /* We also handle line continuation markers in CSS. */
    .code > .lineno::after {
        position: absolute;
        right: 5px;
        content: "\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳";
        white-space: pre;
        color: var(--c-text-muted);
    }
    /* Insert the actual line number */
    .code > .lineno::before {
        content: counter(lineno);
    }
    .code::before {
        counter-reset: lineno;
    }
    .code .hll {}
    /* Following are about 50 lines that define the styling of each kind of pygments syntax highlight token. These lines
       all look like the following: */
    .code .c   { color: var(--c-text); font-weight: 400 } /* Comment */
 This CSS does a few things:
 1. It renders the ``<pre>`` code listing element using a two-column CSS ``display: grid`` layout. The left column is
    used for the line numbers, and the right column is used for the code lines.
 2. It numbers the lines using a `CSS Counter`_. CSS counters are meant for things like numbering headings and such, but
    they are a perfect fit for our purpose.
 3. It inserts the counter value as the line number into the ``<span class="lineno">`` element's ``::before``
    pseudo-element. A side effect of using the ``::before`` pseudo-element is that without doing anything extra, the
    line numbers will remain outside of the normal text selection so they will neither be highlighted when selecting
    listing content, nor will they be copied when copy/pasting the listing content.
 4. It inserts a string of ``"\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳"`` into the line number span's
    ``::after`` pseudo-element. This string evaluates to a sequence of unicode arrows separated by line breaks, and
    starting with an empty line. The ``::after`` pseudo-element is positioned using ``position: absolute``, and the
    parent ``<span class="lineno">`` has ``position: relative`` set. This way, the arrow pseudo-element gets placed on
    top of the lineno span without affecting the layout at all. By setting ``overflow: clip`` on the parent ``<span
    class="lineno">``, the arrow pseudo-element gets cut off vertically wherever the parent lineno element naturally
    ends.
 The line number span is inserted into the parent ``<pre>`` element's CSS grid using ``align-self: stretch``, which
 causes it to vertically stretch to fill the available space. Since the line number span only contains the line number,
 its minimum height is a single line. As a result, it will stretch higher only when the corresponding code line in the
 right grid column stretches vertically because of line wrapping. When that happens, part of the arrow pseudo-element
 starts showing through from behind the ``overflow: clip`` of the line number span, and one arrow gets rendered for each
 wrapped listing line.
 When the page is too narrow, we don't want the code listing's lines to wrapp into a column of single characters. To
 prevent that, we simply set a ``min-width`` on the ``<span class="line">`` in the right column, and set ``overflow-x:
 auto`` on the listing ``<pre>``. This results in a horizontal scroll bar appearing whenever the listing gets too narrow.
 You can try out the line wrapping by resizing this page!
 rst2html wrapper
 ----------------
 Here is the python ``rst2html`` wrapper that monkey-patches code rendering. I made hugo invoke this while building the
 page by simply overriding the ``PATH`` environment variable.
 .. code:: python
    #!/usr/bin/env python3
    # Based on https://gist.github.com/mastbaum/2655700 for the basic plugin scaffolding
    import sys
    import re
    import docutils.core
    from docutils.transforms import Transform
    from docutils.nodes import TextElement, Inline, Text
    from docutils.parsers.rst import Directive, directives
    from docutils.writers.html4css1 import Writer, HTMLTranslator
    class UnfuckedHTMLTranslator(HTMLTranslator):
        def __init__(self, *args, **kwargs):
            super().__init__(*args, **kwargs)
            self.in_literal_block = False
        def visit_literal_block(self, node):
            # Insert an empty "lineno" span before each line. We insert the line numbers using pure CSS in a ::before
            # pseudo-element. This has the added advantage that the line numbers don't get included in text selection.
            # These line number spans are also used to show line continuation markers when a line is wrapped.
            self.in_literal_block = True
            self.body.append(self.starttag(node, 'pre', CLASS='literal-block'))
            self.body.append('<span class="lineno"></span><span class="line">')
        def depart_literal_block(self, node):
            self.in_literal_block = False
            self.body.append('\n</span></pre>\n')
        def visit_Text(self, node):
            if self.in_literal_block:
                for match in re.finditer('([^\n]*)(\n|$)', node.astext()):
                    text, end = match.groups()
                    if text:
                        super().visit_Text(Text(text))
                    if end == '\n':
                        if isinstance(node.parent, Inline):
                            self.depart_inline(node.parent)
                        self.body.append(f'</span>\n<span class="lineno"></span><span class="line">')
                        if isinstance(node.parent, Inline):
                            self.visit_inline(node.parent)
            else:
                super().visit_Text(node)
    html_writer = Writer()
    html_writer.translator_class = UnfuckedHTMLTranslator
    docutils.core.publish_cmdline(writer=html_writer)
 .. _Hugo: https://gohugo.io/
 .. _RestructuredText: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
 .. _Pygments: https://pygments.org/
 .. _`monkey-patched`: https://en.wikipedia.org/wiki/Monkey_patch
 .. _`CSS Counter`: https://developer.mozilla.org/en-US/docs/Web/CSS/counter
--- a/content/blog/epa-sgd-crypto/index.rst
+++ b/content/blog/epa-sgd-crypto/index.rst
@ -0,0 +1,100 @@
 ---
 title: "75 Million Lives, Two Keys"
 date: 2025-01-05T23:42:00+01:00
 draft: true
 ---
 2025 has begun. In this new year, with its new national healthcare record system, the country of Germany will start one
 of the largest rollouts of a cryptographic system in history. While the system has received scrutiny as well as
 resulting harsh criticism from a number of parties ranging from NGOs to everyday civilians, the system has received
 surprisingly little attention from the academic applied cryptography crowd. Additionally, previous criticism of
 the system has largely revolved around organizational issues. While valid, we belive that some cryptographic issues at
 the core of the system have escaped attention unitl now. In particular, at the core of the system is a key escrow system
 that contains several questionable design choices and that in its overall design seems out of place in 2025.
 The aim of the system is to serve as a shared storage for all healthcare records of a person. In the system, a person's
 entire patient file with all documentation on the treatment process including test results, images and other raw data
 will be stored in something vaguely resembling cloud storage such that all healthcare providers that the person visits
 can access the entire file. This centralized, synchronized storage eliminates the need for transferring this data
 between hospitals and doctors offices by fax, mail or physical media as it was common practice until now. After a
 development and testing phase lasting approximately five years, the German government decided to roll out the system to
 everybody insured under Germany's mandatory national health insurance scheme, totalling approximately 75 million people,
 on January 15th 2025.
 In this article, we will give an overview of the system's cryptographic design before highlighting a few odd
 design choices that could amount to a viable attack vector to the powerful adversaies 
 ## Context and involved parties
 Germany has a national, mandatory health insurance system. The system is open to any permanent resident of the country
 irrespective of citizenship. The system is mandatory in that while residents can choose between a number of both
 publically owned as well as private healthcare providers, it is not possible to opt out of the system. The public health
 insurance providers cover approximately 90% of German residents. These providers are organized in an umbrella
 organization named "GKV Spitzenverband". The resposibility of this umbrella organization largely revolves around
 negotiating prices with pharmaceutical companies and with healthcare providers as a publically sanctioned cartel, but
 also includes the specification and operation of shared IT infrastructure for billing and data exchange between
 healthcare providers.
 While GKV Spitzenverband is the party that ultimately holds responsibility for the regulatory administration of national
 healthcare IT infrastructure, it has delegated large parts of both the technical specification of this infrastructure as
 well as its day-to-day operation to Gematik GmbH, a state-owned limited liability corporation created specifically for
 the purpose of developing and implementing national healthcare IT standards. The electronic healthcare record system we
 describe in this article was standardized and implemented by Gematik GmbH under the direction of GKV Spitzenverband.
 Healthcare providers in Germany need to be registered with GKV Spitzenverband to serve members of public health
 insurance providers. Since these public providers constitute approximately 90% market share, the vast majority of
 healthcare providers are registered this way.
 Before the new national health record system, a number of healthcare IT processes have already been standardized and
 implemented by the parties above. In particular, every insured person already owns a cryptographic smartcard that acts
 as their proof of identity when accessing healthcare services. On the other side of such transactions, healthcare
 providers are likewise identified by cryptographic smartcards. Until now, these cards were used to facilitate billing of
 services from healthcare providers to insurers and to transfer prescriptions from prescribing doctors to pharmacies.
 A central role in this existing infrastructure is assumed by VPN gateways that link healthcare providers to
 the centrally-run backend infrastructure. Gematik GmbH calls these devices "Konnektor". They are specially-built
 hardware devices that contain multiple smart cards to authenticate the VPN connection towards the backend, and besides
 acting as a standard VPN gateway for client applications in the healthcare provider's network to tunnnel their backend
 requests through, the Konnektors also perform cryptographic operations in some of Gematik GmbH's protocols, such as
 authenticating certain requests using signatures.
 ## Design principles
 The new health record system was built on top of the existing infrastructure described above. In particular, access to
 health records is managed through keys stored in the patient's and the healthcare provider's existing smartcards, and
 all backend communication is tunneled through the existing VPN. Access to the files is mediated through the healthcare
 provider's existing patient management software. While in early drafts of the system, access to healthcare records
 through the patient's smartcard was gated behind a PIN, the impracticality of making the entire patient populace
 remember PINs led the implementors to scrap this provision, meaning that the patient's smartcard is all a healthcare
 provider needs to access the patient's record.
 A critical cornerstone in the system's design is that the system's designers decided that a lost smartcard should not
 lead to any data loss. As a consequence of this decision, while some of the record's access keys are kept on the
 patient smartcard, in contravention to conventional smartcard designs the same keys are kept accessible in a centralized
 key escrow system named "Schlüsselgenerierungsdienst" and abbreviated as SGD. Furthermore, these keys are not generated
 on the smartcard either -- instead, the key escrow system generates these access keys, one copy of which is then
 transmitted and stored inside the smartcard.
 The system supports re-issuing a smartcard to gain access to a healthcare record. Since the record's privacy pivots on
 this process, the system incorporates some organziational countermeasures that aim to make it hard to gain access to a
 re-issued copy of a patient smartcard without the patient's help or otherwise multiple colluding parties.
 ## Cryptographic design
 ## The implied adversary model
 While Gematik GmbH publishes detailed specifications of the systems they standardize, these specifications and some
 associated implementation guidelines are about the extent of public information. Software implementations are being kept
 secret, and while standardization results are available, a large fraction of design rationale is discussed behind closed
 doors. From an academic perspective, the most glaring omission in Gematik GmbH's public documents is any definition of a
 threat model or an adversary model. As a result of this, we will deduce an adversary model below by contextualizing the
 published standards in the national healthcare setting. We will base our further analysis of the system on this
 adversary model.
 ## Previous reviews and audits of the system
 [0] https://www.destatis.de/DE/Themen/Arbeit/Arbeitsmarkt/Qualitaet-Arbeit/Dimension-2/krankenversicherungsschutz.html
--- a/content/blog/hsm-basics/index.rst
+++ b/content/blog/hsm-basics/index.rst
@ -0,0 +1,214 @@
 ---
 title: "Hardware Security Module Basics"
 date: 2019-05-17T15:29:20+08:00
 summary: >
    I gave a short introduction into Hardware Security Modules at our university workgroup, including an overview on
    interesting research directions.
 ---
 On May 17 2019 I gave a short presentation on the fundamentals of hardware security modules at the weekly seminar of
 Prof. Mori's security research working group at Waseda University. The motivation for this was that outside of low-level
 hardware security people and people working in the financial industry HSMs are not thought about that often. In
 particular most network or systems security people would not consider them an option. Also it could turn out to be
 really interesting to think about what could be done with an HSM in conjunction with modern cryptography (instead of
 just plain old RSA-OAEP and AES-CBC).
 `Click here to download a PDF with the slides for this talk. <mori_semi_hsm_talk_web.pdf>`__
 Ideas for research in HSMs
 ==========================
 Preparing for this talk brought me back to some research ideas I've been working on for a while now. Since I'm not sure
 I'll find the time to properly research this topic, I thought it would be great to write down some rought outlines first
 for future reference.
 The Problem with current HSM tech
 ---------------------------------
 Currently, HSMs are only used in certain specific niche applications such as certificate authority key management and
 financial transaction data handling. One key reason for this is that HSMs currently don't provide the affordances that
 would be needed for them to be adopted more widely by the cryptographic and security engineering community. As far as I
 can tell, the two core missing affordances are:
 1. To be more widely adopted, HSMs must become less expensive. Currently, they go for several tens of thousands of Euro,
   which puts them outside most budgets.
 2. To be more widely adopted, HSMs must provide the standardized programming interfaces familiar to cryptographic
   developers. Currently, every HSM vendor has their own custom cryptographic API and a developer will have to train on
   one specific vendor's tooling. Furthermore, any documentation of these internals is kept secret behind NDAs. This
   constitutes a high barrier to entry, decreasing adoption in particular with young developers accustomed to
   open-source ecosystems.
 Attacking cost of implementation
 --------------------------------
 The first issue can be addressed by simply creating a viable low-cost alternative. There is no fundamental technical
 reason for the high cost of HSMs. This cost is instead due to manufacturers trying to recoup their expenses for R&D as
 well as certification from the small volumes HSMs are sold in.
 Compared to system integration and certification the pure R&D cost of HSM defense mechanisms themselves is not too high
 in an academic context it should be feasible to develop a sort of HSM blueprint that can then be cheaply produced by
 anyone in need.  Since the application areas outlined here are far from the core business areas of the clients of
 established HSM vendors this would most likely not be a realistic threat to any established vendor's business and a
 co-existence of both should not pose any problems in the short term.
 Benefits of an academic HSM standard
 ------------------------------------
 Tackling the high cost of current HSM hardware with an open-source HSM blueprint would yield
 several academic advantages beyond cost reduction.
 1. An open-source blueprint could serve as an academic reference design to evaluate and compare other HSM designs
   against. For instance this would not only allow quantifying the effectiveness of academic security measures but also
   allow an evaluation of commercial HSMs.
 2. An open-source blueprint could stimulate academic research in this academically very quiet albeit commercially
   important area. This research would ultimately benefit everyone employing HSMs by raising security standards in the
   field. Since HSMs are never solely relied upon for overal system security both defensive and offensive security
   research would yield these benefits.
 3. An open-source blueprint would encourage new people to get into the field and both apply HSMs to practical problems
   as well as improve HSMs themselves. Currently, this is highly discouraged due to the strictly proprietary nature of
   all available systems.
 4. Finally, developing an open-source HSM blueprint might yield new findings in adjacent academic areas due to the
   hightly multi-disciplinary nature of security research in general and HSM design in particular.
 Scope of an academic HSM standard
 ---------------------------------
 An academic HSM blueprint would need to be flexible so that researchers can adapt it to their particular problem. A
 modular architecture would lend itself to this flexibility. Fundamentally, there would be three components to this
 architecture. First, a **base** containing infrastructure such as the surveillance microcontroller, power supplies,
 power supply filtering and hardware DPA countermeasures, and possibly a standardized mechanical and electrical
 interface.
 Next to the base, a system integrator would put their *payload*. The nature of this payload is intentionally kept
 unspecified, and it might be anything from a cryptographic microcontroller to a small embedded system such as a
 raspberry pi single board computer. Keeping the *payload* open like this achieves two benefits: It gives the HSM
 blueprint's user *their* familiar tooling and the hardware *they* need, allowing fast adoption. Someone well-versed in
 e.g. Javascript could literally implement their cryptography in Javascript, run it on an off-the-shelf raspberry pi and
 just apply the HSM blueprint around it. In addition, keeping the *payload* open reduces the scope of what needs to be
 implemented. Building a general SDK on top of something like a bare ARM SoC such as a TI OMAP or a Freescale/NXP IMX
 would be a considerable additional burden, on top of the actual HSM design. Keeping the *payload* open allows research
 to concentrate on the actual point, the HSM design.
 The final and most important component would be a set of *security measures* that can be combined with the base to
 form the final HSM. Each of these *security measures* would entail a detailed specification of its design, manufacture
 and security properties. These *security measures* could be simple things like tamper switches or potting, but could
 also be complex things like security meshes.
 Given these three components -- *base*, *payload* and *security measures* as detailed specifications any engineer should
 be able to design and manufacture a HSM customized to their needs. Unifying these three components within the HSM
 blueprint would be a set of reference designs. Each reference design would implement a particular parametrization of the
 three architectural components with a physical hole cut out where the payload would go..  These reference designs would
 for one serve to guide any implementer on the customization and integration of their own derivation from the blueprint.
 In addition it would serve as an extremely simple, low-cost point of entry into the ecosystem. A curious researcher
 could simply replicate the reference design and put their existing payload inside.  Practically this might mean e.g. a
 researcher having PCBs produced according to the design files for a reference design for a mesh-based HSM, producing
 their own mesh, physically glueing a raspberry pi SBC into the middle of it, and potting the resulting system. Given the
 ease of prototype PCB fabrication today this would realistically allow evaluation of HSM technologies on a budget that
 is orders of magnitude less than the cost of current HSMs.
 Research ideas for tamper detection mechanisms
 ==============================================
 The core component of an HSM blueprint would be a suite of tamper detection mechanisms. Following are a few ideas on how
 to improve on the current state of the art of membrane tamper switches plus temperature sensors plus PCB and printed
 security meshes plus potting.
 DIY or small lab mesh production
 --------------------------------
 **Analog sensing** meshes are a proven technology where instead of just monitoring for continuity and shorts, analog
 parameters of the mesh traces such as inductance and mutual capacitance are monitored. In 2019, `Immler et al. published
 a paper <https://tches.iacr.org/index.php/TCHES/article/view/7334>`__ where took this principle and turned it all the
 way up. They directly derived a cryptographic secret from the analog properties of their HSM's security mesh in an
 attempt to built a `Physically Unclonable Function, or PUF
 <https://en.wikipedia.org/wiki/Physical_unclonable_function>`__. The idea with PUFs is that they reproduce some entropy
 that comes from random tolerances of their production process. The same PUF will always yield (approximately) the same
 key, but since you cannot control these random production variations, in practice the resulting PUF cannot be cloned.
 Note however, that its secrets can of course be copied if you find a way to read them out.
 As Immler et al. demonstrated in their paper, you don't need any secret sauce to create an analog mesh sensing circuit.
 All you need are a bunch of (admittedly, expensive) off-the-shelf analog ICs. The interesting bit here is that by
 applying more advanced analog sensing, weaknesses of an otherwise coarse mesh desing could maybe be alleviated. That is,
 instead of monitoring a very fine mesh for continuity, you could instead closely monitor inductance and capacitance of a
 more coarse mesh. This trade-off between sensing circuit complexity (resp. cost) and mesh production capabilities may
 allow someone with a poorly equipped lab to still make a decent HSM. The question is, how do you produce a "decent" mesh
 given only basic tools? Here are some ideas.
 **3D metal patterning techniques** refers to any technique for producing thin, patterned metal structures on a
 three-dimensional plastic substrate. The basic process would consist of 3D-printing the polymer substrate, depositing a
 thin metal layer on top and then patterning this metal layer. A good starting point here would be the recent work of
 `Ben Kraznow`_ on this exact thing.
 **Copper filament methods** would be any method embedding copper wire from a spool in some resin or other matrix. This
 could mean either of a systematic approach of carefully winding or folding the copper wire into patterns or a
 non-systematic approach of simply stuffing a large tangle of copper wire into a small space. The main challenge with the
 former would be to find a non-tedious way of production. The main challenge with the latter would be to find process
 parameters that guarantee complete coverage of the HSM without holes or other areas of lower sensitivity to intrusions.
 Both approaches would require careful consideration of the overall design including the polymer resin supporting
 structure to ensure sensitivity against attacks since copper wire is mechanically much stronger than the micrometre-thin
 metal coatings used in patterning techniques.
 Envelope measurement
 --------------------
 Finally, I think there is another set of currently under-utilized tamper-detection methods that would be very
 interesting to explore. I am not aware of an academic term for these, so I am just going to dub them *envelope
 measurement* here.
 The fundamental apporach of a mesh is to build a physical security envelope (the mesh) that physically detects when it
 is disturbed (open or short circuits). This approach works well but has the disadvantage that these meshes are rather
 complex to manufacture since effectively every part of them is acting as a sensing element. A conceptually more complex
 but in practice potentially simpler approach might be to split the functions of security envelope and sensing element.
 This would mean that in place of the mesh, some form of passive element such as metal foil forms the security envelope
 which is then checked for tampering using a very sensitive sensor inside. This remote-sensing approach might simplify
 the manufacture of the envelope itself and thus yield a design that is more easily customized. Following are a few ideas
 on how to approach this envelope measurement problem.
 **Ultrasonic** If the HSM is potted, a few ultrasonic transducers could be added inside the potting. With several
 transducers, any one could be used to transmit ultrasound while the others measure complex phase and energy of the
 signal they receive. The circuitry for this could be made fairly simple if using a static transmit frequency  or a low
 chirp rate by using a homodyne receiver built around a comparator fed into some timers. This approach would likely
 detect any mechanical attack and would also rule out chemical attacks involving liquids (though starting from which
 amount of liquid depends on receiver sensitivity). The main disadvantages might be high power consumption and cost and
 size of the ultrasonic transducers. Traditional cheap transducers made for air as a transmission medium are fairly large
 and might not adequately couple into potting compound. If somehow one could convince a standard small piezo element to
 do the same job that would be great as far as cost and size are concerned. A concern in some fringe use cases might be
 suceptibility to ambient noise, though this could easily be reduced at the expense of space and heat dissipation
 capacity by adding sound dampening on the outside. A likely attack vector against this approach might be using a laser
 cutter to drill a hole through the potting compound, then inserting probes carefully chosen to not couple too much
 to the potting compound ultrasonically.
 **Light** In either an unpotted HSM or one potted with a transparent (at some wavelengths) potting compound one could
 embed LEDs and photodiodes in a similar setup to the ultrasonic setup described above. In contrast to the ultrasound,
 the LEDs would literally have to light up the HSM's interior and shadows might be an issue since the HSM is likely some
 flat rectangular shape. A possible solution to this would be to coat both the embedded payload and the lid with some
 highly reflective paint such as some glossy silver paint or simple white paint. The basic approach might be as simple as
 simply turning on several LEDs distributed throughout the HSM in turn and measuring amplitude at several photodetectors,
 or as complex as doing a LIDAR-like phase measurement sweeping through a range of frequencies to determine not only
 absorption but also phase/distance characteristics between emitter LED and detector photodiode. Using some high-gain TIA
 along with a homodyne detector (lock-in amplifier) and changing emitter intensity, very precise measurements of both
 absorption and phase might be possible, as might be measurements through almost opaque, diffuse potting compounds such
 as a grey epoxide resin. The main disadvantages of this method would likely be the need to thoroughly light-proof the
 entire HSM (likely by wrapping it in metal foil) and the potentially high cost of transmitter and receiver circuitry
 (nice TIAs aren't cheap). To be effective against attacks using e.g. very fine drills and probes the system would likely
 have to be very sensitive.
 **Radar** Finally, one could turn to standard radar techniques to fingerprint the inside of the HSM. The goal here would
 be fingerprinting instead of mapping since only changes need to be detected. In this approach one could use homodyne
 detection to improve sensitivity and reduce receiver complexity, and sweep frequencies similar to an FMCW radar (but
 probably without exploiting the self-demodulation effect). Besides high cost, this approach has two disadvantages.
 First, such a system would likely not go beyond 24GHz or maybe 40GHz due to component availability issues. Even at 40GHz
 the wavelength in the potting compound would be in the order of magnitude of several millimeters. Fine intrusions using
 some tool chosen to not interact too much with the EM field inside the HSM such as a heated ceramic needle or simply a
 laser cutter might not be detectable using this approach. In any case, this system would certainly not be able to detect
 small holes piercing the HSM enclosure. The HSM enclosure would have to be made into an RF shield, likely by using some
 metal foil in it.
 Overall in the author's opinion these three techniques are most promising in order *Light*, *Ultrasonic*, *Radar*. Light
 would prbably provide the best sensitivity at expense of some cost. Ultrasonic might be used in conjunction with light
 to cover some additional angles since it is potentially very low-cost. Radar seems hard to engineer into a solution that
 works reliably and also would likely be at least an order of magnitude more expensive than the other two technologies
 while not providing better sensitivity.
 .. _`Ben Kraznow`: https://www.youtube.com/watch?v=Z228xymQYho
 .. _affordances: https://en.wikipedia.org/wiki/Affordance
--- a/content/blog/hsm-basics/mori_semi_hsm_talk_web.pdf
+++ b/content/blog/hsm-basics/mori_semi_hsm_talk_web.pdf
--- a/content/blog/ihsm-worlds-first-diy-hsm/index.rst
+++ b/content/blog/ihsm-worlds-first-diy-hsm/index.rst
@ -0,0 +1,44 @@
 ---
 title: "New Paper on Inertial Hardware Security Modules"
 date: 2021-11-23T23:42:20+01:00
 summary: >
    Paper announcement: We have published a paper on how you can DIY a tamper-sensing hardware security module from any
    single-board computer using a moving tamper-sensing mesh made from cheap PCBs.
 ---
 World's First DIY HSM
 =====================
 Last week, Prof. Dr. Björn Scheuermann and I have `published our first joint paper on Hardware Security Modules
 <https://tches.iacr.org/index.php/TCHES/article/view/9290>`__. In our paper, we introduce Inertial Hardware Security
 Modules (IHSMs), a new way of building high-security HSMs from basic components.  I think the technology we demonstrate
 in our paper might allow some neat applications where some civil organization deploys a service that no one, not even
 they themselves, can snoop on. Anyone can built an IHSM without needing any fancy equipment, which makes me optimistic
 that maybe the ideas of the `Cypherpunk movement <https://www.activism.net/cypherpunk/manifesto.html>`__ aren't obsolete
 after all, despite even the word "crypto" having been co-opted by radical capitalist environmental destructionists.
 An IHSM is basically an ultra-secure enclosure for something like a server or a raspberry pi that even someone with
 unlimited resources would have a really hard time cracking without destroying all data stored in it. The principle of an
 IHSM is the same as that of a `normal HSM`_. You have a payload that contains really secret data. There's really no way
 to prevent an attacker with physical access to the thing from opening it given enough time and abrasive discs for their
 angle grinder. So what you do instead is that you make it self-destruct its secrets within microseconds of anyone
 tampering with it. Usually, such HSMs are used for storing credit card pins and other financial data. They're expensive
 as fuck, all the while being about the same processing speed as a smartphone.  Traditional HSMs use printed or
 lithographically patterned conductive foils for their security mesh. These foils are not an off-the-shelf component and
 are made in a completely custom manufacturing process. To create your own, you would have to re-engineer that entire
 process and probably spend some serious money on production machines. 
 Inertial HSMs take the concept of traditional HSMs, but replace the usual tamper detection mesh with a few security mesh
 PCBs. These PCBs are coarser than traditional meshes by orders of magnitude, and would alone not even be close to enough
 to keep out even a moderately motivated attacker. IHSMs fix this issue by spinning the entire tamper detection mesh at
 very high speed.  To tamper with the mesh, an attacker would have to stop it. This, in turn, can be easily detected by
 the mesh's alarm circuitry using a simple accelerometer as a rotation sensor.
 In our paper, we have shown a working prototype of the core concepts one needs to build such an IHSM.  To build an IHSM
 you only need a basic electronics lab. I built the prototype in our paper at home during one of Germany's COVID
 lockdowns.  You can have a look at our code and CAD on `my git <https://git.jaseg.de/ihsm.git>`__. What is missing right
 now is an integration of all of these fragments into something cohesive that an interested person with the right tools
 could go out and build. We are planning to release this sort of documentation at some point, but right now we are
 focusing our effort on the next iteration of the design instead. Stay tuned for updates ;)
 .. _`normal HSM`: {{<ref "blog/hsm-basics/index.rst">}}
--- a/content/blog/jupyterlab-notebook-file-oneliner/index.rst
+++ b/content/blog/jupyterlab-notebook-file-oneliner/index.rst
@ -0,0 +1,21 @@
 ---
 title: "Getting the .ipynb Notebook File Location From a Running Jupyter Lab Notebook"
 date: 2025-06-29T23:42:00+01:00
 summary: >
    If you need to get the path of the ipynb file in a running #Jupyter notebook, this one-liner will do the trick. It
    seems chatgpt is confused, and a bunch of other approaches on the web look fragile and/or unnecessarily complex to
    me.
 ---
 If you need to get the path of the ipynb file in a running #Jupyter notebook, this one-liner will do the trick. It seems
 chatgpt is confused, and a bunch of other approaches on the web look fragile and/or unnecessarily complex to me.
 .. code:: python
    import sys
    Path(json.loads(Path(sys.argv[-1]).read_bytes())['jupyter_session'])
 The way this works is that for each notebook, jupyter starts a python "kernel" process that actually runs the notebook's
 code. That kernel gets a json file with info on the notebook's location on the disk passed through its command line.
 Since we're running code in that exact python process, we can just grab that json file from sys.argv, and read it
 ourselves.
--- a/content/blog/kicad-mesh-plugin/images/anim.webp
+++ b/content/blog/kicad-mesh-plugin/images/anim.webp
--- a/content/blog/kicad-mesh-plugin/images/cells-0.svg
+++ b/content/blog/kicad-mesh-plugin/images/cells-0.svg
--- a/content/blog/kicad-mesh-plugin/images/cells-100.svg
+++ b/content/blog/kicad-mesh-plugin/images/cells-100.svg
--- a/content/blog/kicad-mesh-plugin/images/cells-25.svg
+++ b/content/blog/kicad-mesh-plugin/images/cells-25.svg
--- a/content/blog/kicad-mesh-plugin/images/cells-50.svg
+++ b/content/blog/kicad-mesh-plugin/images/cells-50.svg
--- a/content/blog/kicad-mesh-plugin/images/cells-75.svg
+++ b/content/blog/kicad-mesh-plugin/images/cells-75.svg
--- a/content/blog/kicad-mesh-plugin/images/grid-vis-plain.svg
+++ b/content/blog/kicad-mesh-plugin/images/grid-vis-plain.svg
--- a/content/blog/kicad-mesh-plugin/images/grid-vis.svg
+++ b/content/blog/kicad-mesh-plugin/images/grid-vis.svg
--- a/content/blog/kicad-mesh-plugin/images/kicad-mesh-outline.png
+++ b/content/blog/kicad-mesh-plugin/images/kicad-mesh-outline.png
--- a/content/blog/kicad-mesh-plugin/images/kicad-mesh-result-large.png
+++ b/content/blog/kicad-mesh-plugin/images/kicad-mesh-result-large.png
--- a/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings.png
+++ b/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings.png
--- a/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings2.png
+++ b/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings2.png
--- a/content/blog/kicad-mesh-plugin/images/maze_tiles.svg
+++ b/content/blog/kicad-mesh-plugin/images/maze_tiles.svg
--- a/content/blog/kicad-mesh-plugin/images/maze_tiles_plain.svg
+++ b/content/blog/kicad-mesh-plugin/images/maze_tiles_plain.svg
--- a/content/blog/kicad-mesh-plugin/images/modern_art.svg
+++ b/content/blog/kicad-mesh-plugin/images/modern_art.svg
--- a/content/blog/kicad-mesh-plugin/images/tiles-25-small.svg
+++ b/content/blog/kicad-mesh-plugin/images/tiles-25-small.svg
--- a/content/blog/kicad-mesh-plugin/images/traces-25-small.svg
+++ b/content/blog/kicad-mesh-plugin/images/traces-25-small.svg
--- a/content/blog/kicad-mesh-plugin/index.rst
+++ b/content/blog/kicad-mesh-plugin/index.rst
@ -0,0 +1,229 @@
 ---
 title: "Kicad Mesh Plugin"
 date: 2020-08-18T13:15:39+02:00
 summary: >
    I wrote a little KiCad plugin that you can use to create security meshes, heaters and other things where you need
    one or more traces cover the entire surface of a PCB. The plugin supports arbitrary PCB shapes, cutouts, and can
    route around existing footprints and traces on the PCB.
 ---
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/anim.webp" style="max-width: 20em">
    </figure>
 Tamper Detection Meshes
 =======================
 Cryptography is at the foundation of our modern, networked world. From email to card payment infrastructure in brick and
 mortar stores, cryptographic keys secure almost every part of our digital lives againts cybercriminals or curious
 surveillance capitalists. Without cryptography, many of the things we routinely do in our lives such as paying for
 groceries with a credit card, messaging a friend on `Signal <https://signal.org>`_ or unlocking a car with its keyfob
 would not be possible. The security of all of these systems in its core lies on the secrecy of cryptographic keys.
 Systems differ in what kind of keys they use, how often these keys are replaced and the intricacies of the cryptographic
 operations these keys fit into but all have in common that their security relies on keeping the keys secret.
 In practice, this secrecy has been implemented in many different ways. Mass-market software such as browsers or
 messenger apps usually relies on some operating system facility to tell the computer "*please keep this piece of memory
 away from all other applications*". While on desktop operating systems usually this does not provide much of a barrier
 to other programs on the same computer, on modern mobile operating systems this approach is actually quite secure.
 However, given sufficient resources no security is perfect. All of these systems can be compromised if the host
 operating system is compromised sufficiently, and for organizations with considerable resources a market has sprung up
 that offers turn-key solutions for all wiretapping needs.
 In some applications, this level of security has not been considered sufficient. Particularly financial infrastructure
 is such a high-profile target that a lot of effort has been put into the security of cryptographic implementations. The
 best cryptographic algorithm is useless if it is run on a compromised system (from that system's point of view anyway).
 One of the core cryptographic components in financial applications are smartcards like they are used as payment cards in
 most countries nowadays. These smartcards contain a small, specialized cryptographic microcontroller that is designed to
 be hard to tamper with. Though one of the design goals of the system is to reduce the amount of sensitive information
 stored on the card, things such as copying of a card can only be hindered by making the chip hard to read out.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/modern_art.svg" style="max-width: 20em">
    </figure>
 With smartcards being the means of choice on one side of the counter in electronic payments, on the other side of the
 counter a different technology prevails. Attacks on payment terminals are bound to have much more dire consequences than
 attacks on individual cards since one terminal might see hundreds of cards being read every day. For this reason, the
 level of attack countermeasures employed in these terminals is a considerable step up from bare smartcards. While a
 smartcard is made physically hard to tamper, it does not have a battery and it can only detect tampering once it is
 powered by a reader. This allows for well-equipped attackers to use tools such as Focused Ion Beam (FIB) workstations to
 circumvent the smartcard's defences while it is powered down, and then power up the card to carry out the actual attack.
 The answer to this problem in electronic payment infrastructure is called *Hardware Security Module*, or HSM. An HSM is
 similar to a smartcard in its function (cryptographic processing using keys that are meant to never leave the protection
 of the HSM). The one major between the two is that an HSM has its own battery and is continuously powered from its
 manufacture to the day it is scrapped. If the HSM looses power at any point in time, it uses a small amount of energy
 stored internally to securely wipe all cryptographic secrets from its memory within a few milliseconds.
 Being powered at all times allows the HSM to actively detect and respond to attacks. The most common way this is done is
 by wrapping the juicy secret parts in a foil or a printed circuit board that is patterned with a long and convoluted
 maze of wires, called a *mesh*. The HSM is continuously monitoring these wires for changes (such as shorts, breaks or
 changes in resistance) and will sound the alarm when any are detected. Practically, this presents a considerable hurdle
 to any attacker: They have to find a way to disable or circumvent the mesh while it is being monitored by the HSM.  In
 practice, often this is no insurmountable challenge but it again increases attack costs.
 DIY Meshes
 ==========
 Throughout my studies in security research I have always had an interest in HSMs. I have taken apart my fair share of
 HSMs and at this point, to understand the technology more, I want to experiment with building my own HSM. In last year's
 `HSM basics <{{<ref "blog/hsm-basics/index.rst">}}>`_ post I have lined out some ideas for a next generation design that
 deviates from the bread-and-butter apporoach of using a mesh as the primary security feature. Before embarking on
 practical experiments with these ideas, I want to first take a stab at replicating the current state of the art as best
 I can. State of the art meshes often use exotic substrates such as 3D plastic parts with traces chemically deposited on
 their surface or special flexible substrates with conductive ink traces. These technologies will likely be too
 cumbersome for me to implement myself only for a few prototypes, and industrial manufacturers will most likely be too
 expensive. Thus, I will concentrate on regular PCB technology for now.
 The idea of a mesh on a PCB is pretty simple: You have one or several traces that you try to cover every corner of the
 mesh PCB's area with. To be most effective, the traces should be as thin and as close together as possible. To increase
 the chances of a manipulation being detected, multiple traces can also be used that can then be monitored for shorts
 between them.
 While one can feasibly lay out these traces by hand, this really is an ideal application of a simple auto-router. While
 general PCB autorouting is *hard*, auto-routing just a few traces to approximate a space-filling curve is not. Since I
 am just starting out, I went with the simplest algorithmic solution I could think of. I first approximate the area
 designated to the mesh with a square grid whose cells are a multiple of my trace/space size. The mesh will only be drawn
 into grid cells that are fully inside the set boundaries. All cells outside or going across the border are discarded in
 this step.
 I decided to implement this auto-router in a KiCAD plugin. Though KiCADs plugin API is not the best, it was just about
 usable for this task.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/kicad-mesh-outline.png" alt="KiCAD showing an irregular board shape with rounded corners and
        indents. In the middle of the board there is a footprint for a 4-pin surface-mount pin header.">
        <figcaption>The process starts out with the mesh shape being defined inside KiCAD. The mesh's outline is drawn
        onto one of the graphical "Eco" layers. A footprint is placed to serve as a placeholder for the mesh's
        connections to the outside world. This footprint is later used as the starting point for the mesh generation
        algorithm.</figcaption>
    </figure>
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/grid-vis-plain.svg" alt="A vizualization of the grid fitting process. Over the mesh's irregular
        outline a grid is drawn. In this picture, all grid cells that are fully inside the grid are shown. Grid cells
        that overlap the mesh border are highlighted. Grid cells outside of the mesh border are not drawn.">
        <figcaption>A visualization of the grid fitting process. First, a grid large enough to contain the mesh border
        is generated. Then, every cell is checked for overlap with the mesh border area. If the cell is fully inside, it
        (yellow), it is considered in the mesh generation later. Cells outside (gray) or on the border (red) are
        discarded.</figcaption>
    </figure>
 After generating the grid, starting from the place I want to connect to the mesh, I walk the grid's cells one by one to
 generate a tree that covers the entire grid's area. To set the mesh's starting place I place a footprint on the board
 (dark gray in the picture above) whose designator I then tell my script. The tree generation algorithm looks like a
 depth-first search, except all checks are random. Depending on the level of randomness used at each step of the
 algorithm it yields more or less organized-looking results. Below are five example runs of the algorithm at differing
 levels of randomness with the cells colored according to their distance from the tree root. 0% randomness means that the
 algorithm is going to try cells in forward direction first on every step, and only then try out left and right. 100%
 means that on every step, the algorithm is choosing a new direction at random.
 .. raw:: html
    <div class="subfigure" data-pagefind-ignore>
        <figure>
            <img src="images/cells-0.svg" alt="a completely organized looking grid with spiral patterns all over.">
            <figcaption>0%</figcaption>
        </figure>
        <figure>
            <img src="images/cells-25.svg">
            <figcaption>25%</figcaption>
        </figure>
        <figure>
            <img src="images/cells-50.svg">
            <figcaption>50%</figcaption>
        </figure>
        <figure>
            <img src="images/cells-75.svg">
            <figcaption>75%</figcaption>
        </figure>
        <figure>
            <img src="images/cells-100.svg" alt="a completely random looking grid with cells aggregating into ireggular
            areas that look like paint splotches.">
            <figcaption>100%</figcaption>
        </figure>
    </div>
 After I have built this tree like you would do in a depth-first search, I draw my one or several mesh mesh traces into
 it. The core observation here is that there is only 16 possible ways a cell can be connected: It has four neighbors,
 each of which it can either be connected to or not, which results in 2^4 options. If you consider rotations and
 mirroring, this works out to rotations or mirrored versions of only six base tiles: The empty tile, a tile with all four
 sides connected, a straight through, a 90 degree bend, and a "T"-junction—see the illustration below.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/maze_tiles_plain.svg" style="max-width: 20em">
        <figcaption>
        There are six possible tile types in our connectivity graph inside its square tiling. This graphic illustrates
        all sixteen rotations of these with how they would look in a two-conductor mesh.
        </figcaption>
    </figure>
 After tiling the grid according to the key above, we get the result below.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/tiles-25-small.svg">
        <figcaption>
        An auto-routed mesh with traces colored according to tile types.
        </figcaption>
    </figure>
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/traces-25-small.svg">
        <figcaption>
        The same mesh, but with traces all black.
        </figcaption>
    </figure>
 Putting it all together got me the KiCAD plugin you can see in the screenshot below.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/kicad-mesh-settings2.png">
        <figcaption>
        The plugin settings window open.
        </figcaption>
    </figure>
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/kicad-mesh-result-large.png">
        <figcaption>
            After runing the plugin, the generated mesh looks like this in pcbnew.
        </figcaption>
    </figure>
 I am fairly happy with the result, but getting there was a medium pain. Especially KiCAD's plugin API is still very
 unfinieshed. It is hard to use, most parts are completely undocumented and if you use anything but its most basic parts
 things tend to break. One particular pain point for me was that after generating the mesh, the traces have been added to
 the board, but are still invisible for some reason. You have to save the board first, then re-load the file for them to
 become visible. Also KiCAD crashes whenever the plugin tries to remove a trace, so currently my workflow involves always
 making a copy of the board file first and treating mesh generation as a non-reversible finishing step. 
 `Check out the code on my cgit <https://git.jaseg.de/kimesh.git/tree/plugin/mesh_dialog.py>`_.
 .. ::
    .. raw:: html
        <figure data-pagefind-ignore>
            <img src="images/grid-vis-plain.svg" alt="">
            <figcaption></figcaption>
        </figure>
--- a/content/blog/kicoil-theory/header.png
+++ b/content/blog/kicoil-theory/header.png
--- a/content/blog/kicoil-theory/index.rst
+++ b/content/blog/kicoil-theory/index.rst
@ -0,0 +1,40 @@
 ---
 title: "The KiCoil Planar Coil Generator"
 date: 2025-12-31T13:15:39+02:00
 summary: >
    I wrote a layout tool generating planar coils that can handle spiral coils, toroidal coils, and hybrids in between
    the two.
 ---
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="header.png" style="max-width: 20em">
    </figure>
 A planar coil is a coil that is made from flat traces in some printing process like PCB or IC manufacturing, instead of
 being wound from wire. A few weeks ago, I needed one such planar coil that 
 Project State
 -------------
 Currently, circular coils are special cased. Their layouts are directly generated, without the use of polygon
 offsetting. Windings are efficiently approximated using circular arcs. The circular coil layout code is solid, and
 contains decent (albeit not infallible) parameter sanity checks. Its main limitation is that sometimes, clearances can
 be violated a bit.
 The arbitrary shape code path is less stable, and produces faulty output in some cases. The most common error is
 crossing traces near the first vertex of the polygon when the polygon has highly convex or concave parts. I'm still
 improving this code path, but as long as you check the output, any errors it produces should be easy to fix by hand.
 If you would like to contribute, I'd welcome any ideas on the arbitrary shape code path. I think there is no single
 optimal solution here, and a generic algorithm that can be adjusted to favor for instance shape accuracy versus winding
 smoothness would be nice.
 All project links are listed on `https://jaseg.de/projects/kicoil/ <https://jaseg.de/projects/kicoil/>`__. You can check
 out the code on my git at `https://git.jaseg.de/kicoil.git <https://git.jaseg.de/kicoil.git>`__. Issues are tracked on
 codeberg at `https://codeberg.org/jaseg/kicoil <https://codeberg.org/jaseg/kicoil>`__. The kicad addon can be installed
 from the KiCad plugin manager, and you can install the standalone kicoil python package `from PyPI
 <https://pypi.org/project/kicoil/>`__.
--- a/content/blog/led-characterization/images/daylight_spectrum_dvd.jpg
+++ b/content/blog/led-characterization/images/daylight_spectrum_dvd.jpg
--- a/content/blog/led-characterization/images/driver_ringing_strong.jpg
+++ b/content/blog/led-characterization/images/driver_ringing_strong.jpg
--- a/content/blog/led-characterization/images/driver_ringing_weak.jpg
+++ b/content/blog/led-characterization/images/driver_ringing_weak.jpg
--- a/content/blog/led-characterization/images/electronics_whole.jpg
+++ b/content/blog/led-characterization/images/electronics_whole.jpg
--- a/content/blog/led-characterization/images/hsv_cylinder.png
+++ b/content/blog/led-characterization/images/hsv_cylinder.png
--- a/content/blog/led-characterization/images/photodiode_sensitivity.svg
+++ b/content/blog/led-characterization/images/photodiode_sensitivity.svg
--- a/content/blog/led-characterization/images/preamp_back.jpg
+++ b/content/blog/led-characterization/images/preamp_back.jpg
--- a/content/blog/led-characterization/images/preamp_front.jpg
+++ b/content/blog/led-characterization/images/preamp_front.jpg
--- a/content/blog/led-characterization/images/preamp_schematic.jpg
+++ b/content/blog/led-characterization/images/preamp_schematic.jpg
--- a/content/blog/led-characterization/images/processed_plot_cheap_rgb.svg
+++ b/content/blog/led-characterization/images/processed_plot_cheap_rgb.svg
--- a/content/blog/led-characterization/images/raw_plot_cheap_rgb.svg
+++ b/content/blog/led-characterization/images/raw_plot_cheap_rgb.svg
--- a/content/blog/led-characterization/images/rgb_cube.svg
+++ b/content/blog/led-characterization/images/rgb_cube.svg
--- a/content/blog/led-characterization/images/spectrograph_step1_parts.jpg
+++ b/content/blog/led-characterization/images/spectrograph_step1_parts.jpg
--- a/content/blog/led-characterization/images/spectrograph_step2.jpg
+++ b/content/blog/led-characterization/images/spectrograph_step2.jpg
--- a/content/blog/led-characterization/images/spectrograph_step3.jpg
+++ b/content/blog/led-characterization/images/spectrograph_step3.jpg
--- a/content/blog/led-characterization/images/spectrograph_step4_complete.jpg
+++ b/content/blog/led-characterization/images/spectrograph_step4_complete.jpg
--- a/content/blog/led-characterization/images/zeus_hammer_breadboard.jpg
+++ b/content/blog/led-characterization/images/zeus_hammer_breadboard.jpg
--- a/content/blog/led-characterization/images/zeus_hammer_breadboard_original.jpg
+++ b/content/blog/led-characterization/images/zeus_hammer_breadboard_original.jpg
--- a/content/blog/led-characterization/images/zeus_hammer_schematic.jpg
+++ b/content/blog/led-characterization/images/zeus_hammer_schematic.jpg
--- a/content/blog/led-characterization/images/zeus_hammer_schematic_original.jpg
+++ b/content/blog/led-characterization/images/zeus_hammer_schematic_original.jpg
--- a/content/blog/led-characterization/index.rst
+++ b/content/blog/led-characterization/index.rst
@ -0,0 +1,510 @@
 ---
 title: "LED Characterization"
 date: 2018-05-02T11:18:38+02:00
 summary: >
    Recently, I have been working on a small driver for ambient lighting using 12V LED strips like you can get
    inexpensively from China. I wanted to be able to just throw one of these somewhere, stick down some LED tape, hook
    it up to a small transformer and be able to control it through Wifi. When I was writing the firmware, I noticed that
    when fading between different colors, the colors look *all wrong*! This observation led me down a rabbit hole of
    color perception and LED peculiarities.
 ---
 Preface
 -------
 Recently, I have been working on a `small driver`_ for ambient lighting using 12V LED strips like you can get
 inexpensively from China. I wanted to be able to just throw one of these somewhere, stick down some LED tape, hook it up
 to a small transformer and be able to control it through Wifi. When I was writing the firmware, I noticed that when
 fading between different colors, the colors look *all wrong*! This observation led me down a rabbit hole of color
 perception and LED peculiarities.
 The idea of the LED driver was that it can be used either with up to eight single-color LED tapes or, much more
 interesting, with up to two RGB or RGBW (red-green-blue-white) LED tapes. For ambient lighting high color resolution was
 really important so you could dim it down a lot without flickering. I ended up using the same driver stage I used in the
 `multichannel LED driver`_ project for its great color resolution and low hardware requirements.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/rgb_cube.svg" alt="An illustration of the RGB color cube.">
        <figcaption>An illustration of the RGB color cube.
            <a href="https://commons.wikimedia.org/wiki/File:RGB_color_cube.svg">Picture</a> by
            <a href="https://commons.wikimedia.org/wiki/User:Maklaan">Maklaan from Wikimedia Commons</a>,
            <a href="https://creativecommons.org/licenses/by-sa/3.0/">CC-BY-SA 3.0</a>
        </figcaption>
    </figure>
 To make setting colors over Wifi more intuitive I implemented support for HSV colors. RGB is fine for communication
 between computers, but I think HSV is easier to work with when manually inputting colors from the command line. RGB  is
 close to how most monitors, cameras and the human visual apparatus work on a very low level but doesn't match
 higher-level human color perception very well. When we describe a color we tend to think in terms of "hue" or
 "brightness", and computing a measure of those from RGB values is not easy.
 Colors and Color Spaces
 -----------------------
 `Color spaces`_ are a mathematical abstraction of the concept of color. When we say "RGB", most of the time we actually
 mean `sRGB`_, a standardized notion of how to map three numbers labelled "red", "green" and "blue" onto a perceived
 color. `HSV`_ is an early attempt to more closely align these numbers with our perception. After HSV, a number of other
 *perceptual* color spaces such as `XYZ (CIE 1931)`_ and `CIE Lab/LCh`_ were born, further improving this alignment.  In
 this mathematical model, mapping a color from one color space into another color space is just a coordinate
 transformation.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/hsv_cylinder.png" alt="An illustration of the HSV color space as a cylinder.">
        <figcaption>An illustration of the HSV color space as a cylinder.
            <a href="https://commons.wikimedia.org/wiki/File:HSV_color_solid_cylinder.png">Picture</a> by
            <a href="https://commons.wikimedia.org/wiki/User:SharkD">SharkD from Wikimedia Commons</a>,
            <a href="https://creativecommons.org/licenses/by-sa/3.0/">CC-BY-SA 3.0</a>
        </figcaption>
    </figure>
 CIE 1931 XYZ is much larger than any other color space, which is why it is a good basis to express other color spaces
 in. In XYZ there are many coordinates that are outside of what the human eye can perceive. Below is an illustration of
 the sRGB space within XYZ. The wireframe cube is (0,0,0) to (1,1,1) in XYZ.  The colorful object in the middle is what
 of sRGB fits inside XYZ, and the lines extending out from it indicate the space that can be expressed in sRGB but not in
 XYZ. The fat white curve is a projection of the *monochromatic spectral locus*, that is the curve of points you get in
 XYZ for pure visible wavelengths.
 As you can see, sRGB is *much* smaller than XYZ or even the part within the monochromatic locus that we can perceive. In
 particular in the blues and greens we loose *a lot* of colors to sRGB.
 .. raw:: html
    <figure data-pagefind-ignore>
        <video controls loop>
            <source src="video/sRGB.mkv" type="video/h264">
            <source src="video/sRGB.webm" type="video/webm">
            Your browser does not support the HTML5 video tag.
        </video>
        <figcaption>Illustration of the measured sRGB color space within XYZ. The thick, white line is the spectral
            locus.
            <a href="video/sRGB.mkv">mkv/h264 download</a> /
            <a href="video/sRGB.webm">webm download</a>
        </figcaption>
    </figure>
 The wrong colors I got when fading between colors were caused by this coordinate transformation being askew. Thinking
 over the problem, there are several sources for imperfections:
 * The LED driver may not be entirely linear. For most modulations such as PWM the brightness will be linear starting
  from a certain value, but there is probably an offset caused by imperfect edges of the LED current. This offset can be
  compensated with software calibration. I built a calibration setup for driver linearity in the `multichannel LED
  driver`_ project. Below are pictures of ringing on the edges of an LED driver's waveform.
 * The red, green and blue channels of the LEDs used on the LED tape are not matched.  This skews the RGB color space.
  In practice, the blue channel of my RGB tape to me *looks* much brighter than the red channel.
 * The precise colors of the red, green and blue channels of the LEDs are unknown. Though the red channel *looks* red, it
  may be of a slightly different hue compared to the reference red used in `sRGB`_ which would also skew the RGB color
  space.
 .. raw:: html
    <div class="subfigure" data-pagefind-ignore>
        <figure>
            <img src="images/driver_ringing_strong.jpg" alt="Strong ringing on the LED voltage waveform edge at about
            100% overshoot during about 70% of the cycle time.">
            <figcaption>The LED strip being at the end of a couple meters of wire caused extremely bad ringing at high
            driving frequencies.</figcaption>
        </figure>
        <figure>
            <img src="images/driver_ringing_weak.jpg" alt="Weak ringing on the LED voltage waveform edge at about 30%
            overshoot during about 20% of the cycle time.">
            <figcaption>Adding a resistor in front of the MOSFET gate to slow the transition dampened the ringing
            somewhat, but ultimately it cannot be eliminated entirely.</figcaption>
        </figure>
    </div>
 These last two errors are tricky to compensate. What I needed for that was basically a model of the *perceived* colors
 of the LED tape's color channels. A way of doing his is to record the spectra of all color channels and then evaluate
 their respective XYZ coordinates. If all three channels are measured in one go with the same setup the relative
 magnitudes of the channels in XYZ will be accurate.
 To map any color to the LEDs, the color's XYZ coordinates simply have to be mapped onto the linear coordinate system
 produced by these three points within XYZ. LEDs are mostly linear in their luminous flux vs. current characteristic so
 this model will be adequate. The spectral integrals mapping the channels' measured responses to XYZ need only be
 calculated once and their results can be used as scaling factors thereafter.
 Measuring the spectrum
 ----------------------
 In order to compensate for the cheap LED tape's non-ideal performance I had to measure the LED's red, green and blue
 channels' spectra. The obvious thing would be to go out and buy a `spectrograph`_, or ask someone to borrow theirs. The
 former is kind of expensive, and I did not want to wait two weeks for the thing to arrive. The latter I could probably
 not do every time I got new LED tape. Thus the only choice was to build my own.
 Luckily, building your own spectrometer is really easy. The first thing you need is something that splits incident light
 into its constituent wavelengths. In professional devices this is called the *`monochromator`_*, since it allows extraction
 of small color bands from the spectrum. The second thing is some sort of optics that project the incident light onto a
 screen behind the monochromator. In professional devices lenses or curved mirrors are used. In a simple homebrew job a
 pinhole as you would use in a `camera obscura`_ does a remarkably nice job.
 For the monochromator component several things could be used. A prism would work, but I did not have any. The
 alternative is a `diffraction grating`_. Professional gratings are quite specialized pieces of equipment and thus
 rather expensive. Luckily, there is a common household item that works almost as well: A regular CD or DVD. The
 microscopic grooves that are used to record data in a CD or DVD work the same as the grooves in a professional
 diffraction grating.
 Household spectra
 -----------------
 From this starting point, a few seconds on my favorite search engine yielded an `article by two researchers from the
 National Science Museum in Tokyo`_ providing a nice blueprint for a simple cardboard-and-DVD construction for use in
 classrooms. I replicated their device using a DVD and it worked beautifully. Daylight and several types of small LEDs I
 had around did show the expected spectra. Small red, yellow, green, and blue LEDs showed narrow spectra, daylight one
 continuous broad one, and white LEDs a continuous broad one with a distinct bright spot in the blue part. The
 single-color LED spectra are quite narrow since they are determined by the LED's semiconductor's band gap, which is
 specific to the semiconductor used and is quite precise. White LEDs are in fact a blue LED chip covered with a so-called
 *phosphor*. This phosphor is not elementary phosphorus but an anorganic compound that absorbs the LED chip's blue light
 and re-emits a broader spectrum of more yellow-ish wavelengths instead. The final LED spectrum is a superposition of
 both spectra, with some of the original blue light leaking through the phosphor mixing with the broadband yellow
 spectrum of the phosphor.
 .. raw:: html
    <div class="subfigure" data-pagefind-ignore>
        <figure>
            <img src="images/spectrograph_step1_parts.jpg">
            <figcaption>The ingredients. The cup of coffee and Madoka Magica DVD set are essential to the eventual
            function of the appartus.</figcaption>
        </figure>
        <figure>
            <img src="images/spectrograph_step2.jpg">
            <figcaption>Step 1: Cut to size and mark down all holes as described in <a
            href="http://www.candac.ca/candacweb/sites/default/files/BuildaSpectroscope.pdf">the manual</a></figcaption>
        </figure>
        <figure>
            <img src="images/spectrograph_step3.jpg">
            <figcaption>Step 2: Cut out all holes</figcaption>
        </figure>
        <figure>
            <img src="images/spectrograph_step4_complete.jpg">
            <figcaption>The finished result with the back side showing. The viewing window is on the bottom of the other
            side.</figcaption>
        </figure>
    </div>
 Now that I had a spectrograph, I needed a somewhat predictable way of measuring the spectrum it gave me.
 Measuring a spectrum
 --------------------
 Pointing a camera at the spectrograph would be the obvious thing to do. This produces pretty images but has one critical
 flaw: I wanted to acquire quantitative measurements of brightness across the spectrum. Since I don't have a precise
 technical datasheet specifying the spectral response of any of my cameras I can't compare the absolute brightness of
 different colors on their pictures. Some other sensor was needed.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/daylight_spectrum_dvd.jpg">
        <figcaption>The daylight spectrum as seen using a DVD as a grating.
            <a href="https://commons.wikimedia.org/wiki/File:SpectresSolaires-DVD.jpg">Picture</a> by
            <a href="https://commons.wikimedia.org/wiki/User:Xofc">Xofc from Wikimedia Commons</a>,
            <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC-BY-SA 4.0</a>
        </figcaption>
    </figure>
 Measuring light intensity
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 Looking around my lab, I found a bag of `SFH2701`_ visible-light photodiodes. Their
 datasheet includes their spectral response so I can compensate for that, allowing precise-ish absolute intensity
 measurements. Just like LEDs, photodiodes are extremely linear across several orders of magnitude. The datasheet of the
 classic `BPW34`_ photodiode shows that this photodiode's light current is exactly proportional to illuminance over at
 least three orders of magnitude. The `SFH2701`_ datasheet does not include a similar graph but its performance will be
 similar. The `SFH2701`_ photodiodes I had at hand were perfect for the job compared to the vintage `BPW34`_ since their
 active sensing area is really small (0.6mm by 0.6mm) compared to the BPW34 (a whopping 3mm by 3mm). If I were to use a
 `BPW34`_ I would have to insert some small apterture in front of it so it does not catch too broad a part of the
 spectrum at once. The `SFH2701`_ is small enough that if I just point it at the projected spectrum directly I will
 already get only a small part of the spectrum inside its 0.6mm active area.
 To convert the photodiode's tiny photocurrent into a measurable voltage I built another copy of the `transimpedance
 amplifier`_ circuit I already used in the `multichannel LED driver`_. A `transimpedance amplifier`_ is an
 amplifiert that produces a large voltage from a small current. The weird name comes from the fact that it works kind of
 like an amplified resistor (which can be generalized as an *impedance* electrically). Apply a current to a resistor and
 you get a voltage. A transimpedance amplifiert does the same with the difference that its input always stays at 0V,
 making it look like an ideal current sink to the connected current source.
 Transimpedance amplifiers are common in optoelectronics to convert small photocurrents to voltages. In this instance I
 built a very simple circuit with a dampened transimpedance amplifier stage followed by a simple RC filter for noise
 rejection and a regular non-inverting amplifier using another op-amp from the same chip to further boost the filtered
 transimpedance amplifier output. I put all the passives setting amplifier response (the gain-setting resistors and the
 filter resistor and capacitors) on a small removable adapter so I could easily change them if necessary. I put a small
 trimpot on the virtual ground both amplifers use as a reference so I could trim that if necessary.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/preamp_schematic.jpg" alt="A drawing of the photodiode preamplifier's schematic">
        <figcaption>The photodiode preamplifier schematic. Schematic drawn with an unlicensed copy of
        DaveCAD.</figcaption>
    </figure>
 Following are pictures of the preamplifier board. The connectors on the top-left side are two copies of the analog
 signal for the ADC and a small panel meter. The SMA connector is used as the photodiode input since coax cables are
 generally low-leakage and have built-in shielding. The circuit is powered via the micro-USB connector and the analog
 ground bias voltage can be adjusted using the trimpot.
 For easy replacement, all passives setting gain and frequency response are on a small, pluggable carrier PCB made from a
 SMD-to-DIP adapter.
 Flying-wire construction is just fine for this low-frequency circuit. In a high-speed photodiode preamp, the
 transimpedance amplifier circuit would be highly sensitive to stray capacitance, but we're not aiming at high speed
 here. 
 .. raw:: html
    <div class="subfigure" data-pagefind-ignore>
        <figure>
            <img src="images/preamp_front.jpg">
            <figcaption>The front side of the preamplifier board.</figcaption>
        </figure>
        <figure>
            <img src="images/preamp_back.jpg">
            <figcaption>The wiring of the photodiode preamp.</figcaption>
        </figure>
    </div>
 Given a way to measure intensity what remains missing is a way to scan a single photodiode across the spectrum.
 Scanning the projection
 ~~~~~~~~~~~~~~~~~~~~~~~
 A cheap linear stage can be found in any old CD or DVD drive. These drives use a small linear stage based on a
 stepper-driven screw to move the laser unit radially. Removing the laser unit and connecting a leftover stepper driver
 module I was left with a small linear stage with about 45 steps per cm without microstepping enabled. The driver I used
 was an `A4988`_ module that required at least 8V motor drive voltage. I used a small micro USB-input boost converter
 module to generate a stable 10V supply for the motor driver, with the USB's 5V rail used as a logic supply for the motor
 driver.
 The `SFH2701`_ can easily be mounted to the linear stage using a small SMD breakout board glued in place with thin wires
 connecting it to the transimpedance amplifier. The DVD drive linear stage is not very strong so it is important that
 this wire does not put too much strain on it.
 Above the photodiode, I mounted a small piece of paper on the linear stage to be used as a projection screen to align
 the linear stage in front of the spectrometer viewing window. A line on the screen paper points to the photodiode die in
 parallel to the linear stage allowing precise alignment.
 The whole unit with photodiode preamplifier, linear stage, photodiode and stepper motor driver finally looks like this:
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/electronics_whole.jpg" alt="The complete electronics setup of the spectrograph. In the back
        there is the DVD drive stepper stage. In front of it, mounted on a piece of wood are a small USB-to-12V
        switching-regulator module to power the stepper motor in the top left, below on the bottom left is the
        photodiode preamp and on the right is a breadboard with the stepper driver module and lots of jumper wires
        interconnecting everything. On the right of the breadboard, a buspirate is attached to interface everything to a
        computer. On the bottom edge of the piece of wood, two LED panel meters are mounted for readout of the preamp
        output and the stepper supply voltages.">
        <figcaption>The complete electronics setup. The buspirate on the right interfaces to a computer and controls the
        stepper driver and ADC'es the preamp output. The two panel meters show the preamp output and stepper voltage for
        setup.</figcaption>
    </figure>
 The projection of the spectrum can be adjusted by moving the light source relative to the entry slot and by moving
 around the grating DVD.
 The capture process
 ~~~~~~~~~~~~~~~~~~~
 To capture a spectrum, first the light source has to be mounted near the spectrograph's entry slot. The LED tape I
 tested I just taped face-down directly into it. Next, the grating DVD has to be adjusted to make sure the spectrum
 covers a sensible part of the photodiode's path. Mostly, this boils down to adjusting the photodiode distance and height
 to match the vertical extent and wiggling the grating DVD to adjust the projection's horizontal position.
 After the optics are set-up, the photodiode preamplifier has to be adjusted. In my experiments, most LED tape at 5GΩ
 required a high-ish amplification. The goal in this step is to maximize the peak response of the preamp  to be just
 shy of its VCC rail to make best use of its dynamic range. To adjust the pre-amp, I took several very coarsely-spaced
 measurements to give me an estimate of the peak while I did not yet know its precise location.
 Since stray daylight totally swamped out the weak projection of the LED's spectrum I shielded the entire setup with a
 small box made of black cardboard and two black t-shirts on top. This shielding proved adequate for all my measurements
 but I had to be careful not to accidentially move the DVD that was stuck into the spectrograph with the shielding
 t-shirts.
 For capturing a single spectrum I wrote a small python script that will automatically move the stepper in adjustable
 intervals and take two measurements at each point, one with the LED tape off that can be used for offset calibration and
 one with the LED tape on. All measurements are stored in a sqlite database that can then be accesssed from other
 scripts.
 I built a small script that shows the progress of the current run and an jupyter notebook for data analysis. The jupyter
 notebook is capable of live-updating a graph with the in-progress spectrum's data. This was quite useful as a sanity
 check for when I made some mistake easy to spot in the resulting data.
 After one color channel is captured, the LED tape has to be manually set to the next color and the next measurement can
 begin.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/raw_plot_cheap_rgb.svg" alt="A plot with three wide peaks, two large peaks on both sides and
        one smaller one in the middle. The middle one overlaps the two on the sides. The large ones are about 2.5V in
        amplitude. Overall, the plot is about 300 stepper steps wide with each peak being around 130 steps wide.">
        <figcaption>A plot of the raw preamp output voltage versus stepper position. From left to right, the three peaks
        are blue, green and red. Step 0 corresponds to the bottommost stepper position and the shortest wavelength.
        </figcaption>
    </figure>
 Data analysis
 ~~~~~~~~~~~~~
 Data analysis consists of three major steps: Offset- and stray light removal, wavelength and amplitude calibration and
 color space mapping.
 Offset removal
 **************
 The first task is to remove the offset caused by dark current as well as stray light of the LED's bright primary
 reflection on the DVD. The LED is very bright and only a small part of its light gets reflected by the grating towards
 the photodiode screen. The remaining part of the light is reflected onto the table in front of the DVD spectrograph.
 Though I covered all of this with black cardboard, some of that light ultimately gets reflected onto the photodiode.
 This causes a large offset, in particular in the blue part of the spectrum since in this part the photodiode is closest
 to the spectrograph's opening.
 The composite offset can be approximated with a second-order polynomial that is fitted to all the data outside of the
 main peak's area. Since at this point the wavelength of each data point is still unknown this is done with a rough first
 estimate of the three colors' peaks' locations and widths.
 Wavelength- and amplitude calibration
 *************************************
 The photodiode's response is strongly wavelength-dependent. In particular in the blue band, the photodiode's sensitivity
 gets very poor down to about 20% at the edge to ultraviolet. This effect is strong enough to move the apparent location
 of the blue peak towards red.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/photodiode_sensitivity.svg" alt="A plot of photodiode sensitivity against wavelength relative
        to peak sensitivity at 820nm.  The sensitivity rises from 20% at 380nm approximately linearly to 80% at 620nm,
        then the rise rolls off.">
        <figcaption>A plot of the photodiode's relative sensitivity in the visible spectrum. The sensitivity is
        normalized against its peak at 820nm.
        </figcaption>
    </figure>
 The problem is that in order to remove this non-linearity, we would already have to know the wavelength of the measured
 light. Since I don't, I settled for a two-step process. First, a coarse wavelength calibration is done relative to the
 red peak and the short-wavelength edge of the blue peak. The photodiode measurements are then sensitivity-corrected
 using this coarse measurement. Then all three channel peaks are measured in the resulting data and a fine wavelength
 estimate is produced by a least-squares fit of a linear function. This fine estimate is then used for a second
 sensitivity correction of all original measurements and the scale is changed from stepper motor step count to
 wavelength in nanometers.
 .. raw:: html
    <figure data-pagefind-ignore>
        <img src="images/processed_plot_cheap_rgb.svg" alt="A plot with three wide peaks, all three of different
        heights. The leftmost peak is highest at 6nA, the middle peak lowest at 1.6nA and the rightmost peak in between
        at 4nA.  The middle one overlaps the two on the sides.  Overall, the plot spans about 300nm on its x axis with
        each peak being around 100nm wide.">
        <figcaption>A plot of the processed measurements. From left to right, the three peaks are blue, green and red.
        </figcaption>
    </figure>
 .. FIXME re-do these measurements, avoiding clipping
 .. FIXME re-do calibration using CCFL
 .. FIXME calibration for brightness imbalance due to wedge-shaped projection of spectrum
 Color space mapping
 *******************
 Finally, to achieve the objective of measuring the LED tape's channels' precise color coordinates the measured spetra
 have to be matched against the color spaces' *color matching functions*. The color matching functions describe how
 strong the color space's idealized *standard observer* would react to light at a particular wavelength. Going from a
 measured spectrum to color coordinates XYZ works by integrating over the product of the measurement and each color
 coordinate's color matching function.
 The result are three color coordinates X, Y and Z for each channel R, G and B yielding nine coordinates in total. When
 written as a matrix conversion between XYZ color space and LED-RGB color space is as simple as multiplying that matrix
 (or its inverse) and a vector from one of the color spaces.
 In XYZ space, the set of colors that can be produced with this LED tape is described by the `parallelepiped`_ spanned by
 the three channel's XYZ vectors. In the following figures, you can see a three-dimensional model of the RGB LED's color
 space (colorful) as well as sRGB (white) for comparison plotted within CIE 1931 XYZ. There is no natural map to scale
 both so for this illustration the LED color space has been scaled to fit. These figures were made with blender and a few
 lines of python.  The blender project file including all settings and the python script to generate the color space
 models can be found in the `project repo`_.
 .. raw:: html
    <figure data-pagefind-ignore>
        <video controls loop>
            <source src="video/led_within_srgb_scale=1.0.mkv" type="video/h264">
            <source src="video/led_within_srgb_scale=1.0.webm" type="video/webm">
            Your browser does not support the HTML5 video tag.
        </video>
        <figcaption>Illustration of the measured LED color space scaled to fit within XYZ with sRGB (light gray) for
            comparison. The thick, white line is the spectral locus.
            <a href="video/led_within_srgb_scale=1.0.mkv">mkv/h264 download</a> /
            <a href="video/led_within_srgb_scale=1.0.webm">webm download</a>
        </figcaption>
    </figure>
 As you can see, the result is pretty disappointing. The LED's color space parallepiped is very narrow, which is because
 the blue channel is much brighter than the other two channels. An easy fix for this is to scale-up the RGB space and
 drop any values outside XYZ. The scaling factor is a trade-off between color space coverage and brightness. You can
 produce the most colors when you clip all channels to brightness of the weakest channel (green in this case), but that
 will make the result very dim. Scaling brightness like that stretches the RGB parallelepiped along its major axis. Up to
 a point the number of possible colors (the gamut) increases at expense of maximum brightness. When the parallelepiped is
 stretched far enought for all three channel vectors to be outside the 1,1,1 XYZ-cube, maximum brightness continues to
 decrease but the gamut stays constant. I don't know a simple scientific way to solve this problem, so I just played
 around with a couple of factors and settled on 2.5 as a reasonable compromise. Below is an illustration.
 .. raw:: html
    <figure>
        <video controls loop>
            <source src="video/led_within_srgb_fancy_camera_path_scale=2.5.mkv" type="video/h264">
            <source src="video/led_within_srgb_fancy_camera_path_scale=2.5.webm" type="video/webm">
            Your browser does not support the HTML5 video tag.
        </video>
        <figcaption>Illustration of the measured LED color space at scale factor 2.5 within XYZ with sRGB (light gray)
            for comparison. The thick, white line is the spectral locus.
            <a href="video/led_within_srgb_fancy_camera_path_scale=2.5.mkv">mkv/h264 download</a> /
            <a href="video/led_within_srgb_fancy_camera_path_scale=2.5.webm">webm download</a>
        </figcaption>
    </figure>
 Firmware implementation
 -----------------------
 In the end, the above measurements yield two matrices: One for mapping XYZ to RGB, and one for mapping RGB to XYZ. Of
 the several versions of CIE XYZ I chose the CIE 1931 XYZ color space as a basis for the firmware because it is most
 popular. Mapping a color coordinate in one color space to the other is as simple as performing nine floating-point
 multiplications and six additions. Mapping Lab or Lch to RGB is done by first mapping Lab/Lch to XYZ, then XYZ to RGB.
 Lab to XYZ is somewhat complex since it requires a floating-point power for gamma correction, but any self-respecting
 libc will have one of those so this is still no problem. Lch also requires floating-point sine and cosine functions, but
 these should still be no problem on most hardware.
 My implementation of these conversions in the ESP8266 firmware of my `Wifi LED driver`_ can be found `on Github`_. You
 can view the Jupyter notebook most of the analysis above `here <http://nbviewer.jupyter.org/github/jaseg/led_drv/blob/master/doc/Spectrum%20Measurement.ipynb>`__.
 .. _`on Github`: https://github.com/jaseg/esp_led_drv/blob/master/user/led_controller.c
 .. _`project repo`: https://github.com/jaseg/led_drv
 .. _`Wifi LED driver`: {{<ref "blog/wifi-led-driver/index.rst">}}
 .. _`small driver`: {{<ref "blog/wifi-led-driver/index.rst">}}
 .. _`multichannel LED driver`: {{<ref "blog/multichannel-led-driver/index.rst">}}
 .. _`sRGB`: https://en.wikipedia.org/wiki/SRGB
 .. _`CC BY-SA 3.0`:  https://creativecommons.org/licenses/by-sa/3.0
 .. _`Color spaces`: https://en.wikipedia.org/wiki/Color_space
 .. _`HSV`: https://en.wikipedia.org/wiki/HSL_and_HSV
 .. _`CIE Lab/LCh`: https://en.wikipedia.org/wiki/Lab_color_space
 .. _`XYZ (CIE 1931)`: https://en.wikipedia.org/wiki/CIE_1931_color_space
 .. _`camera obscura`: https://en.wikipedia.org/wiki/Pinhole_camera
 .. _`article by two researchers from the National Science Museum in Tokyo`: http://www.candac.ca/candacweb/sites/default/files/BuildaSpectroscope.pdf
 .. _`spectrograph`: https://en.wikipedia.org/wiki/Ultraviolet%E2%80%93visible_spectroscopy
 .. _`monochromator`: https://en.wikipedia.org/wiki/Monochromator
 .. _`diffraction grating`: https://en.wikipedia.org/wiki/Diffraction_grating
 .. _`SFH2701`: https://dammedia.osram.info/media/resource/hires/osram-dam-2495903/SFH%202701.pdf
 .. _`BPW34`: http://www.vishay.com/docs/81521/bpw34.pdf
 .. _`transimpedance amplifier`: https://en.wikipedia.org/wiki/Transimpedance_amplifier
 .. _`A4988`: https://www.pololu.com/file/0J450/A4988.pdf
 .. _`parallelepiped`: https://en.wikipedia.org/wiki/Parallelepiped
--- a/content/blog/led-characterization/video/led_within_srgb_fancy_camera_path_scale=2.5.mkv
+++ b/content/blog/led-characterization/video/led_within_srgb_fancy_camera_path_scale=2.5.mkv
--- a/content/blog/led-characterization/video/led_within_srgb_fancy_camera_path_scale=2.5.webm
+++ b/content/blog/led-characterization/video/led_within_srgb_fancy_camera_path_scale=2.5.webm
--- a/content/blog/led-characterization/video/led_within_srgb_scale=1.0.mkv
+++ b/content/blog/led-characterization/video/led_within_srgb_scale=1.0.mkv
--- a/content/blog/led-characterization/video/led_within_srgb_scale=1.0.webm
+++ b/content/blog/led-characterization/video/led_within_srgb_scale=1.0.webm
--- a/content/blog/led-characterization/video/led_within_srgb_scale=2.5.mkv
+++ b/content/blog/led-characterization/video/led_within_srgb_scale=2.5.mkv
--- a/content/blog/led-characterization/video/led_within_srgb_scale=2.5.webm
+++ b/content/blog/led-characterization/video/led_within_srgb_scale=2.5.webm
--- a/content/blog/led-characterization/video/led_within_srgb_scale=3.mkv
+++ b/content/blog/led-characterization/video/led_within_srgb_scale=3.mkv
--- a/content/blog/led-characterization/video/led_within_srgb_scale=3.webm
+++ b/content/blog/led-characterization/video/led_within_srgb_scale=3.webm
--- a/content/blog/led-characterization/video/sRGB.mkv
+++ b/content/blog/led-characterization/video/sRGB.mkv
--- a/content/blog/led-characterization/video/sRGB.webm
+++ b/content/blog/led-characterization/video/sRGB.webm
--- a/content/blog/led-characterization/video/scale=1.mkv
+++ b/content/blog/led-characterization/video/scale=1.mkv
--- a/content/blog/led-characterization/video/scale=1.webm
+++ b/content/blog/led-characterization/video/scale=1.webm
--- a/content/blog/led-characterization/video/scale=2.5.mkv
+++ b/content/blog/led-characterization/video/scale=2.5.mkv
--- a/content/blog/led-characterization/video/scale=2.5.webm
+++ b/content/blog/led-characterization/video/scale=2.5.webm
--- a/content/blog/led-characterization/video/scale=5.mkv
+++ b/content/blog/led-characterization/video/scale=5.mkv
--- a/content/blog/led-characterization/video/scale=5.webm
+++ b/content/blog/led-characterization/video/scale=5.webm
--- a/content/blog/make-cgit-serve-pdfs-directly/index.rst
+++ b/content/blog/make-cgit-serve-pdfs-directly/index.rst
@ -0,0 +1,26 @@
 ---
 title: "How to make cgit serve PDF files as direct downloads"
 date: 2025-11-17T23:42:00+01:00
 summary: >
    cgit is great, but by default when you click on a PDF file in a repository content listing it will show you a
    hexdump of the file. You can access the actual file by clicking the "plain" link on top of the listing, but that's
    not only annoying, for large PDF files rendering the hexdump can also hang browser tabs.
 ---
 cgit is great, but by default when you click on a PDF file in a repository content listing it will show you a
 hexdump of the file. You can access the actual file by clicking the "plain" link on top of the listing, but that's
 not only annoying, for large PDF files rendering the hexdump can also hang browser tabs.
 I found a quick and easy solution to this problem, which I'm documenting here because it seems nobody on the
 internet has really done this before, and the usual AI assistants (ChatGPT and Claude) are both deeply confused.
 You just add a simple rewrite rule to your nginx config that 302-redirects requests to ``/tree/.../foobar.pdf`` to
 ``/plain/.../foobar.pdf``. Here's the rule, make sure you put them in your nginx config *before* the location directive
 proxying requests to cgit.
 .. code:: nginx
    location ~ ^/([^/]+)/tree/(.*\.pdf)$ {
        return 302 /$1/plain/$2;
    }
--- a/content/blog/multichannel-led-driver/images/asymmetric_iled.svg
+++ b/content/blog/multichannel-led-driver/images/asymmetric_iled.svg
--- a/content/blog/multichannel-led-driver/images/asymmetric_vgate.svg
+++ b/content/blog/multichannel-led-driver/images/asymmetric_vgate.svg
--- a/content/blog/multichannel-led-driver/images/bcm_schema.jpg
+++ b/content/blog/multichannel-led-driver/images/bcm_schema.jpg
--- a/content/blog/multichannel-led-driver/images/corrected_brightness_sim.svg
+++ b/content/blog/multichannel-led-driver/images/corrected_brightness_sim.svg
--- a/content/blog/multichannel-led-driver/images/driver_linearity_raw.svg
+++ b/content/blog/multichannel-led-driver/images/driver_linearity_raw.svg
--- a/content/blog/multichannel-led-driver/images/driver_output_ltspice_schematic.jpg
+++ b/content/blog/multichannel-led-driver/images/driver_output_ltspice_schematic.jpg
--- a/content/blog/multichannel-led-driver/images/driver_pcb_built.jpg
+++ b/content/blog/multichannel-led-driver/images/driver_pcb_built.jpg
--- a/content/blog/multichannel-led-driver/images/driver_ringing_strong.jpg
+++ b/content/blog/multichannel-led-driver/images/driver_ringing_strong.jpg
--- a/content/blog/multichannel-led-driver/images/driver_ringing_weak.jpg
+++ b/content/blog/multichannel-led-driver/images/driver_ringing_weak.jpg
--- a/content/blog/multichannel-led-driver/images/led_strip_alight.jpg
+++ b/content/blog/multichannel-led-driver/images/led_strip_alight.jpg
--- a/content/blog/multichannel-led-driver/images/linearization_setup.jpg
+++ b/content/blog/multichannel-led-driver/images/linearization_setup.jpg
--- a/content/blog/multichannel-led-driver/images/olsndot_output_schematic.jpg
+++ b/content/blog/multichannel-led-driver/images/olsndot_output_schematic.jpg
--- a/content/blog/multichannel-led-driver/images/olsndot_pcb.png
+++ b/content/blog/multichannel-led-driver/images/olsndot_pcb.png
--- a/content/blog/multichannel-led-driver/images/olsndot_schematic.png
+++ b/content/blog/multichannel-led-driver/images/olsndot_schematic.png
--- a/content/blog/multichannel-led-driver/images/overshoot_sim_r0.svg
+++ b/content/blog/multichannel-led-driver/images/overshoot_sim_r0.svg
--- a/content/blog/multichannel-led-driver/images/overshoot_sim_r100.svg
+++ b/content/blog/multichannel-led-driver/images/overshoot_sim_r100.svg
--- a/content/blog/multichannel-led-driver/images/pwm_schema.jpg
+++ b/content/blog/multichannel-led-driver/images/pwm_schema.jpg
--- a/content/blog/multichannel-led-driver/images/uncorrected_brightness_sim.svg
+++ b/content/blog/multichannel-led-driver/images/uncorrected_brightness_sim.svg
--- a/Show more
+++ b/Show more
Author	SHA1	Message	Date
jaseg	0d689a700c	Publish git migration note and pre-write project announcements	2026-05-30 11:44:14 +02:00
jaseg	fb34ff0c64	Add pixacao project blog post	2026-05-30 10:30:31 +02:00
jaseg	12db898381	Fix kicoil blog post formatting	2026-05-30 10:29:42 +02:00
jaseg	0e09cd96ed	Add new deploy script	2026-05-17 13:46:09 +02:00
jaseg	00005da741	projects/kicoil: fix issue tracker URL	2026-04-24 21:57:21 +02:00
jaseg	ea0940ff66	Add kicoil project page	2025-12-29 12:04:20 +01:00
jaseg	d8bee2acc2	Properly link mastodon profile	2025-12-08 00:06:52 +01:00
jaseg	ccdffd6c65	Remove projects list from home page	2025-11-18 11:51:06 +01:00
jaseg	904f21f1e9	Add cgit pdf download post	2025-11-18 11:49:48 +01:00
jaseg	fed2333433	Sampling mesh monitor post: Fix summary	2025-10-27 12:36:51 +01:00
jaseg	4993431bbe	blog/sampling mesh mon: add git link	2025-10-21 22:10:17 +02:00
jaseg	7fefec320d	sampling mesh monitor post: add pics	2025-10-21 11:33:28 +02:00
jaseg	ebb0df945e	Add sampling mesh monitor paper	2025-10-21 11:12:25 +02:00
jaseg	0a095fa359	theme: fix page background and make headings slightly smaller	2025-10-21 10:59:33 +02:00
jaseg	d70e23068c	kimesh: fix link in readme	2025-09-28 22:13:57 +02:00
jaseg	d2891b448a	Add wsdiff article	2025-07-28 14:08:30 +02:00
jaseg	3fd0c107e0	css code listings post: Fix code link	2025-07-26 17:53:13 +02:00
jaseg	02abb01549	code listing post: Fix code listing, remove unnecessary part	2025-07-26 16:15:51 +02:00
jaseg	90e8ff7ac0	Fix page layout: wrap long literals	2025-07-26 16:10:55 +02:00
jaseg	f5d03ed1cf	Add code listing CSS hack article	2025-07-26 16:03:33 +02:00
jaseg	338de75fb4	Fix font preloads, add speculative prefetch rules	2025-07-26 14:24:12 +02:00
jaseg	9d55ae84a8	Improve performance by preloading webfonts	2025-07-26 13:45:58 +02:00
jaseg	322eddf574	More rendering fixes	2025-06-30 15:40:28 +02:00
jaseg	752f296a77	Rendering fixes	2025-06-30 15:39:45 +02:00
jaseg	16655c00e0	Fix hugo layout in hugo > ~0.130.0 For some reason, newer hugo versions have trouble with .summary, and on some pages where .summary is not defined in the page header metadata, when rendering the page as a preview card, hugo swallows the card's closing </div> tag. Such a weird bug, we now just work around it by explicitly setting the .summary meta on pages that cause this bug(?) to surface.	2025-06-30 15:35:25 +02:00
jaseg	a324ba7b64	WIP	2025-06-30 14:48:34 +02:00
jaseg	bce789de7b	epa-sgd-crypt draft	2025-01-05 15:11:58 +01:00
jaseg	9ee28abd50	deploy.py: Add pagefind build	2023-12-30 16:37:50 +01:00
jaseg	74e119b6e2	theme: Add static page search with pagefind	2023-12-30 16:35:36 +01:00
jaseg	b357b50525	projects/8seg: Update for 37C3 teardown.	2023-12-30 13:43:43 +01:00
jaseg	c12db2ab42	projects/8seg: add 3D model link	2023-12-28 14:55:59 +01:00
jaseg	2bb3b936b4	Add 8seg project page and blog post	2023-12-26 15:30:15 +01:00
jaseg	77fffce8a2	update 8seg tech overview	2023-12-21 19:39:19 +01:00
jaseg	d7ca6c9cdc	8seg post WIP	2023-12-21 19:37:35 +01:00
jaseg	29f6e652de	Make package signing key not mess up the layout on /about	2023-10-14 17:43:31 +02:00
jaseg	5fb6e37fdc	Fix mastodon link	2023-10-14 17:41:38 +02:00
jaseg	588b0a9e10	theme: Make things degrade gracefully on mobile	2023-10-14 17:40:05 +02:00
jaseg	096ffb8c4e	Size down background image	2023-10-14 14:55:42 +02:00
jaseg	f87afaaf44	Make background really pretty	2023-10-14 14:54:07 +02:00
jaseg	2cdeee2a3c	Nyght Serif is the best :)	2023-10-14 13:02:49 +02:00
jaseg	dff5da4d50	Add google web environment integrity protest message	2023-10-14 12:08:40 +02:00
jaseg	2fd22e30ce	template: Make projects sort by date	2023-10-06 14:35:32 +02:00
jaseg	9afd55a603	Projects: Add kimesh	2023-10-06 14:14:06 +02:00
jaseg	32d3a98101	Update theme	2023-09-27 13:05:38 +02:00
jaseg	81f65823f2	Add missing gerbolyze screenshots	2023-03-19 23:43:37 +01:00
jaseg	aa54c194ff	Make images on dark mode darker	2023-03-19 23:41:06 +01:00
jaseg	9d2ecb11fd	Make light mode prettier	2023-03-19 23:24:27 +01:00
jaseg	6658952dcf	dark mode	2023-03-19 23:02:57 +01:00
jaseg	3c6957467f	Update project link display	2023-03-19 18:57:48 +01:00
jaseg	c55e92fe93	Fix headline alignment & deployment	2023-03-19 15:55:56 +01:00
jaseg	77469be23f	Make site mobile-friendly, make code listings pretty	2023-03-19 15:27:45 +01:00
jaseg	92e3b5f49f	Big site update	2023-03-19 00:53:31 +01:00
jaseg	072b2d38e2	Add Telekom GPON SFP ONU page	2022-02-23 22:34:05 +01:00
jaseg	5e93f56038	Update robots.txt, allow crawling	2022-02-21 12:19:50 +01:00
jaseg	fdb87d6c0b	serial protocol post: light proofreading, fix link	2021-11-25 12:40:49 +01:00
jaseg	e7a91af6b5	Update theme to show post list on top level again	2021-11-25 11:54:39 +01:00
jaseg	396c62e422	Polish wifi LED driver post	2021-11-24 12:31:49 +01:00
jaseg	a6ecebf648	Add IHSM post	2021-11-24 12:27:03 +01:00
jaseg	c4af22d852	Finish HSM basics post	2021-11-23 18:40:11 +01:00
jaseg	3dfca328ee	deploy.py: use absolute URL instead of remote name for deployment	2021-08-16 14:28:04 +02:00
jaseg	f61c032d23	deploy.py: auto-push generated commit	2021-08-16 14:27:08 +02:00
jaseg	345867359e	about page: fix mailto link	2021-08-16 14:26:16 +02:00
jaseg	28dae21621	Fill in about page	2021-08-16 14:23:40 +02:00