Log — Embedded & IoT Wiki

Append-only history. Entries start with ## [YYYY-MM-DD] <op> | <title> (split · ingest · query · lint).

[2026-07-27] split | embedded-iot-wiki created from the hub _inbox (4 sources)

Spun out by the hub router when awesome-iot arrived and completed a cluster of hardware strays that had been parked separately: nuvoton-nsc128l42-mcu (embedded-hardware, 2026-07-15), up-wcl-wildcat-lake-sbc (edge-hardware, 2026-06-18), the-open-book-ereader (open-hardware, 2026-07-14).

Why now, when two earlier passes said no. Both prior routers looked at these strays and declined to cluster them, on the grounds that a mixed-signal MCU, an x86 edge SBC and a DIY e-reader "share only hardware" and sit in four different sub-domains. That was a fair call on the evidence then: three unrelated-looking objects with no source describing the field they belong to. awesome-iot is that missing source. Its taxonomy puts bare MCUs, MCU dev boards, Linux SBCs, the RTOS layer and the protocol stack in one structure, which is what turns three strays into three points on one axis (embedded-systems). The spin-out is the hub rule applied (≥3 cohering sources, trigger counts), with the coherence supplied by the trigger.

Deliberately not migrated: the hub's parked nvidia-doca-in-silicon-security — datacenter DPU silicon security, a different layer from edge/device hardware. Two earlier routing passes kept it separate and this one agrees; its _inbox record was updated with an adjacency note pointing here.

Founding pages: 4 sources + 5 concepts (embedded-systems, microcontroller, single-board-computer, iot-protocols, open-hardware) + spine.

Corpus honesty note recorded in synthesis: three of the four founding sources are vendor or author self-descriptions, and nothing here is independently measured. Entity nodes deferred at founding (see index.md notes). Biggest gap named on day one: no firmware/RTOS source.

avoid-ai-writing run over the founding prose. Site rebuilt + verified at the clean rung, as the hub requires for a split.

[2026-08-03] ingest | BitBang (richlegrand) — device connectivity without the cloud

Routed from the hub (Telegram). New: bitbang (T3 source summary), device-reachability (DefinedTerm/constraint). Updated: iot-protocols (the tier above the three tiers), synthesis (thesis addition + a shape-of-the-field bullet + two open questions + a first tension + two adjacency lines), index. Name warning recorded on the page, in the index and in synthesis: this is not bit-banging a protocol on GPIO and has nothing to do with ../bit-manipulation-wiki. Substance: bitbang serve prints a URL; a browser opens it and gets a shell, a file browser and an HTTP proxy to that machine over a WebRTC data channel. The signaling server authenticates the device by RSA challenge and brokers ICE/SDP, then leaves the data path. Device UID = hash of its public key, in the URL; 64-bit access code in the URL fragment, which browsers never send to a server, so the server can route a connection but not initiate one. Four repos incl. an OctoPrint integration (3D printer UI + H.264 camera behind one URL) and a WSGI/ASGI wrapper. MIT, 27★. Why it earned a concept page: it supplies the constraint the spoke was missing above iot-protocols — a NATed device can dial out and can't be dialled, so something with a public address must hold the connection, and whoever runs that ends up owning accounts and data. device-reachability records that plus the project's four-way broker taxonomy (cloud platform / tunnel / mesh VPN / introduction-only), which is a useful map independent of whether BitBang works. Best connection: the spoke now has two refusals of the middleman — the-open-book-ereader drops the radio and gives up remote access, BitBang keeps the network and removes the cloud. Same discomfort, different price. First tension in the spoke, recorded as altitude rather than contradiction: awesome-iot catalogues the platform layer as part of the stack; BitBang calls it an accident of timing. T3 justified — author's own README plus two design docs, MIT and readable, but no independent audit, no benchmark, and no P2P success rate (symmetric/CGNAT and TURN fallback are undiscussed). Entity Rich LeGrand deferred per the spoke's founding practice; noted in index. Verify deferred per hub policy (content-only). avoid-ai-writing run.

[2026-08-05] ingest | Zephyr RTOS documentation (research pass)

