Re: GPS logger with voice recording - Wear balancing for SD/MMC card needed?

> Hi All,
>
> I'm just working on the open source GPS logger with voice recording (to
> facilitate recording tracks for the http://www.openstreetmap.org project).
>
> The current architecture includes:
> GPS module - http://www.f-tech.com.tw/datasheet/GPS/FGPMMOPA2.pdf -
> first tests show, that it performs very well even at low level of GPS
> signal.
> CPU - Atmega32 or PIC18F4550 - not decided yet (the second one could
> provide the USB access to the stored content, but Atmega32 is easier to
> program...)
> Slot for the SD/MMC card,
> The microphone amplifier with the AGC (based on SSM2165 or similar, eg
> this one:
> http://www.cyfronika.com.pl/kityAVT/avt2312pdf.pdf [Polish, sorry])
> UI - very limited. LED diodes or LCD display showing the quality of the
> GPS signal and current operating mode. Switch ON/OFF, switch
> record/pause, unstable switch - record voice annotation.
> Device should be safely operable when driving a car o a bike.
>
> The track will be stored in the NMEA format (no problem with 1GB SD/MMC
> capacity).
> The short voice annotations will be stored in 8-bit 8kHz PCM (also no
> problem with this capacity).
>
> The most important problem I'm facing right now is: how to store the
> information on the SD/MMC card to balance the wear?
> Does the internal controller perform any block readdressing to balance
> the wear?
>
> I'm not bound with any filesystem limitations, because i can use my own,
> very simplified filesystem. The device will be dedicated mainly for
> Linux users, so it will be possible to read the data either via USB (if
> 18F4550 will be used) or via FUSE based simple filesystem driver, or via
> raw access to the block device.
>
> I have some ideas like:
>
>     * Using the whole card as a big circular buffer (well in fact the
>       block 0 will hold an identifier of my "filesystem" to make sure
>       that the card will not be treated as a corrupted volume formatted
>       with other FS). Each 512-byte block will store it's 4-byte
>       sequential number on the begining. Then I will be able to use a
>       quick binary search algorithm to find the first free block, when
>       starting a new track.
>     * Using the first block to store the FS identifier and a number of
>       the block storing the "begining block" of the filesystem. The
>       begining block would be relatively heavily used when
>       recording/erasing track, and if rewritten 10000 times or so it
>       could be moved to the other block - which would require also
>       updating of the block 0.
>
> Which of the above approaches is better? Maybe I should use yet another one?
> Maybe I shouldn't implement wear-balancing at all?
> Any suggestions regarding the implementation of the "filesystem" and
> other functionalities of the device will be appreciated.