www.mikrocontroller.net

Forum: Projekte & Code Wochenendgefrickel: AudioLogger ATMEGA8+SD-Karte


Autor: Buzzwang (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
anbei ein simpler Audiologger. Alle Daten sollten im Anhang vorhanden 
sein. Ach ja, das Ganze befindet sich noch in der heißen Frickelphase.

: Verschoben durch Admin
Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ach ja, das Ganze befindet sich noch in der heißen Frickelphase.

Mit einem ATMega8 wirst du da auch nie rauskommen;)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An sich schon cool, aber ich würde einen Controller mit SRAM-Interface 
nehmen und erstmal das FAT ´rausschmeissen und nativ auf die Karte 
schreiben, dann wird das Ganze auch fit für die Audiodaten. Alternativ 
könnte man statt der SD-Karte ein großes DataFlash nehmen. Diese haben 
SRAM-Buffer eingebaut, die wechselseitig gefüllt werden können, ohne auf 
die Flash-Zeit warten zu müssen. Hat man natürlich weniger Speicher, 
64MBit momentan verfügbar, aber weitaus bessere Quali.

Ein ähnliches Projekt aber mit etwas mehr Aufwand:
Beitrag "SD-Karten-Wave-Recorder"

Autor: Buzzwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

=>Knut:
Dein Projekt war mir zuvor bekannt. Das kann man natürlich nicht mit 
meiner Frickelei vergleichen. Da liegen Welten dazwischen.

Ich wollte schnell was haben, das in Hosentasche passt und auf 
Lochraster hat man da nicht so viele Möglichkeiten.

Ich habe mir noch übelegt den ATTINY zu nehmen, da der schon einen 20x 
Verstärker drin hat. Jedoch wollte ich noch die RS232 für Debuggen 
haben. Deshalb dann der ATMEGA8.

=>FAT:
Pro
1. Ich benutze den internen AD-Wandler vom AVR. Damit erreiche ich 
(trotz Übertaktung) nur ca. 17kByte/s. Das sollte FAT nicht der Engpass 
sein.
2. Wie dann die Daten wieder auf den PC bringen ? Mit FAT ist das 
einfach. Würde ich direkt aufnehmen, müsste ich die Date via RS232 
zurückspielen. Bei meinen 80MB Files würde das etwas länger dauern.
3. Das FAT gab es komplett fertig.

Contra:
1. Ich den Grund für mein 34Hz Rauschen gefunden. Der FAT-Treiber hat 
einen 512 Byte Puffer (entspr. 1 Sektor). Wenn der voll ist, dann wird 
der Puffer auf einmal die SD-Karte geschrieben. Also bei 512 / 17000 = 
30ms => 33Hz. Das erzeugt dann jedesmal ein Burst im System.

Autor: Mike J. (linuxmint_user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Buzzwang,
das Projekt ist gut dokumentiert.

Zu dem Problem:
Du kannst AVCC und AGND durch zwei Tiefpässe entstören (LC-Tiefpass) und 
eine extra analoge Massefläche erstellen.
Ich trenne die beiden (VCC/AVCC , GND/AGND) jedenfalls immer, bei dir 
sind sie verbunden.

Man könnte vielleicht ganz dicht an den VCC und GND Pins des AVR einen 
großen SMD Keramik-Vielschicht Kondensator anlöten und eben an AVCC und 
AGND auch :)

Die SD-Karte kann über einen 3.3V Festspannungsregler (wieder mit Kerko 
dahinter) versorgt werden.

Bei nur 8MHz kannst du den AVR ebenfalls mit den 3.3V versorgen.
Weil:
Der ATmega8 läuft mit 12MHz und 2.55V gerade an (wurde getestet) aber 
man muss ihn mit mindestens 2.7V betreiben damit die 2.56V 
Referenzspannung aufgebaut werden kann.

... ich mach mal eine SMD-Layout, allerdings mit zwei LM358 anstatt des 
LMC6494.

