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.
:
Bearbeitet durch User
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.
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.