mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP FFT mit hoher Auflösung!


Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alle zusammen!

Ich versuche im Rahmen einer Studienarbet einen Spektrumanalysator zu 
entwickeln.
Habe erst angefangen und bin leider absolut kein uC-Pro, aber will es 
lernen, daher habt ein wenig Nachsicht mit mir... :-)

Es geht darum ein analoges Messsignal mittels fft zu analysieren.
(Hardware noch nicht gewählt bisher habe ich freie Hand)

Mein Problem ist nun aber, dass es eigentlich 3 Messsignale gleichzeitig 
sind die der Controller aufnehmen soll UND dass das FFT Ergebnis ein 
Spektrum von 0-3000 Hz mit Schrittweite von 1 Hz für jedes der drei 
Signale ausgeben soll.
Die 3 Signale MÜSSEN zeitgleich erfasst werden, da sie bei späteren 
Analysen miteinander Verglichen werden sollen.

Kann mir jemand Tips geben was Controllerauswahl, Speicherwahl und 
Programmerstellung angeht. Die Programme die ich bisher gefunden habe, 
sind in der Auflösung leider viel zu gering. Daher wende ich mich an 
euch alle!

Danke schon mal für die Hilfe!

Grüße Ares

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleiner Nachtrag, hab mal das Seeeduino V2.12 geordert zum rumspielen. 
(ATmega168 - controller)

Autor: Sebi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da wäre vielleicht ein DSP besser geeignet oder?

