Sunday, March 21, 2010

Blue is dead...

We had a perfect tether flight on Saturday, followed by a bad free flight.
The vehicle started well, but as airspeed built up it started to spin.
It got to about 1Kft then started down. It went unstable probably due to the high rate of spin.
and started to leave the area of the pad and was heading toward the spectator area so I aborted. Both the software driven and RC only vent abort worked.
The vehicle is totaled.

The micro sd flash chip from the vehicle physically looks ok, but gets very warm when power is applied so I've gotten no data from the vehicle.

I had a camera pointed at the bottom of the motor with a good view of the vanes and if I can recover data from the video camera SD card it should provide some information.
The camera was destroyed on impact, the SD card is fine but the camera did not close the video file before impact. So it shows zero length.

Any advice on how to fix this?
My approach:
I've got some utilities for manipulating bare SD sectors that I use for my data logging cards.
Using this I wrote a utility to copy all the sectors off the Cameras SD card into a big file.
So the original card is safe and I won't mess with that.
I then wrote a short utility to copy the exact same sectors contents back onto a equal sized SD card. I'll then run chkdsk on this duplicate SD card.

One rub is that while the SD cards are the same brand and size they report slightly different numbers of physical sectors, will this mess up the FAT table accounting? The card I'm copying to has more sectors than the one off the camera.

The cards is formatted as FAT16 so I can start tracing clusters by hand and reassembling file chains, but its been along time since I did FAT table stuff by hand with a hex editor.
Any recommendations on good tools to do this?


If that does not work,
any other ideas on recovering the video data from the SD card?

11 comments:

bob said...

How about contacting one of those hard drive recovery places? Of course its not a hard drive and they probably don't see much FAT16, but you never know - maybe they have an idea you could investigate.

Daryle Dismukes said...

Ontrack's EasyRecovery Pro has worked wonders for me. They have a free trial version where you can recover one file.
http://www.ontrackdatarecovery.com/data-recovery-downloads/

What file format does the camera write?

Anonymous said...

usually spin increases stability

Paul Breed said...

Not when your trying to navigate and the spin is fast enough to induce what direction is north lag.

Anonymous said...

sounds like you are taking the right and rigorous approach

there are many commercial softwares that could help you, too many to count, but the free needles are out there in that haystack. they're out there and this is all I can tell you
http://www.piriform.com/recuva
http://foremost.sourceforge.net/

ellindsey said...

The micro SD flash chip might be salvageable. I repaired a USB thumb drive with similar symptoms caused by mechanical damage. The board was cracked and had internal shorts. By very carefully desoldering and lifting the pins on the flash chip I was able to isolate and bridge around the short and get the chip working long enough to get the data off. It might be possible to do similar with your micro SD chip.

heroineworshipper said...

If it was empty before the video, it should be perfectly contiguous. AVCHD video is a no brainer since that doesn't require a header. JPEG is a bit harder because it requires building a header. mp4 would be the worst since the audio & video have similar start codes.

JD1985 said...

If the SD card is in good condition as it sounds, you could try "image j". It's free, and as long as the video is saved uncompressed it might be able to recover some frames.

Wolfkeeper said...

You might be unlucky with the video; a lot of OS's cache data in the RAM until the file is closed, because it greatly increases speed to do that. Only if they run out of cache space, or the file is closed, do they write stuff. If so, the data may be gone. The length of the file being zero that does not bode very well.

To avoid this, with many OSs when you mount the flash device you can specify cache behaviour.

Monroe King Jr. said...

Spinrite was an old program I used to use to recover lost files may be of some use. There are newer versions I have no experience with but I remember the version I had rocked.

Monroe King said...

Looking a little deeper if spinrite is not practical perhaps this information will help.

Roadkil's Unstoppable Copier runs under Windows and copies on a file, not sector, basis. It can be set to copy all undamaged files first, and then to try to copy as much as possible of damaged files (although, during extraction, it is difficult to see which file is being copied, and thus to avoid copying files not worth recovering).

Open Source Unix-based alternatives include dd_rescue and dd_rhelp, which work together, or GNU ddrescue. dd_rhelp first extracts all the readable data, and saves it to a file, inserting zeros where bytes cannot be read. Then it tries to re-read the invalid data and update this file. GNU ddrescue can be used to copy data directly to a new disk if needed, just like Linux dd.

dd_rhelp or GNU ddrescue will yield a complete disk image, faster but possibly with some errors. GNU ddrescue is generally much faster whereas dd_rhelp is a shell script wrapper around dd_rescue. Both dd_rhelp and GNU ddrescue aim to copy data quickly from sectors that are free of errors, then copy in smaller blocks, with retries when necessary, where errors are found. These programs are more complicated to use than SpinRite, although GNU ddrescue is fairly easy to use with default options, and can easily be downloaded and compiled on Linux-based Live CDs such as Knoppix. It can also be used with SystemRescueCD.

Hope that helps speed things up I know you can do it the long way from your post but this might speed things up.