P2: deterministic ESP32-P4 Sampled Values publisher and timing evidence

Goal

Replace the P0/P1 slow smoke loop with a deterministic real-time Sampled Values publisher on ESP32-P4-ETH. This phase must produce measured timing evidence before relay interoperability or a large desktop UI is treated as trustworthy.

Preconditions

PR Add ESP32-P4-ETH SMV injector P0/P1 and P2 50 Hz realtime foundation #19 software build is green.
Physical ESP32-P4-ETH link-up is confirmed on an isolated bench/direct capture NIC.
P0/P1 0x88BA Sampled Values PCAP is saved as hardware evidence.

Runtime requirements

50 Hz / 80 samples per cycle = 4000 frames/s.
60 Hz / 80 samples per cycle = 4800 frames/s.
Absolute-deadline scheduling; no vTaskDelay() cadence in the real-time TX loop.
Monotonic smpCnt with correct wrap policy.
No heap allocation, string processing, SCL parsing, or logging in the hot TX path.
Pre-encoded/preallocated SV frame template; patch only changing fields/sample payload.
Bounded TX queue/ring behavior with explicit overrun/drop accounting.
Ethernet DMA buffer count/size explicitly measured and tuned for small high-rate frames.

Timing evidence

Collect ESP32-P4 EMAC hardware TX timestamps where supported by the pinned ESP-IDF version.
Record scheduled deadline and actual TX timestamp for timing-error statistics.
Track frame count, missed deadlines, queue/driver failures, min/max/mean error, P95/P99 jitter.
At least 60 s continuous run at 4000 fps with zero unexplained smpCnt gaps in an independent capture.
Repeat at 4800 fps.
Store machine-readable timing report plus PCAP evidence.

Protocol truthfulness

Keep smpSynch=0 until a measured synchronization source is actually locked.
Do not claim 9-2LE profile compliance until the exact dataset/field presence, channel order, scaling, quality encoding, multicast/VLAN profile and sample-rate behavior are validated against the selected profile/IED.

Exit gate

P2 is complete only when firmware build CI is green and physical timing/capture evidence demonstrates deterministic 4000/4800 fps behavior. After this gate, proceed to the 3-phase waveform/fault engine and desktop control application.

P2 implementation foundation has now landed on the stacked hardware branch/PR #19 after physical P0/P1 evidence. Current code adds a 50 Hz / 80 samples-cycle / 4000 fps absolute-deadline publisher, prebuilt fixed-size templates, generated balanced 4I+4V waveform, continuous smpCnt wrap=4000, canonical VLAN multicast plus a clearly labeled lab-only broadcast capture mirror, and scheduler/TX telemetry. Hardware acceptance for this P2 step is still open: sustained 4000 fps capture, missed-slot/jitter evidence, canonical multicast/VLAN on a suitable NIC/TAP, and hardware TX timestamps remain to be measured before this issue can be closed.

Bench update from 2026-08-10 after GPTimer scheduler + separate diagnostic mirror:

Device telemetry is stable at ~4000 samples/s with canonical TX ok=4000/s, mirror TX ok=4000/s, fail=0, missed=0, wake lateness reported 0/0/0 us in the current software metric.
A raw process-bus analyzer reconstructs balanced 50 Hz three-phase voltage/current waveforms from AR_DIAG_SV1 and reports sequence integrity CONTINUOUS / Loss OK.
The host USB-Ethernet capture path reports ~3999 fps but also arrival-time excursions above 300 us in the observed bench window even though sequence remains continuous.

Interpretation: host arrival timestamps are capture-path evidence, not trustworthy device-TX timing evidence. The next P2 timing gate should therefore be ESP32-P4 EMAC IEEE1588v2 hardware TX timestamps and/or a trusted independent reference capture, not tuning the GPTimer loop to compensate for host buffering/batching.

P2 status update:

50 Hz / 80 samples-per-cycle / ~4000 fps publisher demonstrated on hardware.
GPTimer periodic 250 us sample clock; no busy-spin WDT starvation.
prebuilt fixed templates / no BER encode in hot loop.
current hardware run reports TX fail=0 and missed=0.
EMAC hardware TX timestamp evidence.
P95/P99 on-wire TX error from hardware timestamp or trusted reference capture.
60 s saved PCAP/evidence run on trusted capture path.
60 Hz / 4800 fps.

Standards-first SCL/profile/PTP follow-on is tracked separately in #24.

P2-A hardware timing implementation is now in PR #26 after the merged realtime SV foundation.

Implemented device-side evidence path:

narrow ESP-IDF 5.5.x EMAC timestamp adapter (hardware_timestamp.[ch]);
IEEE 1588 hardware time enabled without making a PTP-lock claim;
canonical SV uses descriptor TX hardware timestamps;
diagnostic mirror remains outside the canonical timing statistics;
records valid/invalid timestamps, clock regressions, TX-to-TX period min/mean/max, signed period error vs 250 us, and bounded absolute-error P95/P99;
smpSynch=0 remains unchanged.

