Kill_LIFE/docs/research/oss_similar_projects.md

OSS Similar Projects Research

Date: 2026-03-25 Author: Kill_LIFE research agent Scope: Programmatic KiCad schematic generation, ESP32-S3 reference designs, ERC-clean LDO patterns, IoT power analysis

---

1. Programmatic KiCad Schematic Generators in Python

1.1 kiutils

Field	Value
URL	https://github.com/mvnmgrx/kiutils
License	GPL-3.0
PyPI	pip install kiutils
Version	1.4.8 (2024-02-02) — also installed locally
Stars	~119
KiCad compat	6.0 and up (tested through 8; format is S-expression, tracks KiCad updates)

Features. kiutils models all KiCad file types as Python dataclasses: .kicad_sch, .kicad_sym, .kicad_mod, .kicad_pcb, .kicad_dru, and library tables. Objects are loaded from file, mutated in Python, and serialised back to S-expression. The library is explicitly designed to be SCM-friendly — it does not reformat unchanged sections, so diffs remain meaningful.

Relevance to Kill_LIFE. kiutils is already installed in the project Python environment (/home/kxkm/.local/lib/python3.12/site-packages/kiutils). It is the most mature option for round-tripping existing .kicad_sch files — for example, to post-process a schematic generated by gen_kicad10.py and update reference designators, add properties, or inject footprint assignments automatically. Its GPL-3.0 licence is compatible with the project.

