Log and keep received DDOP bytes for diagnostics - #96
Merged
Merged
Conversation
On every activation, log the received DDOP's size, chunk sizes and an FNV-1a 64-bit hash, and save the raw bytes once per distinct pool to <NAME>/received/<hash>.ddop. The existing en.ddop is regenerated from the parsed pool and overwritten each session, so it can't show what the client actually sent. Parsing and activation are unchanged; a failed save only logs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gunicsba
added a commit
that referenced
this pull request
Sep 27, 2026
Resolve conflict in task_controller.cpp by keeping both new helpers: find_owning_element_number (GNSS quality) and save_received_ddop (#96). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
2 participants
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.
Summary
Diagnostic only, no behavior change. Follow-up to #78 (closed).
In two field sessions the tracks build subscribed DDI 160 (Section Control State) on element 4 of the Sky "E2 Seeder". In both, the TC got a single 1255-byte upload, and one of them was a freshly started process. The parsed pool had element 4 referencing object 268 (DDI 160). Good sessions don't have that reference. The parser is deterministic and nothing changes the pool afterwards, so the TC most likely received different bytes. We can't check, because
<NAME>/<label>.ddopis regenerated from the parsed pool and overwritten on every activation.Changes
On every activation,
activate_object_pool()now:Client … received DDOP: 1255 bytes in 1 chunk(s) [1255], fnv1a64=…<NAME>/received/<hash>.ddop, once per distinct pool (so disk use stays bounded).Parsing is unchanged. The save runs before the parse result is checked, so failed activations get captured too. A save error is only logged.
Validation
🤖 Generated with Claude Code