fix(sensing-server): make multistatic guard interval configurable (closes #1049)#1104
Open
ruvnet wants to merge 1 commit into
Open
fix(sensing-server): make multistatic guard interval configurable (closes #1049)#1104ruvnet wants to merge 1 commit into
ruvnet wants to merge 1 commit into
Conversation
…rable (#1049) Two ESP32-S3 nodes on WiFi/ESP-NOW sync drift 10-150 ms (~70 ms typ.), exceeding the 60 ms default guard → permanent trust demotion to Restricted, all pose output suppressed, 200k+ errors, no escape but a container restart. Add a direct WDP_GUARD_INTERVAL_US override (+ optional WDP_SOFT_GUARD_US) to multistatic_guard_config_from_env. Precedence (most-specific wins): direct override > WDP_TDM_SLOTS+WDP_TDM_SLOT_US schedule-derived > 60ms/20ms default. Soft band always clamped strictly below hard; malformed/zero ignored (falls back, never breaks fusion). Effective guard logged at startup. Pinned by 6 tests (multistatic_guard_config_tests). sensing-server bin tests 449 -> 455, 0 failed. Python proof PASS, hash unchanged (off signal path). Closes #1049. Co-Authored-By: claude-flow <ruv@ruv.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1049 — permanent trust demotion with WiFi-synced ESP32 nodes
Reporter's symptom (2× ESP32-S3, firmware v0.7.0,
ruvnet/wifi-densepose:latest): the governed-trust cycle permanently demotes toRestrictedand suppresses all pose output because the inter-node timestamp spread (measured 10–150 ms, ~70 ms typical) exceeds the guard interval. Error counter hits 200k+; the only workaround is restarting the container (which re-demotes within minutes).Root cause: ESP-NOW sync (100 ms beacons + WiFi-MAC jitter) cannot hold two independently-clocked boards within the published 60 ms default guard, and there was no runtime/env way to raise it without knowing the exact TDM schedule. (Note: the hardcoded
5000 µsthe issue cites was already raised to60_000 µsin a prior change — but 60 ms still < the reporter's ~70 ms spread.)Fix
A direct
WDP_GUARD_INTERVAL_USoverride (+ optionalWDP_SOFT_GUARD_US), the issue's option 1/2. A deployment just setsWDP_GUARD_INTERVAL_US=200000to lift the guard past its measured spread — no schedule math needed.WDP_GUARD_INTERVAL_US→WDP_TDM_SLOTS+WDP_TDM_SLOT_USschedule-derived → 60 ms/20 ms default. The override applies on top of whichever base is selected.Honest scope
This is the configurability fix (the issue's title + root cause). The reporter also suggested a
POST /api/v1/trust/resetendpoint (option 4) — deferred as a separate, larger change; with a correctly-sized guard the demotion no longer occurs, so the restart-to-reset need goes away. The default stays 60 ms (validated for TDM hardware); WiFi deployments opt into a larger value.Validation
multistatic_guard_config_tests): direct-override-wins · beats-TDM-derived · soft-clamped-below-hard · lowering-hard-pulls-soft-down · malformed/zero-falls-back · default-when-unsetwifi-densepose-sensing-serverbin tests 449 → 455, 0 failedpython archive/v1/data/proof/verify.py→ PASS, hash unchanged (off the signal proof path)🤖 Generated with claude-flow