The embedded firmware cross-compile has passed on the pinned ESP32-P4 CI path. Physical acceptance is deliberately still open: flash PR #26 on the real board, verify non-zero hardware timestamps, then run at least 60 s at ~4000 fps with TX fail=0, missed=0 and clock_regress=0 before establishing any regression threshold. The extended timestamped transmit path waits for descriptor timestamp availability, so its runtime cost must be proven on hardware rather than inferred from compile success.

P1.2 timing handoff: wire counter != sample epoch

IEC 61869-9 F96000S1 is now covered by the P1.2 host semantic regression. It exposes an important runtime boundary for the timing tranche:

the wire smpCnt remains the protocol's bounded 16-bit field;
the F96000S1 sampling identity is 96 ksample/s;
therefore an internal sample epoch / second-alignment policy must not be modeled as a fictitious uint16_t modulus = 96000.

P1.2 deliberately leaves generic counter-wrap policy unresolved for the 96 kHz profile rather than inventing an impossible modulus.

When #21/#56 advance the hardware-time/epoch work, model at least:

wireSampleCounterPolicy
sampleEpochPolicy
sampleInstant / PTP time relationship
second-boundary behavior

as separate semantics.

Do not widen the on-wire counter or reinterpret it as a 17-bit/96000-modulus value. The runtime may use a wider internal absolute sample index, but wire encoding and epoch derivation remain separate authorities.

2026-10-07 timing-authority reconnaissance (no implementation overlap)

Current source shows a concrete reuse path for #21:

embedded/esp32p4_smv_injector/main/ptp_lab_task.cpp already obtains ESP32-P4 EMAC hardware TX timestamps via esp_eth_transmit_ctrl_vargs(eth_handle, &tx_timestamp, 2U, frame.data(), frame.size()), validates the returned timestamp, and uses it for PTP two-step Sync/Pdelay evidence (around lines 332–358).
Canonical SV TX in embedded/esp32p4_smv_injector/main/app_main.cpp (around lines 562–571) currently uses esp_eth_transmit() with only submit-success/failure accounting. Its scheduler's wake_late_us and successful TX return are not actual EMAC egress timestamps.

Next bounded #21 design gate: reuse/factor the existing timestamp-aware EMAC transport adapter instead of creating a second PTP clock, scheduler, or TX failure authority. Correlate immutable profile identity, smpCnt, scheduled GPTimer deadline, task wake, TX submit, and timestamped EMAC egress; validate clock-domain alignment before computing mean/min/max/P95/P99. Keep app_main.cpp as the single canonical SV transport-failure authority. Prove bounded memory/hot-path overhead and feasibility at both 4000 and 4800 fps; if timestamp acquisition is not suitable for every packet, make measurement coverage/sample policy explicit instead of reporting partial observations as full-stream jitter truth.

Acceptance remains open: physical hardware timestamp/independent-capture evidence has not been collected by this source audit. No timing/compliance claim or new code authority is added by this note.

P3-A1: ESP32-P4 bounded binary decoder and atomic profile activation (#…

P2 track reconciliation 24 Oct 2026: exact M3.H source is now in main via #299, baseline a922e9bd...; 4I+4V/4000fps 40.76s capture with 163,048 consecutive frames, no sequence loss, PTP lab metadata. Keep this issue OPEN for its broader original exit gate: 4800fps independent hardware capture, at least 60s continuous runs at both sample rates, physical scheduling jitter percentile evidence and machine-readable timing report. Public M3.H Stable supports only advertised 4kHz lab profile.

M3.H release backlog reconciliation — 2026-10-24

Release scope clarification: M3.H stable 4 kHz/4I+4V local bench build a922e9b... passed 10/10 original CI and the valid 40.76 s capture (163,048 SV; 3999.884 fps). This does not satisfy this issue's full 60 s/4800 fps/jitter evidence acceptance. Keep OPEN for remaining rate and hardware measurements. Do not transplant legacy PR #166 into the immutable M3.H firmware.

Canonical ledger: https://github.com/masarray/arstack61850/blob/main/docs/integration/M3H_MAINLINE_RELEASE_SOURCE_CLOSURE_2026-10-24.md .

Navigation Menu

Repository navigation

P2: deterministic ESP32-P4 Sampled Values publisher and timing evidence #21

Goal

Preconditions

Runtime requirements

Timing evidence

Protocol truthfulness

Exit gate

P1.2 timing handoff: wire counter != sample epoch

2026-10-07 timing-authority reconnaissance (no implementation overlap)

M3.H release backlog reconciliation — 2026-10-24

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

P2: deterministic ESP32-P4 Sampled Values publisher and timing evidence #21

Description

Goal

Preconditions

Runtime requirements

Timing evidence

Protocol truthfulness

Exit gate

Activity

masarray commented on Aug 10, 2026

masarray commented on Aug 10, 2026

masarray commented on Aug 10, 2026

masarray commented on Oct 7, 2026

P1.2 timing handoff: wire counter != sample epoch

masarray commented on Oct 7, 2026

2026-10-07 timing-authority reconnaissance (no implementation overlap)

masarray commented on Oct 24, 2026

masarray commented on Oct 24, 2026

M3.H release backlog reconciliation — 2026-10-24

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions