mavlogdump: CSV option: Don't cut out messages with same timestamp #912
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.
The PR is to fix #905.
It removes the logic which cuts out subsequent messages from CSV output if they have the same timestamp.
This typically affects messages with instances like IMU, where only the last one of a sequence would be output.
It would also affect messages like MSG, MULT, UNIT, etc, which may be added to the log file in batch.
Main Testing
I have tried a few files, with a few message types, and can now see expected output. For example, the IMU data for both instances even when they have the same timestamp:
Additional Testing/Fixes
Testing with DF Text logs found that outputting a text log to CSV was throwing an error.
This has been fixed by using
(isbin or islog)
in place ofisbin
in a couple of the if statements.When specifying a message type that doesn't exist, an exception was being thrown, so I have added some checks to output a nicer message for users in this case:
Behaviour with TLOGs
When dumping TLOGs to CSV, it is allowed to specify multiple messages in the
--type
argument. This outputs data for the message at that timestamp, and empty fields for the others (shown below).This may look a bit odd, and I don't know if it is what was intended, but my change doesn't appear to have altered the behaviour, so I was thinking not to touch it. The previous logic would only ever have merged messages onto one line if they had identical timestamps to the microsecond level - which doesn't sound possible!