Einlesen mehrerer Analog Signale

Malte M. schrieb:
> hatte aber an einen Multiplexer gedacht
> oder an die Verwendung der internen ADCs.

Die meisten STM32 haben beides und können Signale zwischen GND und AREF 
in 12-Bit Werte wandeln. Aber das hängt vom spezifischen Controller ab, 
den du mal näher beschreiben solltest. Ein dicker STM32F429 hat dann bis 
zu 24 Eingänge mit Multiplexer und 3 unabhängige ADCs, wimre.

Malte M. schrieb:
> ungefähr 10 analoge Signale in einen STM32 Controller einlesen.
> Was ist der beste Weg
Was sind das für "Signale"? Woher kommen diese "Signale"? Wie schnell 
ändern sie sich und wie schnell und wie genau müssen die gemessen 
werden? Was soll mit den Messewrten geschehen?

Lothar M. schrieb:
> Was sind das für "Signale"? Woher kommen diese "Signale"? Wie schnell
> ändern sie sich und wie schnell und wie genau müssen die gemessen
> werden? Was soll mit den Messewrten geschehen?

Ergänzung:

Welche Spannungen haben sie?
Welche Impedanz haben die Quellen?
Sind sie galvanisch getrennt oder auf die Masse des STM32 bezogen?

STK500-Besitzer schrieb:
> Sollen die Signale synchron digitialisiert werden?
> Dann brauchst du für jedes einen eigenen ADC. Und die müssen sich
> synchronisieren lassen...

Man muß nicht immer gleich übertreiben. Es reicht völlig, wenn die 
Messungen für die gewünschte Abtastrate hinreichend synchron sind.

STK500-Besitzer schrieb:
> Wenn man bspe. ein Mehrphasenmikrofonarray samplen will, dann ist das
> wohl nötig, oder?

Aber das ist nicht gerade ein Projekt das man macht wenn man wie der TO 
schrieb "relativ neu auf dem Gebit der Mikrocontroller" ist ...

STK500-Besitzer schrieb:
> Wenn man bspe. ein Mehrphasenmikrofonarray samplen will, dann ist das
> wohl nötig, oder?

Wer so fragt wie der TO will das nicht.
Oder er versucht zu rennen bevor er krabbeln kann.

STK500-Besitzer schrieb:
> kann man ihn doch mit Informationen
> überhäufen.

Zielgerichteter und sinnvoller wäre ihn mit Fragen zu überhäufen

Die Fragen wurden schon gestellt

STK500-Besitzer schrieb:
> Der TO hat sein Problem ja nur sehr wage beschrieben.

Das ist aber stark untertrieben.
Die einzige Angabe zu dieser Aufgabe ist, "ungefähr 10". Also nichtmal 
die "10" ist sicher. Auch von Mikrofonen war keine Rede.

Na ja,
LTC1090 hatte ich hier mal am Wickel.
Ist aber obsolet.
Sowas in der Richtung aber moderner?
https://www.analog.com/en/products/ltc1090.html

ciao
gustav

Moin,

STK500-Besitzer schrieb:
> Wenn man bspe. ein Mehrphasenmikrofonarray samplen will, dann ist das
> wohl nötig, oder?

Nee, nicht unbedingt; das kann man sich schon wieder schoenfiltern, 
zumindest, wenn man weiss, wieviel Zeit bzw. Sampleabstandbruchteile 
dazwischenliegen.

Gruss
WK

Olaf schrieb:
> Das koennen wir nicht wissen weil wir nicht wissen welche Aufloesung du
> brauchst und wie oft du das machen willst.

> Die meisten Microcontroller haben nur einen ADC, manche zwei, sehr
> wenige drei. Die haben aber fast alle bereits einen Multiplexer
> eingebaut um damit acht oder 16Eingaenge der Reihe nach messen zu
> koennen. Viele koennen das dann sogar automatisch machen. Haengt halt
> davon ab ob dir die Geschwindigkeit dann reicht.

