From 8be504601aeb9005b4e227fb2529d12672ea697e Mon Sep 17 00:00:00 2001
From: Sadeep Madurange <sadeep@asciimx.com>
Date: Tue, 13 Jan 2026 22:40:06 +0800
Subject: Tighten prose.

---
 _log/etlas.md               | 16 +++++++---------
 _log/fpm-door-lock-lp.md    | 15 +++++++++------
 _log/fpm-door-lock-rf.md    | 30 +++++++++++++++---------------
 _log/matrix-digital-rain.md | 16 +++++++---------
 _log/mosfet-switches.md     | 16 ++++++++--------
 5 files changed, 46 insertions(+), 47 deletions(-)

(limited to '_log')

diff --git a/_log/etlas.md b/_log/etlas.md
index 6d5bd4e..89a7c84 100644
--- a/_log/etlas.md
+++ b/_log/etlas.md
@@ -21,17 +21,15 @@ sensor.
 </table>
 
 Stocks: Two weeks EOD data from Polygon.io (max possible). Flask app on VPS
-manages watchlist, relays the feed. Backend: httpd + htpasswd + slowcgi +
-Flask.
+manages watchlist, relays feed. Backend: httpd + htpasswd + slowcgi + Flask.
 
-gui_plot_stocks() plots a stepped graph; was easier to implement, but the code
-is hideous; triggers watchdog. vTaskDelay() prevents that. 
+gui_plot_stocks() plots a stepped graph. Was easier to implement, but the code
+is hideous; Triggers watchdog without vTaskDelay().
 
 NOTE: Refactor. Bresenham’s?
 
 News: Channel NewsAsia RSS. MCU does the parsing. Didn't plan to have a backend
