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

[Wojciech Zabolotny]

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.
--
TIA & Regards,
Wojtek
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Shawn Tan Ser Ngiap]

On Sunday 11 May 2008 16:40:26 Wojciech Zabolotny wrote:
> 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?

The cards these days have an extremely large number of write cycles before
failure. And, they are fairly cheap to replace anyway. So, I wouldn't worry
too much about write balancing.

--
with metta,
Shawn Tan

Aeste Works (M) Sdn Bhd - Engineering Elegance
http://www.aeste.net

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Marcel Birthelmer]

>
> 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?
>

Wojtek,
I'm fairly certain that SD cards do their own internal wear levelling. No
need for you to worry about it.
Rgds,
- Marcel
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Brendan Gillatt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wojciech Zabolotny wrote:

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

SD cards have their own wear levelling built in.
Also, setting up a FAT32 filesystem will probably be not that much harder
work than writing your own from scratch - the standard is pretty simple.
When I was writing a library for FAT32,
http://www.pjrc.com/tech/8051/ide/fat32.html provided a nice introduction.

- --
Brendan Gillatt | GPG Key: 0xBF6A0D94
brendan {a} brendangillatt (dot) co (dot) uk
http://www.brendangillatt.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFIJyjSuv4tpb9qDZQRAokZAJ9v7xqQrBq5irUx17JNe9EWZJIBEgCff0pj
WlWzsUFbVC8MPPpBoXM/o0w=
=V5OO
-----END PGP SIGNATURE-----
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Dr Skip]

Anybody on the list do any digital photography? Has anyone put together
interesting equipment for it? I'm interested in slave flashes right now, but
also looking for neat, simple add-ons.

One of my digital cams is a Fuji s6000 which puts out great images and has a
lot of really nice features, but it's only drawback is that it's got a pop-up
flash instead of a shoe. It's handy, and some others offer both, but I'd like
to use my external flashes.

On digitals, they often shoot a series of fast, almost invisible (to the eye)
pre-flashes to meter before the real thing. Some solutions use a 200mS timer to
delay the slave flash, others count and you set whatever count your cam does
(play with the settings till it works). Typical external flashes come in low
voltage trigger (10v I think) and high voltage (200v on one I measured, and it
runs on 4 AA's). Triggering is by shorting the terminals.

I believe I can fashion a hood over the popup flash and drop the output. That's
important, since I put a burn mark on a piece of paper when covering it and
letting the cam set the power. It was amazing! A test with lens cover on and
manual aperture or shutter and it stayed cool (low output).

It still puts out some light, but does anyone have any really simple trigger
circuits already worked out? Maybe a phototransistor is all? Maybe a 555 timer
on it or use a CdS cell and cap to delay it? FET or bipolar? Is there a design
for both voltage ranges? I figure I'll make the hood, wire it to a shoe with
this circuit, and use my flashes old-school style.

I don't want to trigger from the popup flash, since it changes the lighting. I
have tried it with slaves with built in triggers, bouncing the popup flash to
them and blocking it from the subject, but it still gives out of control
reflections.

Of course, if anyone has hacked the Fuji s6000fd and put a hot shoe on, that's
best, but my searches aren't coming up with anyone or anything...

TIA for any suggestions.

-Skip



--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist