SD Card GPS Logger optimieren?

MoinMoin,

> Die Daten zu sammeln ist ne andere möglichkeit, erfordert aber auch viel
> Ramspeicher.
>
der Ansatz ist doch schon mal gar nicht so schlecht. Es kommt doch nur 
darauf an, soviel Daten zu puffern, um z.B. soviel zusammen zu haben, 
dass die Schreibroutinen nicht unnötig auf die kleinst mögliche Einheit 
(besagte 512Byte Blockgröße) mehrmals updaten. D.h. doch also nur, dass 
du solange sammelst bis 512Byte zusammen sind und schreibst dann auf die 
SD-Card.

Ok, dass könnte nun bei kleineren MCs (m8, m168 usw.) zu Platzproblemen 
führen, denn die haben nur 1KByte SRAM und damit wären sie schon 
"ausgebucht". Aber wie wäre es, ein externes Speichermedium von ein paar 
kByte mit einzubeziehen. Da gibt es doch einiges, was via SPI, TWI oder 
1wire leicht anschließbar ist.

Grüße Uwe

Hallo Achim,

In der Regel puffert man 512-Byte-Blöcke, die man als ganzes auf die 
Karte schreibt. Ich denke, das bei Karten, die nicht zu alt sind, die 
Wear-Leveling-Algorithmen schon weit genug ausgereift sind, so dass man 
sich um dieses Thema keine allzu großen Sorgen machen muss.

Bei meinem sd-reader wird automatisch ein Schreibpuffer von 512 Bytes 
verwendet, so dass Du das nicht mal in der Anwendung zu erledigen 
brauchst. Allerdings musst Du dann vorher die Datei auf die gewünschte 
Größe aufblasen, damit bei Zugriff auf Verwaltungsstrukturen der Puffer 
nicht doch schon rausgeschrieben werden muss.

Zur FAT: Die FAT verwaltet nur Cluster, d.h. Einheiten von mehreren kB 
Größe. Sie muss also nur geschrieben werden, wenn beim Vergrößern 
Clustergrenzen überschritten werden.

Etwas anderes sind die Verzeichniseinträge der einzelnen Dateien, die 
die genaue Dateilänge Byte-genau speichern. Diese Einträge müssen also 
wirklich bei jeder Dateigrößenänderung verändert werden. Deshalb rate 
ich, die Dateien vor dem ersten Beschreiben auf die gewünschte Endgröße 
zu vergrößern, das bietet zusätzlich auch Performance-Vorteile.

Viele Grüße,
Roland

