The Fly6 rear camera on my bike started giving off three long beeps and shutting down. Doing the reformatting / rebooting dance provides only temporary relief, so I think the card has failed:
The Fly6 can handle cards up to only 32 GB, which means I should stock up before they go the way of the 8 GB card shipped with the camera a few years ago.
Some back of the envelope calculations:
- It’s been in use for the last 19 months
- The last 22 trips racked up 88 GB of video data = 4 GB/trip
- They occurred over the last 6 weeks = 3.6 rides/week
- Call it 250 trips = 1 TB of data written to the card = 32 × capacity
That’s only slightly more than the failure point of the Sony 64 GB MicroSDXC cards. The Fly6 writes about a third of the data per trip, so the card lasts longer on a calendar basis.
So now let’s find out how long the Samsung cards last …
The Smell of Molten Projects in the Morning 
I think the spec for these is 100k writes minimum, but I take such specs with a grain of salt with consumer grade MLC flash. 32x capacity is several orders of magnitude less, but while the data is probably more or less evenly distributed, some blocks holding filesystem information are going to get hammered. If the card does load leveling, that should help some, but there’s going to be a fair amount of write activity that’s not part of the data stream itself. I’m not convinced it’s that many orders of magnitude, however, so I conclude that either the card isn’t doing load leveling (plausible) and/or it isn’t meeting its endurance spec (plausible, but sad). While there are flash-optimized storage algorithms, I doubt it’s practical to build custom firmware for your camera to implement one.
AFAICT, SD cards either don’t do load leveling or can’t do it in real time running against streaming video data. The Fly6 uses the filesystem as a ring buffer, deleting the oldest files when it needs more room, which puts FAT directory updates in the critical path: even if the card load-levels only the directory sectors, any delay will clobber the pending writes.
I’d like to use cameras with readily hackable firmware, but the economics of small-scale production (for optics, among other parts) just don’t work.
That makes no sense to me. You should need one FAT write per recorded file, so assuming 1GB files, you had about 1000 FAT writes all together over the card lifespan – a far cry from 100k. What am I missing?
The solution to every problem – a Raspberry Pi! Throw the Pi Camera on there (or a webcam on your head, or any array of webcams for immersive 360 degree imagery, or..) and take 3 stills a second? Trash an old Thinkpad X40 and you can harvest the 1.4″ disk drive. Or a 1st gen iPod. Millions of write cycles. Can also skip FAT and go straight to ZFS. Runs your APRS, OpenStreetMaps, Music, and news server as well. SSH to it when you get home and dump the video.
Stop me before I hurt myself. :-)
And… I hit the wrong reply button. Sorry ’bout that.
Well played, sir!
One of the RPi streaming players has started transitioning directly from music to white noise, while continuing to respond to keypad input and leaving no trace in the system logs. Haven’t a clue how to debug it; perhaps I should blame it on an SD card failure and skip all the analysis. [sigh]
Please don’t trash any X40s! They’re (by far) the best laptop ever made and I’m trying desperately to keep my stable running :(
OK – I have the x40 that turns into a tablet (and seems to not be a wacom part, either). The hinge is super sloppy, and it’s definitely the friction part and not the mounting screws. Any sources for these?
I’m making the assumption the card has failed: it has perfect data retention and not enough speed to keep up with the video. May be completely wrong, but I can’t think of any other mechanism.
One more idea, if you go with the idea that FAT region is semi-fried, what happens if you add couple of hunderds of small files to a freshly formatted card and never delete them? Any new files recorded by the camera must use FAT locations further down in the address space hopefully skipping the worn out cells.
IIRC, wear leveling reallocates the underlying memory blocks (or whatever they’re called), not the filesystem sectors. The block size seems unknowable to mere mortals, but some casual searching suggests anything up to a few megabytes, depending on the card capacity, which certainly require a whole bunch of trial-and-error to verify.
Advice from a reputable source says just buy good cards, use ’em until they fail, and toss ’em. I have trouble thinking of memory as a consumable, though …