Das Rauschen bekomme ich auf alle Fälle weg, so dass man selbst mit 10 
oder 12 Bit auflösen könnte und kein Rauschen zu erkennen ist.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Buzzwang schrieb:
> =>FAT:
> Pro
> 1. Ich benutze den internen AD-Wandler vom AVR. Damit erreiche ich
> (trotz Übertaktung) nur ca. 17kByte/s. Das sollte FAT nicht der Engpass
> sein.

Naja... Das Problem ist der kleine Puffer und dass Du dann nicht stetig 
den Multiblock-Modus bei der SD fahren kannst. Das ergibt mehr oder 
minder zufällige Drops.

> 2. Wie dann die Daten wieder auf den PC bringen ? Mit FAT ist das
> einfach. Würde ich direkt aufnehmen, müsste ich die Date via RS232
> zurückspielen. Bei meinen 80MB Files würde das etwas länger dauern.

Dafür nehme ich z.B. einen Diskmonitor. Da die Sounddaten linear 
gespeichert werden, kann man die Blöcke markieren und als Datei 
abspeichern.

> 3. Das FAT gab es komplett fertig.

OK.

Buzzwang schrieb:
> 1. Ich den Grund für mein 34Hz Rauschen gefunden. Der FAT-Treiber hat
> einen 512 Byte Puffer (entspr. 1 Sektor). Wenn der voll ist, dann wird
> der Puffer auf einmal die SD-Karte geschrieben. Also bei 512 / 17000 =
> 30ms => 33Hz. Das erzeugt dann jedesmal ein Burst im System.

Das passiert Dir aber auch ohne FAT. Du brauchst zwingend einen 
Daten-Ringpuffer, der ein Vielfaches der Sektorgröße beträgt und in den 
Du schreiben kannst, während die Karte beschrieben wird. In Experimenten 
habe ich mindestens 64k Puffer ermittelt, um sämtliche Karten 
störungsfrei schreiben zu können. Auch wenn im Durchschnitt die Daten 
sehr schnell abgenommen werden (Multiblock-Modus), kommt es durch das 
Wear Levelling zu unkontrollierten Busy-Zeiten von bis zu 200ms.

