Hypothesis

A compact battery-powered ESP32-C6 module with WiFi 6, BLE 5.0, and LoRa 868 MHz can serve as a transparent wireless bridge for the Accordion / Host serial buses (I2C, UART, SPI), eliminating cable runs to remote or hard-to-reach sensors while preserving full backwards compatibility with the existing Accordion / Host.

The module connects to the host over WiFi using MQTT as the application-layer protocol. The remote end presents standard I2C, UART, and SPI interfaces to any connected device via a 60-pin J_EXT connector. LoRa 868 MHz operates simultaneously with WiFi — not as a fallback, but as a supplemental long-range link for infrastructure-free or beyond-WiFi-range deployments.

block-beta
  columns 3
  RPi["Accordion / Host"] space:1 Module["Beacon"]
  space:1 WiFi["WiFi / MQTT"] space:1
  space:3
  space:1 LoRa["LoRa 868 MHz
(supplemental)"] space:1
  space:3
  space:1 space:1 Sensor["Remote Sensor
or Device
(I2C/UART/SPI)"]

  RPi --> WiFi
  WiFi --> Module
  Module --> LoRa
  Module --> Sensor

Key operational modes:

• Sleep OFF — WiFi always on; acts as a transparent bus bridge
• Sleep ON — Deep sleep with configurable wake interval (NVS-persisted); wakes, publishes data over MQTT, returns to sleep. Target: ≤ 500 ms wake-to-publish using static IP cached in RTC memory.

Power architecture: LiPo 800–1000 mAh + USB-C (BQ24075 power path + MCP1700 3.3V LDO). Deep sleep target ≤ 20 µA total board. Runtime targets: ≥ 7 days at 10 s interval / ≥ 45 days at 30 s interval.

Device identity and serial number assignment:

Each device has a unique ID used in all MQTT topics (beacon/<device_id>/...). Identity is determined at boot by a two-stage lookup:

1. Read NVS namespace beacon, key serial — if present, use the stored serial (format A######, e.g. A003460)
2. If absent, derive a temporary ID from the last 3 bytes of the WiFi MAC address (e.g. MAC 8c:fd:49:01:b0:24 → 01b024)

Serial number is assigned over MQTT (provisioning command) and written to NVS. The device reboots after provisioning; from that point all topics use the serial number as device ID. This ties the MQTT identity to the physical unit serial number tracked in PLEASE. See E-020 for the provisioning decision.

Alternatives considered

Open questions

1. PA_BOOST matching network — π-network (C1=10 pF, L1=15 nH, C2=10 pF) defined for SX1276 at 868 MHz; needs VNA verification at bring-up to confirm impedance match and output power.
2. USB-CDC reliability on R0 — Primary flashing/debug path. If unreliable, UART0 headers (J_UART_TX / J_UART_RX) can be soldered. R1 decision pending bring-up result.
3. SX1276 crystal production BOM — R0 uses ECS-320-10-37B-CKY-TR3 (NDK NX2016SA unavailable at order time). NX2016SA noted as cost-effective production alternative — confirm availability at BOM review (REQ-061).
4. Battery divider always-on drain in R0 — Divider is software-disconnectable via GPIO (REQ-011) but lacks a hardware switch. R0 drain ≈ 2.1 µA always-on. Deep sleep budget is still met (≤ 20 µA). Consider PMOS switch in R1 if budget needs tightening.
5. MQTT topic structure and sleep control protocol — Resolved in firmware development. See E-019 (topic structure) and E-020 (device identity).
6. J_EXT pins 16 and 18 deviation — These carry active signals (EXT_SHDNn, EXT_RESETn) where the reference Accordion product uses GND. Any mating board must be aware; a cable compatibility note is required for ecosystem documentation.

Next step

DVT firmware verification: Phase 2 (telemetry bench verification), Phase 3 (SX1276 LoRa TX/RX), provisioning verification after USB flash issue (E-014) resolved.

Hypothesis

A Raspberry Pi acts as a fully self-contained, offline IoT hub — hosting its own Wi-Fi access point and an MQTT broker. ESP32 devices (Accordion Beacon Modules) connect to the Pi's Wi-Fi and communicate via MQTT with no internet required. The cleanest architecture runs two simultaneous Wi-Fi networks per Pi (dual virtual AP) to separate provisioning from normal operation, enabling identical firmware across all ESP32 units.

Core RPi Stack

Recommended hardware: Raspberry Pi 4B or 3B+ for dual-AP stability. Pi Zero W can work but is less reliable for dual virtual AP mode.

The Problem: Multiple Pis, Same SSID

If several Pis broadcast the same SSID, ESP32 devices connect to the strongest signal — not necessarily the intended unit. This creates fleet ambiguity. None of the naive mitigations (TX power reduction, physical separation, unique SSID pre-flashed) are clean at scale.

Recommended Solution: Dual Virtual AP + Provisioning Flow

Run two Wi-Fi networks simultaneously per RPi:

Network 1 — Generic Setup Network (shared across all Pis)

• SSID: IoT-Setup (identical on every Pi)
• Purpose: Bootstrap / provisioning only; low TX power recommended

Network 2 — Operational Network (unique per Pi)

• SSID: derived from Pi serial/MAC (see ASM — pending head of operations approval)
• Purpose: Normal ESP32 MQTT operation after provisioning

Provisioning flow (with acknowledgement lock):

1. ESP32 powers on with no stored operational credentials (or re-provisioning triggered)
2. ESP32 connects to generic IoT-Setup network
3. ESP32 calls GET 192.168.4.1/provision
4. Pi responds with operational credentials and a lock token:

   { "ssid": "Pi-Unit-7-Network", "pass": "abc123", "lock_token": "xyz" }
   

5. ESP32 saves credentials to flash and sends acknowledgement:

   POST 192.168.4.1/provision/confirm  { "lock_token": "xyz" }
   

6. Pi confirms lock. ESP32 is now bound to this Pi.
7. ESP32 reconnects to the unique operational network.

The acknowledgement step prevents accidental or rogue-Pi binding — locking only occurs after explicit two-way confirmation.

ESP32 connection logic (normal boot):

• Has stored operational credentials → attempt connection to operational network
• Connected → normal MQTT operation
• Cannot connect after N retries → enter provisioning mode automatically
• No credentials stored → enter provisioning mode directly

Lost operational network (Pi replaced, out of range) naturally re-triggers provisioning — no separate recovery path needed.

Re-Provisioning Trigger (Hardware)

A dedicated test point on the PCB, held low during boot, forces the ESP32 to clear stored credentials and enter provisioning mode. To be added to R1 schematic. Existing R0 TPs should be reviewed for a suitable candidate (BOOT pin may be usable).

Alternatives Considered

• Single shared SSID across all Pis: Causes roaming ambiguity. Not viable for fleet use.
• Unique SSID pre-flashed per ESP32: Kills the "identical firmware" goal.
• Bluetooth provisioning: Higher firmware overhead; Wi-Fi-only is simpler given ESP32-C6 capabilities.
• Separate re-provisioning GPIO vs. network fallback: Redundant — roaming fallback already covers the recovery case. TP provides the manual override only.

Open Questions

• Should the provisioning endpoint be authenticated? Resolved: Two-way lock acknowledgement added to provisioning flow.
• Re-provisioning trigger? Resolved: TP held low at boot + automatic fallback when operational network unreachable.
• SSID/password derivation from Pi serial/MAC: Agreed in principle — pending approval from head of operations (see ASM).
• Multi-Pi roaming fallback? Resolved: ESP32 always tries operational network first; falls back to provisioning mode if it cannot connect.

Next Steps

• Resolve SSID/password derivation scheme (pending head of operations sign-off — see ASM)
• Prototype dual-AP setup on RPi 4B (hostapd + dnsmasq config)
• Implement provisioning HTTP endpoint with two-way lock acknowledgement
• Define N (retry count) before fallback to provisioning mode
• Add re-provisioning TP to R1 schematic
• Test with ESH10000671 R0 (A003460) once E-023 (J3 short) is resolved

Symptom

Connecting an external device to J3 (external serial bus connector) causes the 3V3 rail to be shorted to GND. Observed on A003460 during TC-C-02 / REQ-020 verification.

Status

Blocker — root cause not yet investigated. Resolution deferred to a later session.

Suspected Area

• J3 pinout / schematic error (3V3 pin shorted to GND pin in connector layout)
• External device pulling 3V3 low via a low-impedance path
• PCB short between 3V3 and GND in the J3 connector area
• Incorrect connector pinout vs. mating cable wiring

Next Steps

1. Verify J3 pinout against schematic — confirm 3V3 and GND assignments
2. Measure resistance between 3V3 and GND at J3 with no device connected (isolate PCB short vs. device-induced)
3. Measure resistance between 3V3 and GND on the external device connector
4. If PCB short: inspect J3 solder joints and surrounding copper
5. If device-induced: review mating connector wiring and device power input

Impact

REQ-020 (External Serial Bus Connector J3) and REQ-024 (USB-C Power Supply) cannot be fully verified until resolved. MS-002 (Base Functions Verified, target 2026-06-12) at risk if not resolved promptly.

Symptom

SPI reads and writes to all SX1276 config registers work. LoRa mode switch (FSK Sleep → LoRa Sleep → Standby) succeeds. However, any write to OPMODE for modes 0x82–0x85 (FSTX, TX, FSRX, RXContinuous — all PLL-active) is immediately rejected. The chip returns to Standby (0x81) on the next read. Firmware confirmed correct.

Root Cause Hypotheses (ranked)

1. VCC_RF missing or undervolted — directly blocks PLL; chip protects itself
2. LORA_RESETn stuck LOW — would produce exactly this symptom (SPI works, mode transitions fail)
3. Crystal load cap wrong or missing — PLL cannot lock without stable XO
4. RF matching network component missing/wrong value — prevents PLL lock
5. QFN thermal pad not soldered — globally degrades the chip RF circuitry

Existing Finding

Crystal XTA amplitude measured at 520 mVpp — below the ~800 mVpp expected. This is a disqualifier on its own for reliable PLL operation. Whether both XTA and XTB are oscillating cleanly and symmetrically remains to be confirmed.

Diagnostic Test Cases Added

• TC-L-04: VCC_RF and VCC supply rail voltages
• TC-L-05: LORA_RESETn pin state and boot pulse verification
• TC-L-06: Crystal XTA/XTB amplitude and frequency (detailed)
• TC-L-07: RF output matching network component population and solder quality
• TC-L-08: SX1276 QFN thermal pad solder quality inspection
• TC-L-09: DIO0 (IO5) passive state check

Problem

The USB-C connector specified/fitted on the R0 PCB is no longer in production. An alternative connector was sourced but required mechanical modification to fit: support legs and shield pins were cut, and epoxy was applied to all four R0 units to restore mechanical grip.

Affected units: A003458, A003459, A003460, A003461 (all R0 builds)

R0 status

Connectors are fitted and epoxied. Functionally the connector should work for bring-up and DVT. Mechanical robustness is reduced — avoid repeated plug/unplug cycles and handle USB-C connections carefully during testing.

TC-C-00 (USB-C connector fit) should note the modification and assess whether the epoxied connector is acceptable for the purpose of bring-up verification.

R1 action

Replace J2 USB-C connector with 12401899E412A. Verify footprint compatibility with R1 layout before releasing gerbers.

Root cause

R1 is a pull-up resistor connected to EN1 (BQ24075 pin 6). With VBUS present, R1 pulls EN1 HIGH. EN2 is also pulled HIGH by design (RILIM mode). EN1=H + EN2=H = Standby mode → OUT disabled.

Intended state

R1 fix for R1 PCB

No schematic change required. R1 shall be marked No Mount (DNP) in the BOM. The footprint remains; the component is simply not populated.

R0 rework required

All four R0 units require R1 physically removed:

• A003458 — rework pending
• A003459 — rework pending
• A003460 — rework done, SYS confirmed at 4.90V ✅
• A003461 — rework pending

Symptom

The ESP32-C6 USB-Serial/JTAG interface (VID 303A PID 1001) stops enumerating on Windows after repeated USB power cycles. Device remains operational (MQTT heartbeats continue) but COM3 does not appear regardless of USB port or cable used.

History

• USB-CDC flashing worked reliably for multiple firmware sessions
• Issue began after repeated USB power cycles performed to work around the WiFi RF PLL calibration bug (E-014)
• Switching to a specific PC USB port briefly restored COM3; device was successfully reflashed once
• Later, USB enumeration stopped entirely — no VID 303A devices visible in Device Manager
• No Windows USB overcurrent events found in system event log

Probable cause

Windows USB host stack state corruption from repeated connect/disconnect cycles, compounded by the warm-reset RF PLL issue requiring frequent power cycles.

Resolution options (in priority order)

1. Reboot PC — resets Windows USB host stack (resolved the issue once)
2. Disable/enable USB Root Hubs in Device Manager
3. Flash via UART (IO16/IO17 with USB-UART adapter) — bypasses USB-CDC entirely
4. OTA update (Phase 4) — eliminates USB dependency for future firmware updates

Status

Open. Active development blocker for flashing fixed provisioning firmware.

Bug description

In the initial provisioning handler implementation, the handler reads serial_j->valuestring after calling cJSON_Delete(root). The cJSON_Delete call frees the entire JSON tree including all string values, so valuestring is a dangling pointer at the point of use. This is a use-after-free memory safety bug.

Impact

• May crash or corrupt memory on provisioning command receipt
• Provisioning firmware was flashed once; bug discovered during code review
• Device was provisioned once successfully (may have been lucky — behaviour is undefined after free)

Fix

Fix is written and built (REPO/build/beacon.bin). The fix ensures the serial string is copied to a local buffer before cJSON_Delete is called.

Status

Fixed build is ready but not yet flashed. Blocked by USB-CDC flashing issue (E-015). Flash and verify provisioning end-to-end once USB is restored.

Verification required after flash

1. Flash fixed build via SCRIPTS/flash.py
2. Send provisioning command: mosquitto_pub -h 192.168.0.147 -p 1884 -t "beacon/01b024/provision" -m '{"serial":"A003460"}'
3. Confirm device reboots and topics change to beacon/A003460/...

Symptom

After a software reset (esp_restart() or triggered by firmware flash via USB), the RF PLL calibration fails with:

pll_cal exceeds 2ms!!!

WiFi scan subsequently finds 0 access points. Device is non-functional on WiFi until a full power cycle.

Workaround (current)

Disconnect and reconnect USB-C after every firmware flash or software reset. This forces a full power-down and restores PLL calibration.

Impact

• High friction during development — every firmware flash requires a physical USB power cycle
• Provisioning via MQTT causes esp_restart() which triggers the issue
• Incompatible with OTA updates (OTA also requires restart) unless resolved first

Hypothesis

Crystal oscillator requires full power-down to re-stabilise after reset. Antenna keepout zone or crystal selection may be a contributing factor. Warm reset leaves RF circuitry in an intermediate state that blocks PLL lock.

Required investigation

1. Check antenna keepout zone compliance on R0 PCB layout
2. Verify crystal load capacitance (ECS-320-10-37B-CKY-TR3, CL=10 pF) against schematic
3. Test with RF shield or known-good crystal to isolate RF path vs oscillator
4. Check CONFIG_ESP_PHY_CALIBRATION_AND_DATA_STORAGE in sdkconfig
5. Consider testing NDK NX2016SA crystal (alternative documented in E-010)

Status

Open. Workaround in place for development. Must be resolved before field deployment.

Observation

U6 (ADS7828EB/2K5, 8-channel 12-bit ADC, LP_I2C address 0x48) on unit A003460 is exhibiting erratic/incorrect readings. Visual inspection of the board revealed that C28 — the decoupling capacitor on U6's VCC power pin — is not mounted.

Probable cause

The ADS7828 requires proper supply decoupling for accurate conversions. Without C28, supply noise (from BQ24075 switching, WiFi TX bursts, or other sources) will couple directly into the ADC reference and supply rails, causing noisy or offset readings. This is a build/assembly defect on this unit.

Affected unit

• A003460 (only unit inspected; other R0 units not yet checked)

Impacted requirements and test cases

• REQ-011 (Battery Voltage Monitoring) — TC-A-00, TC-A-01, TC-A-02
• REQ-059 (Battery Current Monitoring) — TC-A-05

Recommended rework

1. Solder C28 (100nF 0402, EGP10000641) on A003460
2. Re-run TC-A-00, TC-A-01, TC-A-02, TC-A-05 after rework to confirm readings are nominal
3. Inspect C28 on A003458, A003459, A003461 to rule out a systematic assembly issue

Root Cause

INA333 (VSSOP-8) is used for low-side battery shunt current measurement (100 mΩ shunt, inputs at 0–50 mV above GND). For G = 20.6 (RG = 5.1 kΩ), first-stage amplifier A2 must swing its output to approximately −65 mV to maintain its virtual short. On a single 3.3 V supply, A2 cannot swing below V− = GND and clamps at 0 V. Confirmed by INA333 datasheet §7.4.2: "the linear input range is limited by the output voltage swing of amplifiers A1 and A2."

Evidence — Pin Voltages at 100 mA Charge Current

Pin 8 should equal V_IN− = 0 mV (virtual short). Measured 11 mV matches the resistor-divider result when A2_out clamps at 0 V:

V_pin8 = V_IN+ × R_int / (R_int + RG)
       = 13 mV × 50k / (50k + 10k) = 10.8 mV ≈ 11 mV  ✓

G_eff = (V_OUT − V_REF) / V_diff = 24 mV / 13 mV = 1.85 (not 20.6).

Changing RG from 5.1 kΩ → 10 kΩ → 100 kΩ produced no measurable gain change — consistent with A2 clamped throughout; external RG is irrelevant once A2 is saturated.

Impact

Current measurement unreliable on R0 hardware. Firmware was already corrected to use G = 2.0f (from 20.6f), which partially compensates but does not restore full dynamic range or resolution.

R0 Workaround

Set RG = 0 Ω (short pins 1–8). G_eff = 2.0 (maximum achievable with A2 clamped). Keep firmware constant at 2.0f. Effective sensitivity: 5 mA/LSB at 12 bit with 100 mΩ shunt and VREF = 2.5 V.

R1 Fix

Replace INA333 + ADS7828 with INA226 (Texas Instruments, I²C 16-bit bidirectional current/power monitor). Designed specifically for single-supply low-side and high-side sensing. No external gain resistor; gain set by shunt value and internal 2.048 V reference. Eliminates first-stage output headroom constraint entirely. Compatible with existing LP_I2C bus (IO6/IO7, ESP32-C6).

Task

Identify and qualify a LiPo battery that fits within the mechanical envelope of the Beacon Module enclosure.

Dimensional Constraints

Criteria

• Fits within the above envelope (hard constraint)
• Maximise capacity within the envelope
• Standard LiPo voltage: 3.7 V nominal / 4.2 V max
• JST-PH 2-pin connector (matches J1 on ESH10000671 R0)
• Verify polarity against J1 pinout before ordering

Candidate: LP503034

Fits the envelope on all three axes with margin on thickness and width.

Next Steps

1. Identify a specific part number / supplier for LP503034 (Mouser, Digi-Key, RS, LCSC)
2. Confirm JST-PH 2-pin connector and verify polarity against J1 pinout
3. Select and add to component library and BOM

Finding

ESP32-C6 RTC (internal RC oscillator) runs approximately 3 180 ppm slow relative to wall time. Measured from deep sleep test on A003460, 2026-06-11 to 2026-06-12.

Measurement Data

Drift rate by segment:

Impact

• Each 60 s sleep cycle actually runs ~59.81 s
• Loses ~274 s (~4 min 35 s) per day against wall time
• Drift rate is stable across all measured segments

Root Cause

Internal 150 kHz RC oscillator used for RTC during deep sleep. No external 32.768 kHz crystal fitted on R0.

R1 Fix

Add external 32.768 kHz crystal on XTAL_32K_P/N pins. Expected drift: <50 ppm. Required if accurate sleep interval timing is needed for field deployment.

GPIO assignments constrained by ESP32-C6-MINI-1-N4 fixed-function pins (UART0, USB) and available GPIO matrix pins. LP_I2C assigned to dedicated low-power capable pins (IO6/IO7). IO4 and IO5 originally reserved for JTAG (MTMS/MTDI) — reservation removed 2026-04-12; reassigned to SX1276 NSS and DIO0.

Trade-offs: IO9 (I2C0 SCL) is a boot strapping pin — I2C pull-up holds it high at boot (safe). IO15 (UART1 RX) is a strapping pin for JTAG source. All GPIOs fully allocated except IO23.

Logical separation of subsystems improves readability and parallel review. Power sheet is self-contained for electrical safety review. MCU sheet isolates digital complexity.

Trade-offs: Cross-sheet signals require KiCad hierarchical labels. USB D-/D+ route from Power sheet to MCU sheet. LP_I2C routes from MCU sheet to On-board Peripherals sheet.

ISET and ILIM share 1.5kΩ value for BOM consolidation. TMR=56kΩ gives ~7h fast-charge timer adequate for LiPo cells. NTC thermistor function disabled — divider holds TS at valid level to prevent fault.

Trade-offs: ISET=1.5kΩ → ~593 mA charge current → ~0.77W dissipation on BQ24075; thermal pad copper pour required; BQ24075 TREG will throttle if die overheats. SYSOFF must not be pulled to VBUS. CE must not be pulled to VBUS.

Address 0x20 selected (no conflict with ADS7828 at 0x48). All 6 connector signals grouped on Port 0 for single-register read. LORA_RESETn on P10 (Port 1) is isolated from connector signals.

Trade-offs: RESET pin passively pulled to VCC via 10kΩ (no free MCU GPIO for soft-reset); I2C General Call Reset available as software alternative. INT pin is open-drain; 10kΩ pull-up to 3.3V; routed to IO22.

No conflict with PI4IOE5V6416 at 0x20. Simplest configuration — both address pins tied to GND.

Trade-offs: Address is fixed in hardware; cannot be changed without PCB rework.

Deviations required to expose REQ-038 module control signals (SHDNn, RESETn). No other adjacent NC pins available in that row. VREF exposed for potential mating board use.

Trade-offs: Mating cable/PCB MUST NOT connect pins 16 or 18 to GND — deviates from reference product. VREF (pin 7) limited drive; buffer required on mating board if load >5 mA.

If USB-CDC proves unreliable on prototype, headers allow a standard USB-serial adapter for UART0 access. Headers serve as test points when unpopulated.

Trade-offs: Prototype decision — revisit after board verification. If USB-CDC reliable: leave DNP in R1. If unreliable: populate and consider dedicated UART connector in R1. Partially satisfies REQ-030.

Bidirectional measurement needed to validate REQ-035/036 battery life estimates. ADS7828 CH1 was spare — no extra I2C device needed. PMOS power-gate preserves REQ-017 deep sleep budget (INA333 Iq=50µA otherwise exceeds 20µA limit). PI4IOE P06 was NC — zero cost.

Trade-offs: Adds R_SHUNT in battery series path (minor voltage drop at 600mA). Firmware must manage SHUNTn enable/disable around deep sleep entry/exit.

NDK NX2016SA unavailable at DigiKey/Mouser at time of BOM build. ECS ECX-1637B series is direct drop-in: 2016 4-pad footprint, CL=10pF, ESR≤50Ω, ±10ppm — all within SX1276 crystal requirements.

Trade-offs: ECS part used for prototype only. NX2016SA should be evaluated at production BOM review (REQ-061). No functional difference expected.

Decision

Two separate I2C buses are used simultaneously:

Internal LP_I2C devices (PI4IOE at 0x20, ADS7828 at 0x48) are accessed directly by firmware and are not exposed through the MQTT I2C bridge. All MQTT I2C bridge commands route exclusively to I2C0.

Rationale

• Isolates on-board peripherals from external commands — prevents accidental writes to PI4IOE (which controls power gating, LoRa reset, external reset/shutdown)
• LP_I2C is the ESP32-C6 low-power I2C peripheral — can be used independently of the main I2C0 driver
• Allows external I2C scanning without risk of conflicting with internal device addresses

Rejected alternative

Single I2C bus with address filtering — rejected because it requires firmware to maintain an address exclusion list and could still be bypassed by raw write commands.

Firmware implementation

• pi4ioe component owns LP_I2C bus and creates the bus handle at init
• ads7828 component attaches to LP_I2C handle from pi4ioe
• bus_i2c component owns I2C0 and exposes it to the MQTT bridge handler in main.c

Decision

MQTT topic structure is beacon/<device_id>/<function>/<direction>.

<device_id> is unique per unit — MAC-based temporary ID or provisioned serial (see E-018).

Rationale

• Single namespace per device allows multiple Beacons on the same broker without topic conflicts
• Function/direction suffix aligns with common IoT MQTT conventions
• Flat addr field (decimal integer) avoids JSON hex parsing issues

Rejected alternatives

• Per-device subtopic hierarchy per peripheral — rejected as over-engineered for current use
• Binary protocol — rejected for debuggability (mosquitto_sub readable without tools)

Decision

Device identity is determined by a two-stage lookup on boot:

1. Read NVS namespace beacon, key serial
2. If present: use stored serial (format A######, e.g. A003460) as MQTT device ID
3. If absent: derive temporary ID from last 3 bytes of WiFi MAC

Example: MAC 8c:fd:49:01:b0:24 → temporary ID 01b024 → topics beacon/01b024/...

Provisioning flow

Host sends provisioning command → device writes serial to NVS → esp_restart() → topics change to beacon/A003460/.... Idempotent — re-sending overwrites and reboots.

Rationale

MAC-based fallback allows development without manual provisioning. NVS serial ties firmware identity to the PLEASE-tracked physical unit serial number.

Known limitation

esp_restart() triggers the WiFi RF PLL warm-reset bug (E-017). After provisioning, a USB power cycle is required to restore WiFi until E-017 is resolved.

Decision

For R1, remove INA333 (current sense amplifier) and ADS7828 (8-channel I²C ADC) from the design. Replace both with a single INA226 (Texas Instruments, I²C 16-bit bidirectional current/power monitor, EGP10001944).

Rationale

• E-022 root cause: INA333 cannot achieve high gain (G=20.6) with inputs near GND on a single 3.3V supply — A2 first-stage output clamps at 0V. Not fixable in layout; wrong part for this topology.
• ADS7828 was only used for two signals: battery current (INA333 output) and battery voltage (via resistor divider). Both are replaced by INA226 natively.
• INA226 advantages: bidirectional current sensing by design (confirmed), 16-bit resolution, integrated bus voltage measurement (VBAT on V_BUS pin, 0–36V range), I²C interface compatible with existing LP_I2C bus (IO6/IO7 on ESP32-C6), no external gain resistor, no external ADC reference needed.
• Resolution: 2.5 µV/LSB on ±81.92 mV shunt range → 25 µA/LSB with 100 mΩ shunt — significantly better than R0.
• Net result: two ICs removed, one added. Simpler schematic, smaller BOM, better measurement accuracy.

Power Gating — Deep Sleep Requirement

INA226 quiescent current: 420 µA max in active mode. Deep sleep budget (TC-A-03): ≤20 µA total board.

INA226 must be powered via a GPIO-controlled load switch and gated off before the ESP32 enters deep sleep. This is the same approach already specified for INA333 in TC-A-05 ("INA333 supply confirmed off, ≤1 µA contribution, in deep sleep"). The load switch requirement carries forward unchanged to R1 — no new design obligation, but must be explicitly included in the R1 schematic.

Firmware sequence: wake → enable load switch → wait for INA226 ready → read current + voltage → disable load switch → enter deep sleep.

Rejected Alternatives

• INA190A1 (G=25, EGP10001943): Fixes the common-mode limitation but has no REF pin — requires external biasing circuitry for bidirectional sensing. Added complexity without the integration benefit of INA226.
• INA333 with biased inputs: Would require raising common-mode voltage to ≥490 mV, requiring redesign of shunt placement. Adds complexity; INA226 is cleaner.
• Keep ADS7828 + fix INA333: Not feasible — INA333 is the wrong architecture for this application at the required gain.

Follow-up Actions

• Add INA226 to R1 schematic: IN+/IN− across 100 mΩ shunt (low-side); V_BUS → VBAT
• Place INA226 behind GPIO-controlled load switch (power gate for deep sleep)
• Set I²C address via A0/A1 pins — verify no conflict with existing LP_I2C devices
• Update firmware: replace ADS7828 + INA333 driver with INA226 I²C driver
• Update ibat_ma and vbat_mv calculations for INA226 register format
• REF3425 (2.5V reference) is retained in R1 BOM — required to supply VREF to external modules connecting via J3; not dependent on ADS7828 presence

Decision

Battery life target for ESH10000671 in deep sleep mode, based on directly measured average current:

The test on A003460 (E-031) was run with a 1100 mAh battery. The production battery candidate (LP503034, E-027) is ~500 mAh and sized to fit the enclosure envelope (35×34×6 mm). Final target depends on which battery is selected for production.

Note: LP503034 at ~500 mAh yields only ~7 days projected — may be insufficient for field deployment if longer runtime is required. Consider a higher-capacity battery or enclosure resize for R1.

Basis

Average current: 3.038 mA — directly measured latent current draw at 1-minute wake interval on A003460 (supersedes voltage-slope estimate of ~1.6 mA from E-031).

• 1100 mAh / 3.038 mA = 362 h ≈ 15.1 days projected
• 500 mAh / 3.038 mA = 165 h ≈ 6.9 days projected

Targets set at ~25% margin below projection.

Rationale

• Direct current measurement is more reliable than the voltage-slope SoC estimate used previously
• 3.038 mA at 60 s interval breaks down as: deep sleep quiescent + WiFi/MQTT burst (~50–80 mA for ~3 s) averaged over 63 s cycle
• Active time currently ~3 s/cycle; reducing this (static IP RTC cache, faster MQTT handshake) is the primary lever for extending runtime

Assumptions and Caveats

• Full discharge not reached in E-031 — projection not yet validated against actual cutoff
• 1100 mAh test battery capacity not confirmed from datasheet; nominal value used
• LP503034 (~500 mAh) production candidate not yet sourced with confirmed part number (E-027 open)

Follow-up

• Confirm 1100 mAh test battery spec (actual rated capacity and part number)
• Decide production battery — LP503034 (~500 mAh) gives only ~7 days; may require larger cell or enclosure change
• Run full discharge test to cutoff to validate projected 15-day runtime
• Re-evaluate target once production battery is selected
• Re-measure average current after firmware optimisation (static IP, faster MQTT connect)
• Calibrated current measurement available after R1 INA226 integration (E-024)

Requirement REQ-046 ("Battery Supply") has no verifying test case. Add one with please_testcase_create and link it (verified_by).

Requirement REQ-052 ("Transceiver Supply Voltage") has no verifying test case. Add one with please_testcase_create and link it (verified_by).

Requirement REQ-051 ("RF Supply Rail") has no verifying test case. Add one with please_testcase_create and link it (verified_by).

Requirement REQ-053 ("Transceiver Clock") has no verifying test case. Add one with please_testcase_create and link it (verified_by).

Requirement REQ-059 ("Battery Current Monitoring") has no verifying test case. Add one with please_testcase_create and link it (verified_by).

C19 is populated with 2u2 on all four R0 units (A003458, A003459, A003460, A003461) instead of the BOM-specified 4u7. The 4u7 value was not available at build time.

C19 role: Bulk decoupling capacitor on the filtered RF supply rail (RF_VCC), placed after the ferrite bead that separates RF_VCC from the regular 3V3 rail. Provides low-frequency charge reservoir for the SX1276 RF power pin during TX bursts.

Assessment: The critical RF decoupling function is served by the smaller high-frequency caps (100 nF, 10 nF) which are unaffected. The 2u2 value halves the bulk reservoir but on a low-current RF rail this is unlikely to cause a functional issue. The main risk is marginally increased voltage droop on RF_VCC during SX1276 TX — acceptable to verify during bring-up rather than treat as a blocking deviation.

Action: Verify RF_VCC rail stability during TC-P-08 (RF supply rail voltage at transceiver RF pin) with SX1276 in TX mode. If droop is within acceptable range, close this notice. If significant droop is observed, source 4u7 and rework before continuing.

Status

BOD is intentionally disabled in sdkconfig.defaults (CONFIG_ESP_BROWNOUT_DET=n) for R0 development.

Reason for disabling

BOD falsely triggered during WiFi TX association despite a stable 3.3 V rail (confirmed on bench multimeter). Likely caused by inrush current on WiFi startup exceeding the ESP32-C6's internal brownout detection threshold before the bulk capacitance settles.

Production requirement

BOD must be characterised and re-enabled before production. Required actions:

1. Measure actual 3V3 rail dip under WiFi TX load (oscilloscope, 100 µs resolution)
2. Determine minimum voltage during worst-case load (cold WiFi association)
3. Select BOD threshold below that minimum to prevent false triggers
4. Re-enable CONFIG_ESP_BROWNOUT_DET=y with appropriate threshold

Risk

Without BOD, the device will not reset cleanly on low battery. This is acceptable for development (USB-powered) but not for battery-operated field use.

Assumption

Each Raspberry Pi's operational Wi-Fi SSID and password are derived deterministically from the unit's serial number or MAC address. This makes each Pi self-identifying, auditable, and reproducible without a central credential database.

Agreed in principle during E-025 concept discussion. Not yet approved.

Why Approval Is Needed

• Naming/credential scheme becomes a fleet-wide standard — changing it later requires re-provisioning all deployed ESP32 units.
• May intersect with site security policies (predictable credentials derived from hardware identifiers).
• Head of operations must sign off before this is implemented in firmware or Pi OS image.

Blocked Action

E-025 next step "Resolve SSID/password derivation scheme" is blocked on this approval. Prototype work can proceed with hardcoded test credentials in the interim.

Resolution Needed

Head of operations to approve or propose an alternative scheme. Once approved, promote to a decision entry and close this notice.

Charge cycle verification — A003460, 2026-06-10

Data sources: charge_profile.txt (original, session cut short) + new_charge_profile.txt (complete cycle including discharge history and termination).

Phase summary

Total charge time (CC start → termination): ~4h 54 min

Termination event

• Last sample with charge current: ibat = 68.4 mA at uptime 1d 00:40:11
• Next sample: ibat drops to 13.2 mA (noise floor) — BQ24075 terminated
• Net termination current (minus ~13 mA offset): ~55 mA
• Expected BQ24075 ITERM at C/10 of ~570 mA CC: ~57 mA — consistent ✓

ADC offset note

All ibat readings carry a ~13 mA offset (noise floor visible when no charge current flows). Accurate current measurement deferred to R1 (calibrated INA333 circuit). Qualitative charge algorithm shape is valid for R0 verification purposes.

Discharge runtime

Battery ran ~19h 44 min from resting charge (~3.989 V) to ~3.066 V. Logging gaps present due to network drops from logging PC; trend intact.

BQ24075 verification conclusions

• CC phase present and stable ✓
• CC→CV transition at Vreg ✓
• CV taper monotonically declining ✓
• Termination at ~C/10 ✓
• Post-termination vbat relaxes normally ✓

Test Setup

• DUT: A003460
• Start: 2026-06-11 ~09:19:30 (USB disconnected, battery fully charged)
• Mode: deep sleep, nominal 60 s wake interval
• Test paused: 2026-06-12 ~15:54 to reconnect device for firmware work
• Total heartbeats captured: ~430+
• Test status: partial — full runtime not reached; device still had significant charge remaining

Data Gap Note

Uptime jumps from 0d 08:24:02 to 0d 23:48:52 — a 15 h 24 min gap. Device ran continuously; subscriber was offline overnight (approx 2026-06-11 16:40 to 2026-06-12 08:10 real time).

RTC Drift Confirmed

Measured over the full 30.5 h dataset:

Consistent with earlier estimate. See E-030 for root cause and R1 fix.

Wake Interval

Consecutive heartbeat uptime intervals: consistently 62–63 s.

• Breakdown: ~60 s deep sleep + ~3 s active (WiFi connect + publish overhead)
• In real time: ~63.2 s per cycle

Voltage Discharge Profile (clean readings, outliers filtered)

Device entered the LiPo flat plateau at ~3.95 V. Voltage was moving very slowly at test pause — battery had substantial charge remaining.

Average Current Estimate

Derived from gap segment (most reliable):

• 4.008 V → 3.955 V over 15.42 h = ~10% SoC consumed = ~50 mAh (500 mAh cell assumed)
• Average current: ~1.6 mA at 1-minute wake interval

Breakdown (estimated):

• Deep sleep: ~100–200 µA (ESP32-C6 RTC + MCP1700 quiescent + leakage)
• Active (WiFi + MQTT + overhead, ~3 s/cycle): burst ~50–80 mA averaged over 63 s cycle = ~3–4 mA contribution
• Combined: consistent with ~1.6 mA observed

ADC Glitches

Multiple spurious low-voltage spikes visible throughout (readings 30–80 mV below stable neighbours). Consistent with E-021 (missing C28 on ADS7828). Not real voltage events.

Projected Full Runtime (500 mAh battery)

• Average current: ~1.6 mA → 500 mAh / 1.6 mA ≈ 310 h ≈ 13 days
• Target established: ≥ 10 days at 1-minute wake interval (see E-032)
• Full stress test to be run at a later stage with logging coverage through to cutoff voltage

Next Steps

• Full discharge test deferred — reconnect device, work on firmware
• When stress test resumes: log continuously through 3.80 V, 3.70 V, 3.60 V to capture knee and terminal drop
• Verify average current improves with shorter active time (OTA, static IP, faster MQTT connect)

BQ24075 charger (U1): the paired BAT pad (pin 3) and OUT pad (pin 11) are left unconnected — only one pad of each pair carries the battery / system-output current. The datasheet defines BAT = pins 2,3 and OUT = pins 10,11 as paired power pads (BAT rated 4.5 A discharge / 1.5 A charge). Does the single connected pad's trace/via carry the worst-case battery + system current, or should the second pad of each pair be connected per the datasheet? Raising for the battery + system power path.

Receipts: ["observation:8", "component:U1", "datasheet:BQ24075TRGTR", "net:+BATT", "net:Net-(U2-VIN)"]

— odb board 3, concern CON-001

Beacon (ESH10000671 R0) — Probe design review COMPLETE. Analysis run 5: 23/23 checks addressed (100%), 71% with positive evidence, 29% honest abstains (silk / fiducials / derived-value notes — need the fab layers, not connectivity). Verdict: 1 gating concern, otherwise clean.

GATING FINDING — CON-001 / OBS-8: BQ24075 charger (U1) paired power pads under-connected. BAT = pins 2,3 and OUT = pins 10,11 are paired power pads the datasheet says to tie together (BAT rated 4.5 A discharge), but pin 3 (BAT) and pin 11 (OUT) are left unconnected — only pin 2 / pin 10 carry the battery / system current. Fix: connect the second BAT and OUT pads, or verify the single-pad trace/via carries worst-case current.

CLEAN (evidence-backed): I2C bus0 (ESP32 ↔ ADS7828 + PI4IOE5V6416) and bus1 (ESP32 → J3/Sentry) — continuity, pull-ups, role consistency, single 3.3V domain, no address collision (note: 10k pull-ups are comfortable at 100 kHz, marginal at 400 kHz — sanity-check against the I2C clock); SPI ESP32 ↔ SX1276 (PA_BOOST + PE4259 antenna switch); power (8 checks auto-resolved); documentation (title block + net labels); test access (TP1–5 + J3 exposes the serial buses). The 36 single-point nets were reviewed — all benign NC/unused pins except the BQ24075 pads.

ENRICHMENT: 9 active datasheets acquired. Remaining: D1/D2 (LED) and X1 (32 MHz crystal) need an MPN in the BOM to enrich (low value — unlikely to change the verdict).

PROCESS BUGS FILED in Probe (board-tooling, not Beacon defects): BUG-005 (viewer showed a stale schematic for a no-schematic board), BUG-006 (ingest doesn't auto-publish the Trace odbBoardRef link — done manually here).

— odb board 3 (comment)

Trace cross-check — reconciling CON-001 against existing project records:

(1) E-029 (full charge cycle verified on unit A003460): the BQ24075 charges correctly — ~580 mA CC, clean CV taper, termination at ~55 mA. So the single connected BAT/OUT pad IS functional at normal current; CON-001 is NOT a functional blocker. It is a worst-case-current / thermal-margin question — the BAT path is rated 4.5 A and the single pad/trace was never stress-tested near that.

(2) E-015 (BOD disabled — ESP32 brownout false-triggers on WiFi-TX inrush, despite a stable 3.3 V on a multimeter): worth checking whether the unconnected OUT pad (pin 11) is a contributor. WiFi-TX inrush is a fast current transient down the BQ24075 OUT → MCP1700 path; with only one of the two OUT pads connected, that path has higher resistance/inductance and a deeper momentary dip — a plausible contributor to the brownout that E-015's scope action (measure the 3V3 dip under WiFi-TX) would reveal. Connecting both OUT pads is cheap insurance for CON-001 and for the brownout characterisation. (Hypothesis, not a claim — the BOD trigger could equally be bulk-cap / LDO transient response.)

Subject: CON-001

— odb board 3 (comment)

Intent-grounded review pass (board 3) — re-ran the review against the Trace open-issue set, each tested vs the netlist (the FR-010 case in one board):

E-013 CONFIRMED (Probe-domain, headline): R1 (10k) pulls BQ24075 EN1 to +5V (R1.1=+5V, R1.2=EN1); R2 (10k) pulls EN2 to +5V. EN1=H + EN2=H = Standby → OUT disabled (datasheet EN truth table). Intent E-003 wants EN1 LOW. So the R0 board ships with the charger output DISABLED — exactly E-013 (A003460 fixed by removing R1). A connectivity+datasheet finding Probe should auto-produce; it outranks CON-001; the bottom-up pass missed it.

E-022 CONFIRMED: INA333 (U10) V-=GND, V+=Q1-gated 3.3V (single supply), inputs across the low-side shunt near GND (pin3=battery-, pin2=GND), high gain → A2 clamps at GND. Battery-current monitoring (REQ-035/059) inoperative — confirms the team's analog root cause.

E-023 RECONCILED: +3V3 lands on J3.3/J3.9; PowerGroundShort=0 → NO 3V3-GND short in the PCB netlist. The blocking short is off-board/assembly — a mating-cable wiring error or a 0.4mm-pitch solder bridge between the 3V3 pins (3/9) and adjacent GND pins. Schematic exonerated; verify the cable + inspect J3 solder. (Earlier 'clean boundary' was netlist-correct but intent-blind.)

E-028 NARROWED (2 of 5 hypotheses ruled out at netlist level): VCC_RF (U8.24) IS supplied — +3V3 → FB1 ferrite → +3V3RF, decoupled C17/C19 (hyp #1 not a design error); the QFN thermal pad (U8.29) IS tied to GND in the design (hyp #5 is an assembly solder issue, not layout). Live causes remain: crystal load caps (checkable via CrystalLoadCaps + the 10pF CL from E-009), the RF matching network, LORA_RESETn release (firmware). The grounded pass de-risked the bench investigation.

Net: grounding-first surfaced a real charger-disable finding (E-013) in Probe's domain, confirmed E-022, exonerated the J3 schematic (E-023), and narrowed the RF blocker (E-028) — vs the bottom-up pass which found one minor pad item.

— odb board 3 (comment)

U5 (PI4IOE5V6416ZDEX) exposed die pad — pin 25, named GND — is unconnected (single-point net unconnected-(U5-GND-Pad25)). The logic ground pin 9 IS tied to GND, so the device has a return and functions, but the package EP has no copper to GND on R0. Investigate against the PI4IOE5V6416 datasheet whether the exposed pad must be bonded to GND (thermal + ground-return integrity): if mandated, R0 omits it and R1 should add the EP→GND tie + via array; if only recommended, record the disposition. Not a spare-pin NC like P0_6/7 or P1_2–7 — it is the only GND-named pad left floating.

Receipts: ["rule:SinglePointNet — net unconnected-(U5-GND-Pad25) connects only to U5.25", "netlist:U5.9 = GND (logic ground connected)", "datasheet:PI4IOE5V6416ZDEX exposed-pad / GND bonding requirement — to verify", "trace:E-004 (PI4IOE I2C address + port allocation) does not address the exposed pad", "trace:REQ-037 (GPIO expander present on I2C) — functional, unaffected"]

— odb board 4, concern CON-001