Levandor

ESP32 Activity Log

7 min read

For Agents

Reverse-chronological session log. Newest entries at top, grouped by date (## YYYY-MM-DD). Each bullet: one piece of work, short summary, wikilinks to docs touched. Updated by obsidian-documenter on every project doc write. Read by historian at bootstrap.

2026-09-03

  • ⭐ New section: Breadboards — the 5-column geometry rule — and it is the kind of fact that stops a wrong purchase. A standard breadboard is 1.1 in (27.9 mm) outermost row to outermost row: five rows spanning 0.4 in, a 0.3 in channel, five more spanning 0.4 in. Free rows per side by pin pitch: 0.3 in → 4+4, 0.6 in → 2+3, 0.9 in → 1+1, 🔴 1.0 in (ESP32 DevKitC / 32UE) → 1+0, 1.1 in → 0+0. At 1.0 in half the GPIOs are physically unreachable. ⛔ No larger breadboard fixes this — width is fixed across every standard breadboard; a “bigger” board is longer, never wider, which is exactly why buying one is the natural wrong answer. The four real fixes: more boards (one per ESP32 — hence 3× BB-102 on the 2026-09-02 cart), two boards butted with the facing power rails removed, F-M jumpers to lift the board off entirely, or a 0.6 in pitch board (the XIAO ESP32C3 ordered for buttonbox solves it structurally) — Breadboards — the 5-column geometry rule
  • ✅ Correction recorded: the BB-102 is a FULL SIZE board — 56 × 165 mm, 630 + 200 tie points — not a 170-point mini. Earlier sessions assumed otherwise and the wrong fix (830-point breadboards) was nearly ordered to solve a row-access problem that extra length cannot touch — Breadboards — the 5-column geometry rule
  • Wired in the new buttonbox project — two-button gizmo in a gutted industrial pushbutton station, XIAO ESP32C3, design phase. Added a Project Cross-References row (NO/NC convention and why NC fails loud, the mains-vs-battery trade at ~500 ms → ~30 ms press-to-action, the dumb-device + server-side gesture semantics wire format, and a deliberate break of tailnet-service-exposure-convention because an ESP32 cannot join the tailnet) plus a Related entry. Its NC-bias, ext1 single-trigger-level and WiFi-latency findings are not duplicated — they already live in esp32-battery-deep-sleep — esp32

2026-09-02

  • The board stock now has a vault-level home: inventory. Boards on Hand listed the 10 S3-WROOM-1 and 5 32UE DevKits but nothing else from the order they arrived in, so “do I already own one?” was unanswerable for every non-board part. The new note carries all 26 line items of HESTORE H26/7333913 with cikkszámok (boards are 100.474.96 / 100.495.37, pigtails 100.364.22 — boards alone were 47 600 Ft of the 84 100 Ft order), plus the ⭐ cikkszám = product URL number with dots inserted rule (prod_10022512.html → 100.225.12) that turns any HESTORE link into a part number and back. Relevant gaps it surfaces for ESP32 work: zero ceramic capacitors — no 100 nF decoupling anywhere, and an unresolved 17-line 2026-01-24 list that may or may not have been ordered and contains a sixteenth ESP32 (100.481.79 ESP32-S3-DEV-N16R8) — inventory
  • First battery / deep-sleep / low-power content in the vault. Every ESP32 project so far (lightaim, hardcut, 2026-08-11-ruview-esp32-csi-real-hardware) is mains- or vehicle-powered and always-on, so none of this had ever been recorded. Ten silicon/component hazards, continuing esp32’s index as items 12–21: DevKit carrier boards sleep at 20–45 mA vs 7–10 µA for a bare WROOM-1 — a ~3000× spread decided by the carrier (CH343 + AMS1117 + power LED), i.e. ~4 days vs ~30 years on an 18650, which makes the 5× DEVKIT-32UE stock unusable for battery work while the 10× bare S3-WROOM-1 modules are fine; ESP8266EX cannot wake from deep sleep on a GPIO at all (only the RTC timer via GPIO16→RST — a reset carries no record of which pin, and ~250 ms to user code is longer than a tap, so it needs a 74HC74 latch per button; light sleep does wake on GPIO but costs 0.4–0.9 mA → ~130 days — and ESP8266 deep sleep at ~20 µA is worse than the S3 anyway); WS2812 draws ~0.7–1 mA showing black (~100× the sleep budget — use plain LEDs or gate VDD with a FET); power-bank/boost modules (MH-CD42, IP5306 class) auto-shut-off below ~40–50 mA so a device sleeping at 10 µA kills its own supply in ~30 s — 🔶 verify per-unit with a 470 Ω / ~10 mA load for a minute, salvage by tapping B+/B− and ignoring the boost, correct part is TP4056+DW01A (~5 µA); LDO Iq can exceed the MCU — the AP2112K-3.3 from 2026-07-29-hardcut-design’s 12 V chain is ~55 µA (5× a sleeping S3), XC6220 (9 µA, 1 A) satisfies both Iq and the 350–500 mA WiFi peak that rules out MCP1700, and never run an ESP32 off a raw 4.2 V cell; Li-ion self-discharge (~2 %/mo ≈ 1.9 mAh/day) is the floor — 8× a sleeping S3’s 0.24 mAh/day, so below ~10 µA an nRF52840 buys nothing on an 18650 (its real edge is coin cells, which an ESP32 physically cannot use — CR2032 10–15 Ω ESR collapses above ~20 mA); an NC switch bleeds 73 µA through the internal 45 kΩ pull-up — fix with NC to 3V3 + 1 MΩ pull-down, internal pulls off (3.3 µA) which also inverts the sense to LOW-on-press, mattering because esp_sleep_enable_ext1_wakeup() takes one trigger level for the whole mask, not per-pin (per-IO API is IDF 5.x); ext1 ANY_LOW entered with a masked pin already low = infinite wake loop (level- not edge-triggered — a stuck/broken NC button flattens the cell in hours; firmware must check pin states, mask stuck pins out and re-check on a timer) — the archetypal “fine on the bench, dead in a drawer three weeks later”; ⚠️ MEASURE: octal-PSRAM N16R8 parts may add tens of µA depending on VDD_SPI, unverified and directly relevant since all 10 bare modules are R8; and WiFi wake-to-delivered ~2.6 s → ~500 ms by caching BSSID+channel in RTC slow memory (not NVS — that’s a flash write, see Flash operations are the real threat), static lease, literal IP, no TLS on-LAN, with a full-scan fallback given the documented router reflash / DFS churn in 2026-08-26-router-reflash-mac-5ghz-dfs-and-bambu-offline — esp32-battery-deep-sleep
  • Wired the new note into esp32 without restructuring it: hazard-index pointer to items 12–21, a DevKits-are-unusable-on-battery callout under Boards on Hand, a ### Battery and deep sleep subsection in Power & Interfacing (with the AP2112K-is-wrong-for-a-cell warning and a ten-row one-line rule table), plus Project Cross-References and Related rows — esp32

2026-08-13

  • Created the cross-project ESP32 reference area. Consolidated the reusable silicon/toolchain/wiring layer that was previously only findable if you already knew which project hit it — pulled from lightaim, 2026-08-12-lightaim-bench-bringup, 2026-08-11-ruview-esp32-csi-real-hardware, 2026-07-29-hardcut-design, 2026-08-08-hardcut-plan and tatabanya-mesh. Every entry carries the symptom so an agent can match a fault to a rule. Covers: S3 LEDC caps at 14-bit (16 → no PWM at all while the firmware looks healthy), ADC2 dead whenever WiFi is active (ADC1 = GPIO1–10 on S3 / GPIO32–39 on classic, 34–39 input-only), S3 strapping/USB pins to avoid, S3 bootloader at 0x0 vs classic 0x1000, uvx --from platformio needs --with pip (+ rm -rf ~/.platformio/packages/tool-esptoolpy), Arduino core is 2.0.17 not 3.x with the two incompatible LEDC APIs and the verbatim guard from lightaim’s main.cpp, flash over UART (CH343 1a86:55d3) never native USB (303a:*) — native USB cannot flash a running board and cost RuView a whole node, Docker --device sidestepping dialout, the pyserial DTR/RTS reset for capturing boot output esptool eats, core pinning does NOT isolate an ISR from WiFi (~4 µs baseline, +50–100 µs — Espressif forum figures, not a rigorous study) and flash write/erase stalling task code for milliseconds being the real threat, ISR hygiene (LEVEL3|IRAM, out_w1ts/out_w1tc because gpio_set_level() is not IRAM-safe), servo power separation / common ground / feed divider modules’ +5V pad from 3V3, and automotive 12 V reality (13.8–14.4 running, 6–9 cranking, 35–40 V+ load dump). Also recorded boards on hand (10× S3-WROOM-1-N16R8-M PCB-antenna, 5× DEVKIT-32UE-4M U.FL) and the antenna rule: WROOM-1 has no U.FL, only the “U” variants do; the antenna buys ~1 dB, the connector buys 10–20 dB by escaping enclosure loss / keep-out violations / orientation mismatch; SMA and RP-SMA thread together and never make contact. RuView’s display-probe trap is cross-referenced, not duplicated — esp32
  • Added back-pointers to esp32 from all six source notes, plus an Agent Landing project-table row and a #project/esp32 tag row — esp32

Graph View