Problema de señal de parpadeo del osciloscopio analógico

Estoy usando el osciloscopio de doble trazo BK Precision 2125C (30 MHz) , que es analógico. Estoy tratando de observar la señal generada por la salida del microprocesador. Estoy viendo una señal parpadeante (se mueve rápidamente hacia la izquierda y hacia la derecha a los lados del alcance) por lo que sé que probablemente no parpadee así en la "vida" real, pero es muy probable que sea un problema de activación del alcance. Estoy casi seguro de que ese es el caso, ya que observé una onda cuadrada normal antes de esta y también parpadeó como la actual, en alguna configuración de disparo, pero después de restablecer el disparo, no hubo más parpadeo.

Este parpadeo es realmente molesto cuando se trata de observar pequeños cambios en la señal o leer su período.

Aquí está el video para medir la señal de parpadeo.

Solo como referencia, para esta medida, estoy usando la siguiente configuración:

  • Entrada acoplada de CC, CH1 (obtiene el mismo comportamiento con el acoplamiento de entrada de CA)
  • acoplamiento: norma (mismo comportamiento con "auto" o "TV-V" o "TV-H")
  • fuente: CH1
  • modo principal (no modo de mezcla o retardo)
  • voltaje/div: 2V/div
  • base de tiempo/div: 2ms/div

Con respecto al "nivel de activación" y "retención", sin embargo, giro ambas perillas (literalmente cualquier combinación), siempre obtengo una señal parpadeante o no sincronizada. De lo contrario, estoy midiendo en la salida de MCU (transmisión UART de 10k pull-up) con sonda pasiva normal (en tasa de divisor interno 1: 1).

¿Alguna idea de cómo debería lograrse la vista de la señal de mirada "parada" en la pantalla del osciloscopio?

Enlace de vídeo roto. Además, es mejor que su señal sea periódica en un osciloscopio analógico o parpadeará a menos que use el modo de disparo único que los osciloscopios analógicos no tienen. Si sabe lo suficiente para hacerlo de manera segura, conéctelo a la red eléctrica de CA (o a un generador de señal que sea más seguro pero que también requiera más dinero) y vea si funciona. Si es así, su señal no es tan estable como cree.
@DKNguyen Enlace de video actualizado. Sí, una toma no está disponible aquí. Entonces, no hay medición de señal aperiódica con este alcance entonces... :(
Por otro lado, ES periódico... Se repite más tarde... Medí otra señal de transmisión de datos UART otro día, y la imagen no parpadeaba en absoluto, mientras que esta parpadea constantemente en cualquier configuración de activación.
Eso se parece más a fluctuaciones en su señal. ¿Cómo genera la señal la MCU? ¿En software? O en hardware (periférico), y si en software, ¿el código está haciendo algo más? Especialmente tareas que pueden variar en el tiempo (bucles, interrupciones, etc).
@DKNguyen Sí, programación, por lo que es muy posible que el tiempo de ejecución del código varíe entre repeticiones.
Cree un código que literalmente no haga nada más que contar bucles y cambie el pin y no debería ver fluctuaciones ya que el código se ejecuta exactamente igual cada vez (a menos que tenga caché en su MCU)
@DKNguyen Solo para aclarar, muchos osciloscopios analógicos tienen modo de disparo único (por ejemplo, Tektronix 453). No es tan útil porque no hay capacidad de almacenamiento.

Respuestas (2)

ingrese la descripción de la imagen aquí

Figura 1. El rastro se rompe en 0,2 divisiones y se reinicia en casi 4,5 divisiones.

ingrese la descripción de la imagen aquí

Figura 2. La traza se rompe en 0,2 divisiones y se reinicia en casi 4,25 divisiones.

El problema no es su alcance, es la señal. Tiene un jitter de al menos 0,2 / 4 = 5%.

Por lo general, puede confirmar que el osciloscopio es estable utilizando la señal de prueba de 1 kHz presente en el panel frontal de la mayoría de los osciloscopios de banco.

Entonces, probablemente, como sugirió @DKNguyen, ¿problema de software? Si, estoy programando mi microprocesador PIC, donde lo programo. Así que supongo que el tiempo de ejecución del código debe cambiar entre cada repetición.
Sí, diría que es probable.
@Keno No llamaría a esto un problema de software . Si su código está en un ciclo que verifica algún indicador de estado, el tiempo de ejecución del ciclo puede variar. O si ocurren interrupciones, el tiempo de bucle puede variar. Si es así, Holdoff no cambiará la visualización.
@glen_geek Sin embargo, sigo pensando que es un problema de software. Estoy tratando de resolverlo mientras hablamos, y también obtuve cierta reducción en el nerviosismo al modificar el código. De lo contrario, sí, mi código verifica los indicadores de estado y también lo hace a través de interrupciones. Estoy lidiando con el temporizador, que probablemente sea la fuente del problema que estoy tratando de resolver.
Las interrupciones de @keno, el código de bifurcación, el caché y los bucles que pueden ejecutar diferentes números de iteraciones lo harán.
@DKNguyen Sin embargo, extrañamente, solo usar bucles y mientras está en el programa, no causa este parpadeo. Implementar el temporizador, sí. De todos modos, sé que esta discusión ya está fuera del alcance de la pregunta principal, pero aquí hay un enlace a otro foro, donde pregunto sobre el software, para cualquier persona interesada en este asunto. ;)
@Keno Si sus bucles se ejecutan exactamente de la misma manera cada vez y no sucede nada más, entonces no esperaría un parpadeo. Si el temporizador está generando directamente la señal, tampoco esperaría un parpadeo, ya que está siendo generado por ahrdware. Pero si está utilizando el código ISR del temporizador y el IC está haciendo otras cosas, esperaría un parpadeo debido a la variabilidad en los cambios de contexto cuando se activa la interrupción.
@DKNguyen En realidad, incluso probé el temporizador con sondeo e implementé el retraso sin temporizador, pero usando un bucle for() simple... obtuve los mismos resultados. Sin embargo, la fuente de este nerviosismo es definitivamente de la sección de temporizador/retardo

Parece como si fuera una característica de la señal en lugar de un problema con el osciloscopio. Incluso un alcance digital tendría un problema similar.

Una forma de evitar este tipo de problema que utilizo cuando desarrollo software MCU es explotar un GPIO no utilizado en la MCU para que actúe como disparador del osciloscopio.

Conecte este GPIO adicional al otro canal del osciloscopio (o al disparador externo si todos los canales están en uso).

Dentro de su código, cambie este GPIO en el momento en que desee activar el alcance.

Como Transistor indica en otra respuesta, es probable que el problema se deba a la fluctuación de fase en la señal; incluso eso podría solucionarse emitiendo el disparador desde su código, ya que en algunas situaciones puede arreglar que el disparador tenga la misma fluctuación que el señal que desea observar y así se cancela. Por ejemplo, un disparador GPIO justo antes de que se envíe el carácter, el UART debería reducir drásticamente la inestabilidad en lugar de disparar desde el carácter anterior.

Problema de señal de parpadeo del osciloscopio analógico
RespuestasAquíPolítica de privacidad1y, 0v