[F] Oszi: Unklares Geisterbild

Moin!

Bei 1:1000 ist Dir auf dem digitalen Oszi aber erst gar keine Unregelmäßigkeit aufgefallen, also bist Du auch nicht auf die Idee gekommen, persistance anzustellen. :-)

Gruß, Michael.

Am 04.12.2013 22:49, schrieb Michael Eggert:

Challenge accepted :-)

Ich traue mich fast wetten, dass ich einen 1:1000er Glitch auf meinem DS2072 sehe. Bin momentan unterwegs und kann es nicht schnell zusammenhacken + messen, werde das aber machen und meinen Triumph hier dann schildern ;-)

Viele Grüße, Johannes

Moin!

Na da bin ich gespannt. :-)

Auf einem nicht ganz so modernen Gerät müsstest Du schon eine Minute lang auf den Schirm starren, um überhaupt 1000 Bildschirmupdates zu erfassen.

In der Praxis kommts dann auch ganz auf die Erwartungshaltung an: Gehst Du schon davon aus, daß in genau diesem Signal irgendwas faul ist, dann starrst Du eben auf den Schirm, _bis_ Du was siehst. Suchst Du aber ohne eine konkrete Idee einen Fehler in einem komplexen System, oder willst es gar nur testen ohne vorher überhaupt einen Fehler bemerkt zu haben, dann schaust Du Dir etliche Signale kurz an. Für dieses hier reichen Dir dazu 5 Sekunden: "Rechteck, TTL, 38 kHz, passt. Das nächste bitte." - Verloren.

Gruß, Michael.

Michael Eggert :

Ich hab mir mal - um sowas festzustellen - nen kleines retriggerbares Monoflop mit nem 555 gebastelt. Ausgang an den Trigger des Oszis, Eingang ans Signal. Wenn der Monoflop knapp länger als die normale Periodenlänge eingestellt ist, triggert er dann nur noch auf die längere Periode. So ne Funktion ist eigentlich ganz praktisch - macht holdoff sowas? (Mein Oszi hat kein holdoff, daher kann ich das nicht beurteilen).

M.

Moin!

Ja, Pulstrigger ist auch ganz praktisch, manche Oszis können das ebenfalls.

Nein. Holdoff ignoriert den Trigger für eine einstellbare Zeit nach dem letzten (akzeptierten) Trigger. Angenommen, jede zehnte Periode eines Signals zeigt eine Auffälligkeit, dann stellst Du den Holdoff auf 9-10 Periodendauern. Damit triggert das Scope auf jede zehnte Periode, da die folgenden 9 ignoriert werden.

Nachteilig ist, daß Du damit zwar eine feste, aber unbekannte Zuordnung des Triggers zur "interessanten" Periode hast. Bei langem Holdoff und kurzer Zeitbasis kann die interessante also immer auf dem Schirm, genauso aber auch immer draußen liegen. In dem Fall stellt man den Holdoff dann in unserem Beispiel auf 8-9 oder 10-11 Perioden, dann läuft die interessante _langsam_ durchs Bild.

Mit dem Pulstrigger triggerst Du hier immer automatisch auf die interessante Periode, dafür kannst Du mit dem Holdoff ganz andere Probleme erschlagen, wie zum Beispiel eine kleine Amplitudenmodulation eines Signals, welche Du wegen Rauschen nicht mit dem Level-Trigger erwischen kannst.

Noch ein Beispiel: An einem Motor befindet sich ein Encoder mit 1024 Pulsen pro Umdrehung. Nun wollte ich messen, ob durch mechanisches Eiern ein mit der Umdrehung sychrones Phasenjitter der Pulse entsteht. Mit dem Holdoff zwischen 511 und 512 Pulsen gabs alle halbe Umdrehung ein Bild. Je nach Phasenlage zum "Eiern" sah man den Jitter oder nicht und ich konnte mit dem Delay zum maximalen Jitter kurbeln. Schneller gings mit Holdoff zwischen 510 und 511 Pulsen, so waberten die Flanken immer wieder auseinander und wieder zusammen und man konnte den maximalen Phasenjitter prima auch ganz ohne Delay abschätzen.

Gruß, Michael.

Sorry, das war Quatsch, ohne Delay sieht man natürlich keinen Jitter über eine halbe Umdrehung. Ich hatte mit dem Delay auf den 512. Puls gezoomt und den Holdoff auf etwas mehr als 1024 Pulse eingestellt. Damit sah man also die Zeit einer halben Umdrehung nach und nach über die ganze Umdrehung "gescannt":

Trigger auf Flanke 0, Beobachten von Flanke 512 Trigger auf Flanke 1, Beobachten von Flanke 513 Trigger auf Flanke 2, Beobachten von Flanke 514 Trigger auf Flanke 3, Beobachten von Flanke 515 usw...

Gruß, Michael.