Via the hub research pass against growth edge #3. zephyr — the Zephyr Project's own reference documentation, T1, the spoke's first T1 and its first firmware source of any kind. Paged rtos alongside it as the concept, which answers the open question "does the RTOS layer deserve its own pages?" with a yes.

Gap-relevance: this was the spoke's self-declared "most obvious gap" — a hardware-only corpus with nothing about the software running on it. It also retires the zero-T1 auto-edge that has sat on the hub ## Most wanted list since it was added.

What the ingest changed in the thesis rather than merely adding: the RTOS turns out to be where the protocol-tier fragmentation iot-protocols records gets absorbed — one kernel across 10+ architectures, the board expressed as devicetree data rather than a port. That is the first argument in the corpus that the fragmentation is survivable, and it comes from a project with no radio stack to sell.

Recorded weaknesses, because T1 here means authoritative and not disinterested: the docs give no footprint figure and no board count — the two numbers a reader would actually use — and name Common Criteria and FIPS 140-2 as schemes the project might pursue, holding neither. So the spoke still has no independent measurement of anything. Growth edges re-ranked accordingly: the vendor-sourced edge closes, and "still no protocol standard" plus "one RTOS is not a comparison" replace it.

Also located but not fetched: LoRa Alliance TS001 LoRaWAN L2 1.0.4, behind a resource-hub gate. Left as the named target for edge #2 rather than substituted with a summary of it.

[2026-08-05] ingest | awesome-iot (re-seen — refreshed in place)

The same URL arrived again via Telegram. Per the edge rule this refreshes awesome-iot in place; no new page, no _inbox duplicate. Changes since 2026-07-27: ~4.2k → ~4.4k★, 507 → 520 forks, and GitHub reports the licence as MIT where the page recorded CC0. Both licence readings are kept and the conflict flagged on the page — unresolved. Taxonomy and the accretes-rather-than-prunes caveat are unchanged; tier stays T3.

[2026-08-05] ingest | Awesome Embedded and IoT Security (Fraunhofer FKIE)

Routed from the hub (runner-up: ../defensive-security-wiki). New pages: awesome-embedded-iot-security (source, T2) and fraunhofer-fkie (Organization). CC0, 2.4k★, ~100+ entries across software tools, hardware tools, 13 books, 20+ papers, case studies, CTFs and conferences.

Graded T2, above the hub's other curated catalogs: the curator is a publicly funded research institute with an academic record, not an anonymous individual. Noted that it also lists its own tool (FACT).

It closes the standing open question "where does device security land?", and the answer keeps the seam where the spoke put it. Everything in the list is analysis of a device — firmware extraction, binary RE, JTAG/UART, side channels — which is a different activity from the fleet-defense practice ../defensive-security-wiki owns and which precedes it. Residual gap recorded: no network-tier section, so protocol-layer security remains unsourced on both sides.

Synthesis also gained the connection the spoke had been missing: open-hardware and hardware-based attack tooling are the same physical-accessibility property read from opposite ends.

[2026-08-08] ingest | FlopperZiro (lraton/FlopperZiro)

Routed from the hub (Telegram). T1 (official project repo), GPL-3.0, 1.8k★, Arduino/STM32. New pages: flopperziro, lraton. Updated open-hardware — this source earns it a third motivation.

Why it matters here rather than in a security spoke. The subject is a build: a parts list, a wiring diagram and firmware. The established seam (awesome-embedded-iot-security, 2026-08-05) already says the device as an object of study stays in this spoke while the practice of using one belongs to ../osint-wiki / ../defensive-security-wiki. Dual use is recorded on the page rather than argued.

The finding is in the bill of materials. STM32-L432KC, FS1000A/RXB12 433 MHz pair, PN532, SSD1306, microSD shield, TP4056 + boost, IR, six buttons — all commodity breakout boards, no custom PCB. Two things follow:

1. Substitution as a third reason to publish open hardware, beside platform-building and control-over-the-object. It needs neither a company nor a principle — only that the product's functions decompose into parts already on sale.
2. The replication floor. the-open-book-ereader needs PCB fab and reflow to rebuild; this needs a soldering iron. The spoke had discussed openness as licensing and publishing, with the standing note that copying hardware costs money. It costs different money depending on whether a custom board is in the design.

