Resource Measurement and Physical Acceptance Records
This page supplements the recording method of the Release Checklist; the endpoints follow the current development candidate. All field items below are currently NOT_RUN; this page is not a report of deployment or acceptance. Feature descriptions, candidate results, and field capabilities are in Candidate Status and the Capability Matrix.
Before starting, fix the specific operation authorization, device identity and wiring, stable firmware/web summary, config backup, and recovery method. Deployment must have actual write and verification evidence for this run; historical COM/IP cannot serve as the current identity. Restarts, power cuts, config/RTC writes, fault injection, and output actions are each listed in the authorization scope. Output cases with unknown conditions stay NOT_RUN.
Common Records per Test Run
Each round uses a new runId and evidence directory, keeping failures and their subsequent recovery. Record at least:
| Category | Required content |
|---|---|
| Version | Board/hardware revision, chip, measured PSRAM state, candidate summary, firmware/web SHA256, deployment report summary, observer version |
| Field | Authorization record, identity and wiring evidence references, modules/instruments, allowed recovery actions, stop conditions |
| Conditions | Config summary, business/network/server load, instance counts, sampling frequency, warm-up rules, steady-state window, peak observation method, and acceptance thresholds |
| Per sample | Case/event ID, boot session, config summary, host UTC and monotonic timestamps, device uptime and wraparound, interface and HTTP status, elapsed time, raw response file and SHA256 |
| Results | Valid samples/expected count, missed-sample reasons, first failure, first fresh success after recovery, residual faults; command results, readback, and physical feedback listed separately |
Identity, configuration, and raw responses are preserved per Recovery and Configuration Preservation; public reports cite only desensitized summaries. When there is no data, record unknown or not-measured — do not backfill with zeros.
Six Feature/Resource Comparison Groups
Each applicable optional feature is compared under the same board, firmware, and business conditions across the states below. Each group keeps its own config summary; config samples from different groups must not be stitched into one fixed-config long-term run.
| State | Operating condition | Key observations |
|---|---|---|
| S0 | All optional features off, keeping measurement-required entries | Baseline and still-present shared services |
| S1 | Target feature enabled, no instances | Whether useless tasks/allocations appear; actual owner and pending-restart state |
| S2 | Single instance | Valid sampling/actions, shared vs instance resources |
| S3 | Multiple instances | Capacity admission, queues, latency, memory and stack pressure |
| S4 | Disabled, taking effect per the declared method or restart | Config retention; whether tasks/instances/leases actually retire |
| S5 | Re-enable and recovery | New instances and fresh business data, resource recovery, whether old faults are kept |
First record at least three cold boots and one stable baseline, each boot numbered independently. Each group compares steady state, pre/post-operation, and predefined peak windows under the same warm-up and sampling rules; cold boots and S4 restarts must be within the maintenance scope. Initialization failures, low memory, and network/bus faults get separate windows; failure samples are not discarded.
Three cold boots only establish the measurement baseline and do not replace the planned lifecycle targets. Create three additional record types: 100 start/stop or reconfiguration cycles, 20 cold boots, and 20 warm boots; freeze the actual steps, allowed scope, and exit thresholds for each before execution. Per iteration, save the cycle number, boot session, operation and effect results, before/after resource/config evidence, failure/recovery, and physical feedback; summarize planned, attempted, completed, succeeded, failed, and unfinished counts with reasons. Not-executed and interrupted/missing-evidence are recorded separately; one successful recovery must not be filled in as a whole-batch pass.
Endpoints and units follow Health Monitor and API Reference:
| Evidence | Collection entry and fields | Interpretation limits |
|---|---|---|
| Lightweight internal DRAM | data.memory.dram8Free/dram8Largest from /api/system/status, in bytes | Do not substitute total heap or PSRAM headroom for internal DRAM |
| Per-pool memory | data.memory.capabilityPools from full /api/system/info?full=1 or /api/system/diag-bundle; keep observed/free/minFree/largestBlock and sampledAtUptimeMs of internal8/internalDma/psram8 | Bare /api/system/info is slim by default; explicit full can still degrade under memory protection — probe/health or slim responses do not replace the full snapshot; pools overlap and cannot be summed; minFree is not the peak of this operation |
| Runtime resources | data.runtime from the raw /api/peripherals/resources response and the owner, generation, busy, fault, retiring, cleanupPending fields available per source | Not atomic across sources; unregistered SDK resources stay unknown; config removal does not prove actual release |
| Task stack | Authorized developer single POST /api/system/task-stack-snapshot; keep HTTP, success/status/reason, completeAtCapture, count changes, captureDurationUs, and taskNumber/highWaterBytes | No polling, no bypassing the 30-second cooldown; task numbers do not align across restarts; unknown/busy/over-capacity is not an empty task list, and a 0 watermark cannot be treated as unknown |
| Business | Success/expected counts, data quality/age, queue/timeout/allocation failures, protection/degradation, reset reasons, latency p95/p99/max | CPU values without a measured source stay unknown; averages do not replace worst cases |
Both the full per-pool response and the single stack scan have overhead; record the request order and its disturbance window uniformly; a stack scan may pause scheduling, so observe business latency and WDT in the same window. Discrete sampling can miss transient peaks — mark explicitly when uncovered. SDK heap low points also do not guarantee simultaneity.
Static Flash/RAM is taken from map/bin under the same toolchain conditions. Runtime toggles do not shrink firmware; S2-S1 and S3-S2 can only serve as same-observation difference values, not directly called a fixed per-instance cost. Complete six-group data does not automatically prove all feature combinations, fault recovery, or long-term leak-freeness.
RTC Retention and Timekeeping Records
Follow the DS1302 notes. First verify the module, battery, voltage, charging configuration, and safe power-cut method; freeze the calendar interpretation, timezone, run/pause state, outage duration, and error tolerance. Without an independent reference time and its uncertainty, accuracy stays undetermined; this flow does not require auto time sync or changing trickle charging.
- Before the power cut, save the RTC calendar/run state, the independent reference reading, and the collection start/end times. Also record the system
timeSource/timeQuality/timeSourceAuthenticated/timeSyncAgeMs/timeSyncSequence/activeTimezone; the system's own source record is not an independently accurate reference. - On a separately authorized test device, remove the main power while keeping the verified backup supply; record the actual outage start/end reference timestamps, supply, and environment observations. Do not perform the power cut when return-supply/load safety is unclear.
- After recovery, before any operation that could change the RTC calendar, save a second RTC/reference pair, the readback delay, calendar validity, and run state. Windows where a write occurred or cannot be ruled out cannot be used to prove battery retention.
- Judge "readable / keeps counting" and "timekeeping accuracy" separately. With the calendar interpretation fixed and no time-sync or timezone ambiguity, record the two RTC-minus-reference deviations
offset0/offset1; the observed ppm is(offset1-offset0)/reference elapsed seconds x 10^6. Also give the reading resolution, reference, and read-delay uncertainties; when the window is too short to judge, do not fill in 0ppm. - Save the actual values, sampling times, source, and age for web, rules/MQTT, and applicable physical displays separately. Different sampling times need not match verbatim; a correct format does not mean retention or accuracy passed.
Records keep module/battery evidence, calendar interpretation, reference and uncertainty, the two raw RTC/reference pairs, read start/end, actual outage duration, deviation/drift, error tolerance, any writes/source changes during the window, and raw evidence.
Peripheral Fault Windows and Physical Feedback
Reuse each module's existing configuration steps and add the records below to the same case. Fault methods, expected safe states, stop conditions, and recovery actions must be determined in advance; unknown responses are not auto-replayed.
| Scope | Minimum records in the same window |
|---|---|
| SD | Card/filesystem, SPI/CS and shared clients, original length/SHA256 of dedicated test files, re-read length/SHA256 after write, mount/owner/recovery state and capacity sample age; authorized full-card/power-cut faults only on sacrificial media; hot-swap removal is not supported by default |
| UART / Modbus | Peer and logic level/transceiver, controller/pins/parameters, actual sent/received bytes and times, expected frames/boundaries, errors and generations, first frame after recovery; generic text counts do not replace Modbus CRC or hardware-overflow evidence; fault inputs must not connect unauthorized output rules |
| ADS1115 | Board/PSRAM, module, MUX/range/rate, input electrical conditions, reference instrument and calibration info, reference value/raw code/converted value/quality/age/tolerance, NACK or disconnect windows and recovery samples; range is not the allowed port voltage |
| MCP23017 | RESET/power evidence, A7/B7 and actual channels, start/stop physical levels/load feedback, input reference and readback, fault/retire/recovery timestamps; a register ACK does not prove an external RESET or load safety |
| PCA9685 | Independent power-on/OE actual level, shared frequency, channel, measured frequency/pulse width and instruments, enable/disable/stop physical results, offline/power-loss and new-session recovery; follow the prepare/power-on confirmation flow; an angle command is not a measured angle, and OE HIGH is not load power-off |
| RGB panel/touch | Dedicated firmware and board/panel revisions, display orientation/edges/tearing/black screen, press/release/navigation and touch points, backlight, load/duration, picture evidence and failure times, HTTP/sampling/stack/DMA in the same window; web preview or scan endpoints do not replace physical display/touch; buzzers and outputs are authorized separately |
Each fault event keeps eventId, preconditions, fault method, expected safe state, first failure, attempt count, command/readback/physical results, recovery actions, first fresh success, before/after resources, residual faults, raw evidence, and conclusion. A successful recovery does not overwrite the original failure; not attempted is NOT_RUN, unmet preconditions are BLOCKED.
Save the SD file SHA256 and the HTTP response SHA256 separately. When using existing web endpoints for byte comparison, first pick a known ASCII test file of at most 4096 bytes; after GET /api/peripherals/read?id=<SD logical ID>&action=read&path=<sandbox file>&maxBytes=4096 succeeds, UTF-8-encode the data.content from the decoded JSON to get the file bytes, and verify data.length, the expected length, and SHA256; do not add a BOM, convert line endings, or compute a "file hash" over the whole JSON response. Oversized files are rejected for whole reads and the current endpoint has no chunked download; files over 4096 bytes or binary files require separate authorized safe-unmount/power-down and full card-reader readback evidence — without it, file integrity stays unconfirmed. A successful write or capacity change cannot replace readback, much less prove post-power-loss durability.
Handover to Long-Term Stability and Independent Trials
Complete the 2-hour exploration, 24-hour mixed load, and 7-day fixed-candidate observation per the release checklist, keeping the valid span, sample counts, gaps, and cumulative failures. Firmware or key config changes start a new window; stable environment and fault injection are windowed separately.
The current test-device-soak.py serves COM15/ECM50-A-type business and test-screen-panel-soak.mjs serves panel business; changing the URL does not automatically adapt to other boards or H1 scenarios. Both scripts' existing internal memory samples only contain dram8Free/dram8Largest; per-pool DMA/PSRAM and full task-stack data must be collected as above and tied to the same run. Before running on other boards, define the actual entry, fields/units, valid samples, and business counts; unprepared combinations stay BLOCKED — do not reshape field configs to reuse a script.
A PASS from the two scripts also does not automatically complete the originally planned 24-hour head/tail memory screening. test-device-soak.py currently has no head/tail median-decline judgment; the panel script marks sustainedHeapDecline only with at least 60 samples, a head/tail difference over 8192 bytes, and over 25% of baseline — it is not the planned initial screening line max(2 KiB, 2% of baseline). Attach the records below, analyzing internal DRAM and the largest contiguous block separately per the pre-frozen same-load, warm-up, and window definitions; do not re-pick windows to meet thresholds.
| Record item | Required content |
|---|---|
| Window and source | Metric raw path, unit, run/boot/config summary, head/tail window start/end, expected/valid sample counts, missed/abnormal retention method, raw sample references |
| Screening calculation | Head/tail medians, decline bytes and ratio, adopted threshold and approval source; the originally planned line is noted separately as an initial screen, not a leak verdict |
| Verdict | Not measured, missing data/incomparable, meets frozen screening condition, or over-threshold pending investigation; keep investigation conclusions, do not backfill with a script PASS |
| Long-term review | 7-day trend, sustained one-way decline, unrecovered objects, and same-window business/recovery evidence; the protection line and agreed margin for rated features are checked separately |
NC01-NC04 and V14 follow the No-code Acceptance Cards. Technical windows, physical accuracy/load feedback, and independent user operations are accepted separately; automation tools do not sign off on independent trials.