Autor: Buzzwang (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Update:
  - Hardware noch das alte Konzept. Jedoch etwas daran rumgelötet
    (siehe history)
  - Aufgerüstet auf ATMEGA816
  - Aufnahme-Qualität jetzt ganz ok. Besser als wie mein Handy.
  - SW im Anhang

History:
// 29.04.2011: 0xFF - Fehler lag an Hardware. Das Poti-Gehaeuse hatte 
leichten
//             Kontakt zu einem der OP-Pins, was unter unguenstigen 
Faellen zu
//             einem Kurzschluss fuehrte und den Ausgang des 
Mikrophon-Verstaerkers
//             auf 5V setzte.
//             Der ADC wandelt im Moment mit ca. 17kHz. Der Fifo ist nie 
voller
//             als 1Byte, sollte also noch Luft nach oben haben.
//             17kHz x 8Bit macht ca. 1MB/s
//                Program:    9884 bytes (60.3% Full)
//                Data:        859 bytes (83.9% Full)
//             Bestehende Probleme und Todos:
//               -  17kHz sollten theoretisch aber 19kHz sein
//                  Irgendwie fehlt da noch was
//               -  Testcode (z.B. fuer die serielle Schnittstelle) 
koennte wieder
//                  entfernt werden
//               -  Am Ende der Aufnahme wird die zuletzt gemesse 
Sampling-Rate
//                  in den Wave-Header geschrieben. Es kann vorkommen, 
dass der
//                  letzte Sampling-Rate-Messwert durch das Stoppen der 
Messung
//                  verfaelscht wird und deshalb ein falscher Wert in 
den Wave-
//                  Header geschrieben wird.
//
// 25.04.2011: Init-Record in Start-Record verschoben, sonst ging es 
nicht mehr
//             nachdem man die SD-Karte gewechselt hat.
//
//
// 24.04.2011: Noch einen Fehler im Wave-Header repariert
//             Bei längeren Aufnahmen kommte es vor, dass ab einem 
Zeitpunkt
//             nur noch 0xff aufgenommen wird. Grund noch unbekannt.
//                Program:    9866 bytes (60.3% Full)
//                Data:        873 bytes (85.3% Full)
//
// 22.04.2011: Auf dem Target gabe es immer Probleme mit der 
SPI-Kommunikation
//             Nach ziemlich langer Suche herausgefunden, dass es am 
MISO Pin lag
//             Daher noch 2 Widerstaend (180k) an MISO und CS gegen 5V 
eingebaut
//             Den Kondensator am Reset-Pin aufgemacht, damit der Dragon 
tut
//             Fuer Ueberwachungszwecke wieder serielle Schnittstelle 
aktiviert
//                Program:    9878 bytes (60.3% Full)
//                Data:        873 bytes (85.3% Full)
//
//
// 11.04.2011: Geaendert, damit direkt im Wav - Format geschrieben wird
//
//
// 08.04.2011: Neuste LIB geholt => 0.6.3_fix
//
//
// 02.02.2011: In Zwischenzeit ist mir die SD-Karte beim Testen 
gestorben.
//             Als ich mir eine Neue besorgt habe, habe ich gleich noch 
einen
//             AVR Dragon und ein paar ATMEGA168 mit bestellt. Nun kann 
ich auch
//             debuggen und besser testen
//             Beim Test folgende Fehler Probleme bzw. korrigiert.
//             - Einige Registernamen haben sich vom ATMEAG8 zum 
ATMEGA16 geändert
//             - Das Auslesen des 1. Sektors hat nicht mehr getan. 
Herausgefunden,
//               dass es an der Warteschleife liegt. Geändert tut nun
//             - Schreibtest gemacht. Ca. 1337182 Bytes in 61s 
draufgekriegt
//                                           => ca. 21kB/s
//             - Dementsprechend lohnt es sich auch nicht mit 500khz 
(ca. 40kS/s) aufzuzeichnen
//             - 250khz (ca. 20kS/s) aufzuzeichnen tut auch nur wenn der 
code mit Optimierung
//               übersetzt wird. Sonst wird der Fifo schneller gefüllt, 
als wie er geleert wird
//                     => Dead Lock
//             - eine Möglichkeit wäre es noch mit 500kHz Oversampling 
zu betreiben. Das lasse ich aber
//               erstmal sein.
//
//
//
// 11.10.2010: Mal probiert was passiert wenn man den ADC auf 500kHz 
quaelen tut.
//             Jumper-Abfrage hinzugefügt. Werden beide Jumper entfernt, 
wir die
//             Aufzeichnung gestoppt.
//
//
// 10.10.2010: Rauschen kommt vom SD-Karten schreiben. Der FAT-Treiber 
hat
//             einen 512 Byte Puffer (entspr. 1 Sektor). Wenn der voll 
ist,
//             dann wird der Puffer auf einmal in die SD-Karte 
geschrieben.
//             Also bei 512 / 17000 = 30ms => 33Hz. Das erzeugt dann 
jedesmal
//             ein Burst im System.
//              => SD-Karte schreiben aus der ADC-INT-Routine 
rausgenommen
//                 und in die main()-Hauptschleife gepackt.
//                 fifo zur Datenübertragung angelegt
//
// 05.09.2010: Erste Version. Noch unbekanntes 34 Hz rauschen auf der 
Karte


///
//  Programm: Aufzeichnung einer festen Dauer von (ca. 75min).
//            Aufzeichnung startet nach Anschluss der Akku bzw. 
Einschalten und
//            beide Jumper gesetzt sind
//            Stoppt, wenn beide Jumper gezogen sind
//            Faengt, wieder von vorne an, wenn beide Jumper gesetzt 
sind
//
//            Jumper gezogen => 5V
//            Jumper gesetzt => 0V
//
//            LED blinkt bei Aufnahme etwas schneller (5Hz sonst 0,5Hz)
//
//            Jumper2 an  PC.4
//            Jumper1 an  PC.3
//            LED      an PC.2
//            AnalogIn an PC.0

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.