Limits recorded, and labelled as inference from the BOM: fixed-frequency OOK modules replay simple 433 MHz codes and are not a frequency-agile transceiver, so the project reproduces the function list far more cheaply than the instrument. The author's own disclaimer — "not intended to serve as a replacement for professional diagnostic hardware" — reads as accurate rather than defensive.

Entities: 1 created.

[2026-08-08] ingest | Flipper_Zero_DIY (cbwhickstein) — the negative case

Routed from the hub (Telegram), minutes after flopperziro and about the same target. T1 (official repo) and deliberately thin: 96★, 19 commits, no licence, "A NOT FINISHED Flipper Zero Clone." New pages: flipper-zero-diy, cbwhickstein.

Ingested for the negative result. The author worked from the vendor's published schematic toward a custom PCB, priced fabrication and assembly, and stopped: "because of the form factor and factory assambling the price of creating a DIY Flipper would exeed the price of a bought one" — roughly $220, above retail.

Why this matters more than the code. Paired with flopperziro it is a natural experiment on the replication floor this spoke named the same day. Two attempts at the same substitution, one rung apart: breakout modules and no custom board (works, 1.8k★) versus schematic-faithful custom PCB (abandoned, above retail). The deciding variable is form factor, and the author states it.

So the substitution motive added to open-hardware this morning gains a boundary condition rather than a caveat: it holds at the breakout-board rung and inverts at the custom-PCB rung, because what the commercial product sells is integration, and custom-board plus assembly costs do not fall at volume one. Folded into open-hardware and synthesis.

Recorded as a limit: one quote, one fab, one board, undated, no BOM published to check it against. That it stopped the project is the durable fact; $220 is indicative.

Entities: 1 created.

[2026-08-08] ingest | Raspberry Pi Pico series documentation

Routed from the hub (Telegram), third embedded source of the evening. T1, first-party. New pages: raspberry-pi-pico, raspberry-pi. Updated microcontroller, which had carried the Pico as a one-line example since 2026-07-27.

Dedup finding worth recording: the Pico was referenced on four pages (microcontroller, embedded-systems, awesome-iot, the-open-book-ereader) and had no page of its own — a recurring node the corpus used without owning. Created rather than refreshed.

Two things in the docs earn synthesis space.

1. RP2350 boots two instruction sets — "dual-core Arm Cortex-M33" or "dual-core Hazard3 RISC-V processor", same silicon. The spoke's fragmentation-absorption reading (zephyr: one kernel, a dozen architectures, board-as-devicetree) now has an instance one layer lower, in the chip. Absorption at two layers is a stronger claim than either alone.
2. The product matrix is mostly assembly. Strip wireless and the variants differ only by presoldered headers and a JST debug connector — soldering sold as a SKU — while castellated edges on the base model serve reflow into someone else's board. That closes a loop with flopperziro / flipper-zero-diy from the same evening: the replication floor is an axis the vendors price too, not just a property of hobby builds.

Specs recorded: RP2040 M0+/133 MHz/264 kB/2 MB/8 PIO → RP2350 150 MHz/520 kB/4 MB/12 PIO; W variants Wi-Fi 802.11n + BT 5.2, WPA3, soft AP for four clients.

Standing caveat unchanged — first-party docs are authoritative for what is offered and give no power, throughput or comparative figures, the same limit the spoke records against up-wcl-wildcat-lake-sbc.

Entities: 1 created (raspberry-pi).

[2026-08-08] ingest | ESP32 (Espressif Series Datasheet v5.3)

Routed from the hub (Telegram), fourth embedded source of the evening. T1. New pages: esp32, espressif. Updated microcontroller, which had named the part since 2026-07-27 without linking one.

Source substitution, recorded: the link that arrived was the espressif.com product page, which is positioning with almost no figures. Ingested from the Series Datasheet v5.3 instead — same vendor, same product, actual numbers. The page's url: points at the datasheet and says so.

