You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.
Describe the bug
The default copy table looks at byte offset 12 of the cFE messages. The new Tlm secondary header padding for 64-bit alignment causes the start of data to be at 16 bytes into the packet.
To Reproduce
Steps to reproduce the behavior:
Go to '...'
Click on '....'
Scroll down to '....'
See error
Expected behavior
A clear and concise description of what you expected to happen.
The input offset for each should be 16, and the output offset should start at 16 (16, 20, 24, 28, 32).
System observed on:
Hardware: x64 (but should work for any)
OS: PC-Linux (but should work for any)
Versions cFE Draco rc4
Additional context
Additionally (optionally), the current table reads the first 4 bytes out of each packet. I think it would make more sense to only read the command count and command error count (the first 2 bytes) of each packet. If this also gets implemented, remember to update the numBytes accordingly.
Reporter Info
Keegan Moore
NASA/GSFC
The text was updated successfully, but these errors were encountered:
keegan-moore
changed the title
Default InputOffset in HK Copy Table Needs Update for New Tlm
Default InputOffset in HK Copy Table Needs Update for New Tlm Hdr Size
Feb 7, 2023
Checklist (Please check before submitting)
Describe the bug
The default copy table looks at byte offset 12 of the cFE messages. The new Tlm secondary header padding for 64-bit alignment causes the start of data to be at 16 bytes into the packet.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Code snips
Currently:
The input offset for each should be 16, and the output offset should start at 16 (16, 20, 24, 28, 32).
System observed on:
Additional context
Additionally (optionally), the current table reads the first 4 bytes out of each packet. I think it would make more sense to only read the command count and command error count (the first 2 bytes) of each packet. If this also gets implemented, remember to update the numBytes accordingly.
Reporter Info
Keegan Moore
NASA/GSFC
The text was updated successfully, but these errors were encountered: