Moin, als absoluter Freund von Intensity Grading, wie es bei den Rigol-DSOs und auch bei DSOs der höheren Preisklasse anzutreffen ist, stelle ich mir die Frage wie soetwas praktisch mit FPGA+LCD gelöst wird. Kann dazu jemand etwas die Theorie aufrollen? Benötig man für jede Intensitätsstufe einen eigenen Layer auf dem LCD oder wie wird soetwas gelöst? Inspiriert wurde meine Frage insbesondere durch den Thread hier: Beitrag "Re: Vektorgrafik auf Oszi"
Soweit ich weiss, werden die Zellen mit einem FPGA schnell PWM-artig umgeschaltet und damit ausggehend von einem festen analogen Wert gedithert.
dragon schrieb: > Benötig man für jede Intensitätsstufe einen eigenen Layer auf dem LCD > oder wie wird soetwas gelöst? Nein, du hast ja einen Wellenform-Bildspeicher für das LCD, und dann gehst du nur her und skalierst das, was schon da ist ein wenig dunkler, und addierst die neue Welle einfach drauf. So macht es auch ein traditionelles Oszi mit nachleuchtendem Schirm (nur ist dort die "Pixelanzahl" unglaublich viel höher). In den Scopes der oberen Preisklasse wird das ganze Display sowieso per Software von einen uC angesteuert. Die sind für so schnarchlangsame Aufgaben (wie schnell ist dein Auge?) schnell genug. > stelle ich mir die Frage wie soetwas praktisch mit FPGA+LCD gelöst wird. Das FPGA hat mit der (Berechnung der) Darstellung meist nicht viel zu tun, sondern das macht der uC.
:
Bearbeitet durch Moderator
Lothar Miller schrieb: > dragon schrieb: >> Benötig man für jede Intensitätsstufe einen eigenen Layer auf dem LCD >> oder wie wird soetwas gelöst? > Nein, du hast ja einen Wellenform-Bildspeicher für das LCD, und dann > gehst du nur her und skalierst das, was schon da ist ein wenig dunkler, > und addierst die neue Welle einfach drauf. So macht es auch ein > traditionelles Oszi mit nachleuchtendem Schirm (nur ist dort die > "Pixelanzahl" unglaublich viel höher). > > In den Scopes der oberen Preisklasse wird das ganze Display sowieso per > Software von einen uC angesteuert. Die sind für so schnarchlangsame > Aufgaben (wie schnell ist dein Auge?) schnell genug. > >> stelle ich mir die Frage wie soetwas praktisch mit FPGA+LCD gelöst wird. > Das FPGA hat mit der (Berechnung der) Darstellung meist nicht viel zu > tun, sondern das macht der uC. Es gibt einen interessanten Teardown eines DS2072 von Dave Jones: http://www.youtube.com/watch?v=BWZXGzAVkD8 Rigol hat dort 2x Spartan 6 (XC6SLX25) und 1x Blackfin (ADSP-BF526) verbaut. Ein FPGA scheint sich um die A/D-Wandlung zu kümmern und das andere ist mit dem Display verbunden. Ein XC6SLX25 als einfacher Displaycontroller kommt mir etwas überdimensioniert vor, meine Vermutung wäre jetzt das sich hier noch zusätzliche Hardwarebeschleunigung für die Anzeige verbirgt. Z.B. für das Intensity Grading. Mit seinen 38 DSP48-Slices sollte es das schneller als der Blackfin hinbekommen.
dragon schrieb: > Moin, > > als absoluter Freund von Intensity Grading, Was meinst du mit " Intensity Grading "? google führt mich zu diesem Stichwort zur Klassifikation von Diamanten. MfG,
Mike schrieb: > Ein FPGA scheint sich um die A/D-Wandlung zu kümmern und das andere ist > mit dem Display verbunden. Macht also die Displayansteuerung. Das ist schon mal sinnvoll, denn der DSP hat keine Grafikeinheit. > meine Vermutung wäre jetzt das sich hier noch zusätzliche > Hardwarebeschleunigung für die Anzeige verbirgt. > Z.B. für das Intensity Grading. Du vermutest viel zuviel hinter diesem "Intensity Grading". Es ist einfach nur ein "weniger starkes Gewichten alter Information", und das geht am einfachsten (und warum sollte man sich mehr Arbeit machen) so, wie es die alten Oszi-Röhren gemacht haben: ein einzelner Leuchtpunkt verdunkelt sich nach einer e-Funktion. Und wie man das in Software macht habe ich schon beschrieben. Dazu gehört natürlich auch eine Vorverarbeitung der gerade eingelesenen Wellenform, so dass eine steile/schnelle Flanke nicht gleich hell dargestellt wird wie eine langsame/flache Flanke. Aber auch diese Skalierung bekommt man ganz ohne hochwertige Berechnungen mit einem simplen Dreisatz und einer kleinen Abstandberechnung zwischen zwei Punkten hin. Es wird aber sehr wahrscheinlich keiner die letzten 1000 Wellenformen abspeichern und die dann mit einer aufwendigen Blending-Funktion zusammenfassen und auf dem Display darstellen.
Tektronix hat sich vor Jahren die Bezeichnung "Digital Phosphor" reserviert, das "Intensity grading" dürfte dasselbe meinen. Ein langsam verlöschender Schreibstrahl wie im wirklichen Leben. Mit Farbdisplay könnte man das noch echter aussehen lassen, wenn der Punkt zunächst bläulich aufleuchtet und dann eher gelb verglüht.
> Was meinst du mit " Intensity Grading "?
Geschwätz vom Marketing, Graustufen beim Oszilloskopstrahl so wie es
jedes analoge Scope schon immer tat.
Seit 10 Jahren im TDS3000 als digital phosphor bekannt in Farben auf
FarbTFT, heute auch in China angekommen.
Naja also auch wenn man die einzelnen Pixel schwächer leuchten lässt wenn schon etwas Zeit verstrichen ist, muss man sie trotzdem speichern. Und auch das Alter. Ich würde wenn bei der Wellenform z.B. die letzten 1024 Werte neu horizontal angezeigt werden, die letzten sagen wir 1M Punkte speichern. Dann kann man die für jedes neue Frame durchgehen und unterschiedlich hell zeichnen. Man könnte natürlich auch ganze Bilder behakten , abdunkeln und überlagern, aber ein Bild frisst wohl mehr Speicher wie eine Wertereihe. Schnell genug ist die Hardware dafür locker.
Gustl Buheitel schrieb: > muss man sie trotzdem speichern. > Und auch das Alter. Nö. Nur die Summe der Gesamthelligkeit. Und die dann in jedem Schritt mit einer Konstante multiplizieren, daß es verblaßt: pixelhelligkeit_(tn+1) = neupixel + pixelhelligkeit_(tn) * c mit c<1 und sättigender Addition.
:
Bearbeitet durch User
Stimmt aber du musst so zumindest das letzte Bild speichern. Also ein komplettes, nicht nur die Wertetabelle. Und vor allem auch ein Bild mit Farbtiefe. Sagen wir 8Bits dafür bei 1024*512 pixel, also 10*9*8 Bits = 0,5MByte. Da könnte man auch 512 Wellenformen also Wertetabellen mit 8 Bits Tiefe und 1024 Werten speichern. Also will man Speicher sparen kann man auch mit deutlich weniger auskommen wenn man Wertetabellen behält, hat man Speicher dann kann man sich mit dem Speichern von einem Bild viel Rechnerei sparen.
:
Bearbeitet durch User
Gustl Buheitel schrieb: > Stimmt aber du musst so zumindest das letzte Bild speichern. Naja, eine Art Framebuffer braucht man ja so oder so, oder?
Gustl Buheitel schrieb: > Stimmt aber du musst so zumindest das letzte Bild speichern. Den Bildspeicher braucht man für ein ausreichend großes (TFT-)Display sowieso. Und dann kann man da ja mit 2 Puffern fahren: einem, der die Wellenforminfo "vom letzten Mal" hat, und einem Overlaybuffer der die ganzen Menüs undwasweißichauchimmer aufnimmt. Fertig. Alles zusammen: pure Software, die ja auch mit nur 20fps (oder noch weniger) spielend fertig werden müsste...
Naja also ohne Intensity Grading braucht man keinen Bildspeicher, da reicht es völlig die Wertetabelle die man anzeigen will im BRAM zu haben. Das mache ich so und es funktioniert. Ist aber natürlich eine Notlösung weil ich keinen RAM habe.
Lothar Miller schrieb: > Alles zusammen: pure Software, die ja auch mit nur 20fps (oder noch > weniger) spielend fertig werden müsste... Lothar Miller schrieb: > In den Scopes der oberen Preisklasse wird das ganze Display sowieso per > Software von einen uC angesteuert. Die sind für so schnarchlangsame > Aufgaben (wie schnell ist dein Auge?) schnell genug. > >> stelle ich mir die Frage wie soetwas praktisch mit FPGA+LCD gelöst wird. > Das FPGA hat mit der (Berechnung der) Darstellung meist nicht viel zu > tun, sondern das macht der uC. Eben nicht. Die Bildschirmdarstellung wird insb. bei den Besseren Oszilloskopen in Hardware gemacht. Die Windows-Oszilloskope von Agilent z.B. haben/hatten eine spezielle Grafikkarte durch die auch die auch die Hardware in den Bildspeicher für die Waveformdaten schreiben kann. Bei den DSOX/MSOX 2/3/4000 Digiskops hat das Signal vom ADC bis zum Bildschirm keinen einzigen Prozessor gesehen, wird alles im Digital-ASIC gemacht. Anders würde man auch keine 1e6 Waveforms/sec erreichen, wenn nach jedem Trigger die Software einmal den gesamten Bildspeicher neu beschreiben müsste. Klar, es geht auch in Software, aber dann eben nur mit sehr durchwachsener User Experience.
Lukas K. schrieb: > > Eben nicht. Die Bildschirmdarstellung wird insb. bei den Besseren > Oszilloskopen in Hardware gemacht. Die Windows-Oszilloskope von Agilent > z.B. haben/hatten eine spezielle Grafikkarte durch die auch die auch die > Hardware in den Bildspeicher für die Waveformdaten schreiben kann. Mein Agilent hat eine standard Intelgraphic (Q45/Q43 Chipset) > Bei > den DSOX/MSOX 2/3/4000 Digiskops hat das Signal vom ADC bis zum > Bildschirm keinen einzigen Prozessor gesehen, wird alles im Digital-ASIC > gemacht. Anders würde man auch keine 1e6 Waveforms/sec erreichen, wenn > nach jedem Trigger die Software einmal den gesamten Bildspeicher neu > beschreiben müsste. Und genau da ist der Flaschenhals, insbesondere bei Intensity und Colorgrading sollen auch alle Waveforms zum Display beitragen. Um das Beschleunigen gibt es 2 Möglichkeiten: Direkt in den Memory der Ggraphikkarte schreiben, oder meiner Ansicht einfacher, einen FPGA in die LVDS Leitungen zum LCD Panel einschleifen und die Waveforms als Overlay darstellen. Was Agilent macht weiss ich nicht, dazu müsste ich das Ding zerlegen. Es gibt gedoch einen Hilfstreiber neben dem Graphiktreiber, was darauf hindeutet dass Agilent Hardwaresupport hat. > > Klar, es geht auch in Software, aber dann eben nur mit sehr > durchwachsener User Experience. Dem schliesse ich mich an. Die Windowsscopes sind allerdings langsamer als die 1000 bis 6000er (bezogen auf die Waveforms/s)
Lattice User schrieb: > Was Agilent macht weiss ich nicht, dazu müsste ich das Ding zerlegen. Es > gibt gedoch einen Hilfstreiber neben dem Graphiktreiber, was darauf > hindeutet dass Agilent Hardwaresupport hat. Welches isses denn? Mitunter hilft schon das Blockschaltbild aus dem Service-Handbuch weiter.
Lukas K. schrieb: > > Welches isses denn? Mitunter hilft schon das Blockschaltbild aus dem > Service-Handbuch weiter. DSO9254A
Lukas K. schrieb: > Anders würde man auch keine 1e6 Waveforms/sec erreichen, wenn nach > jedem Trigger die Software einmal den gesamten Bildspeicher neu > beschreiben müsste. Das berechnen und Updaten von 1Mio Waveforms im Bildpuffer mit einer Größe von 1024x768 schafft man aber auch nicht mit einem ASIC. Und darum geht es mit den 1Mio Waveforms auch gar nicht. Sondern wie im DB auf Seite 4 aufgezeigt nur um die Totzeit zwischen zwei Triggerzeitpunkten... http://cp.literature.agilent.com/litweb/pdf/5991-1103EN.pdf Das Display kann diese Updaterate schon systembedingt nicht abbilden. Warum also auf dem Weg zum Display schneller sein, als das Ding es überhaupt kann?
Lothar Miller schrieb: > Lukas K. schrieb: >> Anders würde man auch keine 1e6 Waveforms/sec erreichen, wenn nach >> jedem Trigger die Software einmal den gesamten Bildspeicher neu >> beschreiben müsste. > Das berechnen und Updaten von 1Mio Waveforms im Bildpuffer mit einer > Größe von 1024x768 schafft man aber auch nicht mit einem ASIC. Und darum > geht es mit den 1Mio Waveforms auch gar nicht. Sondern wie im DB auf > Seite 4 aufgezeigt nur um die Totzeit zwischen zwei > Triggerzeitpunkten... > http://cp.literature.agilent.com/litweb/pdf/5991-1103EN.pdf > Auch auf Seite 4: Figure 3: The 4000 X-Series captures a glitch occurring once in a million waveform cycles. Wie soll das gehen wenn das Scope nur eine Waveform pro Displayrefresh anzeigen kann? der 1 in einer Million Glitch, bräuchte dann viele Stunden bis man ihn sieht. Trigger hilft da nicht, wie man am Bild sehen kann.
Lattice User schrieb: > Trigger hilft da nicht, wie man am Bild sehen kann. Doch, das ist der Knackpunkt: das Scope muss schneller für den nächsten Trigger bereit sein. Das ist alles. Nur darum geht es im Zusammenhang mit der hohen Erfassungsrate von 1Mio Waveforms/sec. > Wie soll das gehen wenn das Scope nur eine Waveform pro Displayrefresh > anzeigen kann? Ganz einfach: das Scope zeichnet viel mehr auf als es anzeigt. Und zum Finden so eines Glitches ist dann ein guter Trigger nötig. Denn über den Trigger wird dann genau die eine und einzige Waveform mit dem Glitch angezeigt, die in der 1/60 Sekunde seit dem letzten Displayupdate gefunden wurde. Denn es würde rein gar nichts bringen, wenn da 60 mal pro Sekunde 1000000/60 = ca. 16000 Wellenzüge auf dem Display dargestellt würden, denn dann würde man erst recht nichts mehr erkennen. Und natürlich kann die Displayansteuerung auch von dem ASIC gemacht werden, das den Speicher verwaltet, aber die Messung und die Anzeige sind garantiert entkoppelt. So ist z.B. gerade bei den obersten High-End-Scopes immer die Erfassung von der Anzeige getrennt: http://teledynelecroy.com/oscilloscope/oscilloscopeseries.aspx?mseries=390 http://www.home.agilent.com/en/pd-1846742-pn-86100D/infiniium-dca-x-wide-bandwidth-oscilloscope-mainframe?nid=-536902447.937136&cc=DE&lc=ger http://de.tek.com/oszilloskope-f%C3%BCr-die-erweiterte-signalanalyse/mso-dpo70000-0 Jedes dieser Scopes bietet auch die komplette Fernsteuerung von Messabläufen von einem Arbeitsplatzrechner aus (und das das können sogar die kleinen schon...)
Im Datasheet der 7000er Serie http://cp.literature.agilent.com/litweb/pdf/5990-4769EN.pdf definiert Agilent waveform update rate so (Seite 6): What is update rate? Update rate is how many waveforms acquisitions per seconds your scope can acquire, process, and display. Auf den folgenden Seiten sind Beispiele, und auf Seite 7 eine Vergleichtabelle mit der Konkurrenz (muss man natürlich mit Vorsicht geniessen) Das 7000er schafft laut dieser Tabelle 95000 Waveforms/Sekunde. Mein 9000er schafft 250000 WF/s im Segmented-Mode (das ist nur durch den Trigger begrenzt) und mickrige 4000 WF/s im Realtime-Mode, Aber auch 4000 sind noch weit mehr als Auge und LCD Panel schaffen. Der Trick ist, dass man die "Nachleuchtdauer" auf unendlich setzt. Dann reicht auch ein einfacher Leveltrigger um viele Abweichungen vom Sollsignal zu sehen. Diese Diskussion hat aber mit dem ursprünglichem Thema nur noch wenig zu tun.
Lothar Miller schrieb: > Denn über den > Trigger wird dann genau die eine und einzige Waveform mit dem Glitch > angezeigt, die in der 1/60 Sekunde seit dem letzten Displayupdate > gefunden wurde. > Denn es würde rein gar nichts bringen, wenn da 60 mal pro Sekunde > 1000000/60 = ca. 16000 Wellenzüge auf dem Display dargestellt würden, > denn dann würde man erst recht nichts mehr erkennen. Sinn von hohen Updateraten ist es, den Glitch auch zu finden, ohne auf ihn zu triggern. Deshalb werden in einem Frame eben 16000 Waveforms dargestellt, eben überlagert, sodass du den Glitch sehen und den Trigger darauf abrichten kannst. Siehe auch http://www.eevblog.com/forum/testgear/why-is-1m-waveformssec-so-impressive/ und http://eda360insider.wordpress.com/2011/02/15/agilent-knocks-one-out-of-the-park-with-new-low-cost-line-of-digital-scopes%E2%80%94a-very-competitive-entry-into-the-low-end-dso-market-and-a-perfect-example-of-eda360-design-using-end-to-end-design/
Lukas K. schrieb: > Sinn von hohen Updateraten ist es, den Glitch auch zu finden, ohne auf > ihn zu triggern. Deshalb werden in einem Frame eben 16000 Waveforms > dargestellt, eben überlagert Ähm, wenn ich gänzlich ohne Trigger 16000 Waveforms überlagere, dann habe ich nur Matsch auf dem Schirm... > Sinn von hohen Updateraten ist es, den Glitch auch zu finden, ohne auf > ihn zu triggern. Ich möchte aber echt behaupten, dass man mit 1 Mio Messungen pro Sekunde "nur" die jeweils dazugekommenen Waveforms zusätzlich in den Speicher eintragen, aber sicher nicht die bereits vorhergehenden gleichzeitig im selben Speicher noch shaden kann. > Deshalb werden in einem Frame eben 16000 Waveforms dargestellt Es werden sogar viel mehr Waveforms überlagert dargestellt, denn du selber kannst nichts erkennen, wenn der erfasste (aber nicht getriggerte) Glitch nur 1/60 Sekunde lang auf dem Display zu sehen ist. Lattice User schrieb: > Diese Diskussion hat aber mit dem ursprünglichem Thema nur noch wenig zu > tun. Richtig, weil hier ein traditionelles Shading sinnlos wäre. Denn nach 1 sec wäre die millionste vorhergehende Wellenform sicher schon so dunkel, dass man sie nicht mehr sähe. Wie du selber sagst erreicht man diese extremen Zahlen nur mit "Tricks": Lattice User schrieb: > Der Trick ist, dass man die "Nachleuchtdauer" auf unendlich setzt. Und das Shading damit ausschaltet. Auch Oszi-Bauer kochen nur mit Wasser. Vielleicht mit mehr Wasser oder mit heißerem Wasser, aber Wasser bleibt Wasser. Nur haben sie eben ein paar Jahre Vorsprung...
Lothar Miller schrieb: > Lukas K. schrieb: >> Sinn von hohen Updateraten ist es, den Glitch auch zu finden, ohne auf >> ihn zu triggern. Deshalb werden in einem Frame eben 16000 Waveforms >> dargestellt, eben überlagert > Ähm, wenn ich gänzlich ohne Trigger 16000 Waveforms überlagere, dann > habe ich nur Matsch auf dem Schirm... Lukas meint sicher ohne spezielle Triggerbedingungen. > >> Sinn von hohen Updateraten ist es, den Glitch auch zu finden, ohne auf >> ihn zu triggern. > Ich möchte aber echt behaupten, dass man mit 1 Mio Messungen pro Sekunde > "nur" die jeweils dazugekommenen Waveforms zusätzlich in den Speicher > eintragen, aber sicher nicht die bereits vorhergehenden gleichzeitig im > selben Speicher noch shaden kann. Ich würde es so machen: Dualportet Memory für die Waveform (z.b. 8bit * 800x600) Beim Waveformupdate wird für jedes Pixel der Waveform ein 8bit Wert geschrieben, z.B. 2 bit Kanalnummer + 6bit einsen da neu. Auf der Displayseite (ist ja viel langsamer) ist der 8bit Wert ein Index in eine Colour Lookup Table. Bei jedem Screenrefresh wird dann vom 6bit Teil eine einstellbare Konstante subtrahiert und ins Memory zurückgeschrieben. Dargestellt wird das dann als Overlay über die Ausgabe der Standardgraphik für die GUI. Womit wir wieder beim Thema wären. > >> Deshalb werden in einem Frame eben 16000 Waveforms dargestellt > Es werden sogar viel mehr Waveforms überlagert dargestellt, denn /du/ > selber kannst nichts erkennen, wenn der erfasste (aber nicht > getriggerte) Glitch nur 1/60 Sekunde lang auf dem Display zu sehen ist. > > Lattice User schrieb: >> Diese Diskussion hat aber mit dem ursprünglichem Thema nur noch wenig zu >> tun. > Richtig, weil hier ein traditionelles Shading sinnlos wäre. Denn nach 1 > sec wäre die millionste vorhergehende Wellenform sicher schon so dunkel, > dass man sie nicht mehr sähe. Wie du selber sagst erreicht man diese > extremen Zahlen nur mit "Tricks": > Lattice User schrieb: >> Der Trick ist, dass man die "Nachleuchtdauer" auf unendlich setzt. > Und das Shading damit ausschaltet. Der Trick dient nur dazu dass man den einzelnen Ausreiser auch sieht, nicht um die Updaterate zu erreichen. > > Auch Oszi-Bauer kochen nur mit Wasser. Vielleicht mit mehr Wasser oder > mit heißerem Wasser, aber Wasser bleibt Wasser. Nur haben sie eben ein > paar Jahre Vorsprung... Klar, der Vorspung besteht aber zum grössten Teil aus Erfahrung und guten Leuten. Mit Superwasser das unsereins nicht zur Verfügung steht wird nur bei der Samplingrate gekocht, d.h. beim Frontend.
Ich habe die Diskussion hier aufmerksam verfolgt und bewusst laufen lassen ohne mich einzumischen. Danke für die vielen Beiträge. Die genannten Ansätze klingen mir sehr speicherhungrig, da die alten Signalverläufe gespeichert werden müssen, was ja dem Verhalten eines DPOs entspricht. Ein modernes Rigol hat ja mittlerweile auch 56Megapunkte. Gibt es auch Ansätze die mit wenig Speicher auskommen?
Ja. Je nachdem was du als "viel" definierst. Wenn du immer das letzte Bild (also keine Wertetabelle) speicherst, das abdunkelst und die neuen Werte reinmals, dann brauchst du "nur" Speicher für ein Bild. Das ist je nach Bildschirmauflösung und Farbtiefe deutlich kleiner wie eine große Wertetabelle oder aber auch deutlich größer wie eine kleine Wertetabelle. Also an Stelle der 56MPunkte mit sagen wir 8Bits, also 56MBytes braucht ein Bild deutlich weniger wenn es z.B. 1024x512x8Bits ist. Aber eben dieses Bild ist auch wieder viel größer wie eine Wertetabelle mit 64kPunkten mit je 8Bits. Also eb einer gewissen Speichergröße ist es dann vielleicht besser ein Bild statt der Wertetabelle zu speichern und umgekehrt.
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.