Dedup: same shape as raspberry-pi-pico earlier tonight — ESP32 was referenced on three pages (microcontroller, awesome-iot, the-open-book-ereader) and owned by none.

Figures recorded: Xtensa LX6 single/dual core at 240 MHz on TSMC 40 nm; published CoreMark 539.98 (1 core) / 1079.96 (2 cores); 448 KB ROM, 520 KB SRAM, 16 KB RTC SRAM, QSPI to external flash; 802.11b/g/n to 150 Mbps with four virtual interfaces; BT 4.2 BR/EDR + BLE at +9 dBm; deep sleep 10 µA with a ULP coprocessor; secure boot, flash encryption, 1024-bit OTP, hardware AES/SHA-2/RSA/RNG.

The finding is the document, not the chip. Against the Pico the raw numbers are closer than reputation suggests (520 KB SRAM each, 240 vs 150 MHz) and the vendors diverge on what a datasheet is for: Raspberry Pi documents boards (headers, pads, connectors), Espressif documents silicon (benchmark, security blocks, process node, errata, and parts flagged NRND/EOL). Lifecycle status appears in no maker-board page here and is routine in a chip datasheet. Folded into synthesis as a statement of the spoke's maker↔industry span.

Growth edge 1 narrowed, not closed. Espressif publishes a standard benchmark, which beats a TOPS figure; but it is self-reported, CoreMark ignores radio and power, and nobody has run the two parts against each other. Two first-party datasheets are not a comparison — that sentence is now on the page and in synthesis.

Entities: 1 created (espressif).

[2026-08-08] ingest | ESP32 (Wikipedia) — the family, and the RISC-V migration

Telegram source, en.wikipedia.org/wiki/ESP32, T2 (encyclopedic coverage of an established product). Dedup: esp32 already existed, ingested from the Series Datasheet v5.3 hours earlier, so this refreshed that page in place rather than creating a second one. No new pages.

What it adds over the datasheet, which is the whole reason it was worth reading: the launch date (6 September 2016, succeeding the ESP8266), the full variant lineup, and the architecture split. Xtensa stops at the S-series; C2, C3, C5, C6, H2 and P4 are all RISC-V, including the 360 MHz P4. Where the two sources overlap on specs the datasheet wins and the Wikipedia figures were not used.

Reads on the spoke's absorption thread, and against it. RP2350 absorbs the ISA choice into the silicon; Espressif makes the choice once at the vendor level. Recorded in synthesis as a counter-example rather than folded into the existing reading. espressif updated with the one-directional branch; esp32 gained the lineup table and the ESP-IDF note.

No entity discovery — espressif is already a node and Wikipedia names no author.

[2026-08-10] ingest | "$5 microcontroller as a side business" — a paywalled stub

Routed here by the hub. Source: https://medium.com/@andy25/how-a-5-microcontroller-could-quietly-become-your-side-business-1c55ec2a50e2, T4. Page: microcontroller-side-business.

Body never read. WebFetch returned a truncated preview; the firecrawl fallback hit Medium's members-only regwall outright. Per ../HUB.md, that exhausts the escalation, so this is an honest stub built from the preview rather than a summary pretending to be a reading.

What survives: the thesis "It's never the chip that sells. It's the object you hide it inside," the "exactly one job" design rule, and three examples (weather station, electronics in a handbag, cereal box as a game console). No prices, no revenues, no evidence any such business exists. Author has 457 followers and no stated credentials.

Kept for one reason. It states plainly what this spoke's corpus keeps demonstrating silently — the esp32 is in nearly every project here and is never the subject of one (the-open-book-ereader, flipper-zero-diy). And it pairs with mimiclaw in ../agentic-tooling-wiki, routed hours earlier: that project's "$5 chip" headline hides a ~$10 board and metered API calls per turn. Two sources in one day pricing a product at its cheapest component; this one at least admits the chip is not the product.

Refresh in place if the article ever becomes readable.

[2026-08-15] ingest | Input Multiplexing — Maximum Pins with Minimal Resources (Make:)

