Skip to content

Community feedback: SV receiver visibility, VLAN and APPID/svID setup in lab analyzers #324

Open

Description

@masarray

Engineer support: SV receiver visibility and stream configuration

An engineer using the historical M3.H build reported that traffic was not visible in ARSAS or DigSubAnalyzer on their local lab setup. The exact RX-side cause was not established. Keep this real observation available for troubleshooting and community feedback; it is not a purchase requirement, formal interoperability program or blocker to using the M3.H.3 official stable lab simulator.

ARStack's purpose is practical process-bus simulation: ESP32-P4 publishes real 4I+4V SV and internal PTP SOURCE traffic over an isolated Ethernet bench. The latest M3.H.3 release has 4,705,090 on-wire SV frames captured over 19m36s with zero missing/duplicate/reordered/malformed frames, plus autonomous publishing across Studio close/reopen. These results show valid transmission but do not establish the cause of the earlier application-level receive report.

Quick checks when a subscriber shows no SV

  1. Confirm ESP32-P4 is powered, the board UI reports SV RUNNING, and physical Ethernet is connected.
  2. Inspect traffic with Wireshark on the correct test NIC: eth.type == 0x88ba (SV), eth.type == 0x88f7 (PTP). Switches do not automatically mirror every multicast packet to the PC.
  3. Compare actually configured APPID, SV multicast destination MAC, VLAN tag / VID / PCP and svID against the analyzer, relay, or BCU subscriber filters. The default publisher commonly uses 802.1Q priority-tagged VID 0. Some NIC/offload/switch paths behave differently with priority-tagged traffic.
  4. Start with no unnecessary preselected stream filter in the receiving application, when possible. If RX shows a packet but refuses decoding, record the precise decoder message and the actual SavPDU/ASDU identifiers.
  5. Share sanitized firmware/Studio version, RX tool/NIC, APPID/MAC/VLAN/svID, and an optional small PCAP or screenshot if you'd like community help. No GPS unit, spare PTP GM, protection relay, specialist analyzer, long-duration capture or paid laboratory equipment is required to file feedback.

Project prioritization

Non-blocking, community-driven interoperability support. The product roadmap prioritizes concurrent Multi-SV on one ESP32-P4 and SCL-driven Merging Unit simulation. We welcome voluntary ARSAS/DigSubAnalyzer/relay/BCU reports without making them mandatory acceptance gates.

Related receiver work (historical context): DigSubAnalyzer PR #55, ARSAS PR #734.

Use isolated test networks only; do not inject SV/PTP into an operating substation process bus.