Key insight. kiutils does not provide high-level schematic routing or net-level connectivity abstractions. It is a file parser/serialiser, not a netlist engine. It is best used in combination with a generator script (like Kill_LIFE's own gen_schematic.py) for round-trip property management.

---

1.2 SKiDL

Field	Value
URL	https://github.com/devbisme/skidl
License	MIT
PyPI	pip install skidl
Version	2.2.1 (2025-12-26)
Stars	~1,400
KiCad compat	Netlists for KiCad 5–9; .kicad_sch output currently V5 format only

Features. SKiDL lets you describe circuits in Python using a netlist-centric DSL. You instantiate parts from KiCad symbol libraries, connect pins with the & operator, run built-in ERC (unconnected pins, drive conflicts), and emit netlists, XML BOMs, SVG schematics, or DOT graphs. SPICE simulation is supported via direct integration. Hierarchical and modular design are first-class: subcircuits are Python functions, and design variants are trivial to create programmatically.

Relevance to Kill_LIFE. SKiDL's approach (code = circuit) is architecturally closest to what Kill_LIFE's AI-agentic generation pipeline aims to do: produce a circuit description from a spec, validate it, and export it. Its ERC engine and SPICE integration are directly analogous to the project's own spice/05_power_ldo_ams1117.sp validation step.

Key insight — limitation. The .kicad_sch output is documented as "currently V5 only". For KiCad 7/8/10 compatibility, SKiDL output must be imported via KiCad's netlist import workflow rather than opened directly as a schematic. There is an open GitHub discussion (#125) tracking schematic generation for modern formats; as of 2025-12 it remained unresolved. For Kill_LIFE's target of ERC-clean KiCad 10 schematics, SKiDL is useful for netlist and BOM generation but not for the final .kicad_sch artefact.

---

1.3 kicad-skip

Field	Value
URL	https://github.com/psychogenic/kicad-skip
License	Open source (MIT-style, LICENSE file present)
PyPI	pip install kicad-skip
Stars	~198
Last commit	February 2025
KiCad compat	KiCad 7/8 .kicad_sch and .kicad_pcb

Features. kicad-skip is a general-purpose S-expression parser with deep KiCad-specific enhancements. It exposes schematic elements (symbols, wires, labels, junctions) as Python objects with TAB-completion and list semantics. New elements can be created with collection.new(), cloned from existing ones, and placed at arbitrary coordinates. Wire helpers (start_at(), end_at()) simplify routing. The project bills itself as "openSCAD for schematics."

Relevance to Kill_LIFE. kicad-skip fills the gap between kiutils (round-trip parser) and a from-scratch generator. Its new() API allows purely programmatic schematic construction on KiCad 7/8-format files. This is directly complementary to Kill_LIFE's own gen_kicad10.py, which hand-generates S-expressions — kicad-skip could replace or extend that approach with a higher-level API. Documented limitations: Y-axis coordinate semantics require careful attention; multi-sheet coordination is not explicitly handled.

Key insight. The 1.27 mm grid alignment requirement is critical and is shared by Kill_LIFE's gen_kicad10.py (which explicitly snaps all coordinates to 1.27 mm multiples). kicad-skip users report the same constraint.

---

1.4 kicad-sch-api

Field	Value
URL	https://github.com/circuit-synth/kicad-sch-api
License	MIT
PyPI	pip install kicad-sch-api
Version	0.2.4
Stars	~30
Last commit	2024-05-27
KiCad compat	KiCad 7/8 — generates byte-compatible .kicad_sch files

Features. kicad-sch-api provides an object-oriented API with full type hints, automatic orthogonal (Manhattan-style) wire routing, component bounding box calculations, connectivity analysis (wires, labels, hierarchy), real KiCad library integration for component validation, and BOM property management. A companion MCP server (mcp-kicad-sch-api) exposes 15 tools for AI agent integration. There are 70+ format-compatibility tests and a KNOWN_ISSUES.md documenting current limitations. The library ships example circuits: voltage divider, RC filter, power supply, STM32 microcontroller.

Relevance to Kill_LIFE. The MCP server is directly relevant to the project's agentic embedded design workflow. Kill_LIFE already uses MCP tooling (see mcp.json, docs/MCP_SETUP.md). kicad-sch-api's AI-agent-oriented design makes it a natural fit for the project's architecture. The automatic wire routing is a significant advantage over hand-computing wire endpoints in gen_schematic.py.

Key insight — maturity. The project is early-stage (30 stars, last commit May 2024). The documented critical coordinate system caveat (inverted Y-axis between symbol and schematic spaces) is the same issue Kill_LIFE's gen_kicad10.py solves explicitly with the pin_screen() function. Use with caution until the project's test coverage matures.

---

1.5 kinparse / kicad-python (KiCad official API)

Field	Value
URL	https://dev-docs.kicad.org/en/apis-and-binding/pcbnew/
License	GPL (KiCad)
Notes	Official Python bindings exist only for pcbnew (PCB editor). Schematic API planned post-KiCad 9.

Key insight. As of 2026, KiCad's official Python scripting API covers only the PCB layout editor. Schematic manipulation via the official API is explicitly not supported and is tracked for a future release. All programmatic schematic generation must happen through external libraries (kiutils, kicad-skip, kicad-sch-api) or by directly writing S-expression text files — exactly the approach used in Kill_LIFE's gen_schematic.py and gen_kicad10.py.

---

2. ESP32-S3 Minimal Reference Designs

2.1 Espressif Official: Hardware Design Guidelines + KiCad Libraries

Field	Value
URL	https://github.com/espressif/kicad-libraries
Docs	https://docs.espressif.com/projects/esp-hardware-design-guidelines/en/latest/esp32s3/
License	Apache-2.0
KiCad compat	KiCad 8 (distributed via PCM)

Decoupling capacitor values (from official checklist):

• VDD3P3_CPU, VDD3P3_RTC (digital VDD): 100 nF per pin, placed as close as possible
• VDD_SPI: 100 nF + 1 µF extra
• Any VDD rail: add 10 µF bulk capacitor to handle WiFi TX current transients
• LDO input bypass: 100 nF minimum
• LC filter on VDD3P3 power rail to suppress harmonics; inductor rated >= 500 mA

This aligns precisely with Kill_LIFE's own schematic (C1/C2: 100 nF, C3/C4: 10 µF, C5: 100 nF, C6: 4.7 µF) and the SPICE model decoupling values (C_DEC1/C_DEC3: 100 nF, C_DEC2/C_DEC4: 10 µF).

Power management ICs in the official ecosystem: Espressif's reference designs do not mandate a specific LDO; they specify the power rail requirements (3.3 V ± 5%, minimum 500 mA for WiFi TX). Common choices in community boards are AMS1117-3.3, ME6206-33, and RT9013-33.

---

2.2 UnexpectedMaker/esp32s3

Field	Value
URL	https://github.com/UnexpectedMaker/esp32s3
License	Not specified (open hardware, PDF schematics provided)
KiCad compat	KiCad 6 (most boards), KiCad 7 (NanoS3), KiCad 8 (OMGS3)

Boards: OMGS3, NanoS3, TinyS3, ProS3, FeatherS3, FeatherS3 Neo. All target the ESP32-S3 family. The repository includes KiCad 6–8 symbol and footprint files plus PDF schematics.

Relevance to Kill_LIFE. This is the most comprehensive open-source ESP32-S3 KiCad reference set that spans KiCad 6–8, making it useful for symbol/footprint reference. Specific decoupling values are in the PDF schematics and match Espressif's guidelines (100 nF / 10 µF pattern).

---

2.3 WhirlingBits/ESP32-S3-Platform

Field	Value
URL	https://github.com/WhirlingBits/ESP32-S3-Platform
License	MIT
KiCad compat	KiCad 5

Design highlights: ESP32-S3-WROOM-1 (N8R8), three independent power sources (two USB-C + barrel jack) isolated with Schottky diodes, LTC3111 buck/boost converter (3–15 V input → 3.3 V), CP2102 USB-UART, 32 kHz crystal. The LTC3111 is a high-end choice versus the simpler AMS1117 used in Kill_LIFE; it enables battery-powered designs with very wide input voltage range.

Relevance to Kill_LIFE. The multi-source power isolation pattern (Schottky diodes preventing backfeed between USB ports) is a pattern Kill_LIFE should consider for boards with both USB power and external supply.

---

2.4 SENTSOR Core ESP32-EMBED (adamalfath/sentsor-core-esp32embed)

Field	Value
URL	https://github.com/adamalfath/sentsor-core-esp32embed
License	CC-BY-SA-4.0
KiCad compat	Not specified

Design highlights: Dual LDO approach — RT9078-33GJ5 + RT9013-33GB (both low-quiescent, TSOT-23-5). CN3165 battery charger, DW01A protection, LC709203F fuel gauge. Configurable power path via PWRCFG jumper pads.

Decoupling capacitors: C1/C2/C4/C7: 1 µF; C5/C8: 10 µF; C6/C9–C13: 100 nF; C3: 220 µF bulk (CASE-B/3528).

Relevance to Kill_LIFE. This is the best open-source reference for battery-powered ESP32 designs with LDO selection optimised for low quiescent current. The RT9013 (Iq = 25 µA, Vdrop = 250 mV) is a direct improvement over AMS1117 (Iq ~5 mA, Vdrop ~500 mV) for battery applications. If Kill_LIFE targets deep-sleep battery operation, this design documents the component choices and BOM values clearly.

---

3. ERC-Clean Programmatic Schematic Generation

3.1 The power_out / power_in Conflict with LDO Regulators

KiCad's ERC enforces that every power_in net must be driven by exactly one power_out pin. LDO regulators in the KiCad standard library (e.g., Regulator_Linear:AMS1117-3.3) define their output pin (VO) as a generic output pin type, not as power_out. This creates two conflicting ERC states:

• Without PWR_FLAG on the output net: ERC reports "Input power pin not driven by any output power pins" on all power_in symbols (+3V3, GND) connected to the LDO output.
• With PWR_FLAG on the output net: ERC reports "Pins of type power output and output are connected" because PWR_FLAG is a power_out pin, and KiCad does not allow a power_out pin to coexist on a net with an output pin.

3.2 Known Patterns and Solutions

Pattern A: Symbol redefinition (ERC-clean, preferred for programmatic generation) Redefine the LDO output pin as power_out in an embedded lib_symbols block within the schematic. This is exactly what Kill_LIFE's gen_schematic.py does — the AMS1117-3.3 symbol is embedded in the schematic file with the VO pin defined directly, bypassing library lookup and allowing full control over pin types. The schematic's own ERC report (hardware/esp32_minimal/erc_report.txt) confirms 0 errors, 0 warnings with this approach.

Pattern B: 1 Ω series resistor (workaround, not recommended for programmatic generation) A 1 Ω resistor between the LDO output and the power net breaks the direct output-to-power_out connection, eliminating the pin conflict. ERC passes because the resistor's pins are passive. Disadvantage: adds a spurious component to the BOM and schematic, and introduces measurable resistance on a power rail.

Pattern C: ERC suppression via (erc_exclusions ...) in the schematic KiCad allows specific ERC violations to be marked as excluded (via the ERC dialog in the GUI). In a generated schematic, this can be injected as an S-expression block. The violations are still detected but marked as intentionally ignored. This is acceptable for tooling-generated schematics but means the ERC log is not truly clean.

Pattern D: Net tie / passive power connector Add the power:PWR_FLAG symbol as a power_in-type connector on the output net, then suppress the ERC warning. In practice this is equivalent to Pattern C for programmatic use.

Kill_LIFE current approach: Pattern A (embedded symbol with controlled pin types). The gen_kicad10.py script reads pin data directly from /usr/share/kicad/symbols/*.kicad_sym at generation time using extract_symbol() and injects the full symbol definition into the schematic's lib_symbols block. This gives complete control over pin type declarations and is the most robust approach for ERC-clean programmatic generation.

Community consensus (forum.kicad.info): Pattern A is the "correct" solution; Pattern B is a common workaround when modifying symbols is inconvenient in the GUI. There is an open KiCad GitLab issue (#6588) tracking the fundamental ERC rule that prevents power_out + output pin coexistence; it has not been resolved as of 2026-03.

---

4. IoT WiFi Power Management — Open Source Frameworks and Reference Designs

4.1 grillbaer/esp32-power-consumption-test

Field	Value
URL	https://github.com/grillbaer/esp32-power-consumption-test
License	Not specified (open source)
Relevance	Empirical measurement of ESP32 board power consumption across sleep modes

Measures seven commercial ESP32 boards in deep sleep, light sleep, modem sleep, and active WiFi modes. Documents the dramatic range: ~240 mA peak (WiFi TX) down to ~5 µA (deep sleep). No SPICE simulation; purely bench measurement. Directly validates the load profile used in Kill_LIFE's spice/05_power_ldo_ams1117.sp (30 mA idle, 350 mA WiFi TX peak).

4.2 ESP32 + ESPHome Energy Monitor (danpeig/ESP32EnergyMonitor)

Field	Value
URL	https://github.com/danpeig/ESP32EnergyMonitor
License	Not specified
Relevance	Open source ESP32-based power monitoring device

A hardware energy monitor built on ESP32 + ESPHome. Relevant to Kill_LIFE as a reference for current sensing circuits (shunt resistor + ADC, or ACS712-style hall effect sensor). Not a SPICE simulation framework.

4.3 SENTSOR Core (see Section 2.4)

The SENTSOR board's dual-LDO + fuel gauge (LC709203F) pattern is the closest open-source hardware reference to a complete power management subsystem for ESP32. The LC709203F provides SOC (state of charge) estimation over I2C, which is directly relevant to any Kill_LIFE variant targeting battery operation.

4.4 LTspice / ngspice for LDO Power Analysis

No open-source project was found that provides ESP32-specific SPICE models for LDO/power-rail simulation equivalent to Kill_LIFE's spice/05_power_ldo_ams1117.sp. The Kill_LIFE SPICE approach (macro-model LDO + current source load profile) is the standard circuit-simulation technique; Analog Devices' LTspice demo circuit library includes LDO transient models but not ESP32-specific ones.

Kill_LIFE differentiator: The spice/05_power_ldo_ams1117.sp file is a purpose-built transient simulation that models the actual WiFi TX load profile (320 mA, 5 ms pulse at t=1 ms) and measures voltage droop against the ±5% regulation limit. The simulation log (05_power_ldo_ams1117.log) confirms v_droop, making this a documented, reproducible design validation step. No public open-source ESP32 design was found that provides an equivalent artefact.

4.5 LDO Selection for Low-Power ESP32 Designs

Community consensus on ESP32 forums (esp32.com, forum.kicad.info):

LDO	Iq	Vdrop	Suitability
AMS1117-3.3	~5 mA	~500 mV	USB-powered only; unsuitable for battery
RT9013-33	25 µA	250 mV	Good for battery; up to 500 mA
RT9078-33	25 µA	~100 mV	Excellent for battery; up to 600 mA
SPX3819	8 µA	550 mV	Ultra-low Iq but higher dropout
ME6206-33	~15 µA	~300 mV	Common on cheap ESP32 boards

Kill_LIFE currently uses AMS1117-3.3, which is appropriate for the USB-powered Waveshare ESP32-S3-LCD-1.85 target. For any battery variant, RT9013 or RT9078 would be the community-recommended replacements.

---

Summary: Relevance Matrix for Kill_LIFE

Project	Topic	Priority	Action
kiutils (installed)	KiCad file round-trip	High	Use for post-gen property/footprint injection
kicad-sch-api + MCP server	Agentic schematic gen	High	Evaluate MCP server integration with existing mcp.json
kicad-skip	Programmatic creation	Medium	Evaluate as higher-level API alternative to raw S-expr
SKiDL	Netlist/BOM/SPICE	Medium	Use for BOM generation and netlist validation; not for .kicad_sch
espressif/kicad-libraries	Component library	High	Install via KiCad 8 PCM for authoritative symbols/footprints
UnexpectedMaker/esp32s3	Symbol reference	Medium	Use KiCad 8 variant (OMGS3) as schematic reference
SENTSOR Core	Battery power design	Medium	Reference for RT9078/RT9013 dual-LDO + fuel gauge pattern
WhirlingBits/ESP32-S3-Platform	Multi-source power	Low	Reference for Schottky diode isolation pattern
grillbaer/esp32-power-consumption	Load profile validation	Low	Validates 30–350 mA load profile in SPICE model
ERC Pattern A (embedded symbols)	ERC-clean generation	Confirmed	Already implemented in gen_kicad10.py — document and maintain

---

Report generated by Kill_LIFE research agent — 2026-03-25