diff options
Diffstat (limited to 'blog')
| -rw-r--r-- | blog/kicad-mesh-plugin/index.html | 42 | ||||
| -rw-r--r-- | blog/multichannel-led-driver/index.html | 18 | ||||
| -rw-r--r-- | blog/wifi-led-driver/index.html | 9 |
3 files changed, 38 insertions, 31 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). |