From 92e3b5f49f6f5336530988e7839ab3ed283b86e4 Mon Sep 17 00:00:00 2001 From: jaseg Date: Sun, 19 Mar 2023 00:53:31 +0100 Subject: Big site update --- content/blog/_index.rst | 3 + content/blog/hsm-basics/index.rst | 214 + content/blog/hsm-basics/mori_semi_hsm_talk_web.pdf | Bin 0 -> 1075912 bytes content/blog/ihsm-worlds-first-diy-hsm/index.rst | 41 + content/blog/kicad-mesh-plugin/images/anim.webp | Bin 0 -> 35626 bytes content/blog/kicad-mesh-plugin/images/cells-0.svg | 2444 ++++ .../blog/kicad-mesh-plugin/images/cells-100.svg | 2444 ++++ content/blog/kicad-mesh-plugin/images/cells-25.svg | 2444 ++++ content/blog/kicad-mesh-plugin/images/cells-50.svg | 2444 ++++ content/blog/kicad-mesh-plugin/images/cells-75.svg | 2444 ++++ .../kicad-mesh-plugin/images/grid-vis-plain.svg | 138 + content/blog/kicad-mesh-plugin/images/grid-vis.svg | 138 + .../images/kicad-mesh-outline.png | Bin 0 -> 120770 bytes .../images/kicad-mesh-result-large.png | Bin 0 -> 197766 bytes .../images/kicad-mesh-settings.png | Bin 0 -> 46346 bytes .../images/kicad-mesh-settings2.png | Bin 0 -> 131267 bytes .../blog/kicad-mesh-plugin/images/maze_tiles.svg | 2070 +++ .../kicad-mesh-plugin/images/maze_tiles_plain.svg | 1731 +++ .../blog/kicad-mesh-plugin/images/modern_art.svg | 1609 ++ .../kicad-mesh-plugin/images/tiles-25-small.svg | 14636 +++++++++++++++++++ .../kicad-mesh-plugin/images/traces-25-small.svg | 7 + content/blog/kicad-mesh-plugin/index.rst | 221 + .../images/daylight_spectrum_dvd.jpg | Bin 0 -> 79150 bytes .../images/driver_ringing_strong.jpg | Bin 0 -> 285952 bytes .../images/driver_ringing_weak.jpg | Bin 0 -> 292100 bytes .../images/electronics_whole.jpg | Bin 0 -> 438776 bytes .../led-characterization/images/hsv_cylinder.png | Bin 0 -> 293981 bytes .../images/photodiode_sensitivity.svg | 874 ++ .../led-characterization/images/preamp_back.jpg | Bin 0 -> 340446 bytes .../led-characterization/images/preamp_front.jpg | Bin 0 -> 308167 bytes .../images/preamp_schematic.jpg | Bin 0 -> 277414 bytes .../images/processed_plot_cheap_rgb.svg | 2366 +++ .../images/raw_plot_cheap_rgb.svg | 2739 ++++ .../blog/led-characterization/images/rgb_cube.svg | 222 + .../images/spectrograph_step1_parts.jpg | Bin 0 -> 284254 bytes .../images/spectrograph_step2.jpg | Bin 0 -> 277234 bytes .../images/spectrograph_step3.jpg | Bin 0 -> 256192 bytes .../images/spectrograph_step4_complete.jpg | Bin 0 -> 303777 bytes .../images/zeus_hammer_breadboard.jpg | Bin 0 -> 445768 bytes .../images/zeus_hammer_breadboard_original.jpg | Bin 0 -> 2474273 bytes .../images/zeus_hammer_schematic.jpg | Bin 0 -> 148056 bytes .../images/zeus_hammer_schematic_original.jpg | Bin 0 -> 1893757 bytes content/blog/led-characterization/index.rst | 504 + ...led_within_srgb_fancy_camera_path_scale=2.5.mkv | Bin 0 -> 2676955 bytes ...ed_within_srgb_fancy_camera_path_scale=2.5.webm | Bin 0 -> 1822963 bytes .../video/led_within_srgb_scale=1.0.mkv | Bin 0 -> 1223799 bytes .../video/led_within_srgb_scale=1.0.webm | Bin 0 -> 789099 bytes .../video/led_within_srgb_scale=2.5.mkv | Bin 0 -> 1559120 bytes .../video/led_within_srgb_scale=2.5.webm | Bin 0 -> 920089 bytes .../video/led_within_srgb_scale=3.mkv | Bin 0 -> 1709475 bytes .../video/led_within_srgb_scale=3.webm | Bin 0 -> 925593 bytes content/blog/led-characterization/video/sRGB.mkv | Bin 0 -> 1269287 bytes content/blog/led-characterization/video/sRGB.webm | Bin 0 -> 791821 bytes .../blog/led-characterization/video/scale=1.mkv | Bin 0 -> 1011548 bytes .../blog/led-characterization/video/scale=1.webm | Bin 0 -> 758345 bytes .../blog/led-characterization/video/scale=2.5.mkv | Bin 0 -> 1296564 bytes .../blog/led-characterization/video/scale=2.5.webm | Bin 0 -> 882674 bytes .../blog/led-characterization/video/scale=5.mkv | Bin 0 -> 1571645 bytes .../blog/led-characterization/video/scale=5.webm | Bin 0 -> 879476 bytes .../images/asymmetric_iled.svg | 2222 +++ .../images/asymmetric_vgate.svg | 1933 +++ .../multichannel-led-driver/images/bcm_schema.jpg | Bin 0 -> 1626022 bytes .../images/corrected_brightness_sim.svg | 765 + .../images/driver_linearity_raw.svg | 937 ++ .../images/driver_output_ltspice_schematic.jpg | Bin 0 -> 876019 bytes .../images/driver_pcb_built.jpg | Bin 0 -> 1229840 bytes .../images/driver_ringing_strong.jpg | Bin 0 -> 285952 bytes .../images/driver_ringing_weak.jpg | Bin 0 -> 292100 bytes .../images/led_strip_alight.jpg | Bin 0 -> 1752106 bytes .../images/linearization_setup.jpg | Bin 0 -> 2038436 bytes .../images/olsndot_output_schematic.jpg | Bin 0 -> 1410898 bytes .../multichannel-led-driver/images/olsndot_pcb.png | Bin 0 -> 137479 bytes .../images/olsndot_schematic.png | Bin 0 -> 362216 bytes .../images/overshoot_sim_r0.svg | 1885 +++ .../images/overshoot_sim_r100.svg | 1788 +++ .../multichannel-led-driver/images/pwm_schema.jpg | Bin 0 -> 840134 bytes .../images/uncorrected_brightness_sim.svg | 727 + content/blog/multichannel-led-driver/index.rst | 456 + .../olsndot_v02_schematics_and_pcb.pdf | Bin 0 -> 1036117 bytes content/blog/private-contact-discovery/index.rst | 38 + .../mori_semi_psi_talk.odp | Bin 0 -> 35999576 bytes .../mori_semi_psi_talk.pdf | Bin 0 -> 11600295 bytes content/blog/serial-protocols/index.rst | 249 + .../images/succulents.jpg | Bin 0 -> 587685 bytes .../blog/sybil-resistance-identity/index-old.rst | 244 + content/blog/sybil-resistance-identity/index.rst | 89 + .../images/edgerouter_interface_config.png | Bin 0 -> 148433 bytes .../images/edgerouter_route_config.png | Bin 0 -> 75601 bytes .../images/edgerouter_sfp_config.png | Bin 0 -> 56138 bytes .../images/edgerouter_snat_config.png | Bin 0 -> 118370 bytes .../images/edgerouter_snat_config2.png | Bin 0 -> 82458 bytes .../images/sfp_onu_ploam_pw_config.png | Bin 0 -> 152023 bytes .../blog/telekom-gpon-sfp/images/sfp_onu_reset.png | Bin 0 -> 132106 bytes .../telekom-gpon-sfp/images/sfp_onu_web_if.png | Bin 0 -> 133838 bytes content/blog/telekom-gpon-sfp/index.rst | 216 + .../images/thors_hammer_breadboard.jpg | Bin 0 -> 3229178 bytes .../thors-hammer/images/thors_hammer_schematic.jpg | Bin 0 -> 1822573 bytes content/blog/thors-hammer/index.rst | 60 + content/blog/thors-hammer/video/thors_hammer.mkv | Bin 0 -> 3799797 bytes content/blog/thors-hammer/video/thors_hammer.mov | Bin 0 -> 33979697 bytes content/blog/thors-hammer/video/thors_hammer.webm | Bin 0 -> 4868825 bytes .../blog/wifi-led-driver/images/board_in_case.jpg | Bin 0 -> 2898747 bytes .../wifi-led-driver/images/board_in_case.small.jpg | Bin 0 -> 817789 bytes content/blog/wifi-led-driver/images/boards.jpg | Bin 0 -> 3642485 bytes .../blog/wifi-led-driver/images/boards.small.jpg | Bin 0 -> 865465 bytes content/blog/wifi-led-driver/images/layout.png | Bin 0 -> 114048 bytes content/blog/wifi-led-driver/images/schematic.png | Bin 0 -> 301982 bytes content/blog/wifi-led-driver/index.rst | 145 + .../resource/lyza_schematic_and_pcb.pdf | Bin 0 -> 781457 bytes 109 files changed, 51487 insertions(+) create mode 100644 content/blog/_index.rst create mode 100644 content/blog/hsm-basics/index.rst create mode 100644 content/blog/hsm-basics/mori_semi_hsm_talk_web.pdf create mode 100644 content/blog/ihsm-worlds-first-diy-hsm/index.rst create mode 100755 content/blog/kicad-mesh-plugin/images/anim.webp create mode 100755 content/blog/kicad-mesh-plugin/images/cells-0.svg create mode 100755 content/blog/kicad-mesh-plugin/images/cells-100.svg create mode 100755 content/blog/kicad-mesh-plugin/images/cells-25.svg create mode 100755 content/blog/kicad-mesh-plugin/images/cells-50.svg create mode 100755 content/blog/kicad-mesh-plugin/images/cells-75.svg create mode 100755 content/blog/kicad-mesh-plugin/images/grid-vis-plain.svg create mode 100755 content/blog/kicad-mesh-plugin/images/grid-vis.svg create mode 100755 content/blog/kicad-mesh-plugin/images/kicad-mesh-outline.png create mode 100755 content/blog/kicad-mesh-plugin/images/kicad-mesh-result-large.png create mode 100755 content/blog/kicad-mesh-plugin/images/kicad-mesh-settings.png create mode 100755 content/blog/kicad-mesh-plugin/images/kicad-mesh-settings2.png create mode 100755 content/blog/kicad-mesh-plugin/images/maze_tiles.svg create mode 100755 content/blog/kicad-mesh-plugin/images/maze_tiles_plain.svg create mode 100755 content/blog/kicad-mesh-plugin/images/modern_art.svg create mode 100755 content/blog/kicad-mesh-plugin/images/tiles-25-small.svg create mode 100755 content/blog/kicad-mesh-plugin/images/traces-25-small.svg create mode 100644 content/blog/kicad-mesh-plugin/index.rst create mode 100644 content/blog/led-characterization/images/daylight_spectrum_dvd.jpg create mode 100644 content/blog/led-characterization/images/driver_ringing_strong.jpg create mode 100644 content/blog/led-characterization/images/driver_ringing_weak.jpg create mode 100644 content/blog/led-characterization/images/electronics_whole.jpg create mode 100644 content/blog/led-characterization/images/hsv_cylinder.png create mode 100644 content/blog/led-characterization/images/photodiode_sensitivity.svg create mode 100644 content/blog/led-characterization/images/preamp_back.jpg create mode 100644 content/blog/led-characterization/images/preamp_front.jpg create mode 100644 content/blog/led-characterization/images/preamp_schematic.jpg create mode 100644 content/blog/led-characterization/images/processed_plot_cheap_rgb.svg create mode 100644 content/blog/led-characterization/images/raw_plot_cheap_rgb.svg create mode 100644 content/blog/led-characterization/images/rgb_cube.svg create mode 100644 content/blog/led-characterization/images/spectrograph_step1_parts.jpg create mode 100644 content/blog/led-characterization/images/spectrograph_step2.jpg create mode 100644 content/blog/led-characterization/images/spectrograph_step3.jpg create mode 100644 content/blog/led-characterization/images/spectrograph_step4_complete.jpg create mode 100644 content/blog/led-characterization/images/zeus_hammer_breadboard.jpg create mode 100644 content/blog/led-characterization/images/zeus_hammer_breadboard_original.jpg create mode 100644 content/blog/led-characterization/images/zeus_hammer_schematic.jpg create mode 100644 content/blog/led-characterization/images/zeus_hammer_schematic_original.jpg create mode 100644 content/blog/led-characterization/index.rst create mode 100644 content/blog/led-characterization/video/led_within_srgb_fancy_camera_path_scale=2.5.mkv create mode 100644 content/blog/led-characterization/video/led_within_srgb_fancy_camera_path_scale=2.5.webm create mode 100644 content/blog/led-characterization/video/led_within_srgb_scale=1.0.mkv create mode 100644 content/blog/led-characterization/video/led_within_srgb_scale=1.0.webm create mode 100644 content/blog/led-characterization/video/led_within_srgb_scale=2.5.mkv create mode 100644 content/blog/led-characterization/video/led_within_srgb_scale=2.5.webm create mode 100644 content/blog/led-characterization/video/led_within_srgb_scale=3.mkv create mode 100644 content/blog/led-characterization/video/led_within_srgb_scale=3.webm create mode 100644 content/blog/led-characterization/video/sRGB.mkv create mode 100644 content/blog/led-characterization/video/sRGB.webm create mode 100644 content/blog/led-characterization/video/scale=1.mkv create mode 100644 content/blog/led-characterization/video/scale=1.webm create mode 100644 content/blog/led-characterization/video/scale=2.5.mkv create mode 100644 content/blog/led-characterization/video/scale=2.5.webm create mode 100644 content/blog/led-characterization/video/scale=5.mkv create mode 100644 content/blog/led-characterization/video/scale=5.webm create mode 100644 content/blog/multichannel-led-driver/images/asymmetric_iled.svg create mode 100644 content/blog/multichannel-led-driver/images/asymmetric_vgate.svg create mode 100644 content/blog/multichannel-led-driver/images/bcm_schema.jpg create mode 100644 content/blog/multichannel-led-driver/images/corrected_brightness_sim.svg create mode 100644 content/blog/multichannel-led-driver/images/driver_linearity_raw.svg create mode 100644 content/blog/multichannel-led-driver/images/driver_output_ltspice_schematic.jpg create mode 100644 content/blog/multichannel-led-driver/images/driver_pcb_built.jpg create mode 100644 content/blog/multichannel-led-driver/images/driver_ringing_strong.jpg create mode 100644 content/blog/multichannel-led-driver/images/driver_ringing_weak.jpg create mode 100644 content/blog/multichannel-led-driver/images/led_strip_alight.jpg create mode 100644 content/blog/multichannel-led-driver/images/linearization_setup.jpg create mode 100644 content/blog/multichannel-led-driver/images/olsndot_output_schematic.jpg create mode 100644 content/blog/multichannel-led-driver/images/olsndot_pcb.png create mode 100644 content/blog/multichannel-led-driver/images/olsndot_schematic.png create mode 100644 content/blog/multichannel-led-driver/images/overshoot_sim_r0.svg create mode 100644 content/blog/multichannel-led-driver/images/overshoot_sim_r100.svg create mode 100644 content/blog/multichannel-led-driver/images/pwm_schema.jpg create mode 100644 content/blog/multichannel-led-driver/images/uncorrected_brightness_sim.svg create mode 100644 content/blog/multichannel-led-driver/index.rst create mode 100644 content/blog/multichannel-led-driver/olsndot_v02_schematics_and_pcb.pdf create mode 100644 content/blog/private-contact-discovery/index.rst create mode 100644 content/blog/private-contact-discovery/mori_semi_psi_talk.odp create mode 100644 content/blog/private-contact-discovery/mori_semi_psi_talk.pdf create mode 100644 content/blog/serial-protocols/index.rst create mode 100755 content/blog/sybil-resistance-identity/images/succulents.jpg create mode 100644 content/blog/sybil-resistance-identity/index-old.rst create mode 100644 content/blog/sybil-resistance-identity/index.rst create mode 100644 content/blog/telekom-gpon-sfp/images/edgerouter_interface_config.png create mode 100644 content/blog/telekom-gpon-sfp/images/edgerouter_route_config.png create mode 100644 content/blog/telekom-gpon-sfp/images/edgerouter_sfp_config.png create mode 100644 content/blog/telekom-gpon-sfp/images/edgerouter_snat_config.png create mode 100644 content/blog/telekom-gpon-sfp/images/edgerouter_snat_config2.png create mode 100644 content/blog/telekom-gpon-sfp/images/sfp_onu_ploam_pw_config.png create mode 100644 content/blog/telekom-gpon-sfp/images/sfp_onu_reset.png create mode 100644 content/blog/telekom-gpon-sfp/images/sfp_onu_web_if.png create mode 100644 content/blog/telekom-gpon-sfp/index.rst create mode 100644 content/blog/thors-hammer/images/thors_hammer_breadboard.jpg create mode 100644 content/blog/thors-hammer/images/thors_hammer_schematic.jpg create mode 100644 content/blog/thors-hammer/index.rst create mode 100644 content/blog/thors-hammer/video/thors_hammer.mkv create mode 100644 content/blog/thors-hammer/video/thors_hammer.mov create mode 100644 content/blog/thors-hammer/video/thors_hammer.webm create mode 100644 content/blog/wifi-led-driver/images/board_in_case.jpg create mode 100644 content/blog/wifi-led-driver/images/board_in_case.small.jpg create mode 100644 content/blog/wifi-led-driver/images/boards.jpg create mode 100644 content/blog/wifi-led-driver/images/boards.small.jpg create mode 100644 content/blog/wifi-led-driver/images/layout.png create mode 100644 content/blog/wifi-led-driver/images/schematic.png create mode 100644 content/blog/wifi-led-driver/index.rst create mode 100644 content/blog/wifi-led-driver/resource/lyza_schematic_and_pcb.pdf (limited to 'content/blog') diff --git a/content/blog/_index.rst b/content/blog/_index.rst new file mode 100644 index 0000000..9bff67d --- /dev/null +++ b/content/blog/_index.rst @@ -0,0 +1,3 @@ +--- +title: Blog +--- diff --git a/content/blog/hsm-basics/index.rst b/content/blog/hsm-basics/index.rst new file mode 100644 index 0000000..306edcd --- /dev/null +++ b/content/blog/hsm-basics/index.rst @@ -0,0 +1,214 @@ +--- +title: "Hardware Security Module Basics" +date: 2019-05-17T15:29:20+08:00 +--- + +Hardware Security Modules and Security Research and Cryptography +================================================================ + +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. `__ + +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 `__ 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 +`__. 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 + diff --git a/content/blog/hsm-basics/mori_semi_hsm_talk_web.pdf b/content/blog/hsm-basics/mori_semi_hsm_talk_web.pdf new file mode 100644 index 0000000..b8b7177 Binary files /dev/null and b/content/blog/hsm-basics/mori_semi_hsm_talk_web.pdf differ diff --git a/content/blog/ihsm-worlds-first-diy-hsm/index.rst b/content/blog/ihsm-worlds-first-diy-hsm/index.rst new file mode 100644 index 0000000..0932fc9 --- /dev/null +++ b/content/blog/ihsm-worlds-first-diy-hsm/index.rst @@ -0,0 +1,41 @@ +--- +title: "New Paper on Inertial Hardware Security Modules" +date: 2021-11-23T23:42:20+01:00 +--- + +World's First DIY HSM +===================== + +Last week, Prof. Dr. Björn Scheuermann and I have `published our first joint paper on Hardware Security Modules +`__. 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 `__ 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 `__. 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`: {{}} diff --git a/content/blog/kicad-mesh-plugin/images/anim.webp b/content/blog/kicad-mesh-plugin/images/anim.webp new file mode 100755 index 0000000..a2244d0 Binary files /dev/null and b/content/blog/kicad-mesh-plugin/images/anim.webp differ diff --git a/content/blog/kicad-mesh-plugin/images/cells-0.svg b/content/blog/kicad-mesh-plugin/images/cells-0.svg new file mode 100755 index 0000000..f1d881c --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/cells-0.svg @@ -0,0 +1,2444 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/content/blog/kicad-mesh-plugin/images/cells-100.svg b/content/blog/kicad-mesh-plugin/images/cells-100.svg new file mode 100755 index 0000000..efc4f03 --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/cells-100.svg @@ -0,0 +1,2444 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/content/blog/kicad-mesh-plugin/images/cells-25.svg b/content/blog/kicad-mesh-plugin/images/cells-25.svg new file mode 100755 index 0000000..670ad1a --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/cells-25.svg @@ -0,0 +1,2444 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/content/blog/kicad-mesh-plugin/images/cells-50.svg b/content/blog/kicad-mesh-plugin/images/cells-50.svg new file mode 100755 index 0000000..3b5a0a3 --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/cells-50.svg @@ -0,0 +1,2444 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/content/blog/kicad-mesh-plugin/images/cells-75.svg b/content/blog/kicad-mesh-plugin/images/cells-75.svg new file mode 100755 index 0000000..40e7fc4 --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/cells-75.svg @@ -0,0 +1,2444 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/content/blog/kicad-mesh-plugin/images/grid-vis-plain.svg b/content/blog/kicad-mesh-plugin/images/grid-vis-plain.svg new file mode 100755 index 0000000..80b8d84 --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/grid-vis-plain.svg @@ -0,0 +1,138 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/kicad-mesh-plugin/images/grid-vis.svg b/content/blog/kicad-mesh-plugin/images/grid-vis.svg new file mode 100755 index 0000000..fbcdafa --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/grid-vis.svg @@ -0,0 +1,138 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/kicad-mesh-plugin/images/kicad-mesh-outline.png b/content/blog/kicad-mesh-plugin/images/kicad-mesh-outline.png new file mode 100755 index 0000000..fc0d51e Binary files /dev/null and b/content/blog/kicad-mesh-plugin/images/kicad-mesh-outline.png differ diff --git a/content/blog/kicad-mesh-plugin/images/kicad-mesh-result-large.png b/content/blog/kicad-mesh-plugin/images/kicad-mesh-result-large.png new file mode 100755 index 0000000..798287b Binary files /dev/null and b/content/blog/kicad-mesh-plugin/images/kicad-mesh-result-large.png differ diff --git a/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings.png b/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings.png new file mode 100755 index 0000000..72e7e25 Binary files /dev/null and b/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings.png differ diff --git a/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings2.png b/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings2.png new file mode 100755 index 0000000..8da33be Binary files /dev/null and b/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings2.png differ diff --git a/content/blog/kicad-mesh-plugin/images/maze_tiles.svg b/content/blog/kicad-mesh-plugin/images/maze_tiles.svg new file mode 100755 index 0000000..4b71f19 --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/maze_tiles.svg @@ -0,0 +1,2070 @@ + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/kicad-mesh-plugin/images/maze_tiles_plain.svg b/content/blog/kicad-mesh-plugin/images/maze_tiles_plain.svg new file mode 100755 index 0000000..be1f8d5 --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/maze_tiles_plain.svg @@ -0,0 +1,1731 @@ + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/kicad-mesh-plugin/images/modern_art.svg b/content/blog/kicad-mesh-plugin/images/modern_art.svg new file mode 100755 index 0000000..2729b63 --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/modern_art.svg @@ -0,0 +1,1609 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/kicad-mesh-plugin/images/tiles-25-small.svg b/content/blog/kicad-mesh-plugin/images/tiles-25-small.svg new file mode 100755 index 0000000..21b17ed --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/tiles-25-small.svg @@ -0,0 +1,14636 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/content/blog/kicad-mesh-plugin/images/traces-25-small.svg b/content/blog/kicad-mesh-plugin/images/traces-25-small.svg new file mode 100755 index 0000000..af9a8ef --- /dev/null +++ b/content/blog/kicad-mesh-plugin/images/traces-25-small.svg @@ -0,0 +1,7 @@ + + + + + + + \ No newline at end of file diff --git a/content/blog/kicad-mesh-plugin/index.rst b/content/blog/kicad-mesh-plugin/index.rst new file mode 100644 index 0000000..226f23f --- /dev/null +++ b/content/blog/kicad-mesh-plugin/index.rst @@ -0,0 +1,221 @@ +--- +title: "Kicad Mesh Plugin" +date: 2020-08-18T13:15:39+02:00 +--- + +.. raw:: html + +
+ +
+ +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 `_ 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 + +
+ +
+ +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 <{{}}>`_ 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 + +
+ 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. +
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.
+
+ +.. raw:: html + +
+ 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. +
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.
+
+ +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 + +
+
+ a completely organized looking grid with spiral patterns all over. +
0%
+
+ +
25%
+
+ +
50%
+
+ +
75%
+
+ a completely random looking grid with cells aggregating into ireggular + areas that look like paint splotches. +
100%
+
+
+ +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 + +
+ +
+ 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. +
+
+ +After tiling the grid according to the key above, we get the result below. + +.. raw:: html + +
+ +
+ An auto-routed mesh with traces colored according to tile types. +
+
+ +.. raw:: html + +
+ +
+ The same mesh, but with traces all black. +
+
+ +Putting it all together got me the KiCAD plugin you can see in the screenshot below. + +.. raw:: html + +
+ +
+ The plugin settings window open. +
+
+ +.. raw:: html + +
+ +
+ After runing the plugin, the generated mesh looks like this in pcbnew. +
+
+ +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 `_. + +.. :: + + .. raw:: html + +
+ +
+
+ diff --git a/content/blog/led-characterization/images/daylight_spectrum_dvd.jpg b/content/blog/led-characterization/images/daylight_spectrum_dvd.jpg new file mode 100644 index 0000000..d01242e Binary files /dev/null and b/content/blog/led-characterization/images/daylight_spectrum_dvd.jpg differ diff --git a/content/blog/led-characterization/images/driver_ringing_strong.jpg b/content/blog/led-characterization/images/driver_ringing_strong.jpg new file mode 100644 index 0000000..0419a0e Binary files /dev/null and b/content/blog/led-characterization/images/driver_ringing_strong.jpg differ diff --git a/content/blog/led-characterization/images/driver_ringing_weak.jpg b/content/blog/led-characterization/images/driver_ringing_weak.jpg new file mode 100644 index 0000000..12f9c5d Binary files /dev/null and b/content/blog/led-characterization/images/driver_ringing_weak.jpg differ diff --git a/content/blog/led-characterization/images/electronics_whole.jpg b/content/blog/led-characterization/images/electronics_whole.jpg new file mode 100644 index 0000000..faaf751 Binary files /dev/null and b/content/blog/led-characterization/images/electronics_whole.jpg differ diff --git a/content/blog/led-characterization/images/hsv_cylinder.png b/content/blog/led-characterization/images/hsv_cylinder.png new file mode 100644 index 0000000..265f3e0 Binary files /dev/null and b/content/blog/led-characterization/images/hsv_cylinder.png differ diff --git a/content/blog/led-characterization/images/photodiode_sensitivity.svg b/content/blog/led-characterization/images/photodiode_sensitivity.svg new file mode 100644 index 0000000..e845444 --- /dev/null +++ b/content/blog/led-characterization/images/photodiode_sensitivity.svg @@ -0,0 +1,874 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/led-characterization/images/preamp_back.jpg b/content/blog/led-characterization/images/preamp_back.jpg new file mode 100644 index 0000000..0af495d Binary files /dev/null and b/content/blog/led-characterization/images/preamp_back.jpg differ diff --git a/content/blog/led-characterization/images/preamp_front.jpg b/content/blog/led-characterization/images/preamp_front.jpg new file mode 100644 index 0000000..62fad28 Binary files /dev/null and b/content/blog/led-characterization/images/preamp_front.jpg differ diff --git a/content/blog/led-characterization/images/preamp_schematic.jpg b/content/blog/led-characterization/images/preamp_schematic.jpg new file mode 100644 index 0000000..6be7bbd Binary files /dev/null and b/content/blog/led-characterization/images/preamp_schematic.jpg differ diff --git a/content/blog/led-characterization/images/processed_plot_cheap_rgb.svg b/content/blog/led-characterization/images/processed_plot_cheap_rgb.svg new file mode 100644 index 0000000..9745172 --- /dev/null +++ b/content/blog/led-characterization/images/processed_plot_cheap_rgb.svg @@ -0,0 +1,2366 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/led-characterization/images/raw_plot_cheap_rgb.svg b/content/blog/led-characterization/images/raw_plot_cheap_rgb.svg new file mode 100644 index 0000000..895569f --- /dev/null +++ b/content/blog/led-characterization/images/raw_plot_cheap_rgb.svg @@ -0,0 +1,2739 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/led-characterization/images/rgb_cube.svg b/content/blog/led-characterization/images/rgb_cube.svg new file mode 100644 index 0000000..8af7a00 --- /dev/null +++ b/content/blog/led-characterization/images/rgb_cube.svg @@ -0,0 +1,222 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + G+ + + + + + + + + R+ + + + + B+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + R- + + + + B- + + + + + + + + G- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + R : 83 + + + G : 150 + + + B : 60 + + G: 150 + B: 60 + R: 83 + + + + + + + + R + G + B + + + R + G + B + + + R 255 + G 255 + B 255 + + + + + \ No newline at end of file diff --git a/content/blog/led-characterization/images/spectrograph_step1_parts.jpg b/content/blog/led-characterization/images/spectrograph_step1_parts.jpg new file mode 100644 index 0000000..107220a Binary files /dev/null and b/content/blog/led-characterization/images/spectrograph_step1_parts.jpg differ diff --git a/content/blog/led-characterization/images/spectrograph_step2.jpg b/content/blog/led-characterization/images/spectrograph_step2.jpg new file mode 100644 index 0000000..b678372 Binary files /dev/null and b/content/blog/led-characterization/images/spectrograph_step2.jpg differ diff --git a/content/blog/led-characterization/images/spectrograph_step3.jpg b/content/blog/led-characterization/images/spectrograph_step3.jpg new file mode 100644 index 0000000..acd6d5e Binary files /dev/null and b/content/blog/led-characterization/images/spectrograph_step3.jpg differ diff --git a/content/blog/led-characterization/images/spectrograph_step4_complete.jpg b/content/blog/led-characterization/images/spectrograph_step4_complete.jpg new file mode 100644 index 0000000..d23560d Binary files /dev/null and b/content/blog/led-characterization/images/spectrograph_step4_complete.jpg differ diff --git a/content/blog/led-characterization/images/zeus_hammer_breadboard.jpg b/content/blog/led-characterization/images/zeus_hammer_breadboard.jpg new file mode 100644 index 0000000..08efebb Binary files /dev/null and b/content/blog/led-characterization/images/zeus_hammer_breadboard.jpg differ diff --git a/content/blog/led-characterization/images/zeus_hammer_breadboard_original.jpg b/content/blog/led-characterization/images/zeus_hammer_breadboard_original.jpg new file mode 100644 index 0000000..4f8f34e Binary files /dev/null and b/content/blog/led-characterization/images/zeus_hammer_breadboard_original.jpg differ diff --git a/content/blog/led-characterization/images/zeus_hammer_schematic.jpg b/content/blog/led-characterization/images/zeus_hammer_schematic.jpg new file mode 100644 index 0000000..0e6f483 Binary files /dev/null and b/content/blog/led-characterization/images/zeus_hammer_schematic.jpg differ diff --git a/content/blog/led-characterization/images/zeus_hammer_schematic_original.jpg b/content/blog/led-characterization/images/zeus_hammer_schematic_original.jpg new file mode 100644 index 0000000..b50b3a0 Binary files /dev/null and b/content/blog/led-characterization/images/zeus_hammer_schematic_original.jpg differ diff --git a/content/blog/led-characterization/index.rst b/content/blog/led-characterization/index.rst new file mode 100644 index 0000000..6ad4d64 --- /dev/null +++ b/content/blog/led-characterization/index.rst @@ -0,0 +1,504 @@ +--- +title: "LED Characterization" +date: 2018-05-02T11:18:38+02:00 +--- + +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 + +
+ An illustration of the RGB color cube. +
An illustration of the RGB color cube. + Picture by + Maklaan from Wikimedia Commons, + CC-BY-SA 3.0 +
+
+ +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 + +
+ An illustration of the HSV color space as a cylinder. +
An illustration of the HSV color space as a cylinder. + Picture by + SharkD from Wikimedia Commons, + CC-BY-SA 3.0 +
+
+ +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 + +
+ +
Illustration of the measured sRGB color space within XYZ. The thick, white line is the spectral + locus. + + mkv/h264 download / + webm download +
+
+ +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 + +
+
+ Strong ringing on the LED voltage waveform edge at about + 100% overshoot during about 70% of the cycle time. +
The LED strip being at the end of a couple meters of wire caused extremely bad ringing at high + driving frequencies.
+
+
+ Weak ringing on the LED voltage waveform edge at about 30% + overshoot during about 20% of the cycle time. +
Adding a resistor in front of the MOSFET gate to slow the transition dampened the ringing + somewhat, but ultimately it cannot be eliminated entirely.
+
+
+ +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 + +
+
+ +
The ingredients. The cup of coffee and Madoka Magica DVD set are essential to the eventual + function of the appartus.
+
+
+ +
Step 1: Cut to size and mark down all holes as described in the manual
+
+
+ +
Step 2: Cut out all holes
+
+
+ +
The finished result with the back side showing. The viewing window is on the bottom of the other + side.
+
+
+ + +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 + +
+ +
The daylight spectrum as seen using a DVD as a grating. + Picture by + Xofc from Wikimedia Commons, + CC-BY-SA 4.0 +
+
+ + +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 + +
+ A drawing of the photodiode preamplifier's schematic +
The photodiode preamplifier schematic. Schematic drawn with an unlicensed copy of + DaveCAD.
+
+ +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 + +
+
+ +
The front side of the preamplifier board.
+
+
+ +
The wiring of the photodiode preamp.
+
+
+ +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 + +
+ 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. +
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.
+
+ +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 + +
+ 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. +
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. +
+
+ + +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 + +
+ 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. +
A plot of the photodiode's relative sensitivity in the visible spectrum. The sensitivity is + normalized against its peak at 820nm. +
+
+ +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 + +
+ 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. +
A plot of the processed measurements. From left to right, the three peaks are blue, green and red. +
+
+ +.. 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 + +
+ +
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. + + mkv/h264 download / + webm download +
+
+ +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 + +
+ +
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. + + mkv/h264 download / + webm download +
+
+ +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 `__. + +.. _`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`: {{}} +.. _`small driver`: {{}} +.. _`multichannel LED driver`: {{}} +.. _`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 diff --git 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 new file mode 100644 index 0000000..0a1eece Binary files /dev/null and b/content/blog/led-characterization/video/led_within_srgb_fancy_camera_path_scale=2.5.mkv differ diff --git 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 new file mode 100644 index 0000000..04d355c Binary files /dev/null and b/content/blog/led-characterization/video/led_within_srgb_fancy_camera_path_scale=2.5.webm differ diff --git 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 new file mode 100644 index 0000000..69dfccf Binary files /dev/null and b/content/blog/led-characterization/video/led_within_srgb_scale=1.0.mkv differ diff --git 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 new file mode 100644 index 0000000..8034882 Binary files /dev/null and b/content/blog/led-characterization/video/led_within_srgb_scale=1.0.webm differ diff --git 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 new file mode 100644 index 0000000..a7fba0b Binary files /dev/null and b/content/blog/led-characterization/video/led_within_srgb_scale=2.5.mkv differ diff --git 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 new file mode 100644 index 0000000..d0c9135 Binary files /dev/null and b/content/blog/led-characterization/video/led_within_srgb_scale=2.5.webm differ diff --git a/content/blog/led-characterization/video/led_within_srgb_scale=3.mkv b/content/blog/led-characterization/video/led_within_srgb_scale=3.mkv new file mode 100644 index 0000000..94c7750 Binary files /dev/null and b/content/blog/led-characterization/video/led_within_srgb_scale=3.mkv differ diff --git a/content/blog/led-characterization/video/led_within_srgb_scale=3.webm b/content/blog/led-characterization/video/led_within_srgb_scale=3.webm new file mode 100644 index 0000000..3dc88cc Binary files /dev/null and b/content/blog/led-characterization/video/led_within_srgb_scale=3.webm differ diff --git a/content/blog/led-characterization/video/sRGB.mkv b/content/blog/led-characterization/video/sRGB.mkv new file mode 100644 index 0000000..903c719 Binary files /dev/null and b/content/blog/led-characterization/video/sRGB.mkv differ diff --git a/content/blog/led-characterization/video/sRGB.webm b/content/blog/led-characterization/video/sRGB.webm new file mode 100644 index 0000000..737cc1b Binary files /dev/null and b/content/blog/led-characterization/video/sRGB.webm differ diff --git a/content/blog/led-characterization/video/scale=1.mkv b/content/blog/led-characterization/video/scale=1.mkv new file mode 100644 index 0000000..410896e Binary files /dev/null and b/content/blog/led-characterization/video/scale=1.mkv differ diff --git a/content/blog/led-characterization/video/scale=1.webm b/content/blog/led-characterization/video/scale=1.webm new file mode 100644 index 0000000..dc599be Binary files /dev/null and b/content/blog/led-characterization/video/scale=1.webm differ diff --git a/content/blog/led-characterization/video/scale=2.5.mkv b/content/blog/led-characterization/video/scale=2.5.mkv new file mode 100644 index 0000000..6ff3619 Binary files /dev/null and b/content/blog/led-characterization/video/scale=2.5.mkv differ diff --git a/content/blog/led-characterization/video/scale=2.5.webm b/content/blog/led-characterization/video/scale=2.5.webm new file mode 100644 index 0000000..6a6a860 Binary files /dev/null and b/content/blog/led-characterization/video/scale=2.5.webm differ diff --git a/content/blog/led-characterization/video/scale=5.mkv b/content/blog/led-characterization/video/scale=5.mkv new file mode 100644 index 0000000..b4e7e65 Binary files /dev/null and b/content/blog/led-characterization/video/scale=5.mkv differ diff --git a/content/blog/led-characterization/video/scale=5.webm b/content/blog/led-characterization/video/scale=5.webm new file mode 100644 index 0000000..0298a11 Binary files /dev/null and b/content/blog/led-characterization/video/scale=5.webm differ diff --git a/content/blog/multichannel-led-driver/images/asymmetric_iled.svg b/content/blog/multichannel-led-driver/images/asymmetric_iled.svg new file mode 100644 index 0000000..c18d5de --- /dev/null +++ b/content/blog/multichannel-led-driver/images/asymmetric_iled.svg @@ -0,0 +1,2222 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/multichannel-led-driver/images/asymmetric_vgate.svg b/content/blog/multichannel-led-driver/images/asymmetric_vgate.svg new file mode 100644 index 0000000..473f494 --- /dev/null +++ b/content/blog/multichannel-led-driver/images/asymmetric_vgate.svg @@ -0,0 +1,1933 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/multichannel-led-driver/images/bcm_schema.jpg b/content/blog/multichannel-led-driver/images/bcm_schema.jpg new file mode 100644 index 0000000..5d3ef08 Binary files /dev/null and b/content/blog/multichannel-led-driver/images/bcm_schema.jpg differ diff --git a/content/blog/multichannel-led-driver/images/corrected_brightness_sim.svg b/content/blog/multichannel-led-driver/images/corrected_brightness_sim.svg new file mode 100644 index 0000000..2b9cf16 --- /dev/null +++ b/content/blog/multichannel-led-driver/images/corrected_brightness_sim.svg @@ -0,0 +1,765 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/multichannel-led-driver/images/driver_linearity_raw.svg b/content/blog/multichannel-led-driver/images/driver_linearity_raw.svg new file mode 100644 index 0000000..58aa43f --- /dev/null +++ b/content/blog/multichannel-led-driver/images/driver_linearity_raw.svg @@ -0,0 +1,937 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/multichannel-led-driver/images/driver_output_ltspice_schematic.jpg b/content/blog/multichannel-led-driver/images/driver_output_ltspice_schematic.jpg new file mode 100644 index 0000000..52000a8 Binary files /dev/null and b/content/blog/multichannel-led-driver/images/driver_output_ltspice_schematic.jpg differ diff --git a/content/blog/multichannel-led-driver/images/driver_pcb_built.jpg b/content/blog/multichannel-led-driver/images/driver_pcb_built.jpg new file mode 100644 index 0000000..f5da956 Binary files /dev/null and b/content/blog/multichannel-led-driver/images/driver_pcb_built.jpg differ diff --git a/content/blog/multichannel-led-driver/images/driver_ringing_strong.jpg b/content/blog/multichannel-led-driver/images/driver_ringing_strong.jpg new file mode 100644 index 0000000..0419a0e Binary files /dev/null and b/content/blog/multichannel-led-driver/images/driver_ringing_strong.jpg differ diff --git a/content/blog/multichannel-led-driver/images/driver_ringing_weak.jpg b/content/blog/multichannel-led-driver/images/driver_ringing_weak.jpg new file mode 100644 index 0000000..12f9c5d Binary files /dev/null and b/content/blog/multichannel-led-driver/images/driver_ringing_weak.jpg differ diff --git a/content/blog/multichannel-led-driver/images/led_strip_alight.jpg b/content/blog/multichannel-led-driver/images/led_strip_alight.jpg new file mode 100644 index 0000000..b001395 Binary files /dev/null and b/content/blog/multichannel-led-driver/images/led_strip_alight.jpg differ diff --git a/content/blog/multichannel-led-driver/images/linearization_setup.jpg b/content/blog/multichannel-led-driver/images/linearization_setup.jpg new file mode 100644 index 0000000..faafc92 Binary files /dev/null and b/content/blog/multichannel-led-driver/images/linearization_setup.jpg differ diff --git a/content/blog/multichannel-led-driver/images/olsndot_output_schematic.jpg b/content/blog/multichannel-led-driver/images/olsndot_output_schematic.jpg new file mode 100644 index 0000000..90941df Binary files /dev/null and b/content/blog/multichannel-led-driver/images/olsndot_output_schematic.jpg differ diff --git a/content/blog/multichannel-led-driver/images/olsndot_pcb.png b/content/blog/multichannel-led-driver/images/olsndot_pcb.png new file mode 100644 index 0000000..87b10f8 Binary files /dev/null and b/content/blog/multichannel-led-driver/images/olsndot_pcb.png differ diff --git a/content/blog/multichannel-led-driver/images/olsndot_schematic.png b/content/blog/multichannel-led-driver/images/olsndot_schematic.png new file mode 100644 index 0000000..69906e5 Binary files /dev/null and b/content/blog/multichannel-led-driver/images/olsndot_schematic.png differ diff --git a/content/blog/multichannel-led-driver/images/overshoot_sim_r0.svg b/content/blog/multichannel-led-driver/images/overshoot_sim_r0.svg new file mode 100644 index 0000000..004872b --- /dev/null +++ b/content/blog/multichannel-led-driver/images/overshoot_sim_r0.svg @@ -0,0 +1,1885 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/multichannel-led-driver/images/overshoot_sim_r100.svg b/content/blog/multichannel-led-driver/images/overshoot_sim_r100.svg new file mode 100644 index 0000000..c8efd61 --- /dev/null +++ b/content/blog/multichannel-led-driver/images/overshoot_sim_r100.svg @@ -0,0 +1,1788 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/multichannel-led-driver/images/pwm_schema.jpg b/content/blog/multichannel-led-driver/images/pwm_schema.jpg new file mode 100644 index 0000000..0265665 Binary files /dev/null and b/content/blog/multichannel-led-driver/images/pwm_schema.jpg differ diff --git a/content/blog/multichannel-led-driver/images/uncorrected_brightness_sim.svg b/content/blog/multichannel-led-driver/images/uncorrected_brightness_sim.svg new file mode 100644 index 0000000..28cb4be --- /dev/null +++ b/content/blog/multichannel-led-driver/images/uncorrected_brightness_sim.svg @@ -0,0 +1,727 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/blog/multichannel-led-driver/index.rst b/content/blog/multichannel-led-driver/index.rst new file mode 100644 index 0000000..7de03d5 --- /dev/null +++ b/content/blog/multichannel-led-driver/index.rst @@ -0,0 +1,456 @@ +--- +title: "32-Channel LED tape driver" +date: 2018-05-02T11:31:14+02:00 +--- + +Theoretical basics +================== + +Together, a friend and I outfitted the small staircase at Berlin's Chaos Computer Club with nice, shiny RGB-WW LED tape +for ambient lighting. This tape is like regular RGB tape but with an additional warm white channel, which makes for much +more natural pastels and whites. There are several variants of RGBW tape. Cheap ones have separate RGB and white LEDs, +which is fine for indirect lighting but does not work for direct lighting. Since we wanted to mount our tape in channels +at the front of the steps, we had to use the slightly more expensive variant with integrated RGBW LEDs. These are LEDs +in the 5050 (5.0mm by 5.0mm) form factor common with RGB LEDs that have a small section divided off for the white +channel. The red, green and blue LED chips sit together in the larger section covered with clear epoxy and the white +channel is made up from the usual blue LED inside a yellow phosphor in the smaller section. + +Since we wanted to light up all of 15 steps, and for greatest visual effect we would have liked to be able to control +each step individually we had to find a way to control 60 channels of LED tape with a reasonable amount of hardware. + +LED tape has integrated series resistors and runs off a fixed 12V or 24V constant-voltage supply. This means you don't +need a complex constant-current driver as you'd need with high-power LEDs. You can just hook up a section of LED tape +to a beefy MOSFET to control it. Traditionally, you would do *Pulse Width Modulation* (PWM) on the MOSFET's input to +control the LED tape's brightness. + +Pulse Width Modulation +---------------------- + +`Pulse Width Modulation`_ is a technique of controlling the brightness of a load such as an LED with a digital signal. +The basic idea is that if you turn the LED on and off much too fast for anyone to notice, you can control its power by +changing how long you turn it on versus how long you leave it off. + +PWM divides each second into a large number of periods. At the beginning of each period, you turn the LED on. After +that, you wait a certain time until you turn it off. Then, you wait for the next period to begin. The periods are always +the same length but you can set when you turn off the LED. If you turn it off right away, it's off almost all the time +and it looks like it's off to your eye. If you turn it off right at the end, it's on almost all the time and it looks +super bright to your eye. Now, if you turn it off halfway into the cycle, it's on half the time and it will look to your +eye as half as bright as before. This means that you can control the LED's brightness with only a digital signal and +good timing. + +.. raw:: html + +
+ A visualization of PWM at different duty cycles. +
Waveforms of two PWM cycles at different duty cycles.
+
+ +PWM works great if you have a dedicated PWM output on your microcontroller. It's extremely simple in both hardware and +software. Unfortunately for us, controlling 32 channels with PWM is not that easy. Cheap microcontrollers only have `a +handful of hardware PWM outputs`_, so we'd either have to do everything in software, bit-banging our LED modulation, or +we'd have to use a dedicated chip. + +Doing PWM in software is both error-prone and slow. Since the maximum dynamic range of a PWM signal is limited by the +shortest duty cycle it can do, software PWM being slow means it has poor PWM resolution at maybe 8 bits at most. Poor +color resolution is not a problem if all you're doing is to fade around the `HSV rainbow`_, but for ambient lighting +where you *really* want to control the brightness down to a faint shimmer you need all the color resolution you can get. + +If you rule out software PWM, what remains are dedicated `hardware PWM controllers`_. Most of these have either of three +issues: + +* They're expensive +* They don't have generous PWM resolution either (12 bits if you're lucky) +* They're meant to drive small LEDs such as a 7-segment display directly and you can't just hook up a MOSFET to their + output + +This means we're stuck in a dilemma between two poor solutions if we'd want to do PWM. Luckily for us, PWM is not the +only modulation in town. + +.. _`Pulse Width Modulation`: https://en.wikipedia.org/wiki/Pulse-width_modulation +.. _`a handful of hardware PWM outputs`: https://www.nxp.com/parametricSearch#/&c=c731_c380_c173_c161_c163&page=1 +.. _`HSV rainbow`: https://en.wikipedia.org/wiki/HSL_and_HSV +.. _`hardware PWM controllers`: http://www.ti.com/lit/ds/symlink/tlc5940.pdf + +Binary Code Modulation +---------------------- + +PWM is the bread-and-butter of the maker crowd. Everyone and their cat is doing it and it works really well most of the +time. Unbeknownst to most of the maker crowd, there is however another popular modulation method that's mostly used in +professional LED systems: Enter `*Binary Code Modulation* (BCM) `_. + +BCM is to PWM sort of what barcodes are to handwriting. While PWM is easy to understand and simple to implement if all +you have is a counter and an IO pin, BCM is more complicated. On the other hand, computers can do complicated and BCM +really shines in multi-channel applications. + +Similar to PWM, BCM works by turning on and off the LED in short periods fast enough to make your eye perceive it as +partially on all the time. In PWM the channel's brightness is linearly dependent on its duty cycle, i.e. the percentage +it is turned on. In PWM the duty cycle D is the total period T divided by the on period T_on. The issue with doing PWM +on many channels at once is that you have to turn off each channel at the exact time to match its duty cycle. +Controlling many IO pins at once with precise timing is really hard to do in software. + +BCM avoids this by further dividing each period into smaller periods which we'll call *bit periods* and splitting each +channel's duty cycle into chunks the size of these bit periods. The amazingly elegant thing in BCM now is that as you +can guess from the name these bit periods are weighted in powers of two. Say the shortest bit period lasts 1 +microsecond. Then the second-shortest bit period is 2 microseconds and the third is 4, the fifth 8, the sixth 16 and so +on. + +.. raw:: html + +
+ A visualization of BCM at different duty cycles. +
Waveforms of a single 4-bit BCM cycle at different duty cycles. This BCM can produce 16 different + levels.
+
+ +Staggered like this, you turn on the LED for integer value of microseconds by turning it on in the bit periods +corresponding to the binary bits of that value. If I want my LED to light for 19 microseconds every period, I turn it on +in the 16 microsecond bit period, the 2 microsecond bit period and the 1 microsecond bit period and leave it off for the +4 and 8 mircosecond bit periods. + +Now, how this is better instead of just more complicated than plain old PWM might not be clear yet. But consider this: +Turning on and off a large number of channels, each at its own arbitrary time is hard because doing the timing in +software is hard. We can't use hardware timers since we only have two or three of those, and we have 32 channels. +However, we can use one hardware timer to trigger a really cheap external latch to turn on or off the 32 channels all at +once. With this setup, we can only controll all channels at once, but we can do so with very precise timing. + +All we need to do is to set our timer to the durations of the BCM bit periods, and we can get the same result as we'd +get with PWM with only one hardware timer and a bit of code that is not timing-critical anymore. + +Applications of Binary Code Modulation +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +BCM is a truly wondrous technique, and outside of hobbyist circles it is in fact very widely known. Though we're using +it to control just 32 channels here, you can do much more channels without any problems. The most common application +where BCM is invariably used is *any* kind of LED screen. Controlling the thousands and thousands of LEDs in an LED +screen with PWM with a dedicated timer for each LED would not be feasible. With BCM, all you need to dedicate to a +single LED is a flipflop (or part of one if you're multiplexing). In fact, there is a whole range of `ICs with no other +purpose than to enable BCM on large LED matrices `_. Basically, these are a +high-speed shift register with latched outputs much like the venerable 74HC595_, only their outputs are constant-current +sinks made so that you can directly connect an LED to them. + +.. _74HC595: http://www.ti.com/lit/ds/symlink/sn74hc595.pdf + +Running BCM on LED tape +~~~~~~~~~~~~~~~~~~~~~~~ + +In our case, we don't need any special driver chips to control our LED tape. We just connect the outputs of a 74HC595_ +shift register to one MOSFET_ each, and then we directly connect the LED tape to these MOSFETs. The MOSFETs allow us to +drive a couple of amps into the LED tape from the weak outputs of the shift register. + +The BCM timing is done by hooking up two timer channels of our microcontroller to the shift registers *strobe* and +*reset* inputs. We set the timer to PWM mode so we can generate pulses with precise timing. At the beginning of each +bit period, a pulse will strobe the data for this bit period that we shifted in previously. At the end of the bit +period, one pulse will reset the shift register and one will strobe the freshly-reset zeros into the outputs. + +.. raw:: html + +
+ From left to right, we see the STM32, one of the shift + registers, and the LEDs and MOSFETs. The LED tape is driven to ground by the MOSFETs, which are in turn directly + driven from the shift register outputs. The shift register is wired up to the STM32 with its clock and data + inputs on SCK and MOSI and its RESET and STROBE inputs on channel 2 and 3 of timer 1. +
+ The schematic of a single output of this LED driver. Multiple shift register stages can be cascaded. +
+
+ + +Our implementation of this system runs on an STM32F030F4P6_, the smallest, cheapest ARM microcontroller you can get from +ST. This microcontroller has only 16kB of flash and 1kB of RAM, but that's plenty for our use. We use its SPI controller +to feed the modulation data to the shift registers really fast, and we use two timer channels to control the shift +registers' reset and strobe. + +We can easily cascade shift registers without any ill side-effects, and even hundreds of channels should be no problem +for this setup. The only reason we chose to stick to a 32-channel board is the mechanics of it. We thought it would be +easier to have several small boards instead of having one huge board with loads of connectors and cables coming off it. + +The BOM cost per channel for our system is 3ct for a reasonable MOSFET, about 1ct for one eighth of a shift register +plus less than a cent for one resistor between shift register and MOSFET. In the end, the connectors are more expensive +than the driving circuitry. + +.. _MOSFET: https://en.wikipedia.org/wiki/MOSFET +.. _STM32F030F4P6: http://www.st.com/resource/en/datasheet/stm32f030f4.pdf + +Hardware design +=============== + +From this starting point, we made a very prototype-y hardware design for a 32-channel 12V LED tape driver. The design is +based on the STM32F030F4P6_ driving the shift registers as explained above. The system is controlled through an RS485_ +bus that is connected up to the microcontroller's UART using an MAX485_-compatible RS485 transceiver. The LED tape is +connected using 9-pin SUB-D_ connectors since they are cheap and good enough for the small current of our short segments +of LED tape. The MOSFETs we use are small SOT-23_ logic-level MOSFETs. In various prototypes we used both International +Rectifier's IRLML6244_ as well as Alpha & Omega Semiconductor's AO3400_. Both are good up to about 30V/5A. Since we're +only driving about 2m of LED tape per channel we're not going above about 0.5A and the MOSFETs don't even get warm. + +.. _RS485: https://en.wikipedia.org/wiki/RS-485 +.. _MAX485: https://datasheets.maximintegrated.com/en/ds/MAX1487-MAX491.pdf +.. _IRLML6244: https://www.infineon.com/dgdl/?fileId=5546d462533600a4015356686fed261f +.. _AO3400: http://aosmd.com/pdfs/datasheet/AO3400.pdf +.. _SUB-D: https://en.wikipedia.org/wiki/D-subminiature +.. _SOT-23: http://www.nxp.com/documents/outline_drawing/SOT23.pdf + +Switching nonlinearities +------------------------ +During testing of our initial prototype, we noticed that the brightness seemed to jump around when fading to very low +values. It turned out that our extremely simple LED driving circuit consisting of only the shift register directly +driving a MOSFET, which in turn directly drives the LED tape was maybe a little bit too simple. After some measurements +it turned out that we were looking at about 6Vpp of ringing on the driver's output voltage. The picture below is the +voltrage we saw on our oscilloscope on the LED tape. + +.. raw:: html + +
+ Strong ringing on the LED voltage waveform edge at about + 100% overshoot during about 70% of the cycle time. +
Bad ringing on the LED output voltage caused by wiring inductance. Note that the effect on the + actual LED current is less bad than this looks since the LED's V/I curve is nonlinear.
+
+ + +Dynamic switching behavior: Cause and Effect +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A bit of LTSpice_ action later we found that the inductance of the few metres of cable leading to the LED tape is the +likely culprit. The figure below is the schematic used for the simulations. + +.. raw:: html + +
+ The LTSpice schematic of one output of the driver, + taking into account the shift register's output ESR and the wiring ESL. +
The schematic of the simulation in LTSpice
+
+ +As tested, the driver does not include any per-output smoothing so the ~.5A transient on each BCM cycle hits the cable +in full. Combined with the cable inductance, this works out to a considerable lag of the rising edge of the LED +current, and bad ringing on its falling edge. Below is the voltage on the LED output from an LTSpice simulation of our +driver. + +.. raw:: html + +
+ The result of the LTSpice simulation of our driver output. The LED + current shows similar ringing to what we measured using the oscilloscope. Interestingly, the gate voltage shows + strong ringing, too. +
The result of our LTSpice simulation. This simulation assumes 1µH of wiring inductance and 50Ω of + output impedance on the part of the shift register. The ringing at the gate visible in the gate voltage graph is + due to feed-through of the ringing at the output through the MOSFET's parasitic Cgd.
+
+ +We were able to reduce the rining and limit the effect somewhat by putting a 220Ω series resistor in between the shift +register output and the MOSFET gate. This resistor forms an RC circuit with the MOSFET's nanofarad or two of gate +capacitance. The result of this is that the LED current passing the wire's ESL rises slightly more slowly and thus the +series inductance gets excited slightly less, and the overshoot decreases. Below is a picture of the waveform with the +damping resistor in place and a picture of our measurement for comparison. The resistor values don't agree perfectly +since the estimated ESL and stray capacitance of the wiring is probably way off. + +.. raw:: html + +
+ Weak ringing on the LED voltage waveform edge at about 30% + overshoot during about 20% of the cycle time. +
Adding a resistor in front of the MOSFET gate to slow the transition damped the ringing somewhat, + but ultimately it cannot be eliminated entirely. Note how you can actually see the miller plateau on the + trailing edge of this signal. +
+
+ +.. raw:: html + +
+ The result of the LTSpice simulation of our driver output with an + extra 100 Ohms between shift register output and MOSFET gate. Similar to the oscilloscope measurement the + ringing is much reduced in its amplitude. +
The LTSpice simulation result with the same parameters as above but with an extra 100Ω between the + shfit register's output and the MOSFET's gate.
+
+ +A side effect of this fix is that now the effective on-time of the LED tape is much longer than the duty cycle at the +shift register's output at very small duty cycles (1µs or less). This is caused by the MOSFET's `miller +plateau`_. For illustration, below is a graph of both the excitation waveform (the boxy line) and the resulting LED +current (the other ones) both without damping (top) and with 220Ω damping (bottom). As you can see the effective duty +cycle of the LED current is not at all equal to the 50% duty cycle of the excitation square wave. + +.. raw:: html + +
+ The result of an LTSpice simulation of the LED duty cycle without and + with damping. Dampening widens the LED current waveform from 50% duty cycle with sharp edges to about 80% duty + cycle with soft edges. +
Simulated LED duty cycle with and without damping. The damping resistance used in this simulation + was 220Ω.
+
+ +.. raw:: html + +
+ The gate voltages in the spice simulation above. The undamped + response shows sharp edges with the miller plateau being a barely noticeable step, but with strong ringing on + the trailing edge. The damped response shows RC-like slow-edges, but has wide miller plateaus on both edges + adding up to about 50% of the pulse width. +
The MOSFET gate voltage from the simulation in the figure above. You can clearly see how the miller + plateau (the horizontal part of the trace at about 1V) is getting much wider with added damped, and how the + resulting gate charge/discharge curve is not at all that of a capacitor anymore.
+
+ + + +In conclusion, we have three major causes for our calculated LED brightness not matching reality: + +* Ringing of the equivalent series inductance of the wiring leading up to the LED tape +* Miller plateau lag +* The damping resistor and the MOSFET gate forming an RC filter that helps with wire ESL ringing but worsens the miller + plateau issue and deforms the LED current edges. + +Added up, these three effects yield a picture that agrees well with our simulations and measurements. The overall effect +is neglegible at long period durations (>10µs), but gets really bad at short period durations (<1µs). The effect is +non-linear, so correcting for it is not as simple as adding an offset. + +.. _LTSpice: http://www.analog.com/en/design-center/design-tools-and-calculators/ltspice-simulator.html +.. _`miller plateau`: https://www.vishay.com/docs/68214/turnonprocess.pdf + +Measuring LED tape brightness +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In order to correct for the nonlinearities mentioned above, we decided to implement a lookup table mapping BCM period to +actual timer setting. That is, each row of the table contains the actual period length we need to set the +microcontroller's timer to in order to get our intended brightness steps. + +To calibrate our driver, we needed a setup for reproducible measurement of the relative brightness of our LED tape at +different settings. Absolute brightness is not of interest to us as the eye can't perceive it. To perform the +calibration, the LED driver is set to enable each single BCM period in turn, i.e. brightness values 1, 2, 4, 8, 16 etc. + +The setup we used to measure the LED tape's brightness consists of a bunch of LED tape stuck into a tin can for +shielding against both stray light and electromagnetic interference and a photodiode looking at the LED tape. We used +the venerable BPW34_ photodiode in our setup as I had a bunch leftover from another project and because they are quite +sensitive owing to their physically large die area. + +.. raw:: html + +
+ The led measurement setup consists of several PCBs and a + breadboard linked with a bunch of wires and a big tin can to shield the LEDs and the photodiode. A large sub-D + connector is put into the top of the tin can as a feed-through for the LED tape's control signals and the + photodiode signal. In the background the control laptop is visible. +
The LED brighness measurement setup. The big tin can contains a bunch of LED tape and the + photodiode. The breadboard on the right is used for the photodiode preamplifier and for jumpering around the LED + tape's channels. The red board next to it is the buspirate used as ADC. The board on the bottom left is a + TTL-to-RS485 converter and the board in the middle is the unit under test.
+
+ +The photodiode's photocurrent is converted into a voltage using a very simple transimpedance amplifier based around a +MCP6002_ opamp that was damped into oblivion with a couple nanofarads of capacitance in its feedback loop. The MCP6002_ +is a fine choice here since I had a bunch and because it is a CMOS opamp, meaning it has low bias current that would +mess up our measurements. For many applications, opamp bias current is not a big issue but when using the opamp to +directly measure very small currents at its input it quickly swamps out the signal for most BJT-input types. + +The transimpedance amplifier's output is read from the computer using the ADC input of a buspirate USB thinggamajob. In +general I would not recommend the buspirate as a tool for this job since it's ADC is not particularly good and it's +programming interface is positively atrocious, but it was what I had and it beat first wiring up one of the dedicated +ADC chips I had in my parts bin. + +The computer runs a small python script cycling the LED tape through all its BCM period settings and taking a brightness +measurement at each step. Later on, these measurements can be plotted to visualize the resulting slope's linearity, and +we can even do a simulation of the resulting brightness for all possible control values by just adding the measured +photocurrents for a certain BCM setpoint just as our retinas would do. + +.. raw:: html + +
+ +
+ A plot of the measured brightness of our LED tape for each BCM period. The brightness values are normalized + to the value measured at the LSB setpoint (brightness=1/65535). Ideally, this plot would show a straight + line with slope 1. Obviously, it doesn't. The bend in the curve is caused by the above-mentioned duty cycle + offset adding an offset to all brightness values. Shown is both the raw data (light), which has essentially zero + measurement error and a linear fit (dark). + + The plot is in log-log to approximate how the human eye would perceive brightness, i.e. highly sensitive at + low values but not very sensitive at all at large values. +
+
+ +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. + +.. raw:: html + +
+
+ +
+ 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. +
+
+ +
+ Brightness curve for the corrected BCM setup extrapolated using actual measurements. Looks as buttery + smooth in real life as it does in this plot. +
+ +
+
+ +.. _BPW34: http://www.vishay.com/docs/81521/bpw34.pdf +.. _MCP6002: http://ww1.microchip.com/downloads/en/DeviceDoc/21733j.pdf + +Controlling the driver +---------------------- + +Now that our driver was behaving linear enough that you couldn't see it actually wasn't we needed a nice way to control +it from a computer of our choice. In the ultimate application (our staircase) we'll use a raspberry pi for this. Since +we already settled on an RS485_ bus for its robustness and simplicity, we had to device a protocol to control the driver +over this bus. Here, we settled on a simple, COBS_-based protocol for the reasons I wrote about in `How to talk to your +microcontroller over serial `_. + +To address our driver nodes, we modified the Makefile to build a random 32-bit MAC into each firmware image. The +protocol has only five message types: + +1. A 0-byte *ping* packet, to which each node would reply with its own address in the + first 100ms after boot. This can be used to initially discover the addresses of all nodes connected to the bus. You'd + spam the bus with *ping* packets, and then hit reset on each node in turn. The control computer would then receive + each device's MAC address as you hit reset. +2. A 4-byte *address* packet that says which device that the following packet is for. This way of us using the packet + length instead of a packet type field is not particularly elegant, but our system is simple enough and it was easy to + implement. +3. A 64-byte *frame buffer* packet that contains 16 bits of left-aligned brightness data for every channel +4. A one-byte *get status* packet that tells the device to respond with... +5. ...a 27-byte status packet containing a brief description of the firmware (version number, channel count, bit depth + etc.) as well as the device's current life stats (VCC, temperature, uptime, UART frame errors etc.). + +Wrapped up in a nice python interface we can now easily enumerate any drivers we connect to a bus, query their status +and control their outputs. + +.. _COBS: https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing + +Conclusion +---------- + +.. raw:: html + +
+
+ + A picture of the LED driver schematic + +
The LED driver schematic
+
+ + A picture of the LED driver PCB layout + +
The LED driver PCB layout
+
+
+ +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. + +Get a PDF file of the schematic and PCB layout `here `__ or download the CAD files +and the firmware sources `from github `_. You can view the Jupyter notebook used to +analyze the brightness measurement data `here `__. + diff --git a/content/blog/multichannel-led-driver/olsndot_v02_schematics_and_pcb.pdf b/content/blog/multichannel-led-driver/olsndot_v02_schematics_and_pcb.pdf new file mode 100644 index 0000000..2a4e037 Binary files /dev/null and b/content/blog/multichannel-led-driver/olsndot_v02_schematics_and_pcb.pdf differ diff --git a/content/blog/private-contact-discovery/index.rst b/content/blog/private-contact-discovery/index.rst new file mode 100644 index 0000000..797de50 --- /dev/null +++ b/content/blog/private-contact-discovery/index.rst @@ -0,0 +1,38 @@ +--- +title: "Private Contact Discovery" +date: 2019-06-22T10:30:00+08:00 +--- + +Private Contact Discovery +========================= + +Private Contact Discovery (PCD) is the formal name for the problem modern smartphone messenger applications have on +installation: Given a user's address book, find out which of their contacts also use the same messenger without the +messenger's servers learning anything about the user's address book. The widespread non-private way to do this is to +simply upload the user's address book to the app's operator's servers and do an SQL JOIN keyed on the phone number field +against the database of registered users. People have tried sprinkling some hashes over these phone numbers in an +attempt to improve privacy, but obviously running a brute-force preimage attack given a domain of maybe a few billion +valid inputs is not cryptographically hard. + +Private Contact Discovery can be phrased in terms of Private Set Intersection (PSI), the cryptographic problem of having +two parties holding one set each find the intersection of their sets without disclosing any other information. PSI has +been an active field of research for a while and already yielded useful results for some use cases. Alas, none of those +results were truly practical yet for usage in PCD in a typical messenger application. They would require too much CPU +time or too much data to be transferred. + +At USENIX Security 2019, Researchers from technical universities Graz and Darmstadt published a paper titled *Private +Contact Discovery at Scale* +(`eprint `__ | `PDF `__). +In this paper, they basically optimize the hell out of existing cryptographic solutions to private contact discovery, +jumping from a still-impractical state of the art right to practicality. Their scheme allows a client with 1k contacts +to run PCD against a server with 1B contacts in about 3s on a phone. The main disadvantage of their scheme is that it +requires the client to in advance download a compressed database of all users, that clocks in at about 1GB for 1B users. + +I found this paper very interesting for its immediate practical applicability. As an excuse to dig into the topic some +more, I gave a short presentation at my university lab's research seminar on this paper +(slides: `PDF `__ | `ODP `__). + +Even if you're not working on secure communication systems on a day-to-day basis this paper might interest you. If +you're working with social account information of any kind I can highly recommend giving it a look. Not only might your +users benefit from improved privacy, but your company might be able to avoid a bunch of data protection and +accountability issues by simply not producing as much sensitive data in the first place. diff --git a/content/blog/private-contact-discovery/mori_semi_psi_talk.odp b/content/blog/private-contact-discovery/mori_semi_psi_talk.odp new file mode 100644 index 0000000..e7df32e Binary files /dev/null and b/content/blog/private-contact-discovery/mori_semi_psi_talk.odp differ diff --git a/content/blog/private-contact-discovery/mori_semi_psi_talk.pdf b/content/blog/private-contact-discovery/mori_semi_psi_talk.pdf new file mode 100644 index 0000000..e06fd63 Binary files /dev/null and b/content/blog/private-contact-discovery/mori_semi_psi_talk.pdf differ diff --git a/content/blog/serial-protocols/index.rst b/content/blog/serial-protocols/index.rst new file mode 100644 index 0000000..2f9bb2d --- /dev/null +++ b/content/blog/serial-protocols/index.rst @@ -0,0 +1,249 @@ +--- +title: "How to talk to your microcontroller over serial" +date: 2018-05-19T08:09:46+02:00 +--- + +Scroll to the end for the `TL;DR `_. + +In this article I will give an overview on the protocols spoken on serial ports, highlighting common pitfalls. I will +summarize some points on how to design a serial protocol that is simple to implement and works reliably even under error +conditions. + +If you have done low-level microcontroller firmware you will regularly have had to stuff some data up a serial port to +another microcontroller or to a computer. In the age of USB, an old-school serial port is still the simplest and +quickest way to get communication to a control computer up and running. Integrating a ten thousand-line USB stack into +your firmware and writing the necessary low-level drivers on the host side might take days. Poking a few registers to +set up your UART to talk to an external hardware USB to serial converter is a matter of minutes. + +This simplicity is treacherous, though. Oftentimes, you start writing your serial protocol as needs arise. Things might +start harmless with something like ``SET_LED ON\n``, but as the code grows it is easy to end up in a hot mess of command +modes, protocol states that breaks under stress. The ways in which serial protocols break are manifold. The simplest one +is that at some point a character is mangled, leading to both ends of the conversation ending up in misaligned protocol +states. With a fragile protocol, you might end up in a state that is hard to recover from. In extreme cases, this leads +to code such as `this gem`_ performing some sort of arcane ritual to get back to some known state, and all just because +someone did not do their homework. Below we'll embark on a journey through the lands of protocol design, exploring the +facets of this deceptively simple problem. + +.. _`this gem`: https://github.com/juhasch/pyBusPirateLite/blob/dece35f6e421d4f6a007d1db98d148e2f2126ebb/pyBusPirateLite/base.py#L113 + +Text-based serial protocols +=========================== + +The first serial protocol you've likely written is a human-readable, text-based one. Text-based protocols have the big +advantage that you can just print them on a terminal and you can immediately see what's happening. In most cases you can +even type out the protocol with your bare hands, meaning that you don't really need a debugging tool beyond a serial +console. + +However, text-based protocols also have a number of disadvantages. Depending on your application, these might not matter +and in many cases a text-based protocol is the most sensible solution. But then, in some cases they might and it's good +to know when you hit one of them. + +Problems +-------- + +Low information density +~~~~~~~~~~~~~~~~~~~~~~~ + +Generally, you won't be able to stuff much more than four or five bit of information down a serial port using a +single byte of a human-readable protocol. In many cases you will get much less. If you have 10 commands that are only +issued a couple times a second nobody cares that you spend maybe ten bytes per command on nice, verbose strings such as +``SET LED``. But if you're trying to squeeze a half-kilobyte framebuffer down the line you might start to notice the +difference between hex and base-64 encoding, and a binary protocol might really be more up to the job. + +Complex parsing code +~~~~~~~~~~~~~~~~~~~~ + +On the computer side of thing, with the whole phalanx of an operating system, the standard library of your programming +language of choice and for all intents and purposes unlimted CPU and memory resources to spare you can easily parse +anything spoken on a serial port in real time, even at a blazing fast full Megabaud. The microcontroller side however is +an entirely different beast. On a small microcontroller, printf_ alone will eat about half your flash. On most small +microcontrollers, you just won't get a regex library even though it would make parsing textual commands *so much +simpler*. Lacking these resources, you might end up hand-knitting a lot of low-level C code to do something seemingly +simple such as parsing ``set_channel (13, 1.1333)\n``. These issues have to be taken into account in the protocol design +from the beginning. For example, you don't really need matching parentheses, don't use them. + +Fragile protocol state +~~~~~~~~~~~~~~~~~~~~~~ + +Say you have a ``SET_DISPLAY`` command. Now say your display can display four lines of text. The obvious approach to this +is probably the SMTP_ or HTTP_ way of sending ``SET_DISPLAY\nThis is line 1\nThis is line 2\n\n``. This would certainly +work, but it is very fragile. With this protocol, you're in trouble if at any point the terminating second newline +character gets mangled (say, someone unplugs the cable, or the control computer reboots, or a cosmic ray hits something +and ``0x10 '\n'`` turns into ``0x50 'P'``). + +.. _SMTP: https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol +.. _HTTP: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol + +Timeouts don't work +~~~~~~~~~~~~~~~~~~~ + +You might try to solve the problem of your protocol state machine tangling up with a timeout. "If I don't get a valid +command for more than 200ms I go back to default state." But consider the above example. Say, your control computer +sends a ``SET_DISPLAY`` command every 100ms. If in one of them the state machine tangles up, the parser hangs since the +timeout is never hit, because a new line of text is arriving every 100ms. + +Framing is hard +~~~~~~~~~~~~~~~ + +You might also try to drop the second newline and using a convention such as ``SET_DISPLAY`` is followed by two lines of +text, then commands resume.". This works as long as your display contents never look like commands. If you are only ever +displaying the same three messages on a character LCD that might work, but if you're displaying binary framebuffer +data you've lost. + +Solutions +--------- + +Keep the state machine simple +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In a text-based protocol, always use a single line of text to represent a single command. Don't do protocol states or +modes where you can toggle between different interpretations for a line. If you have to send human-readable text as part +of a command (such as ``SET_DISPLAY``), escape it so it doesn't contain any newlines. + +This way, you keep your protocol state machine simple. If at any time your serial trips and flips a bit or looses a byte +your protocol will recover on the next newline character, returning to its base state. + +Encode numbers in hex when possible +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Printing a number in hexadecimal is a very tidy operation, even on the smalest 8-bit microcontrollers. In contrast, +printing decimal requires both division and remainder in a loop which might get annoyingly code- and time-intensive on +large numbers (say a 32-bit int) and small microcontrollers. + +If you have to send fractional values, consider their precision. Instead of sending a 12 bit ADC result as a 32-bit +float formatted like ``0.176513671875`` sending ``0x2d3`` and dividing by 4096 on the host might be more sensible. If you +really have to communicate big floats and you can't take the overhead of including both printf_ and scanf_ you can +use hexadecimal floating point, which is basically ``hex((int)foo) + "." + hex((int)(65536*(foo - (int)foo)))`` for four +digits. You can also just hex-encode the binary IEEE-754_ representation of the float, sending ``hex(*(int *)&float)``. +Most programming languages will have a `simple, built-in means to parse this sort of thing +`__. + +.. _printf: http://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c +.. _scanf: http://git.musl-libc.org/cgit/musl/tree/src/stdio/vfscanf.c +.. _IEEE-754: https://en.wikipedia.org/wiki/IEEE_754 + +Escape multiline strings +~~~~~~~~~~~~~~~~~~~~~~~~ + +If you have to send arbitrary strings, escape special characters. This not only has the advantage of yielding a robust +protocol: It also ensures you can actually see everything that's going on when debugging. The string ``"\r\n"`` is easy to +distinguish from ``"\n"`` while your terminal emulator might not care. + +The simplest encoding to use is the C-style backslash encoding. Host-side, most languages will have a `built-in means of +escaping a string like that `__. + +Encoding binary data +-------------------- + +For binary data, hex and base-64 are the most common encodings. Since hex is simpler to implement I'd go with it unless +I really need the 30% bandwidth improvement base-64 brings. + +Binary serial protocols +======================= + +In contrast to anything human-readable, binary protocols are generally more bandwidth-efficient and are easier to format +and parse. However, binary protocols come with their own version of the caveats we discussed for text-based protocols. + +The framing problem in binary protocols +--------------------------------------- + +The most basic problems with binary protocols as with text-based ones is framing, i.e. splitting up the continuous +serial data stream into discrete packets. The issue is that it is that you have to somehow mark boundaries between +frames. The simplest way would be to use some special character to delimit frames, but then any 8-bit character you +could choose could also occur within a frame. + +SLIP/PPP-like special character framing +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Some protocols solve this problem much like we have solved it above for strings in line-based protocols, by escaping any +occurence of the special delimiter character within frames. That is, if you want to use ``0x00`` as a delimiter, you would +encode a packet containing ``0xde 0xad 0x00 0xbe 0xef`` as something like ``0xde 0xad 0x01 0x02 0xbe 0xef``, replacing the +null byte with a magic sequence. This framing works, but is has one critical disadvantage: The length of the resulting +escaped data is dependent on the raw data, and in the worst case twice as long. In a raw packet consisting entirely of +null bytes, every byte must be escaped with two escape bytes. This means that in this case the packet length doubles, +and in this particular case we're even less efficient than base-64. + +Highly variable packet length is also bad since it makes it very hard to make any timing guarantees for our protocol. + +9-bit framing +~~~~~~~~~~~~~ + +A framing mode sometimes used is to configure the UARTs to transmit 9-bit characters and to use the 9th bit to designate +control characters. This works really well, and gives plenty of control characters to work with. The main problem with +this is that a 9-bit serial interface is highly nonstandard and you need UARTs on both ends that actually support this +mode. Another issue is that though more efficient than both delmitier-based and purely text-based protocols, it still +incurs an extra about 10% of bandwidth overhead. This is not a lot if all you're sending is a little command every now +and then, but if you're trying to push large amounts of data through your serial it's still bad. + +COBS +~~~~ + +Given the limitations of the two above-mentioned framing formats, we really want something better. The `Serial Line +Internet Protocol (SLIP)`_ as well as the `Point to Point Protocol (PPP)`_, standardized in 1988 and 1994 respectively, +both use escape sequences. This might come as a surprise, but humanity has actually still made significant technological +progress on protocols for 8-bit serial interfaces until the turn of the millennium. In 1999, `Consistent Overhead Byte +Stuffing (COBS)`_ (`wiki `__) was published by a few +researchers from Apple Computer and Stanford University. As a reaction on the bandwidth doubling problem present in +PPP_, COBS *always* has an overhead of a single byte, no matter what or how long a packet's content is. + +COBS uses the null byte as a delimiter interleaves all the raw packet data and a `run-length encoding`_ of the non-zero +portions of the raw packet. That is, it prepends the number of bytes until the first zero byte to the packet, plus one. +Then it takes all the leading non-zero bytes of the packet, unmodified. Then, it again encodes the distance from the +first zero to the second zero, plus one. And then it takes the second non-zero run of bytes unmodified. And so on. At +the end, the packet is terminated with a zero byte. + +The result of this scheme is that the encoded packet does not contain any zero bytes, as every zero byte has been +replaced with the number of bytes until the next zero byte, plus one, and that can't be zero. Both formatter and parser +each have to keep a counter running to keep track of the distances between zero bytes. The first byte of the packet +initializes that counter and is dropped by the parser. After that, every encoded byte received results in one raw byte +parsed. + +While this might sound more complicated than the escaping explained above, the gains in predictability and efficiency +are worth it. An implementation of encoder and decoder should each be about ten lines of C or two lines of Python. A +minor asymmetry of the protocol is that while decoding can be done in-place, encoding either needs two passes or you +need to scan forward for the next null byte. + +.. _`Point to Point Protocol (PPP)`: https://en.wikipedia.org/wiki/Point-to-Point_Protocol +.. _PPP: https://en.wikipedia.org/wiki/Point-to-Point_Protocol +.. _`Serial Line Internet Protocol (SLIP)`: https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol +.. _`Consistent Overhead Byte Stuffing (COBS)`: http://www.stuartcheshire.org/papers/COBSforToN.pdf +.. _`Point-to-Point Protocol (PPP)`: https://en.wikipedia.org/wiki/Point-to-Point_Protocol +.. _`run-length encoding`: https://en.wikipedia.org/wiki/Run-length_encoding + +State machines and error recovery +--------------------------------- + +In binary protocols even more than in textual ones it is tempting to build complex state machines triggering actions on +a sequence of protocol packets. Please resist that temptation. As with textual protocols keeping the protocol state to +the minimum possible allows for a self-synchronizing protocol. A serial protocol should be designed such that if due to +a dropped packet or two both ends will naturally re-synchronize within another packet or two. A simple way of doing that +is to always transmit one semantic command per packet and to design these commands in the most idempotent_ way possible. +For example, when filling a framebuffer piece by piece, include the offset in each piece instead of keeping track of it +on the receiving side. + +.. _idempotent: https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning + +Conclusion +========== + +Here's your five-step guide to serial bliss: + +1. Unless you have super-special requirements, always use the slowest you can get away with from 9600Bd, 115200Bd or + 1MBd. 8N1 framing if you're talking to anything but another microcontroller on the same board. Using common values + like these makes it easier when you'll inevitably have to guess these at some point in the future ;) +2. If you're doing something simple and speed is not a particular concern, use a human-readable text-based protocol. Use + one command/reply per line, begin each line with some sort of command word and format numbers in hexadecimal. Bonus + points for the device replying to unknown commands with a human-readable status message and printing a brief protocol + overview on boot. +3. If you're doing something even slightly nontrivial or need moderate throughput (>1k commands per second or >20 byte of + data per command) use a COBS-based protocol. A good starting point is a ``[target MAC][command ID][command + arguments]`` packet format for multidrop busses. For single-drop you may decide to drop the MAC address. +4. Always include some sort of "status" command that prints life stats such as VCC, temperature, serial framing errors + and uptime. You'll need some sort of ping command anyway and that command might as well do something useful. +5. If at all possible, keep your protocol context-free across packets/lines. That is, a certain command should always be + self-contained, and no command should change the meaning of the next packet/line/command that is sent. This is really + important to allow for self-synchronization. If you really need to break up something into multiple commands, say you + want to set a large framebuffer in pieces, do it in a idempotent_ way: Instead of sending something like ``FRAMEBUFFER + INCOMING:\n[byte 0-16]\n[byte 17-32]\n[...]\nEND OF FRAME`` rather send ``FRAMEBUFFER DATA FOR OFFSET 0: [byte + 0-16]\nFRAMEBUFFER DATA FOR OFFSET 17: [byte 17-32]\n[...]\nSWAP BUFFERS\n``. + diff --git a/content/blog/sybil-resistance-identity/images/succulents.jpg b/content/blog/sybil-resistance-identity/images/succulents.jpg new file mode 100755 index 0000000..938bffd Binary files /dev/null and b/content/blog/sybil-resistance-identity/images/succulents.jpg differ diff --git a/content/blog/sybil-resistance-identity/index-old.rst b/content/blog/sybil-resistance-identity/index-old.rst new file mode 100644 index 0000000..6f1bee3 --- /dev/null +++ b/content/blog/sybil-resistance-identity/index-old.rst @@ -0,0 +1,244 @@ +--- +title: "Theia Attack Resistance and Digital Identity" +date: 2020-09-09T15:00:00+02:00 +--- + +.. raw:: html + +
+ +
Photo by Tim Bennett on Unsplash
+
+ + +Theia in Cyberspace +=================== + +In informatics, the term *distributed system* is used to describe the aggregate behavior of a complex network made up of +individual computers. For decades, computer scientists to some success have been trying to figure out how exactly the +individual computers that make up such a distributed system need to be programmed for the resulting amalgamation to +behave in a predictable, maybe even a desirable way. Though seemingly simple on its surface, this problem has a +surprising depth to it that has yielded research questions for a whole field for several decades now. One particular +as-of-yet unsolved problem is resistance against *theia attacks* (or "sybil" attacks in older terminology). + + Named after the 1973 book by Flora Rheta Schreiber on dissociative identity disorder, a sybil attack is an + attack where one computer in a distributed system pretends to be multiple computers to gain an advantage. From your + author's standpoint, naming a type of computer security attack after a medical condition was an unfortunate choice. + For this reason this post uses the term *Theia attack* to refer to the same concept. Theia is a greek godess of light + and glitter and the name alludes to the attacker performing something alike an optical illusion, causing the attacked + to perceive multiple distinct images that in the end are all only reflections of the same attacker. + +The core insight of computer science research on theia attacks is that there cannot be any technological way of +preventing such an attack, and any practical countermeasure must be grounded in some authority or ground truth that is +external to the systems—bridging from technology to its social or political context. + +Looking around, we can see a parallel between this question ("which computer is a real computer?") and a social issue +that recently has been growing in importance: Just like computers can pretend to be other computers, they can also +pretend to be humans. As can humans. Be it within the context of election manipulation or down-to-earth astroturfing_ +the recurring issue is that in today's online communities, it is hard for an individual to tell who of their online +acquaintances are who they seem to be. Different platforms attempt different solutions to this problem, and all fail in +some way or another. Facebook employs good old snitching, turning people against each other and asking them "Do you know +this person?". Twitter is more laid-back and avoids this Stasi_ methodology in favor of requiring a working mobile phone +number from its subjects, essentially short-circuiting identity verification to the phone company's check of their +subscriber's national passport. + +.. the preceding is a simplified representation of these platform's practices. In particular facebook uses several + methods depending on the case. I think this abbreviated discussion should be ok for the sake of the argument. I am + not 100% certain on the accuracy on the accuracy of the statement though. Does fb still do the snitching thing? Is + twitter usually content with a phone number? + +Trusting Crypto-Anarchist Authorities +===================================== + +Beyond these centralistic solutions to the problem, crypto-anarchists and anarcho-capitalists have been brewing on some +interesting novel approaches to online identity based on *blockchain* distributed ledger technology. Distributed +ledgers are a distributed systems design pattern that yields a system that works like an append-only logbook. +Participants can create new entries in this logbook, but no one—neither the original author, nor other participants—can +retroactively change a logbook entry once it has been written. In the blockchain model, past entries are essentially +written into stone. This near-perfect immutability is what opens them for a number of use cases from cryptographic +pseudo-currencies [#cryptocurrency]_. + +An overview over a variety of these unconventional blockchain identity verification approaches can be found in `this +unpublished 2020 survey by Siddarth, Ivliev, Siri and Berman `_. +They walk their readers through a number of different projects that try to solve the question "Is this human who they +pretend to be?" using joint socio-technological approaches. In the following few sections, you may find a short outline +of a small selection of them. The conlusion of this post will be a commentary on these approaches, and on the underlying +problem of identity in a digital world. + +.. BrightID + +In one scheme, identity is determined by "notary" computers that aggregate large amounts of information on a user's +social contacts. These computers then run an algorithm derived from the SybilGuard_, SybilLimit_ and SybilInfer_ lineage +of random-walk based algorithms. These algorithms assume that authentic social graphs are small world graphs: Everyone +knows everyone else through a friend's friend's friend. They also assume that there is an upper bound on how many +connections with authentic users an attacker can forge: Anyone who is not embedded into the graph well enough is cut +out. Like this, they put an upper limit on the number of theia identites an attacker can assume given a certian number +of connections to real people. + +Disregarding the catastrophic privacy issues of storing large amounts of data on social relationships on someone else's +computer, this second assumption is where this model unfortunately breaks down. Applying common sense, it is completely +realistic for an attacker to forge a large number of social connections: This is precisely what most of social media +marketing is about! A more malicious angle on this would be to consider how in meatspace [#meatspacefn]_ multi-level +marketing schemes are successful in coaxing people to abuse their social graphs to disastrous consequences to the +well-being of themselves and others. Similar schemes would certainly be possible in cyberspace as well. An additional +point to consider is that the upper limit SybilGuard_ and others place on the number of fake identities one can have is +simply not that strict at all. An attacker could still get away with a reasonable number of false identities before +getting caught by any such algorithm. + +.. Duniter + +In another scheme, identity is awarded to anyone who can convince several people already in the network to vouch for +them, and who is at most a few degrees removed from one of several pre-determined celebrities. Apart from again being +vulnerable to conmen and other scammers, this system has the glaring flaw of roundly refusing to recognize any person +who is not willing or able to engage with multiple of its members. Along with the system's informal requirement for +members to only vouch for people they have physically met this leads to a nonstarter in a cyberspace that grown +specifically *because* it transcends national borders and physical distance—two most serious obstacles to in-person +communication. + +.. Idena Network + +The last scheme I will outline in this post is based around a set of `Turing tests`_; that is, quizzes that are designed +to tell apart man and machine. In this system, all participants have to simultaneously undergo a Turing test once in a +fortnight. The idea is that this limits the number of theia identities an attacker can assume since they can only solve +that many Turing tests at the same time. The system uses a particular type of picture classification-based Turing test +and does not seem to be designed with the blind or mentally disabled in mind with accessibility concerns nowhere to be +found in the so-called "manifesto" published by its creators. But even ignoring that, the system obviously fails at an +even more basic level: The idea that everyone takes a Turing test at the same time only works in a world without time +zones. Or jobs for that matter. Also, it assumes that an attacker cannot simply hire a small army of people someplace +else to fool the system. + +.. _SybilLimit: https://www.comp.nus.edu.sg/~yuhf/yuh-sybillimit.pdf +.. _SybilGuard: http://www.math.cmu.edu/~adf/research/SybilGuard.pdf +.. _SybilInfer: https://www.princeton.edu/~pmittal/publications/sybilinfer-ndss09.pdf +.. _`Turing Tests`: https://en.wikipedia.org/wiki/Turing_test + +Identity between Cyberspace and Meatspace +========================================= + +A common thread in these solutions, from the Facebook'esque Stasi_ methods to the crypto-anarchist challenge-response +utopias, is that they all approach digital identity as a question of Objective Truth™ that can unanimously be decided at +a system level—or that can be externalized to the next larger system such as the state. Alas, the important question +remains unasked: + + What *is* identity? + +The answer to this question certainly depends on the system being examined. For example, an important reason the +capitalist corporations mentioned above require knowledge about their users' identity is to generate plausible +statistics for the advertisers that form their customer base, similar to how a farmer will keep statics on yield and +quality for the buyers of his crop. With this background, a full decoupling of platform accounts from a notion of legal +identity seems at odds with the platform's business model—and we will have to adjust our expectations for reform +accordingly. + +A common thread among all systems mentioned above is that they all have a social component to them. For this common use +case of social systems, I want to make a suggestion on how we can approach digital identity in a more practical, less +discriminatory [#discriminatory]_ manner than any of the methods we discussed above. I think both using people's social +connections and proxying the decisions of external authorities such as the state are bad systems to decide who is a +person and who is not. I will now illustrate this point a bit. Let us think about how many digital identities a human +beign might have. First, consider the case of n=0, someone who simply wants no business with the system at all. For +simplicity, let us assume that we have solved this issue of consent, i.e. every person who is identified by the system +consents to this practice. For n=1, the approaches outlined above all provide some approximate solution. States may not +grant every human sufficient ID (e.g. children, the mentally disabled or prisoners might be left out), and the social +systems might fail to catch people who simply do not have any friends, but otherwise their approximations hold. Maybe. +But what about n=2, n=3, ...? None of these systems adequately consider cases where a human being might legitimately +wish to hold multiple digital identities, non-maliciously. + +Consider a hypothetical lesbian, conservative politician. An active social media presence is a core component of a +modern politician's carreer. At the same time, "conservative homophobe" is still well within the realm of tautology and +it would be legitimate for this politician to wish to not disclose a large fraction of their private life to the world +at large. They might have a separate online identity for matters related to it. For this politician, the social +relationship-based systems referenced above would either incorporate outing as a design feature, or they would force +the politician to choose either of their two identities: To choose between private life and carreer. When deferring to +the state as the decider over personhood, at least the platform's operator would know about the outrageously sensitive +link between the politician's online identities. Clearly, no such solution can be considered socially just. + +Let us try not to be caught up on saving the world at this point. The issue of conservative homophobia is out of the +scope of our consideration, and it is not one that anyone can solve in the near future. Magical realism aside, least of +all can some technological thing beckon this change. There is a case for legitimate uses of multiple, separate digital +identities, and we do not have a technical or political answer to it. All hope is not lost yet, though. We can easily +undo this gordian knot by acknowledging an unspoken assumption that underlies any social relationships between real +people, past the procrustean bed of computer systems or organizational structures these relationships are cast into. + + As a function of social interaction, digital identities conform to roles_ in sociological terminology, and are not + at all the same as personhood_. Roles are subjective and arise from a relationship between people, and a single + person might legitimately perform different roles depending on context. + +When computer scientists or programmers are creating new systems, there always is an (often implicit) modelling stage. +Formally, during this stage a domain expert and a modeller with a computer science background come together, each +contributing their knowledge to form a model that is both appropriate for real-world use and practical from an +engineering point of view. In practice, these two roles are often necessarily fulfilled by the same person, who is often +also the programmer of the thing. This leads to many computer systems using poor models. A typical example of this issue +are systems requiring a person's name that use three input fields labelled "First Name", "Middle Initial" and "Last +Name". These systems are often created by US-American programmers, who are used to this naming schema from their lived +experience. Unfortunately, this schema breaks down for those few billion people who use their last name first, who have +more than one middle name, or who have multiple given names and do not normally use the first one of those. + +Once a system creator's implicit assumptions have been encoded into the system like this, it is often very hard to get +out of that situation. A pattern to use during careful modelling is to keep the model flexible to account for unforeseen +corner cases. For example, when modelling a system requiring a person's name, one would have to ask what the name is +used for. It may be the most sensible decision to simply ask the user for their name twice: Once in first name/last name +format for e.g. tax purposes, and once with a free-form text field for e.g. displaying on their account page. + +While for names, many systems already use some form of flexible model by e.g. having a *handle* or *nickname* separate +from the *display name*, "social" systems still often are stuck with an identity model based around a concept of a +single, rigid identity. In practice, people perform different roles_ in different circumstances. When asking for a +person's identity, one would get wildly different answers from different people. A person's identity as perceived by +others is coupled to their relationship more than to some underlying, biological or administrative truth. Thinking back +to the straw man politician above, this is evident in subtle ways in almost all our everyday relationships: Some people +may know me by my legal name, some by my online nickname. To some I may be a computer scientist, to some a flatmate. +None of my friends and acquaintances have ever wanted to see my passport, or asked to take my DNA to ascertain that I am +a distinct human being from the other humans they know. Likewise, identifying me by my social connections is impractical +as it would require an exceedingly weird amount of what can only be described as snooping. Yet, this concept of a +single, consistent, global, true identity is exactly what up to now all technological solutions to the identity problem +are trying to achieve. + +Building Bridges +================ + +I think I can offer you one main take-aways from the discussion above. + + During modelling social systems, focus on relationships—not identity. + +Rephrased into more actionable points, as someone designing a social digital system, do the following: + +0. Early in the design stages, take the time to consider fundamental modelling issues like this one. If you don't, you + will likely get stuck with a sub-optimal model that will be hard to get rid of. +1. Where possible, be flexible. Allow people to chose their own identifier. Don't require them to use their real names, + they may not wish to disclose those or they may not be in a format that is useful to you (they may be too long, too + short, too ubiquituous, in foreign characters etc.). A free-form text field with a reasonable length limit is a good + approach here. +2. Do not use credit cards or phone numbers to identify people. There are many people who do not have either, and + scammers can simply buy this data in bulk on the darknet. +3. Allow people to create multiple identites [#accountswitchopsec]_, and acknowledge the role of social relationships in + your interaction features. People have very legitimate reasons to separate areas of their lifes, and it is not for + you or your computer to decide who is who to whom. If your thing requires a global search function, re-consider the + data protection aspects of your system. If you want to encourage social functions in the face of bots and trolls, + make it easy for people to share their identities out-of-band, such as through a QR code or a copy-and-pasteable + short link. If you require someone's legal name or address for billing purposes, unify these identities behind the + scenes if at all and allow them to act as if fully independent in public. + +While change of perspective comes with its share of user experience challenges, but also with a promise for a more +human, more dignified online experience. Perhaps we can find a way to adapt cyberspace to humans, instead of continuing +trying it the other way around. + +.. _astroturfing: https://en.wikipedia.org/wiki/Astroturfing +.. _Stasi: https://en.wikipedia.org/wiki/Stasi + +.. [#cryptocurrency] Pseudo-currencies in that, while they provide some aspects of a regular currency such as ownership + and transactions, they lack most others. Traditional currencies are backed by states, regulated by central banks + tasked with maintaining their stability and ultimately provide accountability through law enforcement, courts + and political elections. + +.. [#discriminatory] Discriminatory as in discriminating against minorities, but also as in deciding what is and what is + not. + +.. [#accountswitchopsec] This does mean that you should not actively prevent people from creating multiple accounts. It + does not necessarily entail building a proper user interface around this practice. If you do the latter, e.g. by + offering a "switch identity" button or an identiy drop-down menu on a post submission form, you can easily + encourage slip-ups that might disclose the connection between two identities, and you make it possible for + someone hacking a single login to learn about this connection as well. + +.. [#meatspacefn] Meatspace_ is where people physically are, as opposed to cyberspace + +.. _Meatspace: https://dictionary.cambridge.org/dictionary/english/meatspace +.. _roles: https://en.wikipedia.org/wiki/Role +.. _personhood: https://en.wikipedia.org/wiki/Personhood diff --git a/content/blog/sybil-resistance-identity/index.rst b/content/blog/sybil-resistance-identity/index.rst new file mode 100644 index 0000000..f90b5ac --- /dev/null +++ b/content/blog/sybil-resistance-identity/index.rst @@ -0,0 +1,89 @@ +--- +title: "Identity between Cyberspace and Meatspace" +date: 2020-09-09T15:00:00+02:00 +draft: true +--- + +.. raw:: html + +
+ +
Photo by Tim Bennett on Unsplash
+
+ +Identity in Cyberspace +====================== + +.. Identity is a frequent problem +.. Easy solutions abound +.. Precise modelling is uncommon +.. True identity is sensitive, hard to handle +.. +.. Often, conversational features emphasized -> true identity is unnecessary +.. Social role theory +.. Call to action + +Most computer systems that interface with humans have a concept of user identity. The data structures used for its +storage vary, but usually one *account* corresponds to one human *user*. In many applications, the system operator tries +to ensure that one user cannot create multiple accounts. In online social networks, astrotufing_ and trolling are easier +to fight when limits are imposed on account creation. In online stores, fraud prevention means the store operator needs +their customers legal identity and the operator must be able to ban offending customers. In mobile messaging systems, +users have to be able to find each other by some identifier such as name or phone number, and this identifier has to be +unique and hard to forge. + +Today, in systems that allow anyone to create an account have largely converged to require either an email address or a +mobile phone number. Email addresses are used by systems that are less vulnerable to abuse and that are used on laptop +or desktop computers. Mobile phone numbers are abundantly used in smartphone apps, as well as in systems more prone to +abuse such as online social networks or ecommerce. Both are easily verified using a confirmation email or SMS. + +When designing or programming an online system, it is uncommon that the precise real-world semantics of accounts are +modelled. Most computer systems use ad-hoc data models. During their creation, their programmers implicit assumptions +about the world are encoded into these data models. Most of the time this works fine, but it does lead to significant +blind spots that can make systems break down for a fraction of their users. + +Lives in Meatspace +================== + +A consequence of the proliferation of phone numbers being used to identify people is that most people will not be able +to create multiple accounts. *"That's the point!"* you might say, but while we want to prevent scammers, spammers and +boored schoolchildren from messing with our systems, everybody else may have legitimate reasons to have more than one +account. + +We can apply sociology's model of roles_ to understand this issue. In sociology, a role is the comprehensive pattern of +rules and expectations that govern an individual's behavior corresponding to their social position. A key fact is that +most people occupy mutliple roles. A parent may also be a company employee or a wife and perform accordingly given the +circumstances. Systems that tie digital identity to legal personhood through the contracts behind phone numbers impede +their users' attempts at role separation. Effects of this are e.g. that nowadays employers routinely screen applicants' +social media accounts for unacceptable content. + +While this role conflict merely amounts to a minor inconvenience to most there are many to who it poses an existential +problem. Consider an LGBT+ person living in a repressive country or a politically conservative person living in a +very liberal city. Both have legitimate reasons to strictly separate parts of their private lives from others. For both, +much is at stake. Yet, both will have to practically circumvent most online systems registration barriers to implement +this separation. + +Trusting the User +================= + +While there is no single solution to these issues, there are several possible mitigations. The first and most important +one is to systematically think about the system's data model when creating it. Which assumptions about the real world +are inherent in it? Are these assumptions likely to cause issues? Ad-hoc models are easily created, but hard to get rid +of when they start causing problems. + +A general guideline on identity should be that hindering trolls by requiring things like phone numbers or credit card +numbers is very likely to also be an obstacle to many entirely legitimate uses. Captchas_ or invitation links can help +to keep out the trolls. Another approach is to limit the damage a troll can cause with things like effective moderation +systems, reputation systems or by limiting the reach of newly created accounts. + +Outside of e-commerce, actually tying a digital account to a real-world identity is very rarely necessary. The value of +a messenger app is not in the names in its contacts list, but the conversations behind these names. When two people meet +each other on the street, their interaction is shaped by a myriad of social factors—but *not* by them showing each other +their photo ID. + +Humans with their messy identities do not fit today's cyberspace well. Let's adapt cyberspace to humans, instead of +trying it the other way around. + +.. _astroturfing: https://en.wikipedia.org/wiki/Astroturfing +.. _roles: https://en.wikipedia.org/wiki/Role +.. _Captchas: https://link.springer.com/content/pdf/10.1007/3-540-39200-9_18.pdf + diff --git a/content/blog/telekom-gpon-sfp/images/edgerouter_interface_config.png b/content/blog/telekom-gpon-sfp/images/edgerouter_interface_config.png new file mode 100644 index 0000000..72d2a9b Binary files /dev/null and b/content/blog/telekom-gpon-sfp/images/edgerouter_interface_config.png differ diff --git a/content/blog/telekom-gpon-sfp/images/edgerouter_route_config.png b/content/blog/telekom-gpon-sfp/images/edgerouter_route_config.png new file mode 100644 index 0000000..fe65051 Binary files /dev/null and b/content/blog/telekom-gpon-sfp/images/edgerouter_route_config.png differ diff --git a/content/blog/telekom-gpon-sfp/images/edgerouter_sfp_config.png b/content/blog/telekom-gpon-sfp/images/edgerouter_sfp_config.png new file mode 100644 index 0000000..01da1e7 Binary files /dev/null and b/content/blog/telekom-gpon-sfp/images/edgerouter_sfp_config.png differ diff --git a/content/blog/telekom-gpon-sfp/images/edgerouter_snat_config.png b/content/blog/telekom-gpon-sfp/images/edgerouter_snat_config.png new file mode 100644 index 0000000..6e033ac Binary files /dev/null and b/content/blog/telekom-gpon-sfp/images/edgerouter_snat_config.png differ diff --git a/content/blog/telekom-gpon-sfp/images/edgerouter_snat_config2.png b/content/blog/telekom-gpon-sfp/images/edgerouter_snat_config2.png new file mode 100644 index 0000000..fb7ce32 Binary files /dev/null and b/content/blog/telekom-gpon-sfp/images/edgerouter_snat_config2.png differ diff --git a/content/blog/telekom-gpon-sfp/images/sfp_onu_ploam_pw_config.png b/content/blog/telekom-gpon-sfp/images/sfp_onu_ploam_pw_config.png new file mode 100644 index 0000000..66f6f6a Binary files /dev/null and b/content/blog/telekom-gpon-sfp/images/sfp_onu_ploam_pw_config.png differ diff --git a/content/blog/telekom-gpon-sfp/images/sfp_onu_reset.png b/content/blog/telekom-gpon-sfp/images/sfp_onu_reset.png new file mode 100644 index 0000000..13c2ca6 Binary files /dev/null and b/content/blog/telekom-gpon-sfp/images/sfp_onu_reset.png differ diff --git a/content/blog/telekom-gpon-sfp/images/sfp_onu_web_if.png b/content/blog/telekom-gpon-sfp/images/sfp_onu_web_if.png new file mode 100644 index 0000000..dea0b8f Binary files /dev/null and b/content/blog/telekom-gpon-sfp/images/sfp_onu_web_if.png differ diff --git a/content/blog/telekom-gpon-sfp/index.rst b/content/blog/telekom-gpon-sfp/index.rst new file mode 100644 index 0000000..17f78d5 --- /dev/null +++ b/content/blog/telekom-gpon-sfp/index.rst @@ -0,0 +1,216 @@ +--- +title: "Ubiquiti EdgeRouter on Deutsche Telekom GPON Fiber" +date: 2022-02-21T20:00:00+01:00 +--- + +Disclaimer +========== + +I provide this guide as a reference for other knowledgeable users without any warranty. Please feel free to use this as +a resource but do not hold me responsible if this does not work for you. There is a significant chance that due to an +error on my side or due to Telekom changing their setup this guide will not work for you, and you may end up having to +pay for an unsuccessful Telekom technician visit. That is your own risk, and I do not assume any liability. + +Tl;dr +===== + +The "Telekom Digitalisierungsbox Glasfasermodem" is a GPON ONT in SFP form factor that works with an Ubiquiti EdgeRouter +6P's SFP port. You can order it from Telekom or other vendors using the Telekom P/N 40823569 or its EAN 4718937619382. +It costs about the same as the separate plastic box modem, but saves a lot of space and does not require a separate +power supply. + +To configure, first access the SFP ONT's web interface at ``10.10.1.1`` by configuring your SPF port's IP to static +``10.10.1.2``. User credentials are either admin/admin or admin/1234. In the web interface, set put PLOAM password into the +"SLID" setting in ASCII mode, then save & reboot the device. Now, configure PPPoE on the router's SFP port using the +PPPoE UID ``[anschlusskennung] [zugangsnummer] "#" [mitbenutzernummer] "@t-online.de"`` and your "Persönliches Kennwort" as +PPPoE password. Set the VLAN to ``7``, and you are good to go. + +Background +========== + +I moved into a new apartment that has a fiber internet connection operated by Deutsche Telekom. Having made some poor +experiences with AVM's FritzBox brand of routers that is commonly used by German carriers, I decided to use my own +Router instead of the one provided by Deutsche Telekom. Like other German providers, Telekom charges exorbitant amounts +in monthly fees for their routers, so even though my choice ended up being a high-end piece of commercial equipment I +will still be cheaper than going with Telekom's much shittier device when added up over a two-year contract period. + +The hardware I chose is the Ubiquiti EdgeRouter 6P. This device is from Ubiquiti's commercial lineup and is intended to +power something like a small branch office of a company. It comes in a small form factor (as opposed to larger rackmount +units), it does not consume a lot of power, it has five PoE-capable Ethernet ports which I can directly connect up to +the Ubiquiti Unifi UAP access point that I already have, and it has a powerful configuration interface. It can even +act as a VPN endpoint! + +Telekom's fiber internet offering for residential customers is GPON-based. GPON stands for "Gigabit Passive Optical +Network" and means that instead of patching through one fiber or pair of fibers to each customer, several customers in +one building are connected to a single fiber through optical splitters. These optical splitters are passive, i.e. they +are just fancy pieces of glass and fibers and do not require electrical power. The advantage of GPON is lower initial +cost for the operator, the disadvantage is that competing providers can only ever hope to get traffic handed through by +Telekom and will never be able to use their own equipment on the "network" end of the fiber. + +Telekom wants you to connect to its fiber network through a small plastic box that they call "modem", and that the rest +of the world calls "ONT", or Optical Network Terminator. Telekom's ONT has an upstream optical port with an LC +connector, and a regular RJ45 ethernet port downstream. The "modem" in fact contains an entire linux system that +terminates the ITU-standard suite of protocols that is used to manage what happens on the fiber, e.g. scheduling of +transmission slots and adjustment of transmitter laser power. + +Looking at Telekom's plastic box ONT and my nice and shiny EdgeRouter, I was not a fan of this solution. Doing some +research I found out that you can in fact get GPON ONTs in an SFP module form factor. My EdgeRouter has an SFP slot, so +if I could get one of these that is compatible with Telekom's GPON flavor I could theoretically just plug it into my +EdgeRouter's SFP slot with no separate power supply needed, saving a lot of space in the process. + +Finding a GPON SFP ONT that is compatible with Telekom's network turned out to be the hard part. While there are lots of +commercial devices that look like they *should be* compatible, I could not be sure and I did not feel like sinking lots +of money and weeks of trial and error into figuring out which are and which are not. After about half a dozen calls with +various Telekom customer service departments I found the solution that ultimately ended up working: For their business +customer fiber internet offering, Telekom uses the same GPON standard, but different ONT equipment. Their router for +business customers is called "Digitalisierungsbox" and it in fact comes with an SFP GPON ONT. And, as it turns out, you +can order that SFP GPON ONT separately for about 50 € (the same as the plastic box one) from either Telekom or a number +of independent online stores. The Telekom part number of the thing is 40823569, the EAN is 4718937619382. + +Below is a list of steps that I had to undertake in order to get my EdgeRouter/SFP ONT setup to work. + +Hardware Setup +============== + +The hardware setup is really simple. The SFP ONU is plugged into the EdgeRouter's SFP port. The ONU is connected to +the Telekom Fiber through the LC/APC to SC/APC adapter cable that is included in its package. Telekom's technician will +install an LC/APC coupler to join both cables. To configure the EdgeRouter, connect yourself through an ethernet cable +*on port 2*. Ubiquiti's setup wizards assume the WAN interface is either port 1 or the SFP port (port 5), and default to +use port 2 as their LAN interface even when port 5 is configured as the only WAN port. The default IP for the EdgeRouter +is ``192.168.1.1``, and the default UID/PW is ubnt/ubnt. + +Configuration +============= + +Getting access to the SFP ONU's config interface +------------------------------------------------ + +In this section I am assuming you want to configure the SFP ONU while it is plugged into the EdgeRouter from a laptop +connected to the EdgeRouter's ethernet port 2. To do this, we have to first configure the right IP/subnet on the +EdgeRouter's SFP interface, then patch connections between the SFP ONU and the laptop through the EdgeRouter. + +1. First, inside the EdgeRouter's config interface we need to configure a static IP with accompanying SNAT rule on the + SFP port to allow us to access the SFP module's web interface through the laptop connected to the EdgeRouter. For + this, configure the eth5 interface (which is the SFP port) to use the static IP ``10.10.1.2/24``. + +.. raw:: html + +
+ + The EdgeRouter's graphical configuration interface showing IP + address 10.10.1.2/24 being configured for interface eth5, which is the SFP interface. + +
SFP interface configuration to access the SFP ONU from a laptop connected to the EdgeRouter's LAN + port
+
+ +2. With the SFP port assigned an IP address, we need to add a NAT rule to forward connections from the configuration + laptop on eth2 to the SFP port. We do this by adding a source NAT rule with masquerading enabled, for the TCP + protocol, with destination address ``10.10.1.0/24`` (the SFP config interface's private network). + +.. raw:: html + +
+ + The EdgeRouter's graphical configuration interface showing a + source NAT being configured for interface eth5 for TCP protocol connections to destination address 10.10.1.1 + using masquerading. + +
Source NAT configuration to access the SFP ONU from LAN. eth5, masquerading on, TCP, destination + 10.10.1.1 (the SFP ONU's IP).
+
+ +3. Finally, make sure that your laptop will actually use the EdgeRouter as its gateway for IPs within ``10.10.1.0/24``. + On the laptop, disable any VPNs, disconnect your Wifi and make sure that IP r shows a default route pointing at the + EdgeRouter's ``192.168.1.1``. If that isn't the case, on Linux you can manually add the necessary route by using + ``sudo ip r a 10.10.1.0/24 via 192.168.1.1 dev enp5s0`` + +After setting up this temporary route, you should be able to access the SFP ONU's configuration web interface by +pointing a browser at ``http://10.10.1.1/`` Just make sure you use plain-text HTTP here, not secure HTTP**S**. The +default login credentials for the device are admin/1234. + +.. raw:: html + +
+ + The SFP ONU configuration web interface is a basic-looking website with + a big Zyxel logo on it. It has menu options named status, setup and management. It shows a system overview + page that lists the device's uptime and software version. + +
The SFP ONU's web interface.
+
+ +Configuring the PLOAM password / SLID / ONT-Installationskennung +---------------------------------------------------------------- + +On the SFP ONU's web interface, we only have to change one single setting: Under "Setup", we have to set what the SFP +ONU calls "SLID" to the PLOAM password for the interface. Telekom calls this the "ONT-Installationskennung". You get +this from your Telekom technician. In the config interface, select ASCII mode and enter the number using the format +``ABCD000000`` with four capital letters followed by six zeros. If necessary, you can read the SFP ONU's serial number +on this page. + +.. raw:: html + +
+ + The SFP ONU configuration web interface shows its SLID + configuration page. A text field labelled SLID asks the user to enter a value of at most ten characters. As + an example, abcdefg123 is listed. + +
The SFP ONU's config interface to set SLID/PLOAM PW/ONT-Installationskennung.
+
+ +Press "Save Config" on the top right of the web page, then select "Reset ONU" and click "Apply" under the "Reset ONU" +link on the left. Make sure to not select the factory reset option instead. + +.. raw:: html + +
+ + The SFP ONU configuration web interface shows its reset ONU page. There + are two options labelled Reset ONU and Reset to factory default settings. The reset ONU option is + selected. + +
Rebooting the SFP ONU.
+
+ +With the ONU configured, after the reset the "GPON Information" page from the left menu under "Status" from the top menu +should show ``GPON Line Status: O5``. You can now remove the SNAT rule and IP address from the SFP interface in the +EdgeRouter's config. I recommend this since there is no way to change the ONU's default credentials, and leaving the +SNAT rule in place makes it vulnerable to attacks from your LAN. If you use the EdgeRouter's setup wizard in the next +step, that wizard will reset all of these settings. + +Configuring PPPoE and NAT +------------------------- + +Our ONU now has a low-level connection to Telekom's fiber network. The next step is to configure the EdgeRouter to +authenticate with the ONU through PPPoE. The easiest way to do this is to use the EdgeRouter's "Basic Setup" wizard as +described in the `EdgeOS User Guide`. In the wizard, select the SFP port (``eth5``) as the internet/WAN port. Select +``Internet Connection Type`` as ``PPPoE``, then enter the PPPoE credentials you got from your Telekom technician. The +password is your "Persönliches Kennwort" that you also use to log in to your customer account on Telekom's website. The +account name is ``[anschlusskennung] [zugangsnummer] "#" [mitbenutzernummer] "@t-online.de"``, so something like +``002712345678012345678901#0001@t-online.de``. Enable "Internet connection is on VLAN" and enter VLAN ID ``7``. This is +necessary because of the way Telekom set up their triple play (TV/phone/internet) service. After following through with +the wizard, your internet should be already working on port 2 of the router. Note that despite selecting the SFP port as +the router's WAN port, the wizard will still reserve port 1 (``eth0``) for another WAN interface, so you will only be +able to access the configuration interface through port 2 (``eth1``) after the wizard is done. You can of course change +this later. + +That's it, you're done and your internet should be working! + +Having Fun with the SPF GPON ONU +================================ + +If you want to dig deeper into the internals of Telekom's GPON implementation, the SFP ONU's firmware is a great +starting point. Default credentials are all admin/admin or admin/1234 and you can even get a regular busybox shell on +the device through SSH. The device's firmware is based on OpenWRT, and the source for large parts of the core control +components can be found under open source licenses as well. While I would strictly advice you to not mess around with +the actual modem settings because due to GPON you share a medium with your neighbors and might very well disrupt their +internet if you mess up, inspecting the ONU's firmware is a great way to learn about the inner workings of a modern GPON +network. + +If you are interested in messing around with the SFP ONU, there is a github repository where interesting thins are +collected `here `__. + +.. _`EdgeOS User Guide`: https://dl.ubnt.com/guides/edgemax/EdgeOS_UG.pdf + diff --git a/content/blog/thors-hammer/images/thors_hammer_breadboard.jpg b/content/blog/thors-hammer/images/thors_hammer_breadboard.jpg new file mode 100644 index 0000000..4504d83 Binary files /dev/null and b/content/blog/thors-hammer/images/thors_hammer_breadboard.jpg differ diff --git a/content/blog/thors-hammer/images/thors_hammer_schematic.jpg b/content/blog/thors-hammer/images/thors_hammer_schematic.jpg new file mode 100644 index 0000000..3061f61 Binary files /dev/null and b/content/blog/thors-hammer/images/thors_hammer_schematic.jpg differ diff --git a/content/blog/thors-hammer/index.rst b/content/blog/thors-hammer/index.rst new file mode 100644 index 0000000..ba851a5 --- /dev/null +++ b/content/blog/thors-hammer/index.rst @@ -0,0 +1,60 @@ +--- +title: "Thor's Hammer" +date: 2018-05-03T11:59:37+02:00 +--- + +In case you were having an inferiority complex because your friends' IBM Model M keyboards are so much louder than the +shitty rubber dome freebie you got with your pc... Here's the solution: Thor's Hammer, a simple typing cadence enhancer +for `PS/2`_ keyboards. + +.. raw:: html + +
+ +
A demonstration of the completed project. + + h264 download / + webm download +
+
+ +The connects to the keyboard's PS/2 clock line and briefly actuates a large solenoid on each key press. An interesting +fact about PS/2 is that the clock line is only active as long as either the host computer or the input device actually +want to send data. In case of a keyboard that's the case when a key is pressed or when the host changes the keyboard's +LED state, otherwise the clock line is silent. We ignore the LED activity for now as it's generally coupled to key +presses. By just triggering an NE555 configured as astable flipflop we can stretch each train of clock pulses to a +pulse a few tens of milliseconds long that is enough to actuate the solenoid. + +.. raw:: html + +
+ The schematic of the PS2 driver +
The schematic of the driver stretching the PS/2 clock pulses to drive the solenoid.
+
+ + +Since PS/2 sends each key press and key release separately this circuit will pulse twice per keystroke. It would be +possible to ignore one of them but I figure the added noise just adds to the experience. + +Built on a breadboard, the circuit looks like this. + +.. raw:: html + +
+ The circuit built on a breadboard +
The completed circuit built up on a breadboard and attached to a keyboard.
+
+ + +Since my solenoid did not have a tensioning spring I used a rubber band and some vinyl tape to make an adjustable +tensioner. The small orange USB hub serves as an end-stop because I had nothing else of the right shape. The sound and +resonance of the thing can be adjusted to taste by moving the end stop, adjusting the tensioning rubber and tuning the +excitation duration using the potentiometer. My particular solenoid was a bit slow so I added some pieces of circuit +board as shims between the plunger and the case to limit the plunger's travel inside the solenoid core. + +.. _`PS/2`: https://en.wikipedia.org/wiki/PS/2_port + diff --git a/content/blog/thors-hammer/video/thors_hammer.mkv b/content/blog/thors-hammer/video/thors_hammer.mkv new file mode 100644 index 0000000..c9581e9 Binary files /dev/null and b/content/blog/thors-hammer/video/thors_hammer.mkv differ diff --git a/content/blog/thors-hammer/video/thors_hammer.mov b/content/blog/thors-hammer/video/thors_hammer.mov new file mode 100644 index 0000000..fff65a8 Binary files /dev/null and b/content/blog/thors-hammer/video/thors_hammer.mov differ diff --git a/content/blog/thors-hammer/video/thors_hammer.webm b/content/blog/thors-hammer/video/thors_hammer.webm new file mode 100644 index 0000000..2bcf1ca Binary files /dev/null and b/content/blog/thors-hammer/video/thors_hammer.webm differ diff --git a/content/blog/wifi-led-driver/images/board_in_case.jpg b/content/blog/wifi-led-driver/images/board_in_case.jpg new file mode 100644 index 0000000..843900a Binary files /dev/null and b/content/blog/wifi-led-driver/images/board_in_case.jpg differ diff --git a/content/blog/wifi-led-driver/images/board_in_case.small.jpg b/content/blog/wifi-led-driver/images/board_in_case.small.jpg new file mode 100644 index 0000000..5c0aa81 Binary files /dev/null and b/content/blog/wifi-led-driver/images/board_in_case.small.jpg differ diff --git a/content/blog/wifi-led-driver/images/boards.jpg b/content/blog/wifi-led-driver/images/boards.jpg new file mode 100644 index 0000000..79f8154 Binary files /dev/null and b/content/blog/wifi-led-driver/images/boards.jpg differ diff --git a/content/blog/wifi-led-driver/images/boards.small.jpg b/content/blog/wifi-led-driver/images/boards.small.jpg new file mode 100644 index 0000000..6f5c28c Binary files /dev/null and b/content/blog/wifi-led-driver/images/boards.small.jpg differ diff --git a/content/blog/wifi-led-driver/images/layout.png b/content/blog/wifi-led-driver/images/layout.png new file mode 100644 index 0000000..11fc50e Binary files /dev/null and b/content/blog/wifi-led-driver/images/layout.png differ diff --git a/content/blog/wifi-led-driver/images/schematic.png b/content/blog/wifi-led-driver/images/schematic.png new file mode 100644 index 0000000..8294f12 Binary files /dev/null and b/content/blog/wifi-led-driver/images/schematic.png differ diff --git a/content/blog/wifi-led-driver/index.rst b/content/blog/wifi-led-driver/index.rst new file mode 100644 index 0000000..f1e53a9 --- /dev/null +++ b/content/blog/wifi-led-driver/index.rst @@ -0,0 +1,145 @@ +--- +title: "Wifi Led Driver" +date: 2018-05-02T11:31:03+02:00 +--- + +Project motivation +================== + +.. FIXME finished project picture with LED tape +.. raw:: html + +
+ +
The completed driver board installed in the 3D-printed case. This device can now be connected to + 12V and two segments of LED tape that can then be controlled trough Wifi. The ESP8266 module goes on the pin + header on the left and was removed for this picture. +
+
+ +After the `multichannel LED driver`_ was completed, I was just getting used to controlling LEDs at 14-bit resolution. +I liked the board we designed in this project, but at 32 channels it was a bit large for most use cases. Sometimes I +just want to pop a piece of LED tape or two somewhere, but I don't need a full 32 channels of control. I ended up +thinking that a smaller version of the 32-channel driver that didn't require a separate control computer would be +handy. So I sat down and designed a variant of the design with only 8 channels instead of 32 and an on-board ESP8266_ +module instead of the RS485_ transceiver for WiFi connectivity. + +The Electronics +=============== + +The schematic was mostly copy-pasted from the 32-channel design. The PCB was designed from scratch. This time, I went +for a 5x7cm form factor to allow for enough room for all connectors and to give the ESP8266_'s WiFi antenna enough +space. The board has two 5-pin Phoenix-style_ for two RGB-White (RGBW) tapes and one 2-pin Phoenix-style_ connector for +12V power input. The control circuitry and the serial protocol are unchanged, but the STM32_ now talks to an ESP-01_ +module running custom firmware. + +The LEDs are driven using a 74HC595_ shift register controlling a bunch of AO3400_ MOSFETs_, with resistors in front of +the MOSFETs_' gates to slow down the transitions a bit to reduce brighntess nonlinearities and EMI_ resulting from +ringing of the LED tape's wiring inductance. + +The board has two spots for either `self-resettable fuses (polyfuses) `__ or regular melting-wire fuses_ in +a small SMD_ package, one for each RGBW output. For low currents the self-resettable fuses should be okay but at higher +currents their `trip times get long enough that they become unlikely to trip in time to save anything +`__, so plain old non-resettable fuses would be the way to go there. + +.. FIXME finished board photos +.. FIXME board with test tape picture + +.. raw:: html + +
+
+ +
+ 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. + Download PDF +
+
+ +
+ The board layout with the top side being visible. The top side contains the footprint for the ESP8266, the + microcontroller, fuses, filter cap, connectors and the shift register. The LEDs are connected on the left, + with one connector per LED tape segment. The power input connector is on the bottom right. The LED driver + MOSFETs are in small SOT-23 packages on the back of the board. Since this board is not intended for + super-high currents, the MOSFETs are adequately cooled just through the board's copper planes. + Download PDF +
+
+
+ +.. raw:: html + +
+ +
The completed PCBs of this project (front) and the `multichannel LED driver`_ project the driver + circuitry was derived from (back). +
+
+ + +The Firmware +============ + +The STM32_ firmware only had to be slightly modified to accomodate the reduced channel count since the protocol remains +unchanged. The ESP firmware is based on esphttpd_ by Spritetm_. The modifications to the webserver firmware are pretty +basic. First, the UART console has been disabled since I use the UART to talk to the STM32. The few bootloader messages +popping out the UART on boot are not an issue, since they're unlikely to contain the fixed 32-bit address prefix the +serial protocol requires for the STM32_ to do anything. + +Second, I added LED control by adding drivers for the serial protocol and a bunch of colorspace conversion functions. +When I first tested the prototype software, I noticed that color reproduction was extremely poor. When I just sent a +HSV_ rainbow fade from a python command line, the result looked totally wrong. The fade did not seem to go at a constant +speed and some colors, in particular yellow, orange and greens, were not visible at all. The problem turned out to be a +stark mismatch of the red, green and blue channels of the LED tape and less-than-optimal color reproduction of the pure +colors. I decided to properly measure the LED tape's color reproduction so I could compensate for it in software. This +turned out to be an extremely interesting project, the details of which you can read in my `LED characterization`_ +article. + +Third, I updated the built-in websites with some ad-hoc documentation on how to use the thing and a basic interface for +LED control. + +.. FIXME screenshot of firmware website + +Making an enclosure +=================== + +To be actually useful, the driver needed a robust enclosure. Bare PCBs are nice for prototyping, but for actually +putting the thing anywhere it needs a case to protect it against random destruction. + +The board has four mounting holes with comfortable spacing in its corners to allow easy mounting inside a 3D-printed +case. The case itself is described in an OpenSCAD_ script. To make it look a little nicer, a little 3D relief is laid +into the lid. The 3D relief is generated with a bit of blender magic. The source STL_ model is loaded into blender, then +blender's amazingly flexible rendering system is used to export a depth map of a projection of the model as a PNG_ file. +This depth map is then imported as a triangle mesh into OpenSCAD_. + +For the relief to look good, I chose a rather high resolution for the depth map. This unfortunately leads to extreme +memory use and processing time on the part of OpenSCAD_, but since I have access to a sufficiently fast machine that is +not a problem. Just be careful if you try opening the OpenSCAD_ file on your machine, OpenSCAD_ will probably crash +unless you're on a beefy machine or interrupt it when it starts auto-rendering the file. + +The board is mounted into the enclosure using knurled insert nuts that are pressed into a 3D-printed hole using a bit of +violence. + +.. _`multichannel LED driver`: {{}} +.. _`LED characterization`: {{}} +.. _ESP8266: https://en.wikipedia.org/wiki/ESP8266 +.. _RS485: https://en.wikipedia.org/wiki/RS-485 +.. _Phoenix-style: https://www.phoenixcontact.com/online/portal/de?uri=pxc-oc-itemdetail:pid=1757019&library=dede&tab=1 +.. _STM32: http://www.st.com/resource/en/datasheet/stm32f030f4.pdf +.. _ESP-01: http://www.watterott.com/de/ESP8266-WiFi-Serial-Transceiver-Modul +.. _74HC595: http://www.ti.com/lit/ds/symlink/sn74hc595.pdf +.. _AO3400: http://aosmd.com/pdfs/datasheet/AO3400.pdf +.. _MOSFETs: https://en.wikipedia.org/wiki/MOSFET +.. _EMI: https://en.wikipedia.org/wiki/Electromagnetic_interference +.. _polyfuse: https://en.wikipedia.org/wiki/Resettable_fuse +.. _SMD: https://en.wikipedia.org/wiki/Surface-mount_technology +.. _fuses: https://en.wikipedia.org/wiki/Fuse_(electrical) +.. _littlefuse-16r-datasheet: http://m.littelfuse.com/~/media/electronics/datasheets/resettable_ptcs/littelfuse_ptc_16r_datasheet.pdf.pdf +.. _OpenSCAD: http://www.openscad.org/ +.. _STL: https://en.wikipedia.org/wiki/STL_(file_format) +.. _PNG: https://en.wikipedia.org/wiki/Portable_Network_Graphics +.. _esphttpd: https://github.com/Spritetm/esphttpd +.. _Spritetm: http://spritesmods.com/ +.. _`HSV`: https://en.wikipedia.org/wiki/HSL_and_HSV + diff --git a/content/blog/wifi-led-driver/resource/lyza_schematic_and_pcb.pdf b/content/blog/wifi-led-driver/resource/lyza_schematic_and_pcb.pdf new file mode 100644 index 0000000..6532888 Binary files /dev/null and b/content/blog/wifi-led-driver/resource/lyza_schematic_and_pcb.pdf differ -- cgit