summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--blog/kicad-mesh-plugin/index.html42
-rw-r--r--blog/multichannel-led-driver/index.html18
-rw-r--r--blog/wifi-led-driver/index.html9
-rw-r--r--projects/svg-flatten/index.html5
-rw-r--r--style.css19
5 files changed, 56 insertions, 37 deletions
diff --git a/blog/kicad-mesh-plugin/index.html b/blog/kicad-mesh-plugin/index.html
index 5c3fb6e..7b57065 100644
--- a/blog/kicad-mesh-plugin/index.html
+++ b/blog/kicad-mesh-plugin/index.html
@@ -128,25 +128,29 @@ algorithm it yields more or less organized-looking results. Below are five examp
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.</p>
-<figure>
-<figure class="side-by-side">
- <img src="images/cells-0.svg" alt="a completely organized looking grid with spiral patterns all over.">
- <figcaption>0%</figcaption>
-</figure><figure class="side-by-side">
- <img src="images/cells-25.svg">
- <figcaption>25%</figcaption>
-</figure><figure class="side-by-side">
- <img src="images/cells-50.svg">
- <figcaption>50%</figcaption>
-</figure><figure class="side-by-side">
- <img src="images/cells-75.svg">
- <figcaption>75%</figcaption>
-</figure><figure class="side-by-side">
- <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>
-</figure><p>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
+<div class="subfigure">
+ <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><p>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
diff --git a/blog/multichannel-led-driver/index.html b/blog/multichannel-led-driver/index.html
index 19b4bd8..43802ff 100644
--- a/blog/multichannel-led-driver/index.html
+++ b/blog/multichannel-led-driver/index.html
@@ -298,15 +298,16 @@ photocurrents for a certain BCM setpoint just as our retinas would do.</p>
</figure><p>While it would be possible to fully automate the optimization of BCM driver lookup tables, we needed only one and in the
end I just sat down and manually tweaked the ideal values we initially calculated until I liked the result. You can see
the resulting brightness curve below.</p>
-<figure>
- <figure class="side-by-side">
+<div class="subfigure">
+ <figure>
<img src="images/uncorrected_brightness_sim.svg" alt="">
<figcaption>
Calculated brightness curve for the uncorrected BCM setup. As you can see, at low setpoints the result
is about as smooth as sandpaper, which is well in line with our observations. At high setpoints the
offset gets swamped out and the nonlinearity in the low bits is not visible anymore.
</figcaption>
- </figure><figure class="side-by-side">
+ </figure>
+ <figure>
<img src="images/corrected_brightness_sim.svg" alt="">
<figcaption>
Brightness curve for the corrected BCM setup extrapolated using actual measurements. Looks as buttery
@@ -314,7 +315,7 @@ the resulting brightness curve below.</p>
</figcaption>
</figcaption>
</figure>
-</figure></div>
+</div></div>
</div>
<div class="section" id="controlling-the-driver">
<h3>Controlling the driver</h3>
@@ -343,19 +344,20 @@ and control their outputs.</p>
</div>
<div class="section" id="conclusion">
<h3>Conclusion</h3>
-<figure>
- <figure class="side-by-side">
+<div class="subfigure">
+ <figure>
<a href="images/olsndot_schematic.png">
<img src="images/olsndot_schematic.png" alt="A picture of the LED driver schematic">
</a>
<figcaption>The LED driver <a href="images/olsndot_schematic.png">schematic</a></figcaption>
- </figure><figure class="side-by-side">
+ </figure>
+ <figure>
<a href="images/olsndot_pcb.png">
<img src="images/olsndot_pcb.png" alt="A picture of the LED driver PCB layout">
</a>
<figcaption>The LED driver <a href="images/olsndot_pcb.png">PCB layout</a></figcaption>
</figure>
-</figure><p>Putting some thought into the control circuitry and software, you can easily control large numbers of channels of LEDs
+</div><p>Putting some thought into the control circuitry and software, you can easily control large numbers of channels of LEDs
using extremely inexpensive driving hardware without any compromises on dynamic range. The design we settled on can
drive 32 channels of LED tape with a dynamic range of 14bit at a BOM cost of below 10€. All it really takes is a couple
of shift registers and a mildly bored STM32 microcontroller.</p>
diff --git a/blog/wifi-led-driver/index.html b/blog/wifi-led-driver/index.html
index 869d165..8e38859 100644
--- a/blog/wifi-led-driver/index.html
+++ b/blog/wifi-led-driver/index.html
@@ -67,15 +67,16 @@ a small <a class="reference external" href="https://en.wikipedia.org/wiki/Surfac
currents their <a class="reference external" href="http://m.littelfuse.com/~/media/electronics/datasheets/resettable_ptcs/littelfuse_ptc_16r_datasheet.pdf.pdf">trip times get long enough that they become unlikely to trip in time to save anything</a>, so plain old non-resettable fuses would be the way to go there.</p>
<!-- FIXME finished board photos -->
<!-- FIXME board with test tape picture -->
-<figure>
- <figure class="side-by-side">
+<div class="subfigure">
+ <figure>
<img src="images/schematic.png">
<figcaption>
The schematic of the driver board, with the ESP8266 on the top left, the STM32 microcontroller for LED
modulation below, the shift register in the middle and the LED drivers and outputs on the right.
<a href="resource/schematic_and_pcb.pdf">Download PDF</a>
</figcaption>
- </figure><figure class="side-by-side">
+ </figure>
+ <figure>
<img src="images/layout.png">
<figcaption>
The board layout with the top side being visible. The top side contains the footprint for the ESP8266, the
@@ -86,7 +87,7 @@ currents their <a class="reference external" href="http://m.littelfuse.com/~/med
<a href="resource/schematic_and_pcb.pdf">Download PDF</a>
</figcaption>
</figure>
-</figure><figure>
+</div><figure>
<img src="images/boards.small.jpg">
<figcaption>The completed PCBs of this project (front) and the `multichannel LED driver`_ project the driver
circuitry was derived from (back).
diff --git a/projects/svg-flatten/index.html b/projects/svg-flatten/index.html
index 61c9b6f..e20adf7 100644
--- a/projects/svg-flatten/index.html
+++ b/projects/svg-flatten/index.html
@@ -41,7 +41,10 @@
<div class="document">
-
+<p>svg-flatten is a command-line utility that performs vector occlusion and clipping on SVG files, producing a flattened
+SVG file without overlapping elements, without changing what the file looks like. svg-flatten is used as a part of
+gerbolyze.</p>
+<p>I developed svg-flatten as part of <a class="reference external" href="http://jaseg.de/projects/gerbolyze/">gerbolyze</a>, but it can be used independently.</p>
</div>
</main><footer>
Copyright © 2023 Jan Sebastian Götte
diff --git a/style.css b/style.css
index fb78377..05baa62 100644
--- a/style.css
+++ b/style.css
@@ -3,8 +3,8 @@ html {
--c-bg-backdrop: #0d1015;
--c-bg-behind: #1f232a;
--c-bg-front: #272c35;
- --c-bg-highlight #383f4c;
- --c-bg-figure-backdrop: #b5bcc8;
+ --c-bg-highlight: #383f4c;
+ --c-bg-figure-backdrop: #383f4c;
--c-text: #d0d0d0;
--c-text-inverted: #101010;
--c-text-muted: #a0a0a0;
@@ -333,8 +333,7 @@ figure.side-by-side {
figure img, figure video {
display: block;
- margin-left: auto;
- margin-right: auto;
+ margin: 0 auto 0 auto;
width: 100%;
}
@@ -356,6 +355,12 @@ img {
max-width: 100%;
margin: 40px auto 40px auto;
display: block;
+ filter: brightness(70%);
+ transition: filter 100ms;
+}
+
+img:hover {
+ filter: none;
}
.code {
@@ -492,7 +497,7 @@ body .il { color: var(--c-text); font-weight: 600 } /* Literal.Number.Integer.L
--c-bg-backdrop: hsl(220, 10%, 90%);
--c-bg-behind: hsl(220, 10%, 95%);
--c-bg-front: hsl(220, 10%, 96%);
- --c-bg-highlight #ffffff;
+ --c-bg-highlight: #ffffff;
--c-bg-figure-backdrop: #b5bcc8;
--c-text: hsl(220, 20%, 30%);
--c-text-inverted: hsl(220, 20%, 100%);
@@ -516,6 +521,10 @@ body .il { color: var(--c-text); font-weight: 600 } /* Literal.Number.Integer.L
a:hover, nav a:hover {
color: var(--c-text-inverted);
}
+
+ img {
+ filter: none;
+ }
.card {
box-shadow: 0 0 3px 1px rgba(0, 0, 0, calc(0.5*var(--shadow-opacity)));