Wieso so einen Pfusch mit der vorgefertigten Datei machen wenn es auch 
ordentlich geht?
Man nehme ein ordentliches Dateisystem wie z.B. das hier:
http://elm-chan.org/fsw/ff/00index_e.html
Das schreibt nur wenn ein Sektor voll ist. Man sollte aber alleine aus 
Gründen des Datenverlusts bei plötzlichem Spannungsausfall häufiger mal 
auch die FAT Tabelle abspeichern. (Abschnitt "Critical Section" auf 
dieser Seite: http://elm-chan.org/fsw/ff/en/appnote.html)

Davon abgesehen würde ich mir bei einem Preis von <5€ für eine SD Karte 
keine großen Gedanken um die Lebensdauer machen:
Bei einer Lebensdauer von sagen wir mal 10000 Schreibzyklen und einer 
NMEA Datensatzgröße von 256Bytes dauert es etwa 48 Tage bis eine 1GB 
Karte voll ist. Dann ist jeder Block einmal beschrieben. Ok, die FAT 
Tabelle gibts auch noch, also wird jeder Sektor häufiger beschrieben 
durch das wear Leveling. Selbst wenn man hier einen Faktor von 10 lebt 
die Karte dann immer noch 131 Jahre.

Und wenn man ganz faul ist, nimmt man direkt die fertige Lösung:
http://elm-chan.org/works/glg/report_e.html

GPS'ler schrieb:
> Nur mir ist halt nicht klar wie und
> wann in der FAT rumgenudelt wir.

Jedesmal wenn ein neuer Cluster angefangen wird (in der Praxis also alle 
4-16 Sektoren je nach Clustergröße). Wobei das Dateisystem aber auch das 
nur dann auf die Karte schreibt wenn die FAT in einen anderen Sektor 
rutscht der gerade nicht im RAM gepuffert wird.
Theoretisch müsste bei jedem Schreiben auch das Verzeichnis aktualisiert 
werden, da hier die Dateigröße verzeichnet wird. Dies wird aber 
üblicherweiße nur beim Schließen der Datei gemacht.

Die Optimierung bei einem Logger sollte daher eher in die Richtung 
gehen, wie man die Datensicherheit bei Spannungsausfall oder einem 
Absturz gewährleistet, also einen Kompromiss zwischen Pufferung im RAM 
und Anzahl an Schreibzugriffen zu finden.

Problem dabei ist ja, dass es kein Journaling bei Fat gibt 
http://de.wikipedia.org/wiki/Journaling-Dateisystem

Klar, könnte man einbauen, aber wäre dann eben auch nicht mehr Fat.

Ich bin auch der Meinung, eine etwas schmutzige Lösung wie die 
angesprochene mit dem Vorverketten einer Datei zur Datensicherheit ist 
schon Ok. Aber gleich die ganze Karte?

Wenn man wirklich nur GPS loggen will, hat man ja auch immer eine 
Sekunde Pause zwischen den paar Bytes die man wegschreiben will. Da hat 
man massig Zeit für verschiedenste Ansätze (werden ja sogar bei den 
meisten Lib's noch 512 Bytes gepuffert also hat man noch länger Zeit).

Wer bei seinem mit Fat Formatierten Pc beim schreiben einfach den 
Stromstecker zieht hat auch Probleme mit den Dateien...

Den Controller mit Notstrom versorgen (großer Elko) wäre eine Hardware 
Lösung...

Grüße Daniel

Hallo Achim,

> Nur mir ist halt nicht klar wie und
> wann in der FAT rumgenudelt wir.

Wie oben schon beschrieben. Immer dann, wenn die Dateigröße geändert 
wird und dabei gleichzeitig ein Vielfaches der Clustergröße über- oder 
unterschritten wird.

Wenn Du vor Start der Aufzeichnung die Datei auf die vorgesehende 
Endgröße vergrößert hast, wird die FAT und auch der Verzeichniseintrag 
während der Aufzeichnung nicht mehr angefasst. Die aktuelle Position 
innerhalb der teilweise gefüllten Datei kannst Du Dir entweder z.B. in 
den ersten vier Bytes merken oder Du gehst die Datei sequentiell durch 
und schaust, wo der erste ungültige (d.h. nur mit Nullen gefüllte) 
Eintrag steht.

> Bei einem Batteriegerät sollten eben auch bei einem AUsfall wenig Daten
> verloren gehen. Einen Tag loggen und dan Ausfall sollte nicht sein.

Ist ja auch nicht so. Das Intervall, nach dem Du jeweils die gepufferten 
Daten rausschreibst, kannst Du selbst bestimmen. Beim sd-reader gibt es 
dafür die Funktion sd_raw_sync(), ansonsten aber spätestens nach jeweils 
512 Bytes.

> Aufgabe:
>
> Kontinuierlicher Datenstrom aufzeichen (Dauerbetrieb) und bei Ausfall
> möglichst wenig Datenverlust.

Pseudocode mit dem sd-reader:

1

struct log_entry

2

{

3

    uint32_t timestamp;

4

    uint8_t gps[12]; /* size just as an example */

5

};

6

7

struct log_entry entry;

8

offset_t file_offset;

9

10

/* ... open card/partition/file ... */

11

12

/* search end of last recording */

13

while(fat_read_file(fd, &entry, sizeof(entry)) > 0)

14

{

15

    if(entry.timestamp != 0)

16

    {

17

        file_offset = -((offset_t) sizeof(entry));

18

        fat_seek_file(fd, &file_offset, FAT_SEEK_CUR);

19

        break;

20

    }

21

} 

22

23

/* main recording loop */

24

while(1)

25

{

26

    gps_receive(entry.gps, sizeof(entry.gps);

27

    entry.timestamp = clock_now();

28

29

    file_offset += fat_write_file(fd, &entry, sizeof(entry));

30

}

Die eigentliche Realisierung ist aber Deine Aufgabe.

Grüße,
Roland

kann er nicht einen ADC Pin für die Spannungsüberwachung opfern.
Ab einem gewissen Spannungspegel vor dem Spannungsregler wird halt die 
Datei geschlossen. mit einem relativ großen Puffer Elko sollte das doch 
machbar sein. Den GPS Empfänger kann er ja gleich bei erkennen 
abschalten so das nur noch die Karte und der µC kurzzeitig versorgt 
werden müssen.

GPS'ler schrieb:
> Kann mir jemand vom Gefühl oder Wissen sagen, wie groß in etwa der Elko
> für eine "letzte" Schreiboperation und schließen der Datei sein sollte?

Davon ausgehend dass hier noch 1-2 Sektoren geschrieben werden müssen 
und das durchaus mal ein paar 100ms dauern kann wenn gerade das Wear 
Leveling aktiv wird, und eine SD Karte sich beim Schreiben auch mal 
einige 10 bis 100mA gönnt, sollten es schon ein paar mF sein. 470µF 
reichen jedenfalls nicht, das habe ich schon ausprobiert.

Sowas hier sollte aber reichen:
http://www.pollin.de/shop/detail.php?pg=Ng==&a=MjEzOTg3OTk=&ts=40

GPS'ler schrieb:
> Hallo
>
> also etwa sowas
> 
===>http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=B318;GROUPID=3148;ARTICLE=19396;START=0;SORT=user;OFFSET=16;SID=31XMMj3qwQAR8AAApHlEkae535059485831c5f64f055c1b01bd7a

Nein.
Der Unterschied zwischen dem von Pollin und dem von Reichelt ist der 
Innenwiderstand:
Der von Pollin hat <100mOhm, der von Reichelt irgendwas im Bereich von 
>10 Ohm.
Letztere sind vor allem als Ersatz von Akkus in Uhren oder zum Erhalt 
von den Daten in Speichern gedacht, also auf wenig Leckstrom und geringe 
Stromentnahme optimiert.

Man könnte doch auch so Low ESR Standard Elkos nehmen wie z.B.
vom Conrad: Artikel-Nr.: 442602 - 62

Der hat 0,027-0,042 Ohm, den dann 2-3 mal parallel, also die drei mal 
(-) an Masse und die 3 mal (+) zur Schaltung.

Da könnte man dann, wenn ich mich nicht verrechnet hab, theoretisch 357 
A Max ziehen.
Oder was besser ist 400ms lang 124mA. Das sollte reichen !

Äh na ja, wenn man dann den Platz dafür hat... 18mmX36mm

Low ESR müssen die Elkos nicht haben, bei sagen wir mal 100mA macht der 
Unterschied 10mOhm oder 100mOhm keinen großen Unterschied beim 
Spannungsabfall (1mV->10mV). Ob 50 Ohm (wie bei den normalen Goldcaps) 
oder <1 Ohm bei den besseren Ultracaps (oder wie auch immer die heißen), 
dagegen schon (5V -> 0,1V).
Es reichen also normale Elkos aus, solange die ausreichend Kapazität 
haben.