Sehr geehrte Forummitglieder,
für ein Projekt benötige ich ein DSP zur Bearbeitung und Analyse (FFT)
eines Signales von einem Beschleunigungssensor. Ich bin in diesem Gebiet
noch neu und bitte etwas um Verständnis. Für die Realisierung meines
Projektes suche ich ein DSP mit eingebauten Analog Digital Umsetzer mit
einer Auflösung von min. 16 Bit und einer Abtastrate von min. 100kSPS.
Gibt es solche DSP Boards mit den genannten Anforderungen ?!
Ich bin für jeden Tipp sehr dankbar.
mfGruß,
opcode
Moin,
ich fand das damals hier zum Starten gut:
http://docs.blackfin.uclinux.org/doku.php?id=netscope
Ist halt schon etwas älter.
Allerdings würde ich mich heutzutage nicht mehr nur auf DSPs fixieren,
ein typischer ARM wie der STM32F kann das was du willst längst auch
schon und ist ev. etwas billiger. Der Knackpunkt ist ev. eher, das
Evalboard zu finden, auf dem sich der passende ADC befindet.
Ich weiss sonst einen, der genau sowas schon gemacht hat und dir ev.
weiterhelfen kann.
Welchen Beschleunigungssensor musst du denn mit 100kSPs abtasten? Die
MEMs hören doch eh bei 1,6kHz auf. Wenn du den mit 5kSPs abtastest und
deine FFT machst, kommst du doch immer noch bis 2,5kHz.
Ein Cortex-M4 mit FPU und DSP-Fähigkeiten reicht da schon. Meist
allerdings nur mit 12-Bit ADC. Bei Freescale gibt es die Kinetis Cortex
M4 als einzige mir bekannte ARM Controller mit 16Bit ADC. Wenn sein muß
kannst du auch 3 ADCs parallel mit 1MSPs laufen lassen. Aber wie gesagt,
wahrscheinlich brauchst du das einfach nicht und du solltest nochmal
deine Anforderungen überdenken.
Hallo Rene,
wenn man auch Stoßmessungen durchführen möchte, tauchen höhere
Frequenzen als nur 1.6kHz im Signal auf. Daher muss ich höher Abtasten,
da ich minimal bis 20kHz messen möchte.
mfGruß,
opcode
20kHz ist doch mal ne Zahl. Da kannst du dich vor nem DSP drücken und
fährst mit nem ARM ganz gut.
Mit den 32kHz hast du nicht zufällig die KX??-Dinger gemeint oder?
Samplerate ist bei denen zwar 32kHz/34Khz, aber die Bandbreite ist
wesentlich geringer (ich meine sogar nur 400 oder 50Hz). Schau dir mal
ganz genau das DB deines Sensors an.
Gibs uns doch mal Anhaltspunkte zu Sensor und Anwendung, sonst bleibt
das ein munteres Ratespiel. Du kannst es natürlich auch von vornherein
over-engineern.
Hallo Rene,
ich verwende den MEMS Sensor ADXL001 von Analog Devives. Dieser hat eine
Resonanzfrequenz bei 22kHz und die -3dB Grenze bei 32kHz. Das
Ausgangssignal ist analog, also eine Spannung proportional zur
Beschleunigung. Ich habe bis jetzt immer piezoelektrische
Beschleunigungsaufnehmer wie z.B. von Brüel&Kjaer 4507 verwendet. Diese
sind vom ICP Typ und geben direkt eine Spannung aus (keine Ladung!).
Diese Sensoren habe ich immer mit der maximalen Abtastrate abgetastet,
um so viel Informationen zu bekommen wie es geht. Natürlich hängt das
auch immer von der Messdauer ab. Wie dem auch sei; kann ich diesen
ADXL001 nicht genau so verwenden ? Ich meine dieser hat ja auch ein
analoges Ausgangssignal und kann laut Datenblatt bis zu 32kHz messen.
Wenn man die Resonanzfrequenz beachtet, wären dann c.a. 20kHz drin.
Somit müsste ich nach Shanon Theorem mind. mit 40kHz abtastet. Aber eine
dreifache bis vierfache Sicherheit kann nicht schaden, so dass man mit
80kHz bis 100kHz abtastet um das Signal soweit wie es geht genau zu
erfassen. Mir ist bewusst, dass je höher die Abtastrate ist, desto mehr
Daten zu bearbeiten sind und die FFT länger dauern kann, aber die
Messung musst nicht ständig "live" geschehen sondern kann schon in sagen
wir mal einigen Minuten Abständen erfolgen.
Kann ich dies auch alles mit einem ARM Board mit eingebauten ADC
erledigen ?! Bei der A/D Umsetzung dachte ich eigl an 24 Bit Delta Sigma
ADC, aber das ist wohl nicht drin oder ?!
mfGruß,
opcode
PS: Die meisten MEMS Sensoren haben einen eingebauten 2 poligen
Besserfilter und diese sind meistens bis 400 Hz begrenzt...
Der ADXL001 ist der einzige Sensor von Analog Devices der überhaupt eine
etwas höhere Frequenzbandbreite hat.
Verpass dem Ausgang des ADXL001 mal einen RC-Filter für 22kHz und schau
dir den Ausgang mal in Ruhe am Oszi an.
Für den RMS-Wert des Rauschens gibt es einen Zusammenhang aus Bandbreite
und max. Beschleunigung die zusammen mit einem sqrt/Hz-Wert aus dem
Datenblatt geworfen werden. Das Grundrauschen macht jede 24Bit oder auch
nur 16Bit-Wandlung denkbar überflüssig.
Ja, der ADXL001 hat tatsächlich die mit Abstand größte Bandbreite der
Beschleunigungssensoren, allerdings ist die kleinste Variante auch bei
70g angesiedelt. Wenn du damit Inertialnavigation machen möchtest, dann
wird das auf jeden Fall sehr spaßig.
Sag doch mal was zu den Anforderungen und was du da machen sollst. Ist
das Forschung an der Uni?
Ich möchte damit keine Inertialnavigation erzielen.
Danke für deine Informationen. Mir fehlt wirklich leider das
Wissen/Erfahrung, aber möchte mich dennoch in das Projekt
"reinschmeißen".
Bei Fragen würde ich mir gerne nochmal hier melden.
Vielen Dank
mfGruß,
opcode
An meiner alten HS war ein Prof. der sich für alles mögliche rund um INS
beschäftigt hat und praktisch alles was man so mit MEMs anstellen kann.
Allerdings würde ich ungern selbst schreiben auf welcher HS ich war.
Mein Vorname und Anfangsbuchstabe des Nachnamens sind mir hier schon
öffentliche Information genug :-)
Wäre halt witzig, wenn du an der gleichen oder einer Partner-HS
unterwegs bist.
Naja ist auch nicht so wichtig, aber lass dich mal nicht von anderen
einschüchtern, die sich selbst aufs hohe Ross heben...
Wie gesagt schnapp dir mal ein Oszi, am besten mit eingebauter FFT und
schätze mal auf Grundlage dieser Daten deine Anforderungen ab.
Hi opcode,
>> vielen Dank für dein Post. Kann ich diejenige Person kontaktieren, die> du kennst ?!>
Ist eingeleitet, er wird sich vermutlich hier melden, wenn er die Zeit
hat :-)
Ansonsten guck dir mal den BlackfinBF506F (ADC eingebaut) als
single-chip-Lösung an, könnte sein, dass Du da auch relativ gut ein
Evalkit kriegen kannst über die FH.
Grüsse,
- Strubi
@Rene:
Danke :-). Sobald die Sensoren da sind, werde ich erst mit den Sensoren
"spielen" d.h. Vergleichsmessungen mit "richtigen"
Beschleunigungssensoren machen wie z.B. die von B&K oder Endevco. Ein
Oszi habe ich natürlich auch da
@Strubi:
Danke für deine Unterstützung :-).
mfGruß und einen schönen Abend,
opcode
Es ist doch unklug sich wegen dem A/D Wandler bei der Wahl des DSPs so
einzuschränken und am Ende bei gelogenen 12bit zu landen. Es gibt echte
16bit ADCs im 10pin SOIC Gehäuse.
Guten Abend nochmal,
ich habe nun sehr viel recherchiert und bin etwas durcheinander. Texas
Instruments und Analog Devices bieten ja viele DSP Eval Boards wie z.B.
der von Strubbi erwähnte BlackFin Processor Eval Board. Brauche ich zum
Programmieren dieses Board noch zusatz Hardware wie z.B. bei den AVR ein
ISP Programmer oder kann ich direkt von PC aus über USB diese Eval
Boards programmieren ?! JTAG benötige ich nur zum Debuggen auf dem
Prozessor stimmts ?!
Würde mich über jede Antwort sehr freuen.
mfGruß,
opcode
Hi opcode,
Bei den EZKITs ist der JTAG mit drauf, tut allerdings fast ausnahmslos
nur mit VisualDSP++ und nicht mit der deutlich billigeren (kostenlosen
:-) ) GNU alternative. Für die brauchst Du dann wieder einen extra ICE.
Das ist ansich bescheuert, aber liegt halt daran, dass sich jede
"Arbeitsgruppe" ihre Entwicklung irgendwie bezahlen lassen muss.
Gibt da hier einige Threads.
Z.B. Beitrag "Blackfin GCC - Standalone!", oder mal Suchfunktion
anschmeissen.
Fürs Evalkit würde ich mit der VDSP-Evaluationsversion (90 tage bzw.
Codegrösse-Limite) anfangen.
Auf der Texas Instruments-Seite sind die Tools erst mal billiger, die
Kosten laufen ev. eher etwas später auf.
Würde mir auf jeden Fall auch einige ARMs unter die Lupe nehmen, da sind
die Tools und JTAG-Debugger (OpenOCD) meist am billigsten in der
Entwicklung und die Performance meist ausreichend.
Die Algorithmen kannst du meist schon im Simulator (skyeye, oder
gdb-Simulator, qemu, etc.) evaluieren.
Grüsse,
- Strubi
P.S. Der Kollege hatte sich wohl noch nicht gemeldet. Ich pinge ihn
beizeiten nochmal an.
Hallo Strubi,
danke für deine schnelle Rückmeldung. Ich habe auch nach ARMS gesucht
und viele gefunden, jedoch sind mir so einige Fragen unklar wie z.B. ob
man die so direkt programmieren quasi per USB...
Ich habe mir mal die ARM Cortex-M4 von ST angeschaut:
z.B.: STM32373C-EVAL
Diese Eval Boards sind ja mit eingebauten Temperatursensoren etc.. zum
testen ausgestattet, die ja an die ADC Eingänge verbunden sind. Kann ich
dennoch eigene Sensoren anschliessen oder bin ich nur beschränkt mit den
Sensoren die dran sind ?! Wenn ja, muss man ja diese Verbindungen ja
selber lösen, wenn das überhaupt geht.
Hast du welche ARM Eval Boards, die du mir empfehlen könntest ?
PS: Gibt es bei den BlackFin BF506 Eval Board keine Möglichkeit, die
Codegrößen-Begrenzung zu umgehen ?! Sind es 4 Kybte die mir zum
Programmieren übrig bleiben ?!
mfGruß,
opcode
@Strubi:
Meinst du ich wäre mit dem BlackFin BF506 Eval Board gut dran ? Kann ich
wirklich mit 2MSPS abtasten, wie es steht ? Also wird das Signal mit
2MPSP abgetastet und sofort in den RAM geschoben ?!
Zweite Frage: Die Beschränkung des Code Speichers auf 1/4 wird doch
hauptsächlich nur von VisualDSP++ verursacht oder tritt dann auch eine
"hardware" seitige Sperre ein ?!
mfGruß,
opcode
Hi opcode,
guck mal nach dem STM32F407xx discovery board, ich hatte mal so eins in
den Fingern, das liess sich prima per USB programmieren (hatte stlink
unter Linux benutzt).
Die on-chip ADCs können halt meist nich mehr als 12 bit, wenn du 16 bit
willst, musst du meist was externes ranbacken und furchtbar auf die
Analog-Kette achten, sonst hast Du von deinen 16 bit nicht viel an
Signalqualität :-)
Ansonsten würde ich mir erst eins der billigeren ARM-STM-Dinger besorgen
und ruhig mal einen der aufgeklebten Sensoren runterlöten, die Dinger
sind zum "hacken" da.
Zum Blackfin: Das durchdachte an den Chip ist, dass er wirklich alle
Daten von der Peripherie auch ins RAM kriegt (nicht so
selbstverständlich). Stichwort DMA, beim Blackfin lassen sich
Deskriptoren so verketten, dass keine Interrupts zum Neuinitialisieren
notwendig sind.
Zur Beschränkung: Die ist auf jeden Fall nur softwareseitig, und kann
man 'ganz einfach' (was relativ zu sehen ist :-) ) mit dem Gnu-Compiler
umgehen. Nervig ist nur, dass ADI den ELF-Standard derart verstümmelt
hat, dass man die Tools nicht kombinieren kann. Ansonsten solltest du
20kB Code generieren können. Es gibt auch noch die Möglichkeit einer
Test-Lizenz für 90 Tage.
Ehrlich gesagt: Zum Anfangen ist der Blackfin ein harter Keks, aber hat
man ihn mal begriffen, lässt er einen kaum im Stich. Mit den
ARM-Cortex-M3 kommst du schneller und günstiger ans Ziel, aber mit der
Performance kann's u.U. eng werden.
Musst Du einfach ausprobieren..
Grüsse,
- Strubi
Guten Abend Strubi,
vielleicht kaufe ich erstmal dieses STM32F407xx discovery board.... um
den Preis mache ich mir nicht so viel Gedanken, da es sowieso die
Hochschule zahlen wird :-P.... aber die Zeit wird knapp. Wenn die
Performance nicht reicht, kann man ja noch immer auf den BlackFin
umsteigen.
Vielen Vielen Dank für deine Hilfe ! Vielleicht kann ich dir in diesem
Thread im Laufe der Zeit noch einige andere Fragen stellen :)
Wünsche dir eine gute Nacht.
mfGruß,
opcode
Ok, bitte meinen vorherigen Post ignorierer.. das ist ja alles Paradox
was da steht...
Die Zeit wird langsam knapp, aber ich versuch dennoch das Discovery
Board, weil ich die Kosten niedrig halten werde.. ob es am Ende reicht
oder nicht, kann man ja sehen.. das Projekt wird nicht mit dem Ziel: "Es
muss funktionieren" gesehen, sondern: "Schauen wir mal, ob wir es
schaffen".
mfGruß,
opcode
Wie wäre es mit einen Beagle Bone oder XM?
Brauchst dann halt einer externen ADC. Aber der XM hat ja einen
schnellen DSP mit integriert. Da kann man gleich ein Monitor für die
Visualisierung anschließen.
Moin,
den OMAP oder Raspberry usw. würde ich für sowas nicht nehmen, das
verkompliziert die Sache nur sinnlos, wegen der inhomogenen Architektur
(ARM+proprietäre Tools für DSP). Bis man den DSP angesteuert hat und die
Daten sauber in den Linux-Userspace bekommen hat, hat man's auf dem
Discovery vermutlich schon fertig.
Alles was mit embedded Linux zu tun hat würde ich bei der Ausgabe erst
mal ausklammern und die Sache "standalone" realisieren (auf dem OMAP
ohne teures ICE kein Spass), sonst tauchen schnell nervige Hürden auf,
die mit dem eigentlichen Ziel nix mehr zu tun haben. Mit einer Ausnahme:
Wenn es eine fertige, dokumentierte Referenzanwendung gibt, die auch
wirklich gut auf Treiberseite funktioniert.
Das gute an FH-Projekten ist ja der obengenannte Aspekt "Schauen wir
mal, ob wir es schaffen". Die Einstellung finde ich gut.
Als Referenzprojekt betr. Beschleunigungsmessung und 'fliegendes Linux':
noch einen Link:
http://rocketware.othello.ch/
Der fliegende Linux-Ansatz war aber mehr als mutig (und erforderte einen
ziemlichen Biss), die Jungs waren 3 Monate dran. Manche Doktoranden
brauchen für sowas 3 Jahre :-)
Grüsse,
- Strubi
Guten Tag Strubi,
ich werde nun das Discovery Board bestellen und daraus das Beste
versuchen.
Danke.
Auch wenn zu früh: Ich wünsche schöne und besinnliche Feiertage.
mfGruß,
opcode