Wie mit dem Rigol spectrum analyzer; Mitte 900 MHz, 30 MHz Bandbreite, alles leer, nix da. Komisch nur, daß das Telephon gerade Internetzugang hat. Auf dem ollen konventionellen HP hat man dann die Zappler herrlich gesehen.

-ras

Versprochen ist versprochen:

Null Komma Null Probleme auf dem DS2072. Ich mag mein neues Spielzeug, ist echt jeden Cent wert :-)

Code habe ich auf angehängt, Link in der Videobeschreibung.

Viele Grüße, Johannes

Moin!

Sieht wirklich nett aus.

Das ist aber auch kein "klassisches" Digiscope mehr (eine einzelne Samplesequenz -> ein Bild), sondern einem analogen Scope nachempfunden (viele Sequenzen übeinandergelegt -> ein Bild in verschiedenen Graustufen).

Insofern sieht man das auf diesem Scope sicher gut, aber die Behauptung...

...ist doch etwas irreführend, denn auf jedem klassischen Digiscope (z.B. Tek TSD2000er Serie) dürfte das ganz anders ausschauen.

Gruß, Michael.

Johannes Bauer schrieb:

Ist die zugehörige PC-Software einigermaßen brauchbar?

Oder benutzt Du Fremdtreiber?

Mein Chinese hat jedenfalls ein ganz grottiges Auslese- und Fernsteuerprogramm. Dilaogfenster einfach dupliziert und dabei nicht bemötiogte Teile abgeschaltet (aber sichtbar gelassen), wirre Menüs, etc. Bis man die gesuchte Funktion gefunden hat, ist es vom rumprobieren abgestürzt. :(

Marc (mit zunehmendem Budget-Jucken ;)

Das ist schon prima, denn früher war Schluß bei der Bildwiederholfrequenz bei den billigen digitalen Scopes. Wenn einmal getriggert wurde, dann kam der nächste Trigger erst frühestens 1/60 Hz später. Aber heutzutage ist die Bildschirmdarstellung von der Triggerfrequenz (relativ) unabhängig, bei den besseren Geräten. Es wird viel häufiger getriggert, und die Bilder dann überlagert, sodaß es schon recht nahe an analoge Scopes rankommt.

Würde mich mal interessieren, was bei dem Rigol bei 1 : 1.000.000 zu sehen ist. Hier bei meinem Agilent DSO-X 3012A, bei 100 MHz per FPGA generiert:

Ja, das ist echt gut mittlerweile; glaube das DSOX3012 und das DSO2072 haben in etwa dieselbe Wiederholrate (50k), das DSOX4nnn hat dann 100k.

Ich bin leider kompletter FPGA-Dilletant und kann das daher nicht synthetisieren, ums nachzuvollziehen. Würde ich natürlich auch gerne wissen, so als direkten Vergleich. Hab ein Lattice ECP3 Demoboard hier, aber fand VHDL-Development immer extrem zäh und kenne mich daher damit quasi nicht aus. Das ist schon wirklich frustrierend, wenn man Debuggen will und dann die synthese zwanzig Minuten dauert (bis man rausfindet, dass es wieder nicht geht).

Viele Grüße, Johannes

Naja, da simme ich nur so halb zu. Die Bildwiederholrate ist halt mittlerweile grandios, die war früher extrem lahm. Von daher finde ich halt, dass die Vorurteile gegen die "digitalen" pauschal nicht mehr so stimmen.

Ja, Grusel. Aber das ist halt echt ein Generationenunterschied. Die TSD2000 fand ich schon vor zehn Jahren ganz schrecklich, vorallem aber wegen ihrer extrem beschränkten Speichertiefe (15kPts oder so waren das IIRC).

Aber der Punkt ist halt: ein Digiscope wie das Rigol DS2000 kostet heute

Viele Grüße, Johannes

Hm, ich habe die nicht benutzt. Aber im EEVBlog ist das reviewed worden, da geht er auch auf die Software ein:

Ich instrumentiere das Scope per LXI, das ist quasi TMC über TCP/IP. Dafür habe ich mir ein bischen Python-Code zusammengeschrieben. Ist nicht wirklich schwierig, halt zum Triggern und Waveforms runterladen. Kommt mir als Linuxer sehr entgegen.

Welches ist das denn? Bei den Chinesen kenn ich nur Rigol und GWInstek. Ohja und natürlich Owon. Die produzieren allerdings so vollumfänglichen Vollschrott, dass es mir schon eiskalt den Rücken runterläuft, wenn ich den Namen nur schreibe :-)

Höhö, also ich bereue die Investition kein Stück. Das Ding macht ECHT Spaß. Ist wirklich kein Vergleich gegen die alten Digiscopes vom Schlag DS1052 (obwohl das für seinen Preis und die Zeit damals echt in Ordnung war).