https://makezine.com/article/electronics/input-multiplexing-maximum-pins-with-minimal-resources/ arrived via Telegram; routed here by the hub (runner-up: none — no other spoke owns MCU I/O technique; ../bit-manipulation-wiki is instruction-level bitwise work, a different subject). Chris Wasshuber, Make:, 2026-08-10. Six ways to read more switches than you have GPIO pins, written from a stated corner: six switches, two pins left, simultaneous presses required. New pages: input-multiplexing-make (source), input-multiplexing (technique). microcontroller gained a "pins are the other scarce thing, and they trade" section. Tier T2, and the justification matters: this is the spoke's first quantified comparison of alternatives — 190 B flash to read an I²C expander, 59 mV worst-case noise margin on a 4-resistor ladder, −2 mV/°C on a diode ladder — on declared assumptions (3 V, 10-bit ADC, E12 values, 1–2 kB ATtiny-class parts), which makes the arithmetic checkable. It is not independent: the winner is the author's own 5-resistor scheme (124 mV vs 59 mV, 94 B vs 162 B), measured by him, replicated by nobody, verified on a "miniTesla prototyping system." Recorded on the page rather than smoothed over. Gap-relevance: this is a new layer for the spoke (circuit-level I/O), not an answer to a standing question. It does move the corpus-quality caution: from "no independent number about anything" to "no number from anyone without a stake." New coverage edge 9 (debounce/ESD/tolerance stacking, and an application note or text that nobody is selling from). Synthesis: new section "The constraint has an exchange rate" — the six techniques are conversions between scarce things (pins → flash bytes → noise margin → thermal drift → capability), and they run microcontroller's integration argument backwards: integration deletes external parts by spending die area, multiplexing deletes pins by spending external parts and firmware. Corrections to received wisdom worth keeping: matrix scanning saves one pin on six switches (it pays from 4×4 up), and Charlieplexing's n(n−1) yields two switches on two pins and cannot report simultaneous presses at any size. Entities: none created. Wasshuber named in prose, not paged (one article, no biography evidenced — same call as Qarroum/Castillo/LeGrand in the founding note). Make: has no publisher node here. Verify deferred per hub policy (content-only). avoid-ai-writing run.

[2026-08-15] ingest | Scanning For Lifesigns With ESP32 And Raspberry Pi (Hackaday → wifisense-pi)

https://hackaday.com/2026/08/15/scanning-for-lifesigns-with-esp32-and-raspberry-pi-now-open-source/ primary: https://github.com/The-Masked-Bear/wifisense-pi arrived via Telegram; routed here by the hub (runner-ups: ../osint-wiki and ../defensive-security-wiki — a through-wall presence detector is a collection capability and its telemetry gets encrypted for that reason, but the subject is a two-board device and its physics, which is this spoke). Fetched the repository README as the primary per ../HUB.md; the Hackaday post is a short write-up and is recorded as also-read. The-Masked-Bear, Apache-2.0, created 2026-08-14, 15★/5 forks/58 commits at ingest. New pages: wifisense-pi (source), wifi-sensing (technique), the-masked-bear (Person). Updated: esp32 gained "The radio turns out to be a sensor" (CSI is exposed by the chip; ADC2 is unusable while Wi-Fi runs; N16R8 octal PSRAM eats GPIO 33–37). single-board-computer gained the MCU-captures / SBC-computes split as a legible instance of the founding axis. Tier T1, first-party project documentation, with this spoke's standing caveat that the author measured his own build. What justifies the tier beyond the usual: the figures are given against ground truth (14.1 bpm measured against 14.0; empty room +1.1 dB motion / +0.0 dB vitals) and tools/validate_dsp.py drives the detector chain with synthetic CSI of known rate — 81 checks, run by CI on every push. It is the corpus's first reproducible claim, which is not the same as an independent one. Gap-relevance: opens the sensing layer named as unsourced in open question "How wide is embedded?", and narrows growth edge 1 from "nobody measures anything" to "nobody without a stake has measured." New coverage edge 10 (sensors as parts — datasheet, interface, calibration curve, error budget). New open question: whether a third party can recover the same information without the network's cooperation, which decides if Wi-Fi sensing is a device feature or a property of every 2.4 GHz network. Findings worth keeping: CSI exists only when a packet is received, so the Pi sends 100 UDP packets a second purely as stimulus and the sample rate is chosen rather than discovered (passive listening gives ~1 Hz and does not work). Everything reads in dB above the receiver's own noise floor, so an empty room is 0 dB at any distance or transmit power — no calibration, no baseline that can drift. Motion and breathing are separable only because both are Doppler bands: walking at 1 m/s lands near 8 Hz, breathing at 0.13–0.7 Hz. Synthesis: new section "The radio was already a sensor" — capability from signal processing over hardware already installed, a third source of it beside on-die integration and added components; plus the reading habit the corpus keeps confirming, that the sections about failure carry the most information (section 2 of this README is "What it cannot do, and why", alongside flipper-zero-diy's costing and bitbang's concession). Entities: the-masked-bear paged. Hackaday not paged as a publisher — same call as Make: on input-multiplexing-make; no publisher nodes exist in this spoke. Verify deferred per hub policy (content-only). avoid-ai-writing run.