Danke für die zahlreichen Antworten.
Als Auflösung sind 8 Bit ausreichend und die Sample Rate soll pro Signal 
bei etwa 100Msamples/s liegen. (Was schon recht schnell ist.)
Dafür werden die eingebauten ADCs wohl zu langsam sein. Gibt es Lösungen 
das zu realisieren ohne 10 ADCs parallel schalten zu müssen.

Grüße

Malte

Malte M. schrieb:
> Als Auflösung sind 8 Bit ausreichend und die Sample Rate soll pro Signal
> bei etwa 100Msamples/s liegen. (Was schon recht schnell ist.)
> Dafür werden die eingebauten ADCs wohl zu langsam sein. Gibt es Lösungen
> das zu realisieren ohne 10 ADCs parallel schalten zu müssen.

Soll er auch noch fliegen können, oder reicht es kürzere Strecken zu 
gleiten?

Also die STM32 können ja eine Menge, aber 1 Milliarde Messwerte pro 
Sekunde gehören nicht dazu.

Mal Grundsätzlich:
Haben die Signale alle das gleiche Referenzpotential?

Alles Gleichspannungen oder auch etwas Später-

Wenn alles mit dem Faktor 10 belegt wird, werden der Speicherbedarf und 
-durchsatz entsprechend groß.
Es besteht ein riesiger Unterschied zwischen mit 1 MHz messen und diese 
auch zu be-/verarbeiten.
Ich unterstelle dabei mal, dass Du die Messdaten nicht in 
Endlosschleifen zyklisch überschreiben tust, wodurch das Messen zum 
Selbstzweck verkommt.

Malte M. schrieb:
> Als Auflösung sind 8 Bit ausreichend und die Sample Rate soll pro Signal
> bei etwa 100Msamples/s liegen. (Was schon recht schnell ist.)
> Dafür werden die eingebauten ADCs wohl zu langsam sein. Gibt es Lösungen
> das zu realisieren ohne 10 ADCs parallel schalten zu müssen.

Der Aufwand, bei den geforderten Abtastraten(!) einfach zehn separate 
ADCs zu verwenden, ist deutlich geringer als einen schnellen ADC und 
entsprechende Multiplexer. Ein Multiplexer schaltet nicht beliebig 
schnell, und auch nach dem Umschalten muss der Eingang des ADC zunächst 
einmal auf den neuen Analogwert umgeladen werden, bevor die Wandlung 
getriggert werden kann. Um das alles zu gewährleisten, muss man schon 
mit erheblichem Simulationsaufwand und Schaltungsoptimierung, 
impedanzkontrolliertem Leiterplattenlayout und anschließenden Messungen 
an die Sache herangehen. Ein ADC mit 1 GS/s ist zudem auch nicht 
wirklich billig und muss ggf. auch mit einem Kühlkörper usw. entwärmt 
werden. Mit solch einer Schaltung wäre ein sehr erfahrener Entwickler 
schon einige Wochen beschäftigt.

ADC mit 100 MS/s und 8 Bit sind im Vergleich dazu noch sehr leicht zu 
handhaben und kostengünstig. Außerdem besteht da nicht die Gefahr, dass 
es zu einem Übersprechen zwischen den Eingangskanälen kommt.

Bei beiden Varianten muss man natürlich überlegen, wie man die Daten 
überhaupt aufzeichnet. Mit einem normalen Microcontroller geht das 
nämlich nicht so ohne weiteres. Ich würde hierfür z.B. einen Xilinx Zynq 
verwenden (vorbehaltlich der derzeitigen Liefersituation...).

Wie einfach sich ein Fuenfzeiler zu einem 8 Kanal Oszilloskop aufblasen 
kann...
Ich nehme jetzt mal an, nach etwas Prozessing muss visualisiert werden, 
weil auf einen Speicher wegschreiben ja eher sinnlos ist.
Allenfalls waere jetzt noch interessant was fuer ein Prozessing dazu 
kommt.

MaWin schrieb:
> Und überlege dir, wie du 8 GByte Daten/Sekunde wegschaufeln willst, dazu
> reicht weder USB noch eine SSD noch Ethernet oder WLAN, oder direkt vor
> Ort verarbeiten willst, ein FPGA müsste schon recht schnell sein,
> parallelisiert programmiert.

