Corrupted data flash log

I think I have a corrupted data flash log. I’m getting an error (“ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection”) when I try to geotag my images in Mission Planner using this log, so I really need to try and fix it.

When I download the log from Pixhawk (running Copter 3.3) using mavlink in Mission Planner (v1.3.32) it is assigned a file name using the date and time of the download, not of the mission, which already indicates a problem I think.

When I review the log in Mission Planner the data/time column shows 0001-01-01 00:00:00.000 throughout. The same happens if I choose to review the mavlink downloaded BIN file in MP after it goes through the auto convert to LOG. And the same also with the BIN file copied directly from the SD card.

When I open the log in a script editor it appears to be OK with time values recorded for each data row but I don’t know well enough how to interpret these values to spot where it’s gone wrong.

Flash logs before and after this one have been fine.

The BIN file is too large to upload here (26 minute mission) so I’ve had to chop a bunch off the bottom of the file using a text editor in order to upload. So I hope that still leaves enough for the issue to be revealed. I’m imagining that the problem is somewhere near the top of the file.

Many thanks for any help.

Jeremy

I’ve tracked down the problem in the file. The GPS status was recorded as 4. I’ve no idea why or what a value of 4 might mean - the wiki makes no reference to a value of 4.

When I changed all the GPS status values to 3 using a text editor, then Mission Planner recognised the dates in the log file, and the geotagging worked.

The GPS was operating perfectly well in terms of position, HDOP etc. I’m using a Neo8 compass/GPS module. (or at least I think I am - that’s what I ordered but I don’t know how to check that’s what it really is)

I’ve noticed in two subsequent logs that the GPS status changed from 3 to 4 mid flight bit this seems not to have caused Mission Planner a problem, perhaps because the initial GPS readings were accepted so it could figure out the time. I’ve not tinkered around further to check if this is true.

Any suggestions as to why value of 4 was logged? Does this suggest a bug somewhere?

I’ll mark this one as solved and raise a new question about the logging of value 4 for GPS status.

Jeremy