Logs Drop Mid-Flight

Dataflash logs stop recording useful data mid-flight. I have a SanDisk Pixator UHS class I 16GB memory card that has logged long flights just fine. It’s about 30% full. My last two flights were uneventful, but the logs are missing for over half of the flight.

LOGS: https://1drv.ms/f/s!AunBK4rE1ZDC8iXvkuz4ffReBYIg

That is quite bizarre. Any ideas @peterbarker or @tridge? Nate says the flight went find, it continued flying for another hour and landed fine. Mauch power supply. Good SDcard. No no log entry for the remainder of the flight

I would have thought it was a 1-off, but it happened twice back-to-back yesterday. Both flights should have been about 2 hrs, and each had 2 or 3 arms/disarms/takeoffs before I unplugged and switched the battery. I had 20 complete logs before this happened yesterday, and I only changed some parameters related to the tail. Nothing else to my knowledge.

cross-posed: https://github.com/ArduPilot/ardupilot/issues/7962

Last time this happened it was resolved as “SD card was counterfeit and
smaller than advertised”.

Check your .tlog’s - did the vehicle know it wasn’t logging to the SD
card?

Also - how big are the logs?

@peterbarker The cards were purchased from a Best Buy store, so I doubt they were counterfit.

I did not see any messages from the .tlog. I’ll add them to the folder in a few minutes as a reference.

26 and 27 were the issue logs - 131 and 34 megabytes. I’ve had much larger ones, so I’m not sure what’s going on.

.tlog files are included in the original link. https://1drv.ms/f/s!AunBK4rE1ZDC8iXvkuz4ffReBYIg

This reminds me of my problem reported here:


I also know that the issue remained after the next release, reproducible only now and then, and on only one Pixhawk. formatting / replacing microSD did not help.

Sometimes, an log could end midflight, then the following logs would not even create a file.
removing/reinserting card would not create file on next reboot+arming.
doing some card operations, (like backup all files, then format and restore all) it would be used again. I suspected some crazy bug in FAT library.

All my SD cards are good stuff, verified using f3-6.0 and benchmarked with gnome-disk-utility

Also: fake SD cards, are never fake in the start of the address space, that’s where the FAT is , they just don’t store data after their real size.
So a fake card (even when full) would create file (in FAT), and filesize would be good, except when read, it would be all “1” or “0” (depending on the hardware)

As long the user don’t see a new file being created in FAT, - the issue is not simply a fake card.

We had a closer look at these logs. There is an indication in the log of
a problem with the IO thread, however Plane 3.8 doesn’t currently
incorporate some fixes present on the master branch. Hopefully for 3.9…

Flew master plane 3.9 PX4-v3 built on 3/31. Ran into the same issue about 2 hours through my flight. This time I got a “bad logging” message consistently on my HUD in Mission Planner. That’s an improvement, but I’ll be replacing the memory card before I troubleshoot more.

I did clear my memory card of all of my previous logs before I flew, so I know there was plenty of card capacity to log more than 2 hours.

Flew master plane 3.9 PX4-v3 built on 3/31. Ran into the same issue about 2
hours through my flight. This time I got a “bad logging” message
consistently on my HUD in Mission Planner. That’s an improvement, but I’ll
be replacing the memory card before I troubleshoot more.

Great! The patch that tridge pulled in should have had that effect.

I did clear my memory card of all of my previous logs before I flew, so I
know there was plenty of card capacity to log more than 2 hours.

You can test this on the ground if you have time to find a convenient way
to power your vehicle; set LOG_DISARMED to 1 and wait…

Check the size of the file created - there is going to be a hard limit on
that given the filesystem.

Maybe that’s the whole issue. I definitely have some ground testing to do. Thank you.