Liebes Mikrocontroller Forum,
ich stehe aktuell vor einem Problem bezüglich Signalverarbeitung und
benötige dazu etwas Rat. Es geht um Folgendes:
Ich soll einen Messaufbau erstellen, der darauf setzt, nicht-periodische
Lichtreflexe über einen Photomultiplier zu identifizieren und
aufzuzeichnen. Im Vorentwurf zu diesem Aufbau wird angegeben, dass - um
die Signale ausreichend abzutasten - bei der Signalverarbeitung eine
Rise Time unterhalb von 2 Nanosekunden notwendig sind.
Dazu wird auch ein entsprechender A/D Wandler, bzw. ein entsprechendes
Oszilloskop genannt, das mittlerweile nicht mehr verfügbare HAMEG HMO
2022.
Die (vielleicht triviale) Frage, die ich mir nun stelle ist, wie
ermöglichen diese Geräte es, eine hohe Übertragungsrate der Daten zu
erzielen? Wenn ich die Angabe der 2 Nanosekunden Rise Time überschlage,
erhalte bei Annahme von acht Bit eine Datenrate von mehreren Gigabyte
pro Sekunde. Nun verfügen viele Oszilloskope lediglich über
USB-Schnittstellen, teilweise sind diese sogar nur in der Version 2.0
verfügbar.
Vielleicht übersehe ich etwas in der Bedienungsanleitung, aber wie ist
es bei diesen Geräten möglich, derart hohe Datenaufzeichnungen zu
übertragen oder zwischenzuspeichern?
Vielen Dank im Voraus
Sam F. schrieb:> Die (vielleicht triviale) Frage, die ich mir nun stelle ist, wie> ermöglichen diese Geräte es, eine hohe Übertragungsrate der Daten zu> erzielen? Wenn ich die Angabe der 2 Nanosekunden Rise Time überschlage,> erhalte bei Annahme von acht Bit eine Datenrate von mehreren Gigabyte> pro Sekunde.
Ja, das ist so, bei Sampleraten von mehreren GSa/sec kommt das so raus.
> Nun verfügen viele Oszilloskope lediglich über> USB-Schnittstellen, teilweise sind diese sogar nur in der Version 2.0> verfügbar.
Das hat damit nichts zu tun.
> Vielleicht übersehe ich etwas in der Bedienungsanleitung, aber wie ist> es bei diesen Geräten möglich, derart hohe Datenaufzeichnungen zu> übertragen oder zwischenzuspeichern?
Über USB übertragen? Kann man natürlich nicht, braucht man aber auch
nicht.
Zwischenspeichern geht weil im Oszi schnelles RAM verbaut ist das solche
Datenmengen bei richtiger Benutzung handhaben kann.
Und wenn man die Daten erstmal im RAM hat kann man sie dann relativ
gemütlich verarbeiten und auf dem Bildschirm anzeigen oder auch per USB
rausschicken.
Dabei entstehen natürlich Lücken in denen das Signal nicht abgetastet
werden kann weil ja der letzte Datenblock erstmal verarbeitet werden
muss - siehe Beschreibungen zur Funktion digitaler Oszis, Stichworte
sind z.B. Totzeit, Trigger Re-Arm, WFM bei der Darstellung.
Wenn Du es jetzt immer, ohne Lücken, in Echtzeit brauchst - dann wird es
nochmal eine Ecke komplexer.
Mit einem Oszi kannst du Einzelereignisse gut angucken. Also eine
Triggebedingung definieren. Dann wird ab oder rund um den Trigger Signal
abgespeichert im Oszi, also dort im RAM und das kannst du auslesen oder
und angucken.
Aber zwischen zwei Triggern vergeht Zeit die du verlierst. Du erfasst so
also nicht alle Ereignisse.
Der Ausweg ist die Auswertung nicht am PC sondern in schneller Hardware
am ADC zu machen. Da sind FPGAs üblich. Deine Auswertung schreibst du
dir als Hardwarebeschreibung und kannst dann parallel auf der vollen
Datenrate und ohne Totzeit arbeiten. Zum PC werden dann nur deutlich
weniger Daten übertragen, da reicht dann USB2 oder vielleicht sogar eine
langsame UART Schnittstelle.
Erstmal vielen Dank für die Antworten, das war schon mal sehr hilfreich?
Die Frage, die mir dann noch bleibt, wäre, wenn ich ein bestimmtes
Trigger-Signal definiere, kann ich dann innerhalb eines festgelegten
Zeitintervalls auch die Anzahl der (Licht-)Reflexe automatisch
aufzeichnen lassen?
Sam F. schrieb:> Die Frage, die mir dann noch bleibt, wäre, wenn ich ein bestimmtes> Trigger-Signal definiere, kann ich dann innerhalb eines festgelegten> Zeitintervalls auch die Anzahl der (Licht-)Reflexe automatisch> aufzeichnen lassen?
Das Oszi soll die Pulse innerhalb dieses Zeitfensters für dich zählen?
Oder soll es nur das Zeitfenster für dich aufzeichnen, damit du später
die Pulse selbst zählen kannst.
Die zweite Variante geht (das Zeitfenster ist durch die Speichertiefe
des Oszis begrenzt). Die erste Variante lässt sich vielleicht bei
manchen Oszis hinfrickeln (mit n-fach Pulstriggerung oder mit Puls-Count
Auswertung...) Aber im Allgemeinen ist ein Oszi nicht das richtig
Werkezeug für die erste Variante.
Wenn du Photonen-Pulse innerhalb bestimmer Zeitfenster zählen willst,
ist ein Multi Channel Scaler das übliche Werkzeug (z.B. so einer:
https://www.ortec-online.com/products/electronics/counters-timers-rate-meter-and-multichannel-scaling-mcs/easy-mcs)
Wer den Kauf scheut und lieber selber bastelt kann sowas auch schon in
einem netten FPGA-Projekt umsetzen. Man braucht dann aber eine
Vorverarbeitung des Signals, die aus dem Puls am PMT-Ausgang einen
sauberen Logikpuls macht.
Gibt da auch eine deutsche Firma:
https://www.fastcomtec.com
Aber bisher wissen wir ja nicht was er genau will. Nur irgendwelche
Pulse zählen? Braucht er auch eine Energieauflösung? Was ist der
minimale Impulsabstand? Was ist die maximale Impulsrate?
Bei dem genannten HMO gibt es einen Bottleneck, der nicht unbedingt aus
dem Datenblatt ersichtlich ist. Der Acquisition-Teil hat eine ganze
Menge sehr schnelles RAM, der mit der vollen Samplerate gefüllt werden
kann. Das sind GHz mal 8 bit, schon bei einem Kanal. Das geht so lange,
bis der RAM voll ist, in diesem Fall einige Megabyte.
Nun zur Besonderheit der Hamegs: Die Anbindung des Anzeigeteils ist der
riesige Bottleneck in dem Gerät, und kann nur einen kleinen Bruchteil
der Sampledaten übertragen. Für 2000 Bildpunkte pro Bild muß ich nicht
mehrere Megabyte in die Anzeige schieben. Die Angabe der wfm/sec ist
schon ein erster Indikator dieser Schwachstelle.
Es hat in den letzten ein bis zwei Jahren sehr preiswerte Oszis gegeben,
die auch 50 MPts oder mehr für relativ schmales Geld mitbringen. Damit
könnte man zumindest eine Weile mitlesen, aber die kompletten Daten dann
über Ethernet weiter aus einen Massenspeicher zu transferieren, wird
eine Zwangspause bei der Acquise benötigen. In "Echtzeit" wird das nach
meinem Kenntnisstand nicht gehen.
Jochen F. schrieb:> Bei dem genannten HMO gibt es einen Bottleneck, der nciht unbedingt aus> dem Datenblatt ersichtlich ist.
Den kann ich bestätigen. War anfangs auch etwas irritiert weil sich das
Oszi seltsam verhält. Und es hat auch ein Problem mit Unterabtastung.
Jochen F. schrieb:> In "Echtzeit" wird das nach> meinem Kenntnisstand nicht gehen.
Genau. Am Ende limitiert eben die Datenrate zum Rechner. Wobei Echtzeit
schon geht, wenn man mit der Abtastrate oder der Auflösung runter geht.
Es war von 2 nsec Anstiegszeit die Rede, das entspricht 170 MHz
Bandbreite, also mindestens 340 MSample/s. Wir können uns auf 500
Msample/s einigen, mal 8 Bit. Ein Scope mit 10 Gbit Ethernet habe ich
noch nicht gesehen, zumindest in dem für mich akzeptablen Preissegment.
Infiniband in einem Scope?
Es ist vermutlich die einfachere Lösung die Daten in Echtzeit ohne PC zu
verarbeiten oder zumindest deutlich zu reduzieren und dann nur wenige
Daten zum PC zu übertragen.
Klar, es kann schon Sinn machen alle Daten immer zum PC zu übertragen,
aber das ist aufwändig und ich finde ohne zwingenden Grund muss das
nicht sein.
Pulse lann man ganz gut auch ohne PC in einem FPGA erkennen und damit
Dinge rechnen. Am Ende wandert je Impuls nurnoch ein Wert und ein
Zeitstempel zum PC. Dafür reicht dann UART.
Man muss das alles auch nicht selber bauen. Es gibt eine große Auswahl
an FPGA Platinen und auch eine recht große Auswahl an ADC Platinen. Da
sucht man sich was passendes raus, steckt das zusammen und schreibt dann
den Code.
Jochen F. schrieb:> Nun zur Besonderheit der Hamegs: Die Anbindung des Anzeigeteils ist der> riesige Bottleneck in dem Gerät, und kann nur einen kleinen Bruchteil> der Sampledaten übertragen. Für 2000 Bildpunkte pro Bild muß ich nicht> mehrere Megabyte in die Anzeige schieben. Die Angabe der wfm/sec ist> schon ein erster Indikator dieser Schwachstelle.
Naja ein Scope ist halt kein Transientenrekorder. Offnsichtlich ist
die Messtechnikausbildung der Nachwuchsingenieure sehr lückenhaft, das
sie diesen Unterschied nicht kennt.
https://tmi.yokogawa.com/de/solutions/products/oscilloscopes/scopecorders/
Sam F. schrieb:> Die (vielleicht triviale) Frage, die ich mir nun stelle ist, wie> ermöglichen diese Geräte es, eine hohe Übertragungsrate der Daten zu> erzielen? Wenn ich die Angabe der 2 Nanosekunden Rise Time überschlage,> erhalte bei Annahme von acht Bit eine Datenrate von mehreren Gigabyte> pro Sekunde. Nun verfügen viele Oszilloskope lediglich über> USB-Schnittstellen, teilweise sind diese sogar nur in der Version 2.0> verfügbar.
Da gibt es auch noch andere Möglichkeiten, z.B.:
https://spectrum-instrumentation.com/en/m4i2212-x8
"Sustained streaming speed card to PC up to 3.4 GB/s"
fchk
Jo. Kann man machen. Man kann aber auch direkt hinter dem AD Wandler die
Datenrate reduzieren. Und dann nur wenige Daten zum PC übertragen.
Ist eben die Frage welche Informationen der Impulse benötigt werden.
> Bei dem genannten HMO gibt es einen Bottleneck, der nicht unbedingt aus> dem Datenblatt ersichtlich ist.
Interessanterweise stoert mich das nicht mal besonders....
> könnte man zumindest eine Weile mitlesen, aber die kompletten Daten dann> über Ethernet weiter aus einen Massenspeicher zu transferieren, wird
...allerdings stoert es gewaltig das dieses HMO sowohl USB wie auch
Ethernet auf internes RS232 mit 115200Baud mappt. Damit transferierst du
deine Daten nicht schnell.
Olaf
Sam F. schrieb:> Nun verfügen viele Oszilloskope lediglich über> USB-Schnittstellen, teilweise sind diese sogar nur in der Version 2.0> verfügbar.
Die Daten können meistens komprimiert werden, da kaum jemand mehr, als 8
Bit Auflösung benötigt. Oft reichen weniger, wenn die Signale gleich in
digitale Signale verwandelt werden, indem der exakte Zeitpunkt der
Flanke beim Durchtritt berechnet wird. Dann hat man nur noch digitale
Signale als ON OFF mit relativen Zeitangaben. Das ist auf den ersten
Blick 10-20mal genauer, als ein kontinuierlich abgetastetes Signal,
spart aber 7 Bit ein und kann RLE codiert werden. Da kommt schon
weniger, als 1/100stel bei raus, wenn man unkorrelliertes Rauschen
aufnimmt und bei periodischen Signalen sind es nochmals weniger.
