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.
Hallo Strubi, vielen Dank für dein Post. Kann ich diejenige Person kontaktieren, die du kennst ?! Danke dir. mfGruß, opcode
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.
Ich habe ein MEMS gefunden, dessen Bandbreite bis 32kHz geht. mfGruß, opcode
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
PS: Ja, es ist ein Projekt an meiner Hochschule. Es geht dabei um Schwingungs und Stoßmessungen im Maschinenbau. 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.
Hallo Rene, ich bin gerad nicht stolz auf meine Hochschule :-( mfGruß, opcode
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 Blackfin BF506F (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
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.