Hallo, anbei ein simpler Audiologger. Alle Daten sollten im Anhang vorhanden sein. Ach ja, das Ganze befindet sich noch in der heißen Frickelphase.
Angehängte Dateien:
-
AL_Alles_Oben1K.JPG
190 KB
:
Verschoben durch Admin
>Ach ja, das Ganze befindet sich noch in der heißen Frickelphase.
Mit einem ATMega8 wirst du da auch nie rauskommen;)
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"
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.
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.
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.