Activity

  1. masarray commented on Oct 24, 2026

    @masarray
    OwnerAuthor

    Progress update: DigSubAnalyzer source-derived M3.H 4I+4V VLAN 0 / untagged regression merged in masarray/DigSubAnalyzer#55 (CI, runtime stability and CodeQL green). ARSAS PR masarray/arsas#734 now adds first-received unfiltered SV auto-capture in addition to wire regression; CI running. ARStack PR #325 provides an untagged lab SCL and a first-packet NIC/Wireshark isolation guide; CI running. P0 remains OPEN pending user-side independent Ethernet RX capture/actual live app recognition; synthetic decoder success is not physical closure.

  2. masarray commented on Oct 24, 2026

    @masarray
    OwnerAuthor

    P0 continuation — 25 Oct 2026 (current source and release evidence)

    Keep this issue OPEN until the physical NIC receive gate passes. Synthetic decoder tests, successful firmware builds, or a Studio-side PCAP do not establish that ARSAS/DigSubAnalyzer receive live Ethernet frames.

    • ARStack diagnostic PR #325: corrected the Wireshark display filter to eth.type == 0x88ba || vlan.etype == 0x88ba, explicitly accounting for priority-tagged VLAN 0/PCP4, NIC offload, and untagged A/B. Added a tagged-vs-untagged SCL semantic-parity regression; latest head 46ba4d0f74a18730636df76bf2d69b5799f608c4. CI is running; the PR is not yet merged at the time of this note. The frozen M3.H/M3.H.1 firmware remains unchanged.
    • ARSAS source #734 merged 2bdb6c0: provides First received SV stream (no preloaded APPID/MAC/svID filter) plus 4I+4V regression. The last public stable ARSAS v1.6.41 was released Oct 13, so it does not contain this Oct 24 code. A successful main-build #40104371705 produced a Windows portable EXE CI artifact (not a certified/public stable release).
    • DigSubAnalyzer #55 merged 0a49dcc: exercised its existing SV decoder and analyzer discovery with source-derived tagged/untagged synthetic 4I+4V frames. This is a regression test, not a verified live capture repair. The last stable v1.4.2 predates this test.
    • The DigSub Npcap capture filter source accepts both direct and single-802.1Q SV EtherTypes; ARSAS Snapshot capture similarly has a VLAN-aware BPF. Source inspection does not establish whether the actual receiver NIC passed VLAN 0, which adapter was chosen, or whether the shipped app version was used.

    Exact physical acceptance gate

    1. On an isolated bench confirm Studio SV RUNNING, ESP32 board TX counter/fps increasing (PTP alone is insufficient).
    2. Capture unfiltered at the exact receiving NIC in Wireshark for 3–5 seconds; apply eth.type == 0x88ba || vlan.etype == 0x88ba only as a display filter. Save sanitized original PCAPNG + adapter name, VLAN/offload settings, topology, and firmware/Studio/receiver versions.
    3. If zero SV at NIC: isolate TX cable/switch/TAP, adapter and VLAN 0 priority tag path (compare untagged lab SCL). If SV present: compare raw APPID/MAC/svID/smpCnt/noASDU/64-byte 4I4V data against the analyzer.
    4. With actual source build/CI candidate for ARSAS (not v1.6.41), select First received SV stream and correct Npcap adapter. Confirm populated capture. Confirm DigSubAnalyzer actual live stream discovery and values.
    5. Only close once both applications display real received SV with matching PCAP identity and versions. Any necessary application/firmware fix must go into a new versioned binary; do not rewrite M3.H.1.

    This preserves release integrity while making the final failure diagnostic evidence-driven.

  3. masarray commented on Oct 24, 2026

    @masarray
    OwnerAuthor

    P0 source integration merged — 25 Oct 2026

    ✅ PR #325 is MERGED into main, merge commit 8eca4367eb85edf7b4dbb00ced391bba82cf592d. Exact PR head 83439a4a15f186b0e95b5ca139c336a271042bf1 passed 14 checks with success, 1 conditional skip, zero failures before merge. All inline review threads are resolved. The default M3.H.1 firmware and seven published release assets were not altered.

    Delivered: independent receive/Wireshark guide with correct direct+VLAN-tagged SV display filter; untagged 4I+4V lab SCL for priority VLAN 0 A/B isolation; SCL regression to preserve reference MAC, APPID, svID, confRev, rate, ASDU count and dataset size; exposed troubleshooting link in SUPPORT. Windows/MSVC /WX build passed after fixing test integer types.

    P0 LIVE ACCEPTANCE REMAINS OPEN. We still lack sanitized unfiltered 3–5 second packet capture from the actual recipient Ethernet NIC, plus physical app-visible SV values in both DigSubAnalyzer and ARSAS. The last published stable ARSAS v1.6.41 predates source commit 2bdb6c0 adding “First received SV stream”; use the newer tested CI candidate for this specific diagnostic (run 40104371705, artifact ARSAS-win-x64-portable-single-exe) or a separately verified later release, not the older stable executable. DigSubAnalyzer PR #55 only added source-derived synthetic decode coverage, not a proven NIC-runtime bug fix.

    Next classification: If frames are absent in unfiltered capture, diagnose NIC/switch/tagged VLAN 0 path (try new untagged SCL); if frames arrive, attach PCAP and decoder diagnostics before altering firmware/receiver code. Close only on independent field acceptance evidence. Post-merge main CI may still be running; premerge gate is complete.

  4. masarray commented on Oct 24, 2026

    @masarray
    OwnerAuthor

    Physical test package / operator handoff — 25 Oct 2026

    The exact P0 Windows test download matrix and step-by-step untagged SCL A/B procedure have been merged into main via PR #326, commit f89b28893b3e7bcbb5fec285f37aa6337832eb33:

    Read the current independent SV receive guide.

    Downloads:

    Use a real receiving NIC on isolated Ethernet, save an unfiltered 3–5 second PCAPNG and apply display-only filter eth.type == 0x88ba || vlan.etype == 0x88ba; test priority-tagged VLAN 0 versus untagged on the same NIC/cable, and show live svID, APPID, counters, waveform/values in ARSAS and DigSubAnalyzer.

    Do not close P0 until independent receiver-side PCAP and both real application acceptance checks succeed. Both PRs #325/#326 are code/docs integration only and do not establish physical acceptance.

  5. masarray commented on Oct 24, 2026

    @masarray
    OwnerAuthor

    Field failure investigation — CANONICAL_SV_TX_FAILURE / RUNTIME_FAULT (25 Oct 2026)

    Operator provided a real screenshot of ARStack Studio preview v0.1.1 and two device diagnostics excerpts. Identified hardware: ESP32-P4 on COM15, exact GUI/firmware build 83439a4a15f186b0. The firmware was verified and the serial lease was healthy (lease_ms=6000, hb_max_gap_ms=774, stop stop_hb_age_ms=0).

    Strong source-derived STOP path: app_main.cpp increments consecutive_canonical_tx_failures for failed esp_eth_transmit/link attempts; at kTransportFailureStopThreshold=400 (nominal 100ms at 4000fps), it calls live_control_force_stop() and stores RUNTIME_FAULT. This matches field SVSYNC EVENT ... CANONICAL_SV_TX_FAILURE uptime_ms=1308394 followed by SVLIFE ... stop_cause=RUNTIME_FAULT stop_uptime_ms=1308494. At later time, SV was manually restarted and reported RUNNING, MC ok=4000, missed=0; historical stop cause correctly remained sticky. PTP TXfail was cumulative 30 with later ETH STARTED/link UP. The exact ESP-IDF TX error at the original stop is absent from the supplied last-12k log. Avoid attributing cause to PHY/DMA/PTP concurrency without error evidence.

    Patch under PR #327 (in CI): retain first/last esp_err_t, TX burst counts, actual Ethernet link event at failure, sticky stop_seq and last-stop error across manual START; print SVTXFAULT with every device SHOW and surface newest stop error in Studio footer; revoke SV synchronization authority only once per consecutive failed burst (not on all 400 frames) while preserving every TX failure and the exact fail-closed STOP threshold. New native CTest checks stop/recovery/sticky semantics. This does NOT claim the root EMAC error has been fixed.

    Physical retest acceptance (isolated bench)

    1. Use paired PR P0: preserve canonical SV TX fault evidence and make revocation burst-bounded #327 Studio preview and exact-HEAD firmware only after required CI passes. Keep stable M3.H.1 untouched; do not mix artifact firmware versions.
    2. Reproduce a fresh START/STOP without unplugging COM15. Export field diagnostics immediately and record SVLIFE stop_seq + SVTXFAULT last_stop_seq,last_stop_first_error,last_stop_last_error,last_stop_link_up,last_stop_burst; note PTP TXfail change across STOP and PHY link LED.
    3. Compare PTP SOURCE active vs operator-stopped PTP on isolated bench, keeping SV frame profile/cable/receiver NIC unchanged, if the GUI/firmware allows that mode. Never use on live process bus.
    4. If first/last error is ESP_ERR_INVALID_STATE, investigate driver link/state transitions; for ESP_ERR_TIMEOUT, examine MAC DMA descriptor/driver mutex stalls; for other codes, use exact error name and physical NIC capture.
    5. Close only on repeated physical stability AND independent SV receipt in ARSAS/DigSubAnalyzer. Keep fail-closed on sustained TX failure.

    The current two uploaded diagnostic exports do not include the full persistent Studio event log around uptime 1308394 ms.

  6. masarray commented on Oct 24, 2026

    @masarray
    OwnerAuthor

    Precision correction for the field-evidence analysis: SVLIFE stop_hb_age_ms=0 on RUNTIME_FAULT is not an independently measured heartbeat age. Current live_control_force_stop() explicitly calls record_sv_stop(SvStopCause::runtime_fault, 0U). The absence of lease expiry is established instead by the RUNTIME_FAULT vs LEASE_EXPIRED control path, actual hb_seen=1, hb_max_gap_ms=774, and the canonical TX failure/forced-stop code. Do not use the hardcoded 0 ms as evidence of serial timing correctness at the precise fault instant.

  7. masarray commented on Oct 24, 2026

    @masarray
    OwnerAuthor

    P0 spontaneous SV STOP — exact-head diagnostic fix is MERGED

    On 25 Oct 2026 PR #327 merged to main as 09095e204c269ad0a2018a400ec6b7d9ff143427, pre-merge head 9e9da379d278ec01d434958414ef9a3819df5900. 25 CI checks success, one conditional skip, zero failures (includes firmware, Windows/MSVC, Clang/GCC, sanitizer, strict PTP regressions, Qt, Windows GUI/firmware paired preview, migration test).

    Paired preview download: https://github.com/masarray/arstack61850/actions/runs/40142192449/artifacts/12579298218

    • Name: arstack-studio-native-preview-win-x64-327-9e9da379d278ec01d434958414ef9a3819df5900
    • Native Qt GUI + verified matching preview firmware packaged with portable ZIP / Inno Setup. Don't mix installed M3.H.1 production binaries and preview firmware. Isolated lab only.
    • Matching firmware-only artifact is available for traceability but prefer the paired GUI package.

    New evidence and behavior: board SHOW prints SVTXFAULT state=... svlife_stop_seq=... last_stop_seq=... last_stop_burst=... last_stop_first_error=... last_stop_last_error=... last_stop_link_up=.... GUI footer for current RUNTIME_FAULT can render Ethernet TX TIMEOUT · link UP or Ethernet TX INVALID_STATE · link DOWN when same SVLIFE stop_seq evidence is present. Consecutive TX failure threshold remains 400; no retries/automatic restart or spurious wire success claims. Phase/smpSynch authority revokes once per failed burst.

    This is diagnostic/root-path hardening, not proof that the hardware failure cannot recur. Exact real esp_err_t during operator's past failure was not available in supplied last-12k serial excerpts. Source notes that stop_hb_age_ms=0 for runtime_fault is a sentinel, not a measured contemporaneous HB age.

    Bench acceptance: update GUI and ESP32 from matched new preview package. On isolated Ethernet START SV and observe at least several minutes/starts. If STOP: export full Studio persistent diagnostics and include new SVTXFAULT and SVLIFE, record port/link, PTP source active, PTP TXfail delta, and sanitized receiver-side PCAPNG. Only then classify root as driver TX timeout/state/link. Independently confirm real 0x88BA on receiver NIC and values in ARSAS + DigSubAnalyzer. Keep issue #324 OPEN for physical acceptance.

  8. masarray commented on Oct 25, 2026

    @masarray
    OwnerAuthor

    P0 UI acceptance: stale STOP startup alarm and COM-status indicator merged — 25 Oct 2026

    PR #328 is MERGED into main at c8d351f1fe80ca4cf8f3e58cf6727566bec7d1f6. Exact tested source head fb81c247fb24cd6b5ac6aad6b3fb27486d620b96; 10 success, 1 skipped, zero failed/pending checks. Windows Qt GUI, HiDPI/headless smoke, deterministic session tests, hardware firmware build, Windows close/reopen, ownership, Inno upgrade/uninstall and historical NSIS migration completed.

    Correct Windows physical retest GUI preview artifact: https://github.com/masarray/arstack61850/actions/runs/40145602361/artifacts/12580357695
    Artifact name: arstack-studio-native-preview-win-x64-328-fb81c247fb24cd6b5ac6aad6b3fb27486d620b96. Contains native Windows GUI preview with matching firmware bundle. Keep stable M3.H.1 release unchanged; avoid mixing old firmware and new GUI on bench.

    Operator-visible fix

    • Previously SHOW's latched SVLIFE state=STOPPED stop_cause=RUNTIME_FAULT was incorrectly promoted into a new active svStopReason after Studio startup, causing a red central toast and red status on a healthy idle board.
    • svLastStopCause remains historical diagnostic evidence only. svUnexpectedStopObserved is asserted only after an actual RUNNING→STOPPED edge observed on the verified active COM/boot without operator STOP. One toast per svUnexpectedStopIncident (not every historical SHOW/TX detail); genuine fail-closed incident remains visible. In-place firmware reboot / foreign identity is treated as a reconnect/identity event, not false SV TX fault.
    • Compact LED-style COM indicator at far-left status bar: grey DISCONNECTED; blue CONNECTING; amber PREPARING; green READY / RUNNING; red ERROR only for active fault or setup failure. Event/property-based, no new polling loops.

    Field gate

    On Windows launch with ESP32-P4 powered and not publishing, verify no red RUNTIME_FAULT toast even if SHOW retains an old error; COM status should become COM15 · READY after verification/profile sync. Start SV, then if a new hardware error occurs, status must switch red and expose live SVTXFAULT diagnostics. This UI fix does not prove physical Ethernet TX/receiver correctness or close the separate P0 independent ARSAS/DigSubAnalyzer acceptance. Keep issue #324 OPEN until PCAP and both receivers pass.

  9. masarray commented on Oct 25, 2026

    @masarray
    OwnerAuthor

    M3.H.2 RC1 field handoff — real user READY/RUNNING evidence, receiver acceptance still OPEN (25 Oct 2026)

    Published M3.H.2 RC1 Public Engineering Preview via successful immutable-provenance workflow. Packaged Windows GUI and firmware are from exact source head fb81c247fb24cd6b5ac6aad6b3fb27486d620b96 (PR #328); the candidate includes first/last Ethernet TX error diagnostics merged in PR #327. All 5 public assets have SHA256 digests verified after publication. This release is explicitly prerelease=true, and M3.H.1 Stable remains latest stable, unchanged.

    The operator supplied two Windows GUI screenshots from a physical ESP32-P4 on COM15, showing READY while idle, then RUNNING after START, with indicated FPS 3999, MISSED 0, TX FAIL 0, and the fixed graphical board-status indicator. This establishes operator-facing state and one observed telemetry snapshot, not 3600s endurance, independent Ethernet capture, or receiver acceptance.

    P0 closure STILL BLOCKED: record actual frame reception on recipient NIC with unfiltered PCAPNG and confirm live decoded 4I+4V, svID, APPID, smpCnt in both ARSAS and DigSubAnalyzer. Please attach NIC/filter/topology, sanitized PCAP and receiver screenshots/logs. Also run retained multi-start/stop stability test as scoped in release-candidate notes. Do not close #324 from transmitter-only screenshots or CI green checks.

  10. masarray commented on Oct 25, 2026

    @masarray
    OwnerAuthor

    NEW physical capture + root ownership correction — 25 Oct 2026

    User supplied Studio independent NIC export (events, samples, seconds, report) from COM15 ESP32-P4, firmware build 83439a4a15f186b0. Inspectable summary: duration 1231.678668s (~20m31.7s), 4,926,580 real SV frames (~3999.88985fps), 0 missing_sample_counts, counter resets/reorder, duplicate counters and malformed frames, 3693 PTP Layer2 packets (1231 each Sync/Follow_Up/Announce), smpSynch initially 0 and then mostly 2. Capture status INVALID_CAPTURE only because SV source was observed STOPPED before requested 3600s; raw CSV report contains no authoritative SVLIFE stop_cause around the stop, so final trigger remains UNPROVEN. Last Studio report telemetry shows RUNNING=false, PTP running=true, SVSYNC reason=PUBLISHER_STOP, device cumulative missed/TX failures 0. This is physical evidence of previously clean wire, not a 1h PASS.

    Proven architecture defect in old source (irrespective of which event ended this capture):

    • live_control.cpp had a 6000ms serial heartbeat lease that forcibly stopped active SV upon COM/Studio loss.
    • DeviceController::shutdown() sent implicit SV STOP if running_ while closing Studio, although PTP survived.
    • This makes a LAN data-plane publisher depend on unreliable host USB/COM; a bench encoder must run independently after explicit START.

    New PR #330 — CI ongoing:

    • Remove heartbeat-as-lifetime authorization and the Studio closing STOP. Board owns SV/PTP after verified START and real PHY UP; HEARTBEAT diagnostic only.
    • Stop SV immediately on Ethernet DISCONNECTED/driver STOP (reason ETHERNET_LINK_DOWN), enforce PHY UP on verified START, guard race on link disappearance. Keep 400 canonical TX failures fail-closed.
    • PTP source pauses all TX and revokes authority while link is DOWN, resumes on restored PHY only after new packet qualification; clock task remains independent of USB.
    • New exact-pair capability SV-LAN-AUTONOMY-V1 in ESP32 firmware, GUI, manifest, CI; Studio reads fresh authoritative RUNNING/PTP on reconnect, no unrequested START/STOP. Explicit SV STOP remains a real high-priority command, PTP STOP separate.
    • Autonomy fault injection and field acceptance matrix.

    Gate remains OPEN until new paired artifact passes real LAN capture during >15min disconnect Studio, USB unplug/replug, explicit STOP, Ethernet down/up and 3600s receiver acceptance. Existing published M3.H.1 stable + M3.H.2 RC1 must not be replaced without proof.

  11. masarray commented on Oct 25, 2026

    @masarray
    OwnerAuthor

    Physical capture evidence + autonomous USB/LAN redesign (25 October 2026)

    Operator uploaded four correlated exports (events.csv, report.json, samples.csv, seconds.csv) from ARStack Studio independent NIC capture. Old firmware build: 83439a4a15f186b0, COM15. Report:

    • Requested 3600 s; captured 1231.678668 s (~20m32s), capture_interrupted=true, status=INVALID_CAPTURE, physical_acceptance=false, reason: SV publisher STOPPED mid-capture. Final passive Studio snapshot: running=false, ptp_running=true; SVSYNC says PUBLISHER_STOP after a prior ACQUIRED transition. This does NOT distinguish operator STOP, USB lease expiry, or other fault without device SVLIFE.
    • 4,926,580 received SV frames on independent NIC; observed mean 3999.88985 fps, missing_sample_counts=0, duplicate_sample_counts=0, counter_reset_or_reorder_events=0, malformed_frames=0, single APPID 16384 ARSTACK_SV01. Some host timestamp gaps (850 >1ms; max 7997µs) are not automatically sample-count loss.
    • 3,693 PTP Layer 2 frames: 1231 each ANNOUNCE/SYNC/FOLLOW_UP, ptp_malformed_frames=0; 3,999+fps source and PTP L2 continuity significant, but exact GM traceability/physical egress phase unverified; PTP SOURCE / UNLOCKED can be valid in local SOURCE mode.

    Confirmed architectural issue from current main source: firmware live_control.cpp 6-second PC HEARTBEAT lease drives g_running=false on expiry, and Studio DeviceController::shutdown sends STOP automatically if still running. This creates unnecessary coupling of ESP32-P4 Ethernet real-time operation to Windows USB/COM process lifetime.

    PR #331 — board-autonomous publishing is currently under CI:

    • Studio shutdown/USB disconnect no longer STOPs SV/PTP. Firmware heartbeat expiry becomes diagnostic, not a publisher STOP authority. START still requires verified config + fresh control session; explicit STOP remains effective.
    • Physical Ethernet down event stops SV immediately with SVLIFE stop_cause=ETHERNET_LINK_DOWN; PTP receives nonblocking atomic teardown request (task cleanup within ≤5ms poll). Existing 400-consecutive-transmit-failure fail-closed guard remains for MAC/driver faults independent of physical-link event.
    • New UI source contract test plus physical runbook docs/BOARD_AUTONOMOUS_SV_PTP_CONTROL.md. Board-source boot PTP supervisor may boundedly resume local SOURCE after qualifying link cycle, while SV never restarts on its own after physical Ethernet fault.
    • New source/firmware/GUI pair must prove 10-minute unplug-USB continuous NIC capture, reconnect verified RUNNING (without restarting phase/smpCnt), explicit STOP, physical Ethernet loss and 3600s independent NIC capture before issue closure or stable promotion.

    This is an in-progress PR, not a claim of completed field acceptance. M3.H.1 Stable and M3.H.2 RC1 public preview remain untouched.

  12. masarray commented on Oct 25, 2026

    @masarray
    OwnerAuthor

    PR #331 revision (latest head c9f1e998) — LINK_DOWN PTP policy correction

    The early investigation comment stated the M3.B boot SOURCE supervisor might recover on Ethernet replug. That is explicitly disabled in the revised P0 patch after the verified physical UP→DOWN edge: ar_ptp_lab_request_link_down_stop() in ptp_mode_facade.cpp latches ar_ptp_boot_supervisor_operator_override(), cancels SOURCE plus TIME_RECEIVER/MONITOR via separate atomic flags, and invalidates smpSynch authority. Firmware START crossing a link-loss edge is cancelled by a monotonic link-fault epoch and existing serialized cancellation gate. PTP will not silently resume after replug; manual operator START required. Initial boot without prior Ethernet UP is not treated as a physical fault. Studio USB loss remains independent and must not stop an already-running publisher.

    The exact feature is still under CI on PR #331. Field verification of source/receiver PTP teardown and no implicit re-start remains open, and current M3.H.2 RC1 binaries predate this patch.

  13. masarray commented on Oct 25, 2026

    @masarray
    OwnerAuthor

    2026-10-25 P0 LAN autonomy field report + latest implementation

    User supplied four physical independent-NIC capture files. Summary: 1231.679 s, 4,926,580 SV frames, observed 3999.89 fps, zero missing/duplicate/reordered smpCnt, zero malformed, 3693 PTP frames (1231 each Announce/Sync/Follow_Up). Capture is INVALID_CAPTURE as publisher STOPPED before 3600 s. Crucially this report does not contain a board SVLIFE stop cause; firmware build 83439a4a15f186b0 is the pre-autonomy image. Do not attribute that observed stop exclusively to USB expiry absent board logs.

    PR #331 is MERGED in main at 0ec12c04c131e494d451e79960c75c9c34b37f5f: 20 CI success, 1 skip. USB/Studio heartbeat expiry and normal GUI shutdown no longer stop already-running SV; verified START, explicit SV/PTP STOP and actual PHY-down fail-closed still apply, with nonblocking PTP teardown and no automatic restart on LAN return. Lab-only new matched Windows Studio+firmware artifact was built from PR-head c9f1e998bec69e55dee3f95764d1477e87f518b7. Existing stable M3.H.1/RC1 untouched.

    Still OPEN: PR #330 is overlapping and now conflicting; it additionally proposes detailed board setpoint reconciliation and a renamed breaking firmware capability, not included in PR #331. Do not blindly merge it or force a capability change on an existing release. Resolve its non-overlapping GUI scenario readback under a new rebased PR and a matched firmware/GUI compatibility gate. Test 10min USB unplug with independent capture; board still RUNNING on reconnect; explicit STOP verifies; LAN unplug immediate STOP and no implicit auto-resume; 3600s capture; ARSAS and DigSubAnalyzer independent receive. Do not close issue #324 or promote stable until completed.

  14. changed the title [-]P0: ESP32-P4 M3.H SV not visible in ARSAS and DigSubAnalyzer — independent RX acceptance[/-] [+]Community feedback: SV receiver visibility, VLAN and APPID/svID setup in lab analyzers[/+] on Oct 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions