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
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?
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 ;-).
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.
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ß
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
@ 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
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.
