Problem mit dem flackernden Signal des analogen Oszilloskops

Ich verwende das analoge BK Precision 2125C Dual Trace Oszilloskop (30 MHz) . Ich versuche, das vom Ausgang des Mikroprozessors erzeugte Signal zu beobachten. Ich sehe ein flackerndes Signal (bewegt sich schnell nach links und rechts zu den Seiten des Zielfernrohrs), von dem ich weiß, dass es im wirklichen "Leben" höchstwahrscheinlich nicht so flackert, aber das ist höchstwahrscheinlich das auslösende Problem eines Zielfernrohrs. Ich bin mir fast sicher, dass dies der Fall ist, da ich vor dieser eine normale Rechteckwelle beobachtet habe und sie bei einer Triggereinstellung auch wie die aktuelle flackerte, aber nach dem Zurücksetzen des Triggers gab es kein Flackern mehr.

Dieses Flackern ist wirklich ärgerlich, wenn man versucht, kleine Änderungen im Signal zu beobachten oder seine Periode abzulesen.

Hier ist das Video zur Messung des Flackersignals.

Nur als Referenz, für diese Messung verwende ich folgendes Setup:

  • DC-gekoppelter Eingang, CH1 (gleiches Verhalten bei AC-Eingangskopplung)
  • Kopplung: Norm (gleiches Verhalten bei „auto“ oder „TV-V“ oder „TV-H“)
  • Quelle: CH1
  • Hauptmodus (nicht Mix- oder Delay-Modus)
  • Spannung/Div.: 2V/Div
  • Zeitbasis/div: 2ms/div

Bezüglich "Trigger Level" und "Hold Off" drehe ich jedoch an beiden Reglern (buchstäblich jede Kombination), bekomme ich immer ein flackerndes oder unsynchronisiertes Signal. Ansonsten messe ich am Ausgang der MCU (10k Pull-up, UART-Übertragung) mit normaler passiver Sonde (in interner Teilerrate von 1: 1).

Irgendwelche Ideen, wie man die Ansicht des "stillstehenden" Signals auf dem Bildschirm des Zielfernrohrs erreichen sollte?

