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
Kleiner Nachtrag, hab mal das Seeeduino V2.12 geordert zum rumspielen. (ATmega168 - controller)
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.
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...
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?
> (mindestens: 10*(Höchste zu ermittelnde Frequenz = Samplerate)
2* sollte langen - Nyquist-Shannon. Bleibt trotzdem eine Herausforderung
:-)
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.
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...
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?
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
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.
>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 ;-).
P.S.: Als FFT unbedingt eine 'in-place'-Implementierung des Radix-2 nehmen, sonst hast du zuwenig Speicher!
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.
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?
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
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?
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... :-))
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.
P.S.: Speicherbereich wird eine SD-Karte oder so werden müssen wegen der Laufzeit des Systems und der dadurch produzierten Datenmenge.
Wie lange braucht der ADC? Wie lange dauert das Schreiben auf einer SD-Karte? Fragen über Fragen
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
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...
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.
> 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
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??
>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.
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
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)
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
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
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.
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.
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ß
Hi, schau mal in diesem Buch (Signalverarbeitung mit Matlab/Simulink - Joseph Hoffmann / Franz Quint) ab Seite 350 http://books.google.de/books?id=q2SO6PLLdVsC&printsec=frontcover&dq=Quint+Hoffmann&hl=de&ei=C9ZjTOH4K5D34Abu_eitCg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CCwQ6AEwAA#v=onepage&q=fft&f=false Gruß
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.
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
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
Dir zu nahe zu treten liegt mir fern, aber was studierst du denn so? Gartenbau?
@ 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.
@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.
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
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)
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
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.
@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
P.S.: Beim ADXL330 ist der Temperaturbereich zu klein. brauch was, dass zwischen-40° und (am besten) +150° noch funktioniert
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
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!
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.
Bitte 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.