Repository navigation
Conversation
…le, before issuing serial commands
… without misleading toggle bounce
…o and runtime options
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
…Advanced, no immediate switch snapback
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 654dd4284c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| || panel.device.ptpRunning || panel.startPending || panel.session.updatingFirmware) | ||
| return false | ||
| const accepted = panel.session.requestStartPtpConfigured(role, panel.ptpProfile()) | ||
| const accepted = panel.session.requestStartPtpConfigured(role, panel.ptpProfile(role)) |
There was a problem hiding this comment.
When the board currently stores a RECEIVER or MONITOR profile with peer delay disabled, this call constructs a valid SOURCE profile with peer delay forced on, but startPtpConfigured() sends PROFILE PTPROLE SOURCE before sending that profile. The firmware's PTPROLE handler clones and validates the existing peer-delay-disabled configuration, so it rejects the role before the corrected PTP CONFIG can arrive; consequently SOURCE still cannot start after using the newly supported non-SOURCE setting. Apply the target profile before role validation or make the role/profile transition atomic, and cover the RECEIVER-with-Pdelay-off to SOURCE transition in the deterministic harness.
AGENTS.md reference: AGENTS.md:L232-L234
Useful? React with 👍 / 👎.
| 'checked: false' in ptp_panel and | ||
| 'Require hardware peer-delay responses' in ptp_panel, | ||
| "Firmware tab must show exact build and SOURCE Pdelay must be explicit") | ||
| 'respondToPeerDelay: role === "SOURCE" ? true : pdelayCheck.checked' in ptp_panel and |
There was a problem hiding this comment.
This updates one structural assertion for the new role-aware ptpProfile(role) call but leaves the assertion at line 256 expecting the removed literal requestStartPtpConfigured(role, panel.ptpProfile()). As a result, the Studio CI command python3 apps/arstack_studio/tests/check_operator_workspace.py fails at this commit with main PTP must reuse the existing verified Advanced profile, so the workflow cannot pass until that earlier expectation is updated as well.
AGENTS.md reference: AGENTS.md:L236-L236
Useful? React with 👍 / 👎.
…ore/backend validation for direct calls
…-3 profile summary
1 participant
Physical incident
User's PR #264 Studio screenshot: PTP control immediately flips back OFF; firmware reports
PTP configuration rejected: stop PTP first or correct the profile,SVSYNC DIAG events=0. Not a PTP 4kHz lock fault: the configuration was rejected before PTP START.Root cause proven in code
PR #264 changed hidden QML Pdelay default to
checked:false. Firmwarevalidate_runtime_configenforces IEC/IEEE 61850-9-3 SOURCE cadence and hardware Pdelay: 1000 ms Announce, 1000 ms Sync, Pdelay responder enabled. CI passes because deterministic harness generatedrespondToPeerDelay:trueand did not test actual QML contract. Source-level mismatch caused user-visible CONFIG failure.Production correction
inspect_ptp_power_profile_cadence(announce_ms,sync_ms,pdelay)alongside protocol options checker; SOURCE preflight in real Qt DeviceController rejects invalid profile locally with explanatory error before any PTPROLE/CONFIG; regular receiver/monitor roles remain configurable.PTP configuration rejected: reason=SOURCE_REQUIRES_1S_ANNOUNCE_1S_SYNC_AND_PDELAY,PTP_RUNTIME_ALREADY_ACTIVE,INVALID_OR_UNSUPPORTED_PTP_PROFILE, or race reason; firmware reason is bounded, atomic and control-path only, with no PTP/SMV transmit hot-path modification.Exit / safety
CI must pass exact HEAD: Studio Qt/Linux+Windows harness, ESP32-P4 SOURCE/RECEIVER, Studio Native Preview matched firmware/installer, Windows lifecycle, C++/MSVC. Hardware Pdelay RX capability still must be verified on real ESP32-P4; no PTP lock or IED compatibility claims without Capture+on-board proof. PR stays unmerged, main unchanged.