[2026-09-03] ingest | 6LoWPAN — RFC 4944 and RFC 6282, the spoke's first read specification

Sources: https://www.rfc-editor.org/rfc/rfc4944.txt and rfc6282.txt (T1, IETF Standards Track). Research pass, quality cycle; the spoke was third in the least-recently-hunted order (last hunted 2026-08-05).

Growth edge 2 named IEEE 802.15.4, a Thread specification or LoRa Alliance TS001 and all three are gated — IEEE sells its standards, the LoRa Alliance puts TS001 behind a resource hub (already noted on the edge), and the CSA routes Matter and Thread through a download-request form. Checked each before substituting. The IETF gates nothing, and the layer it specifies — how an IPv6 packet crosses an 802.15.4 link — is the part a device actually implements, so the substitution closes the edge rather than dodging it.

Correction to an existing page. iot-protocols said 6LoWPAN exists so IPv6 can cross a "127-byte frame." 127 octets is the PHY maximum; RFC 4944 states the budget as a 102-octet MAC payload, less with link-layer security. Corrected in place with a strikethrough and the date.

What is worth keeping beyond the spec. RFC 6282 obsoletes RFC 4944's LOWPAN_HC1 and says exactly why in three numbered reasons — it optimised link-local traffic nobody sends, refused to use the 16-bit short address the link already supplied, and carried full 128-bit multicast addresses inline — ending with "Implementation of Section 10 of [RFC4944] is now NOT RECOMMENDED." That is a public, venue-internal re-examination of an earlier group's mechanism with no product at stake, which is the shape the hub's standing "nobody re-runs anybody's numbers" item keeps failing to find.

Edge 2 closed; successor edge 2a opened — the 802.15.4 PHY/MAC itself is still bought, not read, the same wall loudspeaker-design hit on IEC 60268. avoid-ai-writing run. Verify deferred to the cycle's single end-of-run gate.

[2026-09-27] ingest | Suutari20 — DIY modular macro keyboard (Squalius-cephalus)

Source: https://github.com/Squalius-cephalus/suutari20 (repo README + GitHub wiki: Getting started, TRRS Splitter, Designing your own module). Routed from the hub with foss-applications-wiki named as runner-up for the QMK/Vial firmware angle; recorded as cross-spoke context on the source page, not ingested there — the dominant substance is the physical, modular open-hardware device.

RP2040/Pico-based macro keyboard whose modules connect over 3.5 mm audio jacks (mono up to TRRS), custom PCB, 3D-printed case, QMK+Vial firmware, MIT licence, 18 stars / 0 forks at ingest.

New page: suutari20 (source). Updated: open-hardware gained a fourth pattern — reuse — alongside platform-building, control-over-the-object and substitution: the PCB imports key-switch and jack footprints from two other published projects (ScottoKeebs, foostan/kbd) instead of drawing its own, a cheaper path in design time though not in build cost (still a custom-PCB replication floor). raspberry-pi-pico gained a fifth citing project. synthesis gained a new dated section folding both observations in, plus the note that QMK+Vial is the spoke's first purpose-built (non-RTOS) firmware stack, alongside zephyr.