-at the time. Now that I have one for stocks, should relay the feed for
-flexibility.
+at the time. Now that I have one for stocks, should relay feed for flexibility.
 
 Weather: DHT22 single-wire protocol. 26µs/50µs/70µs pulses are too fast for
 standard ESP32 APIs. Bit-banged relative pulse widths (ported from <a
@@ -95,9 +93,9 @@ static inline int dht_get_raw_data(unsigned char buf[BUFLEN])
 ```
 
 epd_init() stalls intermittently on first refresh() after flash. Toggling delay
-values in refresh() resolves it. If the first refresh succeeds, it remains
-stable. Root cause unknown--suspect noisy power supply due to powering display
-via MCU.
+values in refresh() resolves it. If the first refresh succeeds, system remains
+stable. Root cause unknown--suspect noisy supply due to powering display via
+MCU.
 
 Uptime: August 2024 - January 2026
 
diff --git a/_log/fpm-door-lock-lp.md b/_log/fpm-door-lock-lp.md
index aed991e..b846797 100644
--- a/_log/fpm-door-lock-lp.md
+++ b/_log/fpm-door-lock-lp.md
@@ -6,9 +6,10 @@ project: true
 thumbnail: thumb_sm.jpg
 ---
 
-Second iteration of the [RF door lock](../fpm-door-lock-rf). Old version worked
-but drew too much quiescent current. Sensor and servo pulled 13.8mA and 4.6mA
-idle. Linear regulators were a disaster. Battery didn't last 24 hours.
+Second iteration of the [fingerprint door lock](../fpm-door-lock-rf). Old
+version worked but drew too much quiescent current. Sensor and servo pulled
+13.8mA and 4.6mA idle. Linear regulators were a disaster. Battery didn't last
+24 hours.
 
 <video style="max-width:100%;" controls="" poster="pcb.jpg">
   <source src="video.mp4" type="video/mp4">
@@ -42,8 +43,8 @@ and servo before deep sleep. Through-hole MOSFETs that switch at 3.3V are
 getting harder to find. NDP6020P already obsolete. 
 
 Replaced linear regulators with MP1584EN DC-DC buck converters. No RFM--noise
-isn't a big concern. Buck's pin breakout not great--wouldn't fit commercial dev
-boards.
+isn't a big concern. Buck's pin breakout not great--wouldn't fit on commercial
+dev boards.
 
 Squeezed more power savings by underclocking MCU to 8MHz/3.3V. Combined
 with buck converters: 56% total power savings.
@@ -52,7 +53,9 @@ Wake sequence: MCU activates FPM MOSFET, unlocks FPM over UART, scans and
 matches fingerprint. Match triggers blue LED, servo MOSFET, PWM signal to
 unlock. No match triggers red LED. MOSFETs off, back to sleep.
 
-Total power savings: 99.9% (30.6mA → 2.9μA). Verdict: Fixed. 
+Total power savings: 99.9% (30.6mA → 2.9μA). 
+
+Verdict: Fixed. 
 
 Commit: <a
 href="https://git.asciimx.com/fpm-door-lock/commit/?id=75290945b2fd84b3bc108fd46419ee478eaac3ca"
diff --git a/_log/fpm-door-lock-rf.md b/_log/fpm-door-lock-rf.md
index 97779db..7c2b9ef 100644
--- a/_log/fpm-door-lock-rf.md
+++ b/_log/fpm-door-lock-rf.md
@@ -9,22 +9,22 @@ thumbnail: thumb_sm.jpeg
 Wanted to unlock door with fingerprint, wirelessly to avoid drilling.
 
 2024-11: Started with basic 433MHz RF modules and two Arduinos. Connected data
-lines of the transceivers to UART RXD/TXD of an ATmega328P.
-Unreliable--constant packet loss.
+lines of the transceivers to UART RXD/TXDs of the MCUs. Unreliable--constant
+packet loss.
 
 2025-01: Switched to RFM69 modules. Complete ball-ache. Followed datasheet to
 the letter, audited code many times, cross-checked with RadioHead and RFM69
-open-source drivers. No luck. 
+drivers. No luck. 
 
-ATmega328P runs at 5V; RFM69 3.3V. Suspect logic-level converter (LLC)
-issues. High resistance. Not enough swing.
+ATmega328P runs at 5V; RFM69 3.3V. Suspect logic-level converter (LLC) issues.
+High resistance; Not enough swing.
 
 2025-04: Ditched RFM69s. Switched to NRF24L01+ modules--data pins 5V tolerant,
 no LLC required. Spent six weekends writing a clean-room driver from scratch.
 Works like a charm. 
 
-Basic security via xor cipher–good enough for a door behind a guard post and
-gate:
+Basic security via xor cipher--good enough for a door behind a guard post and
+a gate:
 
 ```
 void xor(const char *k, const char *s, char *d, uint8_t n)
@@ -56,12 +56,12 @@ static inline void keygen(char *buf, uint8_t n)
 ```
 
 Protocol: FPM sends SYN. Servo responds with session key. Both xor-ed with
-static key. Session key used thereafter. Private command set authenticates
-endpoints.
+static key. Session key used thereafter. Command set private--serves to
+authenticate endpoints.
 
 2025-05: Wrote FPM drivers for R503 and FPM10A. UART RX sequence was
-tricky--adopted Adafruit C++ FOSS implementation to C. R503 has built-in LEDs
-and better form factor. Chose it for the lock.
+tricky--adopted Adafruit C++ implementation to C. R503 has built-in LEDs and
+better form factor. Chose it for the lock.
 
 2025-06: Two PCBs for FPM (front) and servo (back) controllers. 
 
@@ -90,15 +90,15 @@ and better form factor. Chose it for the lock.
 
 PCB specs: 2-layer, 1oz copper, 0.3mm traces (0.5mm for power). Ground plane.
 
-2025-06: NRF24L01+ on the back stopped working after mounting on PCB. Too close
-to servo's PWM line. Soldering a large 47uF (16V) electrolytic capacitor
-between VCC and ground fixed it.
+2025-06: NRF24L01+ stopped working after mounting on PCB. Too close to PWM
+line. Soldering a large 47uF (16V) electrolytic capacitor between VCC and
+ground fixed it.
 
 Power problems became clear. Linear regulators dissipated too much heat. Sensor
 and servo drew 13.8mA and 4.6mA quiescent currents--unacceptable for battery.
 Servo inrush current exceeds 1A. 0.3mm tracks cuts it too close.
 
-Verdict: Functional but not practical. Battery dead in under 24 hours. Led to
+Verdict: Functional but not practical. Battery died in under 24 hours. Led to
 [redesign](../fpm-door-lock-lp/) with proper power management.
 
 Commit: <a
diff --git a/_log/matrix-digital-rain.md b/_log/matrix-digital-rain.md
index 2edc7e7..43944ae 100644
--- a/_log/matrix-digital-rain.md
+++ b/_log/matrix-digital-rain.md
@@ -6,7 +6,7 @@ project: true
 thumbnail: thumb_sm.png
 ---
 
-The 2022 version worked but had some loose ends. Unicode support was
+2022 version worked but had loose ends. Unicode support was
 incomplete--couldn't mix ASCII with Katakana; Phosphor decay was stored in a
 separate array when it should've been packed with RGB; Code was harder to read
 than it needed to be.
@@ -18,11 +18,11 @@ than it needed to be.
 Moved phosphor decay into the 4th byte of the RGB union--should’ve done this 
 in 2022; What was I thinking.
 
-Keeping the RGB union despite portability concerns. All my systems are
-little-endian and the code is cleaner this way.
+Kept the RGB union. Portability not a concern. All my systems are little-endian
+and the code is cleaner this way.
 
-Fixed Unicode by introducing a charset array. UNICODE(min, max) packs Unicode
-ranges into uint64: low four bytes for start, high four bytes for end.
+Fixed Unicode by introducing a charset array. UNICODE(min, max) macro packs
+Unicode ranges into uint64: low four bytes for start, high four bytes for end.
 insert_code() unpacks a random block and picks a character from it:
 
 ```
@@ -49,7 +49,7 @@ static inline void insert_code(matrix *mat,
 Full-width Katakana breaks column alignment. Stick to half-width
 (U+FF61-U+FF9F) range. Compile with -DNOKANA to disable Katakana altogether.
 
-blend() for screen decay is still good:
+blend() for screen decay is still good. Left it alone:
 
 ```
 static inline void blend(matrix *mat,
@@ -64,8 +64,6 @@ static inline void blend(matrix *mat,
 }
 ```
 
-Left it alone.
-
 Optimized RNG--xorshift instead of rand():
 
 ```
@@ -80,7 +78,7 @@ static inline uint32_t xor(void)
 }
 ```
 
-NOTE: Non-linear variations (xorshitr+) for more speed.
+NOTE: Non-linear variants (xorshitr+) for more speed.
 
 Tossed license and automake cruft. Just `cc -O3 main.c -o matrix` now. Don't
 need the ceremony.
diff --git a/_log/mosfet-switches.md b/_log/mosfet-switches.md
index 4fc1d31..bfe471a 100644
--- a/_log/mosfet-switches.md
+++ b/_log/mosfet-switches.md
@@ -4,9 +4,9 @@ date: 2025-06-22
 layout: post
 ---
 
-Needed low-power switching for the [fingerprint door
-lock](../fpm-door-lock-lp/). Servo and FPM draw high quiescent current--had to
-cut power electronically during sleep. MOSFETs can do this.
+Needed low-power switching for [fingerprint door lock](../fpm-door-lock-lp/).
+Servo and FPM draw high quiescent currents--had to cut power electronically
+during sleep. MOSFETs can do this.
 
 Schematics belong to <a
 href="https://electronics.stackexchange.com/users/292884/simon-fitch"
@@ -40,7 +40,7 @@ suitable through-hole MOSFET I could find.
 
 ![N-channel high-side switching circuit](n_high_side.png)
 
-Less common but works if you have voltage high enough to drive the gate. Both
+Less common but works if you have a voltage high enough to drive the gate. Both
 M1 and M2 are N-channel. MCU low → M2 off → M1 gate rises above threshold →
 servo on. MCU high → M2 on → M1 gate drops → servo off. R2 prevents
 high-impedance power-up from switching servo on.
@@ -49,7 +49,7 @@ M2 needed in both topologies for level conversion (0V ↔ +6V or +9V). Carries
 <1mA. Gate-source threshold must be lower than MCU supply. Common choices:
 2N7000, 2N7002, BSS138.
 
-Note: D1 flyback diodes protect MOSFETs from voltage spikes caused by inductive
+Note: D1 flyback diode protects MOSFET from voltage spikes caused by inductive
 loads (servos, relays).
 
 ## A BJT alternative
@@ -58,14 +58,14 @@ loads (servos, relays).
 
 Simpler, cheaper, more available. Q2 conducts when MCU outputs high. Q2
 amplifies Q1's base current. Unlike MOSFETs (voltage-driven), BJTs are
-current-driven. R3 and R4 must be calculated for desired base currents.  <a
+current-driven. R3 and R4 must be calculated for desired base currents. <a
 href="https://teachmetomake.wordpress.com/how-to-use-a-transistor-as-a-switch/"
 class="external" target="_blank" rel="noopener noreferrer">Guide on BJT
 switches</a>.
 
 ## Which topology?
 
-MOSFETs preferred in professional work—more efficient when on. Harder to drive
+MOSFETs preferred in professional work--more efficient when on. Harder to drive
 at 3.3V due to V<sub>GS</sub> requirements for full saturation (low
 R<sub>DS(on)</sub>).
 
@@ -73,7 +73,7 @@ N-channel: Lower on-resistance, cheaper, more efficient than P-channel. Harder
 to drive high-side (gate must be above source—requires extra circuitry like
 MOSFET drivers).
 
-Used P-channel high-side for the door lock redesign. Simpler to drive from 3.3V
+Used P-channel high-side for door lock redesign. Simpler to drive from 3.3V
 MCU, no driver needed.
 
 ## Further reading
-- 
cgit v1.2.3