Es fallen bei 10*8*100 MS/s aber nur 8 GBit/s und nicht 8 GByte/s an 
Daten an. Als erfahrener Entwickler kann man es durchaus schaffen, 
mittel FPGA/SoC diese Datenmenge in normales DRAM und/oder sorgsam 
ausgewählte SSDs zu schaufeln.

Trotzdem ist das kein Einstiegsprojekt für Anfänger.

Wahrscheinlich wirft der TE aber nur mit irgendwelchen Zahlen um sich, 
weil er keine Ahnung hat und sich einfach aufplustern will. Vor einiger 
Zeit fragte mich auch eine Bekannte, welche Komponenten sie für ihre 
Heimnetz kaufen solle, und zwar für 100 GBit/s. Ich fragte sie mehrmals, 
ob sie wirklich 100 GBit/s benötige oder doch eher nur 100 MBit/s oder 
ggf. 1 GBit/s. Sie bestand immer auf den 100 GBit/s. Ich erklärte ihr 
dann, dass sie für einen Switch mit etlichen 100 GBit/s-Port auf jeden 
Fall eine Klimatisierung benötige. Und ein Fileserver, der solch einen 
Durchsatz schafft, fällt ja nun auch nicht in die Rubrik von Heim-NAS.

Auf meine Fragen, wofür sie den ganzen Kram brauche, meinte sie nur, 
dass sie das einfach haben wolle und müsse. Schließlich dürfe ja ihr 
"teurer" neuer 100 GBit/s-Internetzugang nicht ausgebremst werden. 
Irgendwann schaute sie dann mal in die Leistungsbeschreibung und las 
dann durchaus realistische 100 MBit/s. Ihrer Meinung nach wäre das ja 
aber nur ein Unterschied von einem Buchstaben.

Andreas S. schrieb:
> Schließlich dürfe ja ihr
> "teurer" neuer 100 GBit/s-Internetzugang nicht ausgebremst werden.
> Irgendwann schaute sie dann mal in die Leistungsbeschreibung und las
> dann durchaus realistische 100 MBit/s. Ihrer Meinung nach wäre das ja
> aber nur ein Unterschied von einem Buchstaben.

Genau, und da M ja viel weiter hinten im Alfabet kommt als G: Ist M 
besser.


Herrlich, ich liebe solche Kundengespräche.

Malte M. schrieb:
> die Sample Rate soll pro Signal
> bei etwa 100Msamples/s liegen. (Was schon recht schnell ist.)

"recht schnell" ist stark untertrieben, das kann kaum einer selber 
bauen, erst recht kein Anfänger.

Falls Du wirklich 100Msamples/s brauchen solltest, kaufe ein fertiges 
16-Kanal Scope. Ein Selbstbau würde erheblich teurer, wenn er auch noch 
funktionieren soll.

Andrew T. schrieb:
> Herrlich, ich liebe solche Kundengespräche.

Ist ganz einfach, sind nur 10 Kanäle, auch nicht besonders schnell, nur 
100 MHz pro Kanal und kaum weiter was, nur dieses Fast Dingens, Fast 
Foyer oder so, muss maximal 1 Stunde aufzeichnen, ach ja, wir wollen in 
4 Wochen anfangen zu liefern und das darf nicht mehr als 5 € kosten…

Sebastian schrieb:
> Ein Logic Pro z.B. schafft es nicht alle 16 Analogkanäle mit höchster
> Geschwindigkeit auszulesen; je mehr Analogkanäle man auswählt desto
> kleiner wird die mögliche Samplingrate.

Die erste Wahl für solche vielkanaligen Anwendungen sind Produkte von 
Yokogawa, z.B. ein DL590 kann mit bis zu 32 Kanälen a 200 MS/s 
konfiguriert werden.

Benutzername  malte_me
Vorname  Malte
Nachname  M.
Firma
Angemeldet seit  05.05.2022 09:47
Beiträge  2

Zusammen mit seinen zwei Beiträgen gibt das satte 8/10 Trollpunkte. 
BRAVO!