Tier T1, per the standing rule (../QUALITY.md → tier by the claim, not the URL): the page rests on the project's own artifact facts (BOM, connectors, firmware, licence), not a capability or performance claim, the same reasoning that tiered the-open-book-ereader and flopperziro T1. Star count does not enter the tier.

No published: — the repo and wiki state no publication date, only a last-wiki-edit date, which is not the same thing. No entity page for the author: the GitHub handle Squalius-cephalus carries no other identifying information, so per this ingest's instructions the project is paged as the entity and no Person page or same-as: was written.

Gap-relevance: the source is honestly thin — five of seven wiki pages are one-revision placeholders ("more information coming soon"), no pinout or module-design rules are published in text, and the README says a YouTube video holds more information than the documentation. Recorded as a property of the source rather than smoothed over.

avoid-ai-writing run (detect + one fix: a "worth recording on its own" vague-endorsement phrase cut). Verify deferred to the next cycle-end gate per hub policy; ran check:wikilinks and check:freshness only, per the per-ingest rule.

[2026-09-27] ingest | VeroDesigner

blazethablunt's browser tool (github.com/blazethablunt/VeroDesigner): draw a schematic, click "Generate Vero," get a stripboard (vero) layout automatically. Single self-contained HTML file, no dependencies, .kicad_sch import, PNG/BOM export. Repo created 2026-07-25, 33 commits, 51 stars/1 fork, latest release v1.4.0 (2026-09-26). No LICENSE file in the repo — recorded as a gap.

New page: verodesigner (source). Updated: open-hardware gained a new section — the tool names a prototyping rung the spoke hadn't sourced before, point-to-point stripboard construction, sitting between flopperziro's bare breakout modules and the custom-PCB rung the-open-book-ereader and suutari20 both sit on. It shows a tool can cut the design labor of a rung (schematic → layout) without moving the replication floor itself, the same shape of saving as suutari20's footprint reuse one rung up. synthesis gained a dated section and a new cross-spoke adjacency entry.

Tier T1, per the standing rule (../QUALITY.md → tier by the claim, not the URL): the page rests on the tool's own artifact facts (features, architecture, component list, licence gap), not on its one comparative claim ("close to hand-designed layouts by experienced builders"), which is reported in prose as the maker's own assessment rather than folded into the tier.

No published: date from the source's own text; used the repository's creation date (2026-07-25), matching this spoke's precedent in ../foss-applications-wiki for whole-repo ingests. No entity page for the author: the GitHub handle blazethablunt carries no other identifying information, the same call made for suutari20 and flopperziro.

Runner-up spoke: ../music-tech-wiki, whose component library is audio-DIY-skewed (12AX7/12AU7 tubes, TL072/NE5532 op-amps, PT2399, NE555, V2164 VCA — guitar-pedal/synth-DIY staples). The tool itself is general-purpose, so the dominant substance stays here; the adjacency is recorded on the source page and in synthesis.md, not duplicated as a second page.

avoid-ai-writing run in detect mode: no word-list violations or hollow intensifiers found; em dashes and bold feature-list labels left as-is, matching this spoke's established prose convention (visible throughout suutari20, flopperziro, open-hardware). Verify deferred to the next cycle-end gate per hub policy; ran check:wikilinks and check:freshness only, per the per-ingest rule.

[2026-10-04] research | IEEE 802.15.4-2024 (edge 2a half closed)

Quality-cycle research pass, Most wanted #35. The edge asked for a freely readable radio-layer specification, on the premise that IEEE sells 802.15.4. IEEE's own listing for 802.15.4-2024 says the PDF "is available at no cost compliments of the IEEE GET program". So the premise was wrong. New page ieee-802-15-4 (T1) holds the scope and the access route. "IEEE sells 802.15.4" is struck and dated on 6lowpan and in the synthesis. The normative text is not read: downloading needs an IEEE account, so successor edge 2b waits on the curator. avoid-ai-writing run.