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
For data processing / exporting, the timestamps used for CAN messages are based off the timestamps in the msg packed messages, which come from the timestamps of each computer on the omnibus, which are not synced. This causes issues where the same CAN message can be reported by two different systems at the same real time, but differing timestamps, so they would seem to be two different updates. As a current hack, only one "stream of time" is taken as truth, using msgpackFilterUnpacker, so it either ignores messages that come from "the past" (any messages where the time is lower than the currently seen max time, so like an earlier clock), or instead only takes these "old" messages, to ignore the "ahead of time" computer. These sometimes yield different results, with the behind mode giving more data points if it's available, but super super super hacky and bad.
To remedy this, timestamps should be decoded from the contents of the CAN/Parsley message. The only issue is that this is a small value (16 or 24 bits) so overflows a lot, and we would need to undo it.
For more info, see: https://waterloorocketry.slack.com/archives/C07MX0QDS/p1706479899045329 In here, there is also an algorithm proposed to unwrap the timestamps, but more work needs to be put into planning how this process should be implemented into the data exporting pipeline (maybe enable inserting messages at arbitrary timestamps? change the way msgpacked messages are ingested?)
The text was updated successfully, but these errors were encountered:
For data processing / exporting, the timestamps used for CAN messages are based off the timestamps in the msg packed messages, which come from the timestamps of each computer on the omnibus, which are not synced. This causes issues where the same CAN message can be reported by two different systems at the same real time, but differing timestamps, so they would seem to be two different updates. As a current hack, only one "stream of time" is taken as truth, using
msgpackFilterUnpacker
, so it either ignores messages that come from "the past" (any messages where the time is lower than the currently seen max time, so like an earlier clock), or instead only takes these "old" messages, to ignore the "ahead of time" computer. These sometimes yield different results, with the behind mode giving more data points if it's available, but super super super hacky and bad.To remedy this, timestamps should be decoded from the contents of the CAN/Parsley message. The only issue is that this is a small value (16 or 24 bits) so overflows a lot, and we would need to undo it.
For more info, see: https://waterloorocketry.slack.com/archives/C07MX0QDS/p1706479899045329 In here, there is also an algorithm proposed to unwrap the timestamps, but more work needs to be put into planning how this process should be implemented into the data exporting pipeline (maybe enable inserting messages at arbitrary timestamps? change the way msgpacked messages are ingested?)
The text was updated successfully, but these errors were encountered: