Moin Leute, zurzeit beschäftige ich mich mit dem Thema Analog-Digital-Wandler. Ich würde gerne ein Signal mit einer Frequenz von 20 MHz und einer Auflösung von 16 Bit abtasten. Als Hardware wollte ich hierfür anfangs einen Raspberry Pi und den Mikrocontroller AMC1305M05-Q1 verwenden. Jetzt konnte ich bereits recherchieren, dass der RasPi das nicht schaffen wird. Was ist hierbei der limitierende Faktor bezüglich des Einplatinensystems? Was wäre eine gute alternative zu dem RasPi? Habt ihr Literaturempfehlung die das Thema ADC abdecken? Beste Grüße Stefan
Hans J. schrieb: > und den Mikrocontroller AMC1305M05-Q1 Das ist kein Microcontroller. Wie kommst Du ausgerechnet auf diesen Baustein? http://www.ti.com/lit/ds/sbas654f/sbas654f.pdf
Hans J. schrieb: > zurzeit beschäftige ich mich mit dem Thema Analog-Digital-Wandler. Schön. > Ich würde gerne ein Signal mit einer Frequenz von 20 MHz und einer > Auflösung von 16 Bit abtasten. Wirklich. Warum fängst du nicht erstmal mit etwas einfacherem an? Bei 16 Bit Auflösung wirken sich schon kleinste Störungen aus. Wenn du z.B. einen Meßbereich von 0..10V mit 16 Bit auflöst, ist das LSB gerade noch 150µV. Jetzt denk mal an Rauschen, Offsetspannungen (resp. deren Drift), Thermospannungen etc. Fang doch lieber mit 10 Bit an. Und dann 20MHz Abtastfrequenz. Das gibt bei 16 Bit Breite einen Datenstrom mit 40MB/s. 320 MBit/s. Netto. Da brauchst du schon USB-3 oder Gigabit-Ethernet, um das verläßlich zu transportieren. > Jetzt konnte ich bereits recherchieren, dass der RasPi das nicht > schaffen wird. Was ist hierbei der limitierende Faktor bezüglich des > Einplatinensystems? Na schonmal das Nichtvorhandensein einer Schnittstelle, die diese Datenraten zuverlässig übertragen könnte. > Habt ihr Literaturempfehlung die das Thema ADC abdecken? Bei deinem bisherigen Kenntnisstand? Jedes Buch zum Thema.
Hallo, " Ich würde gerne ein Signal mit einer Frequenz von 20 MHz und einer Auflösung von 16 Bit abtasten." Dein stürmisches Interesse ist sehr löblich, nur dürfte die Aufgabe nur für fortgeschrittene lösbar sein und vermutlich bei Deinem Kenntnisstand nur Frust erzeugen. Früher wäre das ein besseres Digitalspeicheroszilloskop geworden. Vielleicht fängst Du mit NF an und tastest mit 100 kHz ab, benutzt hierzu erstmal 8 Bits und steigerst Dich dann schrittweise. Ganz ohne Messmittel wird dies auch nicht zu realisieren sein. MfG
Vielen Dank für die schnellen Antworten! Rufus Τ. F. schrieb: > Das ist kein Microcontroller. Wie kommst Du ausgerechnet auf diesen > Baustein? > > http://www.ti.com/lit/ds/sbas654f/sbas654f.pdf Danke, stimmt. Ich bin davon ausgegangen, dass der IC-Baustein meine Anforderungen erfüllen kann. Ansonsten gab es keine Gründe genau dieses Modell zu verwenden. Axel S. schrieb: > Schön. Danke^^ Axel S. schrieb: > Warum fängst du nicht erstmal mit etwas einfacherem an? Da ich einen Sensor habe, den ich mit diesen Mindestanforderungen abtasten möchte. Natürlich könnte ich mich erst einmal mit einfacheren Signalen beschäftigen. Da ich aber am Ende immer noch die anfangs erwähnte Abtastung durchführen möchte, sehe ich -mit meinem begrenzten Wissen in dieser Materie- keine Mehrwert darin einen Umweg über andere Projekte zu gehen. Axel S. schrieb: > 40MB/s. 320 MBit/s. Netto. Da brauchst du schon USB-3 > oder Gigabit-Ethernet, um das verläßlich zu transportieren. Mir ist klar, dass ich bereits bei kurzen Messungen eine erhebliche Menge an Daten erzeuge. Der Raspberry Pi 3B+ besitzt doch einen Gigabit-Ethernet Anschluss. Die GIPOs reichen aber für diese Übertragungsrate nicht aus? Und wie sieht es mit der Rechenleistung des Raspberrys aus? Christian S. schrieb: > Ganz ohne > Messmittel wird dies auch nicht zu realisieren sein. Ist damit der Sensor und ein referenz Messsystem gemeint? Ich hatte anfangs noch vergessen, dass das ganze System echtzeitfähig sein soll. Vermutlich macht es das nicht besser. :D Dann werde ich mich jetzt wohl erst einmal mit der Literaturrecherche beschäftigen.
Da stellt sich die Frage Welcher Sensor liefert solche Daten? Und hast du dir den AMC1304 mal angesehen? Das ist nur ein sigma delta modulator. Da fällt ein 1Bit Stream mit 20MHz raus und wenn du den dezimierst kommst du auf ca. 16Bit bei ca. 100kHz bei +-50mV ist das trotzdem gut, jedoch musst du schon einen sehr nieder impedante signal quelle haben, also n Shunt zum Strommessen oder Ähnliches. Also kläre uns bitte mal auf was du überhaupt machen willst oder ist das "geheim"?
Der Raspberry hat eigentlich genug Rechenleistung. Nur musst du die Daten reinbekommen. Ein Raspberry ist für vieles gut zu nutzen, aber Echtzeit + hohe Datenmenge über GPIO ist nicht das ideale Einsatzgebiet. Wenn du alles übers Ethernet reinschieben möchtest brauchst du wieder einen EthernetController und das wäre wieder ein immenser Mehraufwand. Wenn du mit einem Delta/Sigma Wandler 16 Bit reinmorsen möchtest (seriell) dann hätte dein GPIO-Pin mal eben 180 MHz für reine Nutzdaten. Dein Ausgesuchtes Bauteil hat einen Bustakt von max 20 MHz und kann daher knapp > 1 MHz scannen.
Hans J. schrieb: > Axel S. schrieb: >> Warum fängst du nicht erstmal mit etwas einfacherem an? > > Da ich einen Sensor habe, den ich mit diesen Mindestanforderungen > abtasten möchte. Aha. Und ist das tatsächlich eine harte Anforderung oder einfach nur ein "es wäre schön wenn"? > Natürlich könnte ich mich erst einmal mit einfacheren > Signalen beschäftigen. Da ich aber am Ende immer noch die anfangs > erwähnte Abtastung durchführen möchte, sehe ich -mit meinem begrenzten > Wissen in dieser Materie- keine Mehrwert darin einen Umweg über andere > Projekte zu gehen. Au contraire. Wenn du ein Nichtschwimmer bist, ist es wenig sinnvoll, wenn du dich gleich für einen Ironman anmeldest. Es wäre schon sinnvoll, vorher erstmal Schwimmen zu lernen und ein paar kürzere Strecken zu schwimmen. >> 40MB/s. 320 MBit/s. Netto. Da brauchst du schon USB-3 >> oder Gigabit-Ethernet, um das verläßlich zu transportieren. > > Mir ist klar, dass ich bereits bei kurzen Messungen eine erhebliche > Menge an Daten erzeuge. Der Raspberry Pi 3B+ besitzt doch einen > Gigabit-Ethernet Anschluss. Der an die CPU aber auch nur per USB-2 angebunden ist. Das reicht nicht für 40 Megabyte pro Sekunde. > Und wie sieht es mit der Rechenleistung des Raspberrys aus? Kommt drauf an, was du mit den Daten anstellen willst. Einfach nur von A nach B schieben schafft der RasPi locker. Nur hat er eben keine Interfaces, die dafür geeignet wären. IMHO gehst du das vom falschen Ende her an. Sobald Abtastrate und Auflösung feststehen, kannst du Hersteller von ADC abklappern und dir einen Überblick darüber verschaffen, welche geeigneten ADC es gibt und wie deren digitale Schnittstelle aussieht (wird wohl auf LVDS hinauslaufen). Und dann kannst du auf die Suche nach geeigneten µC Boards gehen. Sofern es überhaupt ein µC sein muß. Kommt ja darauf an, was mit den Daten passieren soll.
Generation Raspberry/Arduino. 12bit und 100kHz? Da geht noch mehr!!11elf! 16 Bit und 20MHz, desto mehr, desto besser. Zu 99,9999% wird deine Anforderung nicht gebraucht. Zu 99,99% kann deine wirkliche Anforderung jeder beliebige 8bitter erledigen und schläft dabei ein. Verrate uns im Detail, was du vor hast :).
Maik S. schrieb: > Der Raspberry hat eigentlich genug Rechenleistung. ..für 20 Ms/s etwa? Du machst Witze. Selbst für nen etwas schnelleren Audio-ADC mit 192 kS/s ist der noch ein bissel zu klein, es sei denn, man will die Daten ohne jegliche Bearbeitung wieder zu einem Audio-DAC hinausbefördern. W.S.
Alexander B. schrieb: > Also kläre uns bitte mal auf was du überhaupt machen willst oder ist das > "geheim"? Nein, geheim ist das nicht^^. Ich möchte das Signal eines AE-Sensors auswerten. Dieser Arbeitet bei einer Frequenz von bis zu 800 KHz. Mit AE-Messungen beschäftige ich mich im Rahmen meiner Studienarbeit (Maschinenbaustudium). Für diese benötige ich kein Wissen über AD-Wandler, denn ich verwende dort ein kommerzielles Messsystem. Ich komme also in der Studienarbeit nicht in Kontakt mit dieser Art der Signalverarbeitung. Da das angesprochene Messsystem extrem teuer ist, ich das Thema interessant finde und gerne mehr über das Thema Signalverarbeitung wissen möchte, bin ich dann hier gelandet. Ich hoffe das reicht an Kontext. Axel S. schrieb: > Und ist das tatsächlich eine harte Anforderung oder einfach nur ein > "es wäre schön wenn"? Den Sensor habe ich bei max. 800 KHz verwendet. Das Signal würde ich dann gerne mit 20 MHz Abtasten. Axel S. schrieb: > Au contraire. Wenn du ein Nichtschwimmer bist, ist es wenig sinnvoll, > wenn du dich gleich für einen Ironman anmeldest. Es wäre schon sinnvoll, > vorher erstmal Schwimmen zu lernen und ein paar kürzere Strecken zu > schwimmen. Schöner Vergleich! :) Wenn du aber für den Ironman schwimmen trainierst, bringt es dir nicht viel den Schwimmstil "Delphin" zu erlernen. Axel S. schrieb: > IMHO gehst du das vom falschen Ende her an. Ich vermute, da wirst du recht haben! W.S. schrieb: > Selbst für nen etwas schnelleren > Audio-ADC mit 192 kS/s ist der noch ein bissel zu klein, es sei denn, > man will die Daten ohne jegliche Bearbeitung wieder zu einem Audio-DAC > hinausbefördern. Bearbeiten möchte ich das digitale Signal an dieser Stelle nicht.
Hans J. schrieb: > Da das angesprochene Messsystem extrem teuer ist Ja, dann ist es ja auch völlig klar, dass das jeder Anfänger ohne Kenntnisse jederzeit nachbauen kann, und das noch VIEEEL billiger. Georg
Hans J. schrieb: > Den Sensor habe ich bei max. 800 KHz verwendet. Was heißt das? Für die Antastung brauchst du ein bandbegrenztes Signal, bei dem die höchsten Signalanteile unterhalb der halben Abtastfrequenz liegen. Alles was darüber liegt, wird in die unteren Frequenzen runter gespiegelt und macht dir die 16 Bit zunichte, wenn du das Signal bei der Bandbreite überhaupt mit einer Dynamik von 90dB aufbereitet bekommst. Schon effektive 14 Bit wären da sportlich.
Hans J. schrieb: > Ich möchte das Signal eines AE-Sensors auswerten. Ich kann zwar gurgeln, aber es wäre nett gewesen, wenn Du geschrieben hättest, dass das Sensoren für akustische Emissionen sind. Ich als nicht-MaschBauer weiss das nämlich nicht. > Dieser Arbeitet bei einer Frequenz von bis zu 800 KHz. Okay. > Da das angesprochene Messsystem extrem teuer ist, ich > das Thema interessant finde und gerne mehr über das > Thema Signalverarbeitung wissen möchte, bin ich dann > hier gelandet. > Ich hoffe das reicht an Kontext. Ja, für's erste. Die Sache ist doch im Prinzip ganz einfach: 1. Du musst nicht gleich mit 800kHz einsteigen. Wenn es 80kHz für den Anfang auch tun, versuch's mit einer hochwertigen Soundkarte, die mit 192kHz abtastet. 2. Um Dich an das Thema heranzutasten, muss Du nicht unbedingt kontinuierlich messen --> kauf' Dir einen passenden USB-Oszi. 3. Um 800kHz zu digitalisieren, muss man nicht mit 20MHz abtasten. 4MHz tun's für den Anfang auch (theoretisch kommt man auch mit 2MHz aus, aber das will man nicht wirklich). Wenn Du mit 400kHz Nutzbandbreite zufrieden bist, kannst Du auch auf 2MHz heruntergehen. 4. 16Bit Auflösung ist Irrsinn, wenn man nicht GANZ sicher weiss, was man tut. Zum Einstig genügen 8bit und ein VGA; Fortgeschrittene können sich an 12bit versuchen. Nur mal als Vergleich: Ein (etwas älteres) hochempfindliches spezielles Ultraschallmessgerät kommt mit dem 10bit-Wandler eines ATMega32 aus. 1MSps ist nominell schon mit einem STM32 machbar; was real geht, kann ich nicht beurteilen. Mehr Speed liefert ein ADS830; hier liegt das Problem darin, die Daten schnell genug wegzuschaffen.
"Ich habe keine Ahnung von Eisenbahn. Jetzt will ich mit einem A380 auf der Landstraße zwischen Hinterbummshausen nach Tachelfing 10500km/h fahren. Welchen Belag soll ich auf meine Pizza streuen"? Kennt man ja, hier. z.B. von dem hier: Beitrag "6kW Buck Converter, Mikrocontroller gesteuert" Der hat offensichtlich schon aufgegeben. Das gilt es zu vermeiden. Ich würde zunächst mal den Raspberry dahin packen, wo er hingehört - in die Mülltonne. Für dieses Projekt ist er untauglich. Ein Arduino tut leider auch nicht, zu langsam, den kann ma also auch gleich vergessen. Also brauchts einen 32-Bit-µC oder einen DSP. Für den Sensor dürfet ein µC schon noch reichen. Irgenwas in der Kategorie STM32 oder so. Denkbar wäre zum Beispiel der da, der ist Analogspezialist: http://www.st.com/en/microcontrollers/stm32f303ze.html http://www.st.com/en/evaluation-tools/nucleo-f303ze.html Das Evalboard ist praktisch, weil du außer diesem keinerlei Ausrüstung benötigst (Debugger, Strom, alles drauf) - gut für Studenten! Da baust du den Sensor mal hin. Der µC hat mehrere 5MSPS-ADCs. Einer davon dürfte vermutlich erst einmal reichen, um den Sensor auszuwerten. Die lassen sich aber auch zusammenschalten, um höhere Sampleraten zu erreichen. Die ADC haben zwar nur 12Bit, aber auch das sollte für den Anfang reichen. Geschickt aufgebaut, bekommt man die aus diesem µC auch heraus (im Gegensatz zum F4). Wenn die Samples mal im Prozessor sind, kannst du überlegen, was du damit tun willst. Vom Anzeigen über aufzeichnen bis zu "Zusammenfassung an PC schicken" ist vieles möglich.
Possetitjel schrieb: > hier liegt das Problem darin, > die Daten schnell genug wegzuschaffen. Ach, der TE ist doch der Meinung, dass mit Hilfe der GIPOs erledigen zu können. Mit GPIOs, die der Rest der Welt verwendet, geht das natürlich nicht. Die zeitliche Streuung (Jitter) bei einer rein softwaremäßigen Signalabtastung mit allem möglichen im Hintergrund werkelnden Kram (Linux-System auf dem RPi) wird meines Erachtens ohnehin so groß sein, dass man das ganze Messignal eh in die Tonne kloppen kann. Aber der TE weiß es ja besser.
:
Bearbeitet durch User
Andreas S. schrieb: > Possetitjel schrieb: >> hier liegt das Problem darin, >> die Daten schnell genug wegzuschaffen. > > Ach, der TE ist doch der Meinung, dass mit Hilfe der GIPOs > erledigen zu können. Mit GPIOs, die der Rest der Welt > verwendet, geht das natürlich nicht. Was soll mir dieser Absatz sagen? > Die zeitliche Streuung (Jitter) bei einer rein softwaremäßigen > Signalabtastung mit allem möglichen im Hintergrund werkelnden > Kram (Linux-System auf dem RPi) wird meines Erachtens ohnehin > so groß sein, dass man das ganze Messignal eh in die Tonne > kloppen kann. Vielleicht ist das bei mir falsch angekommen, aber ich hatte den TO nicht so verstanden, dass außer dem RasPi und dem ADC keinerlei weitere Hardware verwendet werden darf. Das Problem ist halt, dass seine Anwendung gleichzeitig - relativ viel Rechenleistung und Speicher, - einigermaßen einfache Programmierung und - Echtzeitfähigkeit voraussetzt. Zwei von drei bekommt man recht leicht unter einen Hut, aber die dritte Forderung bringt die Sache dann zu Fall.
Andreas S. schrieb: > Die zeitliche Streuung (Jitter) bei einer rein softwaremäßigen > Signalabtastung mit allem möglichen im Hintergrund werkelnden Kram > (Linux-System auf dem RPi) wird meines Erachtens ohnehin so groß sein, > dass man das ganze Messignal eh in die Tonne kloppen kann. Aber der TE > weiß es ja besser. Ich fürchte eher, dass dem TO der Unterschied zwischen ADC-Auflösung und effektiven Bits nicht klar ist.
Axel S. schrieb: > Und dann 20MHz Abtastfrequenz. Das gibt bei 16 Bit Breite einen > Datenstrom mit 40MB/s. Nö, das Signal hat 20MHz. Dann ist die benötigte Abtastfrequenz eher 50MHz oder noch mehr und die Datenrate somit mindestens 100MByte/s.
So ein AE-Sensor dient dazu, zu überwachen ob eine Maschine noch richtig arbeitet indem man vergleicht ob die produzierten Schwingungen so (ähnlich) sind wie im (zuvor geprüften) Idealfall, richtig? Das muss also weit über dem menschlichen Hörvermögen hinaus gehen und darum die 20Mhz... > Da das angesprochene Messsystem extrem teuer ist, ich das Thema > interessant finde und gerne mehr über das Thema Signalverarbeitung > wissen möchte, bin ich dann hier gelandet. > Ich hoffe das reicht an Kontext. Fürchte wie die anderen hier auch dass das echt zu harter Tobak ist für einen Studenten (keine Abwertung gemeint, bin selbst einer). Wahrscheinlich ist das selbst für Erfahrene Einzelpersonen schwierig und eher was für Team-Projekte in Unternehmen. Jedenfalls wenn da verlässliche Werte bei rauskommen sollen natürlich. Wenn du wirklich was praxisnahes lernen willst, geh einfach ein paar Schritte zurück und bau sowas wie eine Soundkarte (also max 20Khz). Damit kann man immer noch demonstrativ unterscheiden/feststellen ob z.B. der Bohrer der Bohrmaschine abgebrochen ist o.ä.
:
Bearbeitet durch User
Autor: Hans Janssen (stefan_masch) Datum: 26.03.2018 17:35 >Alexander B. schrieb: >> Also kläre uns bitte mal auf was du überhaupt machen willst oder ist das >> "geheim"? >Nein, geheim ist das nicht^^. >Ich möchte das Signal eines AE-Sensors auswerten. Dieser Arbeitet bei >einer Frequenz von bis zu 800 KHz. >Mit AE-Messungen beschäftige ich mich im Rahmen meiner Studienarbeit >(Maschinenbaustudium). Für diese benötige ich kein Wissen über >AD-Wandler, denn ich verwende dort ein kommerzielles Messsystem. Ich >komme also in der Studienarbeit nicht in Kontakt mit dieser Art der >Signalverarbeitung. >Da das angesprochene Messsystem extrem teuer ist, ich das Thema >interessant finde und gerne mehr über das Thema Signalverarbeitung >wissen möchte, bin ich dann hier gelandet. Hallo Hans, da scheint mir ein domänenspezifisches Verständigungsproblem zwischen den Disziplinen Maschinenbau und Elektrotechnik vorzuliegen. Ich werde mal versuchen, das Problem ( kabaretistisch ) aus der elektrotechnischen in die Maschinenbauwelt zu übersetzen. Nehmen wir an, Du hast ein Mofa mit dem Du jeden Morgen mit 25km/h zur Arbeit fährst. Die Geschwindigkeit ist Dir zu langsam, Du möchtest lieber mit 250km/h zur Arbeit fahren. Man kann solche Gefährte kaufen, aber sie sind leider zu teuer. Deshalb möchtest Du Dir selbst eines bauen. Auf Ebay hast Du Dir einen günstigen LKW-Motor mit 300PS Leistung ersteigert ( so wie er normalerweise im IVECO-PI LKW eingebaut ist ). Das Einzige, was jetzt noch zu tun ist, ist im Mofacontroller.net Forum die Experten zu fragen, wie man den Motor ins Mofa einbaut. An diesem Punkt befindest Du Dich gerade.
Hans J. schrieb: > Den Sensor habe ich bei max. 800 KHz verwendet. Das Signal würde ich > dann gerne mit 20 MHz Abtasten. Falls 8 oder 10 Bits reichen. Wie wär es mit einem Oszilloskop?
Hp M. schrieb: > Axel S. schrieb: >> Und dann 20MHz Abtastfrequenz. Das gibt bei 16 Bit Breite einen >> Datenstrom mit 40MB/s. > > Nö, das Signal hat 20MHz. Hmm. Ja. Auch so könnte man den Eröffnungspost deuten. Ich war aber davon ausgegangen, daß er mit Hans J. schrieb: > würde gerne ein Signal mit einer Frequenz von 20 MHz und einer > Auflösung von 16 Bit abtasten. tatsächlich die Abtastrate angegeben hat und nicht die Signalbandbreite. Außerdem schreibt ja explizit "Frequenz" und wenn das die Frequenz des Signals wäre, dann wäre die Bandbreite im Zweifelsfall nochmal deutlich höher, weil eher nicht davon auszugehen ist, daß sein Signal ein reiner Sinus ist. > Dann ist die benötigte Abtastfrequenz eher 50MHz oder noch mehr und > die Datenrate somit mindestens 100MByte/s. Nun, mittlerweile wissen wir ja, daß sein Sensorsignal eine Frequenz von (bis zu?) 800kHz hat. Da sind 20MHz Abtastrate vermutlich schon weit übertrieben. 50MHz ganz sicher. Ich stecke im Thema so gar nicht drin, aber es geht wohl darum, Schwingungen am Werkzeug oder Werkstück auszuwerten, die bei der mechanischen Bearbeitung auftreten. Ich denke mal, man braucht da 1. die Erkennung daß überhaupt was vibriert ("Drehmeißel hat Kontakt hergestellt, jetzt Vorschub verringern") 2. eine Überwachung der Amplitude ("da schwingt was heftig und steht kurz vor dem Bruch") 3. einen grobe Spektralauswertung ("das Werkstück ist schief eingespannt und schlägt gegen den Drehmeißel") Aus meinen Exkursen in die Metallbearbeitung kenne ich nur Schwingungen im (unteren) Hörbereich. 800kHz halte ich für sehr sportlich für ein mechanisches System. Wahrscheinlich sind 800kHz Bandbreite gemeint.
W.S. schrieb: > Maik S. schrieb: >> Der Raspberry hat eigentlich genug Rechenleistung. > > ..für 20 Ms/s etwa? Du machst Witze. Selbst für nen etwas schnelleren > Audio-ADC mit 192 kS/s ist der noch ein bissel zu klein, es sei denn, > man will die Daten ohne jegliche Bearbeitung wieder zu einem Audio-DAC > hinausbefördern. > > W.S. Hallo, im Datenblatt steht 20 MHz Takt, was an Daten ~ 1,x MHz entspricht, bit 16 Bit und serieller Ausgabe.
Sebastian schrieb: > Das Einzige, was jetzt noch zu tun ist, ist im Mofacontroller.net Forum > die Experten zu fragen, wie man den Motor ins Mofa einbaut. MOFACONTROLLER.NET Sehr geil... YMMD
Maik S. schrieb: > im Datenblatt steht 20 MHz Takt Wo gab es ein Datenblatt des AE-Sensors? Das ist doch alles wüstes Gerate hier ohne Substanz. Datenblatt des Sensors wäre das erste Die zu erwartenden Signale das nächste. Nur weil der Sensor 800kHz kann heisst das nicht, daß das zu messende System auch 800kHz emittiert. Dann die gewünschte Dynamik und Genauigkeit. DANN und erst DANN kann man sich Gedanken über die notwendige A/D Auflösung und Abtastfrequenz machen. Und dann über die µC Hardware.
Maik S. schrieb: > Hallo, > > im Datenblatt steht 20 MHz Takt, was an Daten ~ 1,x MHz entspricht, bit > 16 Bit und serieller Ausgabe. Ebenfalls Hallo, worüber schreibst du? Der TO will nen ADC betreiben, der 20 MSPS mit je 16 Bit liefert. Also die ADC-Werte rauschen mit 20 MHz herein. Annahme, daß so ein Raspberry rund 1 GHz an Systemtakt kann und noch ne Annahme, daß es dabei keine Waitstates gibt, weil der jeweilige Cache das hergäbe, dann hätten wir 1000MHZ/20MHz also 50 Maschinentakte pro ADC-Wert zur Verfügung. Was bittesehr willst du mit 50 Takten/Sample anfangen? Selbst wenn du beim Audio-ADC mit knapp 200 kHz arbeitest (stereo), hättest du 1000MHz/(2*0.2MHz) nur relativ mickrige 2500 Maschinentakte pro Sample. Allein ein simples FIR-Filter mit 2*201 Taps frißt dir davon fast die Hälfte weg. Damit eine ausgiebige Bearbeitung und auch noch nebenher die Bedürfnisse des OS erfüllen, ist elendiglich knapp. W.S.
@ W.S. Schätze mal die Daten werden in irgendein kompakteres Format ummodeliert und diese dann rigendwie evrarbeitet/verglichen. Denn was soll in Echtzeit (Anforderungd es TE) schon damit geschehen? So macht man das z.B. bei Bildern. Die Pixelwerte werden alle erstmal aufgenommen aber dann werden POI/Keypoints oder "Features" heraus analysiert (gibt relativ efiziente Algorithmen) und auf diese wenige KB großen Daten laufen dann höhere Algorithmen wie Gesichtserkenner etc. Das schafft ein Raspi durchaus. Dabei profitiert man aber sicherlich von den 4 Kernen des Raspi. Ob man Multithreading auch im zusammenspiel mit ADCs anwenden könnte?
Alex G. schrieb: > Ob man > Multithreading auch im zusammenspiel mit ADCs anwenden könnte? Man kann durchaus 4 ADCs verwenden, um bessere Abtastraten zu realisieren, aber nur wenn die synchron reihum angesteuert werden - mit 4 Threads geht das natürlich nicht. Aber eigentlich ist es unnötig sich Gedanken zu machen, der TO leidet schlicht an naivem Grössenwahn. Georg
Das Uebliche : Das Messsystem, das ich nicht verstehe, ist viel zu teuer, ich mach's billiger... Da geht viel Zeit und Geld rein, nachher geht's eh nicht, und der Lerneffekt ist Null. Mach was anderes .. eine Led blinken lassen, oder so.
Sebastian schrieb: > Das Einzige, was jetzt noch zu tun ist, ist im Mofacontroller.net Forum > die Experten zu fragen, wie man den Motor ins Mofa einbaut. Die DSPs von Motoroller werden jetzt von Freescale hergestellt.
Beitrag #5367178 wurde von einem Moderator gelöscht.
georg schrieb: > Man kann durchaus 4 ADCs verwenden, um bessere Abtastraten zu > realisieren, aber nur wenn die synchron reihum angesteuert werden - mit > 4 Threads geht das natürlich nicht. Damit die 16 Bit der synchronisierten Wandler dann auch zu einem Datenstrom mit effektiven 16 Bit führen, müssen die Dinger, abhängig von der Slew-Rate der Signale im Pikosekundenbereich synchronisiert sein. Das scheint mir beim derzeitig präsentierten Kenntnisstand die Sache nicht zu vereinfachen.
Egal welchen Wandler Du ins Auge fasst: "Echte" 16 Bit sind wirklich sportlich. Wenn Du keine fertige Lösung kaufen kannst/willst, solltest Du Dir das als Anfänger wirklich verkneifen.
W.S. schrieb: > Maik S. schrieb: >> Hallo, >> >> im Datenblatt steht 20 MHz Takt, was an Daten ~ 1,x MHz entspricht, bit >> 16 Bit und serieller Ausgabe. > > Ebenfalls Hallo, > > worüber schreibst du? > Der TO will nen ADC betreiben, der 20 MSPS mit je 16 Bit liefert. Also > die ADC-Werte rauschen mit 20 MHz herein. Annahme, daß so ein Raspberry > rund 1 GHz an Systemtakt kann und noch ne Annahme, daß es dabei keine > Waitstates gibt, weil der jeweilige Cache das hergäbe, dann hätten wir > 1000MHZ/20MHz also 50 Maschinentakte pro ADC-Wert zur Verfügung. Ich hatte mich auf den ausgesuchten Baustein bezogen. Der Raspberry hat 1,4 GHz und 4 Kerne. Der ausgewählte Wandler seriell einen Bustakt von 20 MHz bei serieller Übertragung. (Ist halt für die Aufgabenstellung das total falsche Bauteil, ich hätte mir irgendwas mit parallelem Ausgang gesucht und die Auswertung über in einen [DSP/FPGA/µC je nach Auswertungsaufgabe] geschoben. Er schrieb nur von abtasten, was für mich erstmal bedeutet aufnehmen & ablegen -> Das sollte ein Raspberry schaffen. > Was bittesehr willst du mit 50 Takten/Sample anfangen? ggf. Aufzeichnen > Selbst wenn du beim Audio-ADC mit knapp 200 kHz arbeitest (stereo), > hättest du 1000MHz/(2*0.2MHz) nur relativ mickrige 2500 Maschinentakte > pro Sample. Allein ein simples FIR-Filter mit 2*201 Taps frißt dir davon > fast die Hälfte weg. > > Damit eine ausgiebige Bearbeitung und auch noch nebenher die Bedürfnisse > des OS erfüllen, ist elendiglich knapp. Ja, wenn du mehr als Grenzwertanalyse oä machen willst (siehe meine Begründung oben)
Ainen gudden! Hans J. schrieb: > Ich möchte das Signal eines AE-Sensors auswerten. Jetzt mal im Ernst. Das mit den 20Mhz ist doch ein Witz. Oder willst Du irgendwelchen Molekülresonanzen auf die Spur kommen? Da muß ich Dich aber enttäuschen. Dem stehen allein schon die Korngrenzen im Weg. Da stehst Du mit Deinen 16 Bit mitten in der Wüste und das Einzige was Du vielleicht zu sehen kriegst ist eine Fata Morgana. Jedes Bit mehr vergrößert nur die Wüste. Und fang jetzt bloß nich mit mathematischem Taschenbilliard an. Sandkörner zählen kannst Du alleine. Dwianea hirnschaden
> Der ausgewählte Wandler seriell einen Bustakt von 20 MHz bei serieller
Übertragung.
Seriell? Willst du jetzt 16 Bit Werte, die mit 20 Mhz gesampled werden
oder 16 Bit Werte, die mit 20 Mbps eingelesen werden?
Hans J. schrieb: > Was wäre eine gute alternative zu dem RasPi? Ein FPGA. Der LTC2270 ist teuer genug, da kommt es auf den FPGA nicht mehr an. Und wenn du dann noch das Eigangssignal verstärken musst, und einen Eingangsspannungssprung innerhalb von 50 Nanosekunden auf 0.001% genau abgebildet haben musst, ist der Rest mit der Signalauswertung Kinderkram. Mit etwas Mühe könnte man sogar einem rPi ein neues echtzeitfähiges Betriebssystem mit Einlesen der Daten mit hoher Samplerate verpassen.
P.S.: Der TO klingt fast wie Kurt, unser verkappter Stringtheoretiker. Leider will keiner Kurt beim Sandkörnerzählen helfen. P.P.S.: Mit Rechenschieber wär' das nich' passiert.???
Was willst du denn bei der Anwendung mit 16 Bit? Ich hätte mal mit 1 Bit angefangen zu planen und dann nach einem eventuellen Grund gesucht, aus dem ich doch 2 oder mehr brauche.
Der TO ließt bestimmst schon nicht mehr mit, weil ihr zu viel rum gemeckert habt ;-) . Es ist immer vergebene Mühe auf solche Threads konstruktiv zu antworten.
Ainen gudden! Wenn er nicht dumm ist, dann googelt er nach "digitale signalverarbeitung" und fängt an zu lesen. Demoboards gibt es ja wie Sand am Meer. Dwianea hirnschaden
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.