Intensity Grading

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.

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.

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.

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.

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.

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:
> 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?

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...)

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...

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.