Videoverbindung unterbrochen. Außerdem sollte Ihr Signal auf einem analogen Oszilloskop besser periodisch sein oder es würde flackern, es sei denn, Sie verwenden den One-Shot-Modus, den analoge Oszilloskope nicht haben. Wenn Sie genug wissen, um dies sicher zu tun, schließen Sie es an das Wechselstromnetz an (oder einen Signalgenerator, der sicherer ist, aber auch mehr Geld erfordert) und sehen Sie, ob es funktioniert. Wenn dies der Fall ist, ist Ihr Signal nicht so stabil, wie Sie denken.
@DKNguyen Videolink aktualisiert. Ja, One Shot ist hier nicht verfügbar. Also keine aperiodische Signalmessung mit diesem Oszilloskop ... :(
Andererseits IST es periodisch ... Es wiederholt sich später ... Ich habe neulich ein anderes UART-Datenübertragungssignal gemessen, und das Bild flackerte überhaupt nicht, während dieses bei jeder Triggereinstellung ständig flackerte.
Das sieht eher nach Jitter in deinem Signal aus. Wie wird das Signal von der MCU erzeugt? Bei der Software? Oder in Hardware (Peripherie), und wenn in Software, macht der Code noch etwas anderes? Insbesondere Aufgaben, die zeitlich variieren können (Schleifen, Interrupts usw.).
@DKNguyen Ja, Programmierung, daher ist es höchstwahrscheinlich, dass die Codeausführungszeit zwischen Wiederholungen variiert.
Erstellen Sie Code, der buchstäblich nichts anderes tut, als Schleifen zu zählen und den Pin umzuschalten, und Sie sollten keinen Jitter sehen, da der Code jedes Mal genau gleich ausgeführt wird (es sei denn, Sie haben Cache in Ihrer MCU).
@DKNguyen Nur zur Verdeutlichung, viele analoge Oszilloskope verfügen über einen One-Shot-Modus (z. B. Tektronix 453). Nicht allzu nützlich, da keine Speicherkapazität vorhanden ist.

Antworten (2)

Geben Sie hier die Bildbeschreibung ein

Abbildung 1. Trace bricht bei 0,2 Divisionen und startet bei fast 4,5 Divisionen neu.

Geben Sie hier die Bildbeschreibung ein

Abbildung 2. Trace bricht bei 0,2 Divisionen und startet bei fast 4,25 Divisionen neu.

Das Problem ist nicht Ihr Zielfernrohr - es ist das Signal. Sie haben einen Jitter von mindestens 0,2 / 4 = 5 %.

Normalerweise können Sie anhand des 1-kHz-Testsignals auf der Vorderseite der meisten Tischoszilloskope bestätigen, dass das Oszilloskop stabil ist.

Ist es also wahrscheinlich, wie @DKNguyen vorgeschlagen hat, ein Softwareproblem? Ja, ich programmiere meinen PIC-Mikroprozessor, wo ich ihn programmiere. Ich gehe also davon aus, dass sich die Ausführungszeit des Codes zwischen jeder Wiederholung ändern muss.
Ja, ich würde sagen, das ist wahrscheinlich.
@Keno Ich würde das nicht als Softwareproblem bezeichnen . Wenn sich Ihr Code in einer Schleife befindet, die ein Status-Flag überprüft, kann die Ausführungszeit der Schleife variieren. Oder wenn Unterbrechungen auftreten, kann die Schleifenzeit variieren. Wenn dies der Fall ist, ändert Holdoff die Anzeige nicht.
@glen_geek Ich denke jedoch immer noch, dass es sich um ein Softwareproblem handelt. Ich versuche, es zu lösen, während wir sprechen, und habe auch eine gewisse Reduzierung des Jitters beim Ändern von Code. Ansonsten ja, mein Code prüft auf Statusflags und tut dies auch über Interrupts. Ich beschäftige mich mit dem Timer, der höchstwahrscheinlich die Ursache des Problems ist, das ich zu lösen versuche.
@keno Interrupts, Verzweigungscode, Cache und Schleifen, die eine unterschiedliche Anzahl von Iterationen ausführen können, tun dies alles.
@DKNguyen Seltsamerweise verursacht die Verwendung von Schleifen und während des Programms dieses Flackern nicht. Die Implementierung des Timers tut es. Wie auch immer, ich weiß, dass diese Diskussion für die gestellte Hauptfrage bereits den Rahmen sprengt, aber hier ist ein Link zu einem anderen Forum, in dem ich nach Software frage - für alle, die sich für diese Angelegenheit interessieren. ;)
@Keno Wenn Ihre Loops jedes Mal genau gleich laufen und nichts anderes passiert, würde ich kein Flackern erwarten. Wenn der Timer das Signal direkt generiert, würde ich auch kein Flackern erwarten, da es von einer Hardware generiert wird. Aber wenn Sie Timer-ISR-Code verwenden und der IC andere Dinge tut, dann würde ich ein Flackern aufgrund der Variabilität der Kontextänderungen erwarten, wenn der Interrupt ausgelöst wird.
@DKNguyen Eigentlich habe ich sogar versucht, einen Timer mit Polling und einer Verzögerung ohne Timer zu implementieren, aber mit einer einfachen for () -Schleife ... habe ich die gleichen Ergebnisse erzielt. Die Ursache dieses Zitterns liegt jedoch definitiv in der Timer-/Verzögerungssektion

Es sieht so aus, als ob es sich eher um ein charakteristisches Signal als um ein Problem mit dem Oszilloskop handelt. Sogar ein digitales Oszilloskop hätte ein ähnliches Problem.

Eine Möglichkeit, diese Art von Problem zu umgehen, die ich bei der Entwicklung von MCU-Software verwende, besteht darin, einen nicht verwendeten GPIO auf der MCU auszunutzen, um als Auslöser für den Bereich zu fungieren.

Verbinden Sie diesen zusätzlichen GPIO mit dem anderen Kanal des Oszilloskops (oder dem externen Trigger, wenn alle Kanäle verwendet werden).

Schalten Sie diesen GPIO in Ihrem Code zu dem Zeitpunkt um, zu dem Sie den Bereich auslösen möchten.

Wie Transistor in einer anderen Antwort angibt, wird das Problem wahrscheinlich durch Jitter im Signal verursacht - selbst das kann hilfreich sein, indem Sie den Trigger aus Ihrem Code heraus ausgeben, da Sie in einigen Situationen möglicherweise dafür sorgen können, dass der Trigger den gleichen Jitter wie der hat Signal, das Sie beobachten möchten, und hebt sich somit auf. Zum Beispiel sollte ein GPIO-Trigger, kurz bevor das Zeichen gesendet wird, den Jitter drastisch reduzieren, anstatt vom vorherigen Zeichen auszulösen.

Problem mit dem flackernden Signal des analogen Oszilloskops
AntwortenHierDatenschutz-Bestimmungen1y, 2v