Repository navigation
PTP troubleshooting #287
Description
When selecting "Follow external PTP", counters don't go up and Discipline remains as "unlocked". I wonder if there is a way to troubleshoot/verify if there's any PTP traffic being received.
When selecting "Provide PTP timing", my network switch takes the smv injector as master but the offset is huge (140737488355327 ns). Is there a way to verify the ESP32 clock?
ARStack Studio v0.1.1 + ESP32-P4-ETH v3.2 running arstack_esp32p4_smv_injector_v0.1.1.bin built from source for board v3.0+.
Activity
masarray commentedon Oct 23, 2026
2026-10-23 Stage→Main open-issue triage — PTP receiver / v3.2 hardware (KEEP OPEN)
This report remains distinct from generic #154/#162 acceptance: it is from ARStack Studio v0.1.1, ESP32-P4-ETH v3.2, firmware built for board v3.0+, and shows (a) external SOURCE-follow counters not incrementing / discipline UNLOCKED; (b) network switch selects board as GM but displays offset 140737488355327 ns. Neither symptom is shown resolved by current v3.0+ hardware capture; do not close as duplicate.
Useful numerical clue: 140737488355327 = 2^47 − 1 exactly, a boundary/max-value pattern rather than a plausible measured real-world offset. This may be an invalid/uninitialized/saturated value displayed by the switch, but that interpretation is a HYPOTHESIS: the source that generated this exact number is unknown. Do not publish it as ESP32 hardware clock accuracy or actual PTP offset without raw device diagnostics.
Verified software readback path: In
embedded/esp32p4_smv_injector/main/ptp_mode_facade.cpp, a PTP2 status line presentsoffset=NAwhenstatus.offset_validis false, and includesrole/discipline/source,rxAnnounce/rxSync/rxFollowUp/rxPdelay,pdelayReq, accepted/rejected counts. Studio'sDeviceController.cppparses the numeric orNAoffset as a string andPtpExpertPanel.qmldisplays it verbatim. This helps separate a number shown by the external switch from a number measured by the board.Reproduction plan on authorized isolated process-bus lab only:
IDENTIFYbuildId/manifest, selected role, PTP profile (L2 UDP vs L2, domain, VLAN/PCP, transportSpecific, two-step, E2E vs P2P), PHY link and Ethernet driver status. DO NOT flash an older pre-v3 image onto v3.2.0x88F7for L2, plus VLAN-tagged frames): Count Announce, Sync, Follow_Up, Pdelay_Req/Resp/Resp_Follow_Up; inspectdomainNumber,clockIdentity, sourcePortIdentity and selected GM. If no incoming packets, troubleshoot VLAN/switch filtering/port mirror and role first; a zero RX count is not evidence that the servo itself is broken.source=... offset=... path=... discipline=...diagnostics over 30–60s. In internal SOURCE mode, capture Announce flags/clockClass/traceability and compare to actual external reference and switch screen; avoid asserting GPS/UTC traceability without a qualified source.PTP2status log and switch UI/specific offset field (including units/scale). Then reproduce with latest v3.0+ compatible firmware only once matched source/build is known. SIPROTEC 5 LOCKED/4I4V acceptance belongs to separate M2: continuously PTP-disciplined SV timeline, truthful smpSynch and IED sync-alarm acceptance #154.Closure gate: explain/resolve raw 2^47−1 offset provenance, prove receiver packet RX and correct GM qualification or document explicit unsupported setup, and capture repeatable source/receiver behavior with exact firmware. #287 stays OPEN; no guessed fix or production code change from housekeeping.
masarray commentedon Oct 24, 2026
PTP troubleshooting update: The 2026-10-24 M3.H Stable simulator has source and release ancestry merged into main through #299; its local internal simulated Global GM produced a 40.76s verified SV/PTP capture. This does NOT prove or retest the older v0.1.1 external-follow PTP-unlocked case, switch offset value, real peer Pdelay exchange, or physical UTC traceability in this issue. Remain OPEN pending a matched-firmware reproduction and real PTP packet/clock evidence. If retested, record actual firmware Build ID, domain, GM ID, Announce/Sync/FUP and Pdelay/servo readback, rather than assuming the updated local-source simulator solves external receiver behavior.
masarray commentedon Oct 24, 2026
M3.H release backlog reconciliation — 2026-10-24
M3.H release is INTERNAL_GM_ONLY simulated PTP and does not resolve the original v0.1.1 external FOLLOW UNLOCKED or switch-offset observation. Historical PR #266 closed unmerged; preserve requirements for bounded PTP STOP/ACK/readback and diagnostic visibility under #300. Actual external GM/switch troubleshooting remains open here pending physical capture, switch GM/clockClass/offset and firmware Build ID evidence.
Canonical ledger: https://github.com/masarray/arstack61850/blob/main/docs/integration/M3H_MAINLINE_RELEASE_SOURCE_CLOSURE_2026-10-24.md .