[EE] 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

project).

The current architecture includes: GPS module -

- 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: [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.