Autor: mano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwar kenn ich mich mit FFT nicht perfekt aus, aber ich würde mir mal 
Gedanken über die Samplingfrequenz machen, wenn ich eine 
(kontinuierliche) FFT mit einem Frequenzspektrum bis 3 kHz und einen 
Frequenzabstand von 1 Hz haben möchte.

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aufgabenstellung ist es erst mal so zu versuchen und es mit dem 
Controller hin zu bekommen...
daher ist vorerst mal Systemrecherche angesagt und Selektion geeigneter 
Sensorik....
Wie gesagt bin noch ganz am anfang aber dachte mal ich Frag mal Leute 
die damit erfahrung haben...

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was die Samplingfrequenz betrifft so brauche ich ja mindestens eine 
Samplerate von 30 KHz je Kanal.
(mindestens: 10*(Höchste zu ermittelnde Frequenz = Samplerate)

Was ja bedeutet, dass die 3 Eingänge mit mindestens 90 KHz ausgelesen 
und die Werte gespeichert werden müssen.
Bei einem Clockspeed von 16MHz des Controllers sollte das ja wohl drin 
sein...
Oder nicht?

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> (mindestens: 10*(Höchste zu ermittelnde Frequenz = Samplerate)

2* sollte langen - Nyquist-Shannon. Bleibt trotzdem eine Herausforderung 
:-)

Autor: mano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was die Samplingfreq. betrifft, brauchst Du in der Theorie min. das 
zweifache, wie g457 geschrieben hat. Praktisch hast Du aber keinen 
unendlich steilen Tiefpass, darum kann die doppelte Freq. nicht 
unbedingt genügen.

Du möchtest ja drei Signale gleichzeitig erfassen, also brauchst Du auch 
drei ADCs und nicht einen, den man auf verschiedene Kanäle schaltet.

Bei 2048 (2**11) Samples, die mit einer Frequenz von 12 kHz abgetastet 
worden sind, komme ich auf einen Frequenzabstand von 5,859 Hz (= 1 / 
(2048 * 1/12000)  in Hz). Somit lässt sich doch schon im voraus der 
Speicherverbrauch und die Zeit zur Berechnung abschätzen. Also weitere 
Kriterien zu µC-Auswahl.

Autor: Simon D. (simon86)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nyquist-Shannon Theorem -> du musst mit mind. 6 kHz abtasten

DFT Mathematik - Schrittweite 1 Hz -> du musst das Signal 1 sec 
aufnehmen

d.h. dein Speicher muss eine Kapazität von mind. 3 mal 6000 mal ADC-Bits 
Bit haben

ADC Wandler mit 6 kHz sollte kein Problem sein, wenn diese aber wirklich 
parallel und nicht sequentiell betrieben werden soll wird es 
schwierig...

Autor: mano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon D. schrieb:
> d.h. dein Speicher muss eine Kapazität von mind. 3 mal 6000 mal ADC-Bits
> Bit haben

...fürs Sampling und nochmal min. 3 mal 6000 für die DFT, oder?

Autor: Gustav (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du nicht eine Auflösung von 1Hz benötigen würdest, würde ich dir 
einen dsPIC empfehlen.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde das ganz stark davon abhängig machen, was das Gerät am Ende 
kosten darf und wann es fertig sein soll. Zur Bitauflösung hast du auch 
noch nichts gesagt.

Wenn ich das morgen fertig haben müsste, dann würde ich ein 
Mehrkanalaudiointerface mit ASIO-Treiber an einem normalen PC verwenden. 
Am Ende braucht man für eine ordentliche Visualisierung ja auch ein 
großes Display...

Die Software kann man dann selbser entwickeln, oder aber auch etwas 
fertiges verwenden (Samplitude o.Ä.).

So hat man ohne weitere Probleme 24 Bit Auflösung und bis zu 192 kHz 
Samplingrate.


Wenn es ein aufwändiger Eigenbau werden soll, würde ich trotzdem 
AD-Wandler aus dem Audiobereich verwenden, weil diese einfach zu 
beliebiger Kanalanzahl synchronisierbar sind, eine mehr als ausreichende 
Auflösung liefern und die Samplingrate die 10-fache Überabtastung 
erfüllt.

Die CPU sollte neben genügend Arbeitsspeicher (SD-RAM) und einem I2S 
Interface auch in Echtzeit ein halbwegs vernünftiges Display ansteuern 
können, es wäre also etwas mit integriertem Framebuffer nicht schlecht. 
Da fällt mir spontan die AP7000 Serie von Atmel ein und natürlich die 
OMAP von TI.

Von der Rechenleistung her könnte der AP7000 knapp bemessen sein, der 
OMAP reicht auf jedem Fall. Beide Prozessoren sind aber nicht einfach in 
der Handhabung. Das ist aber eigentlich mit allem in dieser 
Leistungsklasse so.

Ohne das jetzt nachgerechnet zu haben, würde ich nicht unter 100 MHz 
Taktfrequenz anfangen. Damit fallen eigentlich fast alle hobbyüblichen 
Prozessoren heraus.

Wenn die Ergebnisse nicht online in Echtzeit benötigt werden, schaut das 
natürlich etwas anders aus. Dann muss man ja nur die Signale aufzeichnen 
können, dafür würde auch etwas in der Größenordnung eines ARM7 oder mit 
etwas Geschick auch ATXmega ausreichen. Es kommt nätürlich darauf an, 
wie lang die aufgezeichneten Sequenzen sind.

Grüße,

Peter

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verwendung eines Pc´s ist leider nicht möglich System soll
- kostengünstig
- klein und
- autark sein....
also auch kein Display nötig oder solche Dinge.

ansonsten soll das Sample zwischengespeichert werden mit fft 
transformiert und dann das spektrum abgelegt werden. bzw die 3 Spektren.

Autor: Alt-Student (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Spektrum von 0-3000 Hz mit Schrittweite von 1 Hz

Damit weißt du schon alles! 3000Hz sind die halbe Abtastrate =>
mit mindestens 6000Hz samplen. 1Hz Schritte bedeutet, dass du mindestens
1sec lang samplen muss. Ergo musst du mindestens 6000 Messwerte mit 6KHz
Abtastrate sammeln. Ich empfehle dir, lieber 8192 Samples mit 8192Hz zu 
sampeln. dann bleibt deine Schrittweite von 1Hz enthalten und du kannst 
bis
4,096Khz auswerten. Warum empfehle ich das: 8192 ist genau 2 hoch 13,
damit kannst du den Radix-2-Algorithmus anwenden.
Ein AT32UC3A1512 als Mikrocontroller kann die Daten zwischenspeichern.
Bei 16Bit Auflösung brauchst du 48KB, also 3/4 des RAMs.
Für zwei Kanäle habe ich das schon damit gemacht, allerdings lag meine 
Abtastrate beim 30fachen ;-).

Autor: Alt-Student (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.: Als FFT unbedingt eine 'in-place'-Implementierung des Radix-2 
nehmen, sonst hast du zuwenig Speicher!

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das Signal selber nicht schon bandbegrenzt ist, dann braucht man 
unter 8kHz Abtastrate gar nicht anzufangen. Selbst mit 8kHz wird der 
notwendige Tiefpass schon eine Qual(8.Ordnung->Aufwand). Deshalb lieber 
mit höherer Frequenz abtasten. Damit landen wir also bei einer 8K oder 
16K FFT um 1Hz aufzulösen. Oft findet man für die Prozessoren Benchmarks 
mit FFTs. Achtung, auf die Rechengenauigkeit bei diesen Angaben achten. 
Oft wird da mit lausigen 16Bit gerechnet die am Ende zu 8Bit Genauigkeit 
führen. Wenn das einigermaßen zügig gehen soll, dann nimm einen DSP oder 
einen 32Bit uP. Klasse waren ja früher die Motorola DSP56xxx 
Prozessoren(24bit). Allerdings sind die irgendwie etwas aus der Mode 
gekommen. Heute nimmt Hinz und Kunz meistens DSPs von TI.

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Signal, das gemessen wird, ist eventuell ein Rauschen. (noch nicht 
genau bekannt aber sehr wahrscheinlich ein weißes Rauschen)
Der auszuwertende Bereich ist aber eben nur bis ~3KHz das darüber ist 
uninteressant.
Kann man denn nicht einfach zwischen Sensor und AD-Umsetzer nen 
"normalen" Tiefpassfilter hängen mit ner Grenzfrequenz bei irgendwas 
bischen größer als 3KHz?

Autor: Simon L. (simon_l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

wenn man sich für einen DSP entscheidet könnte man ja den Filter digital 
machen, bzw einen einfach Tiefpass niederer Ordnung und nochmals einen 
in Software. (nur ein Denkanstoß ;) )

Gruß Simon

Autor: mkeller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ein 8biter vom Schlage des AVR ist hier denkbar ungeeignet. Besser 
geeignet sind DSPs oder Controller mit DSP Funktionen. Z.B. dsPIC 
Controller. Das sind 16bit Controller die einen breiten Multi/Dividierer 
haben usw.

Wenn du freie Wahl bei der Hardware hast, wieso machst du es dir selbst 
schwer?

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja die Vorgabe zur Verwendung des AVR kam vom Projektbetreuer....
Manchmal ist es einfach schlecht nachzufragen was man machen darf, 
anstatt einfach das Projekt durchzuziehen und dann die Leute vor 
vollendete Tatsachen zu stellen...  :-))

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie lange braucht denn eigentlich ein AVR um befehle auszuführen?
Also im konkreten Fall wenn ich 3 sensoren über ADC auslese und davor 3 
Speicherbereiche definiert habe, in denen die Werte abgelegt werden.
Dann sieh das ja so aus:

-AD1-lesen
-Zeiger auf 1. Speierbereich
-Wert speichern
-AD2-lesen
-Zeiger auf 2. Speierbereich
-Wert speichern
-AD3-lesen
-Zeiger auf 3. Speierbereich
-Wert speichern

Daran kann ich ja dann errechnen wie lange er braucht bzw ob es der AVR 
schafft dies ~6000 mal pro Sekunde zu machen.

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.:
Speicherbereich wird eine SD-Karte oder so werden müssen wegen der 
Laufzeit des Systems und der dadurch produzierten Datenmenge.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... Wie lange braucht denn eigentlich ein AVR um befehle auszuführen ...

RTFM

Autor: mano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie lange braucht der ADC?
Wie lange dauert das Schreiben auf einer SD-Karte?

Fragen über Fragen

Autor: hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ares,

was soll mit den gespeicherten Daten geschehen.
Wenn keine Anzeige in Echtzeit erfolgt würde doch
ein normaler Datenlogger reichen. Die Auswertung wird
erst dann gemacht wenn auch eine Auswertung erfolgt.
Man kann dann auch unterschiedliche Fensterfunktionen
(z.B. Hamming) auf die selben Daten anwenden.

Für so einen Datenlogger bei der Datenrate würde dann
auch der 8-Bit AVR reichen.

hans

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also nochmal anders Formuliert.
Doch zunächst mal Danke für die viele Hilfe von euch allen!!!!

Es soll eigentlich so laufen, dass die 3 Kanäle eingelesen werden und 
die Daten erst mal temporär gespeichert werden.
Danach soll die FFT (Fensterung ist nur eine Erweiterung und für 
Prototyp nicht notwendig) ausgeführt werden.
Die 3 errechneten Spektren sollen dann mit einem Zeitstempel auf der 
SD-Karte abgelegt werden.
Anschließend soll neue Messung ausgeführt werden.

Das alles so lange bis die Karte voll ist oder eben bis der Speicher 
ausgelesen wird.
Der erste Prototyp soll nur mal die Funktion haben.

Erweiterungen V-2:
-Sleep Modus
-genauere Definition des Startevents (wann wird gemessen und wie oft)
-Miniaturisierung

Zum Thema Dauer des ADC.
In der Beschreibung des ATMega168 steht drin: 13-260 us conversation 
Time
Woher weis ich dann im voraus wie lang er wirklich braucht oder variiert 
das?
Denn mit 260 wär er zu langsam. mit 13 us würds klappen.
ansonsten werde ich nach den ersten versuchen dann eher dazu tendieren 
externe ADC´s zu verwenden, da diese eigentlich besser wären. Grad wegen 
der Bearbeitungszeit...

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alles klar die ADC´s des controllers kann ich vergessen.
also die externe vatriante.
Werde jetzt einfach alle möglichkeiten mit dem ATMEGA168 ausprobieren 
bzw beleuchten und nacheinander ausschließen und dann auf höhere Systeme 
umsteigen.

Autor: Max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls es auch ohne uC sein darf - Soundkarte nehmen

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Zum Thema Dauer des ADC.
> In der Beschreibung des ATMega168 steht drin: 13-260 us conversation
> Time. Woher weis ich dann im voraus wie lang er wirklich braucht oder
> variiert das?

Im Datenblatt [1] weiterlesen, grob Kapitel 23.4 'Prescaling and 
Conversion Timing'.

HTH und HF

[1] http://atmel.com/dyn/resources/prod_documents/doc2545.pdf

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
g457 schrieb:
> Im Datenblatt [1] weiterlesen, grob Kapitel 23.4 'Prescaling and
> Conversion Timing'.

An der Stelle steht nun halt drin, dass er mit nem Clock zwischen 50 und 
200 kHz versorgt werden soll und dass er 13 clock cycles braucht um eine 
Umsetzung durchzuführen.
Also wären das ja 200kHz/13= ~15kHz
das würd ja passen. (abgesehen vom ersten mal nach dem Anschalten, da 
braucht er insgesammt 25 clocks)
oder versteh ich da grad was falsch??

Autor: Audioprofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>So hat man ohne weitere Probleme 24 Bit Auflösung und bis zu 192
>kHz Samplingrate.

Ja nee, is klar. Hast du mal die lumpigen und ungenauen FFTs der 
Audiospektralanalyzier nachgemesen? Die sind sowas von mies und taugen 
nur zum Anschauen und Schätzen - nicht zum messen.

Eine FFT mit 1Hz und 192kHz bekommt man nicht einmal mit einem FPGA in 
Echtzeit hin. Ich habe eine 16384er auf 48kHz (downsample von 96kHz) -> 
3Hz Auflösung.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab ja auch nicht gesagt, dass ich die 192 kSamples/sec direkt auf 
die FFT geben will. Ich hab nur gesagt, dass das ein relativ einfacher 
Weg ist, die analogen Signale zu digitalisieren und in den PC zu 
bekommen.
Dort muss natürlich ein Tiefpassfilter mit anschließendem Downsampling 
vor der FFT sein, sonst wäre der Rechenaufwand viel zu hoch.

Grüße,

Peter

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was könntet ihr mir denn empfehlen?
Im endeffekt gibt es ja 2 naheliegende Möglichkeiten zur Auswertung der 
FFT.

1. Berechnung der FFT mit dem Controller
2. Speicherung der Samples und Berechnung am PC.

An sich wäre es halt schön, wenn man die Daten vom Speicherchip liest 
und direkt das errechnete Spektrum hat.
Außerdem wären es weniger daten die man auf dem Chip speichern muss.

Variante 2 hätte halt den Vorteil, dass man am PC genauere und auch noch 
andere Berechnungen durchführen könnte.

Daher die Frage, sind FFT´s die man auf dem Controller berechnet 
vergleichbar mit denen am PC errechneten?
(wegen der Höheren Rechenleistung und mögliche Verwendung von 
hochwertiger Auswertesoftware, würde ich mittlerweile zu Warriante 2 
tendieren, auch wenn ich dadurch ja mindestens das 2-fache an Speicher 
brauche)

Autor: hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ares,

das ist eine Zeitfrage. Wieviel Zeit willst du in dein
Projekt investieren.

Einen Datenlogger auf SD-Karte mit einem ATMega? ist noch
relativ leicht auch für Anfänger.

Eine FFT ist deutlich aufwändiger und der ATMega ist dafür
sehr knapp. Hier wäre wohl eine andere Hardware erforderlich.

Möglich wäre z.B. auch ein XMega der über Timerevent die
3 Kanäle mit 12 Bit einliest und ablegt, die SD-Karke über
DMA beschreibt und mit dem Hauptprogramm die FFT macht und die
Daten aufbereitet.
Für dein Projekt mit ca. 1 Sekunde Messung dann Auswertung wie
gemacht.
Aber auch hier ist Erfahrung erforderlich oder muß gewonnen werden.

Ich würde daher zu 2 = PC-Lösung raten

Am PC mal mit der FFT spielen (d.h. selber machen) und wenn
dann Zeit und können Ausreichen weitersehen.

Hans

Autor: Joe Joe (j_955)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

du kannst ebenfalls durch Zeropadding deine Schrittweite fast beliebig 
erweitern, wenn du den Rechner die FFT machen lässt-das kann erganz gut, 
und du brauchst nicht auf den Speicherplatz achten, der beim Controller 
meist knapp bemessen ist....Ich glaube auch, dass die FFT am PC leichter 
zu implementieren ist..

Grüße

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also Zeit für deises Projekt wäre bia Anfang Dezember, dann sollte aller 
spätestens ein erster Prototy stehen, der dann Miniaturisiert und um 
einzelne Funktionen erweitert wird (Sleep-modus etc)

Ansonsten schau ich mich grad nach neuen controllern um.
Der Atmega168 wär zwar ok aber nur wenn ich die Auflösung auf 
4096Samples/Sekunde unterschraub.
Das zwar zwar mal ein erster Dummy werden einfach zum rumspielen 
(Programmtesting, FFT-Test, Sensortests) und dann wird das System 
erweitert.
Brauch halt erst mal was in der Hand damit wir loslegen können.

Autor: mano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ares schrieb:
> ...
> Brauch halt erst mal was in der Hand damit wir loslegen können.

Zuerst auf dem großen System, also PC + Soundkarte, dann zum kleineren 
runtergehen und die SW anpassen bzw. abspecken. Ausserdem hast Du dann 
gleich was zum Vergleichen.

Wenn ihr mehrere Personen seit, dann könnt ihr ja euch aufteilen. Die 
einen machen schon mal die FFT am PC, die anderen kümmeren sich um die 
HW und wenn beides steht, dann die Implementierung auf die HW.

Autor: FFTler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

den Vorschlag mit dem PC halte ich für sinnvoll. Ich habe es damals mit 
Matlab und einer Wandlerkarte von NI gemacht. Wenn das Equipment nicht 
vorhanden ist wird das natürlich teuer. Wie schon ein Vorredner erwähnt 
hat, ist auch eine Soundkarte geeignet.

Eine FFT ist natürlich eine willkommene Anforderung für einen DSP. Ein 
ARM-Controller ist auch bedingt geeignet, DMA sollte schon sein wenn die 
Daten verarbeitet werden sollen. Auf einem Amega läuft es bestimmt auch, 
aber er wird dann schon gut was zu rechnen haben.

Gruß

Autor: FFTler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

schau mal in diesem Buch (Signalverarbeitung mit Matlab/Simulink - 
Joseph Hoffmann / Franz Quint) ab Seite 350

http://books.google.de/books?id=q2SO6PLLdVsC&print...

Gruß

Autor: Alt-Student (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was sein größtes Problem werden wird, ist der Speicherverbrauch.
Bei den min. 6000 Samples * 2 Byte/Sample * 3 = 48KB ist nicht mehr
jeder Mittelklasse-Controller verwertbar. Die 8-Bit-AVRs scheiden
schon deshalb aus.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den neuen ATXmega kann man SD-RAM anschließen, das würde dann schon 
ausreichen. Aber die Rechenleistung genügt hinten und vorne nicht. Ein 
8-bit AVR wird schätzungsweise einige Zig Sekunden an einer einzigen 
Transformation rechnen.
Während dieser Zeit kann man auch nicht schon den nächsten Datensatz 
aufnehmen.
Man sollte mal abschätzen, wie viele FLOP für eine Transformation 
benötigt werden. Das kann man dann in Integerarithmetik gleich nochmal 
machen, weil der AVR keine FPU hat. Dabei ist zu beachten, dass der auch 
nicht wirklich Fixpunktformate kann, sondern eigentlich nur mit 
Ganzzahlen rechnen kann. Eine Implementierung mit Ganzzahlarithmetik 
stell ich mir nicht so einfach vor. Alternativ kann man die 
Floatingpointbibliothek verwenden und damit mal ansatzweise die 
Rechenzeit abschätzen.

Was ich damit sagen will: Besorg dir am besten eine CPU mit FPU, z.B. 
den TMS320F28335.

Grüße,

Peter

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle zusammen!

Also die FFT wurde vorerst mal verworfen.
Vorerst bin ich dabei passende Sensoren zu finden, die mir in der 
benötigten Geschwindigkeit Daten liefern können UND den passenden 
frequenzbereich abdecken.
Was leider den Nachteil eines erhöhten Speicherbedarfs hat.
hat zufällig jemand nen Link, unter dem man Programme findet die 
SD-Karten beschreiben und zwar NICHT in C.
Warum kein C? Weil die Sprache (laut Aussagen aus anderen Foren) zu 
langsam ist für die Frequenzanalyse. Oder stütze ich mich da auf 
falsche/schlechte Beiträge?

Ansonsten gäb es noch was. S-Karten kann man ja in 512er Blöcken 
beschreiben.
Kann man aber auch einfach einen ganzen Block mit Messdaten von 6000 
Samples * 2 Byte/Sample * 3 = 48KB beschreiben?

Grüße

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dir zu nahe zu treten liegt mir fern, aber was studierst du denn so? 
Gartenbau?

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Martin
Nein studiere ich nicht.
Aber ich habe KEINEN Draht zu Programmmiersprachen und dachte daher ich 
frag Leute die davon Ahnung haben, dass man dann solche Antworten 
bekommt ist nicht gerade ermutigend aber naja.
Und das Projekt mache ich, weil ich es lernen will, nur bin ich derzeit 
am Arbeiten und versuche nebenher so schnell und viel wie möglich dazu 
zu lernen.
Was leider nicht so klappt wie ich es mir vorstelle.
und meine "teamkollegen" sind noch weniger als nicht hilfreich, daher 
wird das wohl mein eigenes projekt und die dürfen sich was anderes 
suchen (sofern mein Prof gue laune hat und die hatte er nicht bisher, 
was aber nicht mehr mein Problem ist). Daher wurde auch die fft 
ausgegliedert und es minimal vereinfacht.

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@martin
und falls du dich wunderst, was ich neben der arbeit mache.
im moment mit Sensorherstellen in Verhandlungen stehen Sondermuster zu 
fertigen, um passende Sensorik zu erhalten.
da die Sensoren auf dem Markt entweder zu langsam, zu schlecht auflösend 
sind oder zu niederfrequente Bereiche abdecken....
und auf ne Kombilösung aus 2 verschiedenen Sensortypen will ich 
verzichten, da der Datenaufwand kaum noch zu bewältigen wäre bzw zu 
wenige Messungen durchgeführt werden können, da der speicher mit zu 
vielen daten zugemüllt wird.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SD-Karten kann man selbstverständlich auch ohne Dateisystem direkt 
Blockweise beschreiben. Das geht sogar erheblich schneller, wenn die 
Rechenleistung knapp ist. Nur auskennen muss man sich da drauf noch, 
eventuell auch noch nach mehreren Aufnahmen, man sollte also eine gute 
Strategie haben, wodurch man weiß, welche Daten was sind.

Und bei SD-Karten natürlich mit der maximalen Schreibzyklenzahl 
aufpassen, man kann einen Sektor nicht beliebig oft beschreiben. Man 
sollte es also vermeiden, bestimmte Sektoren oft hintereinander zu 
schreiben (z.B. wegen Indextabellen, die sich ständig ändern). Aber 
ansonsten ist das kein Problem, die Daten auf eine SD-Karte zu 
speichern. Ob das nun in C, Assembler oder einer anderen Sprache gemacht 
ist, ist primär zunächst unwichtig, solange du die sourcen kompilieren 
kannst und die Datenrate am Ende ausreicht. Für viele open-source FAT 
Treiber sind für übliche Prozessoren die Datenraten, die im Schreiben 
und Lesen erreicht worden sind, angegeben.

Angenommen, es gibt 3 Kanäle 6000 Samples pro Sekunde mit je 16 Bit 
Auflösung, dann sind 36 kB pro Sekunde zu speichern. Mit einem guten FAT 
Treiber ist das kein Problem, wenn doch dann geht es auf jeden Fall, 
wenn man die Karte ohne FAT betreibt.

Um welche Sensoren geht es denn eigentlich?

Grüße,

Peter

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sensoren die Beschleunigungen im Bereich von 0-3000 Hz detektieren 
können.
Problem ist, dass viele einen integrierten Teifpass bei 50 Hz haben oder 
eben eine schlechte Auflösung (Messbereich von +-600 g [g= 
Erdbeschleunigung NICHT GRAMM] und 3LSB/g)
Oder, dass sie zu teuer sind (z.B.:  www.pcb.com über 1000 Euro je 
Sensor und die Auswerteelektronik der Piezos ist auch nicht grad 
günstig)

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einem ADXL330?

Hier stellt man die Grenzfrequenz über einen externen Kondensator ein, 
wenn dieser klein genug ist, könnte es bis 3 kHz funktionieren. Der 
Sensor arbeitet intern mit 50 kHz, der Kondensator soll diese filtern. 
Mit den vorgeschlagenen Werten kommt man laut Datenblatt bis 1,6 kHz. 
Das ist dann die 3dB Eckfrequenz.

Ich würde versuchen, den Kondensator wegzulassen, oder zumindest noch 
wesentlich kleiner als 10 nF zu wählen und dafür danach ein 
steilflankigeres Analogfilter einsetzen.

Wenn man dazu noch eine frequnzabhängige Kalibrierung vornimmt, sollte 
das schon gehen. Dazu braucht man einen Vibrationsprüfstand, der 
definierte Beschleunigungen einer bestimmten Frequenz erzeugen kann.

Der Sensor macht +- 3g und hätte bei 3 kHz Bandbreite einen RMS 
Rauschpegel von etwa 0,02 g. Es handelt sich dabei um weißes Rauschen, 
die Messung ist bei den hohen Frequenzen also nicht ungenauer als bei 
den niedrigen.


Grüße,

Peter

Autor: mano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Diener schrieb:
> Wie wäre es mit einem ADXL330?

Das ist aber ein Beschleunigungssensor der ein 
mikro-elektro-mechanisches System (MEMS) enthält, also kein 
piezoelektischer Beschleunigungssensor.

In meiner alten Arbeitet haben wir Erschütterungen von der Straßenbahn, 
U- & S-Bahn, Abbrucharbeiten usw. gemessen. Allerdings war unsere 
Grenzfrequenz weit unter 3 kHz, eher so um die 100 Hz rum. Die Sensoren 
stammten von Brüel & Kjær, die passenden Verstärker ebenso. Die Sensoren 
mit einer Elektronik drinnen, haben den großen Vorteil, dass der Aufbau 
leichter ist (Elektronik bedeutet, dass ein Ladungsverstärker gleich 
drinnen ist). Die Verarbeitung der gewonnen Daten erfolgte natürlich am 
PC. Die Beschleunigung war idR. gar nicht interessant, sonder die 
Geschwindigkeit. Darum hatten wir bei einen Fall auch gleich einen 
Integrationsverstärker verwendet.

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter
der ADXL330 klingt nicht schlecht, aber sein Messbereich ist wieder zu 
klein.
uns schwebt was im bereich von +-80g vor um auch größere Peaks 
abzudenken aber danke für die Info.

@mano
es muss kein Piezo-Sensor sein, das war nur ein Beispiel. generell ist 
es egal was für ein Sensor es ist, solange die Grenzfrequenz über den 
3000 Hz liegt.

Prüfstand und passende Messtechnik um das System zu Validieren ist alles 
vorhanden

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.: Beim ADXL330 ist der Temperaturbereich zu klein. brauch was, dass 
zwischen-40° und (am besten) +150° noch funktioniert

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann eben drei mal den ADXL001:

+-70g Vollaussteuerung bei 22kHz Bandbreite, Temperaturbereich -40°C bis 
+125°C.

Alles über 125°C ist eigentlich nicht mehr machbar, solange da 
Elektronik drin ist, da gehen dann nur noch passive (dynamische oder 
piezoelektrische) Sensoren. Die können aber keine Gleichanteile messen.

Warum muss der Sensor in so heißen Bereichen eingesetzt werden? Kann man 
den nicht kühlen?

Grüße,

Peter

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Kühlung wäre eine Idee, diese wären evneutell auch im Labor 
realisierbar.
Aber eben nicht bei Tests unter Realbedingungen...also draußen...
Geht nicht durch den Verwendungsort der Sensorik.

aber Danke für die Hilfe!

Autor: Ares (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem ADXL001 lassen sich immerhin mal problemlos X und Y Achse 
Messen.
In Z-richtung (vertikal) müsste man eine seperate Platine fertigen, die 
man senkrecht zur Hauptplatine aufbaut.

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.