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:> 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.htmlhttp://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.
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.ä.
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.
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