Viele Grüße, Johannes

Der Lattice ECP3 sieht gut aus, damit macht FPGA Entwicklung bestimmt Spaß, solltest du mal ausprobieren. Von Lattice habe ich bisher nur die kleineren MachXO-Bausteine verwendet, die ich für mein Crazy Cartridge plane (

Den VHDL-Quelltext zu deinem Board zu portieren sollte nicht schwierig sein. Einfach eins der Tutorials durcharbeiten und dann statt den Tutotrial-Code den Code aus main.vhd einsetzen.

Die aktuelle Lattice Diamond IDE ist auch relativ einfach zu bedienen (am besten die aktuelle Version aus dem Internet laden, falls die freie Version für dein Chip funktioniert). Zwar nicht ganz so selbsterklärend wie Altera Quartus, erinnert mich eher an Xilinx ISE, aber hat gute Tools. Z.B. unter "Tools->Spreadsheet View" kannst du die Pins zuweisen und "Tools->IPexpress" bietet sowas wie der Quartus MegaWizard, was du für die PLL brauchen wirst, falls dein Demoboard keinen 200 MHz Oszillator drauf hat (das clock200-Signal in main.vhd).

So ein kleines Projekt wird übrigens in wenigen Sekunden synthetisiert (mit Quartus auf meinem Rechner in 25 Sekunden). Und natürlich testet man größere Projekte vorher immer gründlich per ModelSim o.ä., und behebt alle Warnings (besonders die Timing-Warnings) bevor man es auf realer Hardware testet :-)

Johannes Bauer schrieb:

Guck ich. :)

Ah ja, gefällt mir. Ich brauche meistens nur ein paar DAtenreihen oder auch mal längere Aufzeichnungen zur separaten Auswertung. Fernsteuern kommt auch vor.

UNI-T(rend) UT2062CE. Würde ich nach gesammelten Eindrücken gefühlt so zwischen Rigol/GWInstel und Owon ansiedeln.

Das Scope selbst ist durchaus OK, ein oder zwei winzige Macken in der Firmware, tut aber klaglos. Manche Features, FFT z.B., sind schlecht umgesetzt, sieht aus wie kurz vor dem Release noch reingeprügelt.

Nur das selbsterfundene Softwareprotokoll und die chinesische alle-gegen-alle-Software nervt. Vielleicht lernt ja die nächste Generation Ingenieurs-Musterschüler endlich mal Teamwork ...

Es gibt da wohl einen Python-Treiber mit qt-gui, aber das ändert nichts daran, welche Möglichkeiten die Firmware (nicht) kennt.

HT

Anläßlich der Diskussion analog/DSO hier neulich im Thread mit den Geisterbildern war ich drauf und dran, mir die Ausrüstung für die Reparatur des alten Philips zusammenzusammeln. Ein hübsches DSO dieser neuen Generation gefällt mir aber noch besser. Allein der große Schirm. ;)

Marc

Was heißt das in Zahlen ausgedrückt?

Moin!

Glaub ich nicht. Samplesequenz-Wiederholrate ja, aber nicht Bildwiederholrate. Ich seh in Deinem Video in jeder Periode viele Glitches pro Sekunde. Bei einer Wahrscheinlichkeit von 1:1000 bräuchte es dafür bei direkter Darstellung viele 1000 Bildschirmupdates pro Sekunde. Und das ist erstes völlig unrealistisch für LCD/TFT, zweitens ists unsinnig, schneller zu sein als das Auge, und drittens hättest Du dann genau den Effekt, den Du beim analogen Scope bemängelst: Der saubere Rechteck würde Dir um den Faktor 1000 heller erscheinen als die Glitches und letztere würdest Du nicht mehr sehen. Viele Sequenzen in ein Bild zu überlagern ist also nicht nur der einzig machbare Weg, sondern auch viel sinnvoller als die Bildwiederholrate hochzudrehen.

Ja, aber dann sollte man eben auch zwischen den klassischen und den moderneren differenzieren.

Und der grottenlahme Zugriff auf USB-Sticks. Und dieser seltsame Multifunktions-Drehknopf, der für numerische Eingaben oft nervig skaliert ist und für z.B. die Selektion des Triggerkanals eigentlich eine Rasterung haben sollte.

Das hat aber alles nichts damit zu tun, daß _alle_ damaligen Digiscopes nur eine gute Handvoll Samplesequenzen pro Sekunde 1:1 auf den Schirm brachten.

Gruß, Michael.

Ja, du hast natürlich Recht, Bildwiederholrate ist der falsche Begriff. Aber ich weiß auch nicht, was der richtige Begriff dafür ist, wenn mehrfach pro Frameanzeige gesampelt wird und das dann kombiniert gezeigt.

Stimmt. Aber die sterben ja jetzt gottseidank aus :-)

Viele Grüße, Johannes