Tengo un diseño que espera una onda cuadrada de nivel TTL de un receptor de radio que se alimenta a un microcontrolador. Hay algo de ruido de nivel TTL ya que no se realiza codificación en el extremo de transmisión. Me preguntaba si alguien tenía algún consejo sobre cómo podría disminuir el ruido en el software. (Entiendo que hay varias soluciones de hardware, pero me interesa más aprender) No busco a nadie que me resuelva mi problema, solo algunos consejos.
¡Nombres/artículos/temas serían geniales!
De su último comentario, sugeriría sobremuestrear la entrada. Grabe varias muestras consecutivas, y luego su salida debería ser cualquiera que sea la mayoría de las muestras grabadas.
Por ejemplo, supongamos que graba 10 muestras. Si obtiene un pico de ruido, solo una o dos de las muestras se dañarán, mientras que la mayoría de ellas tienen el valor correcto. Si obtiene datos reales, eventualmente los 1 superarán en número a los 0 y la salida cambiará.
Hay muchas formas de trabajar con el ruido en el software, y cada vez son más eficaces para implementar en el software en lugar del hardware, lo que reduce el costo del sistema.
En lugar de intentar explicarlo yo mismo, voy a pasarte a Jack Ganssle , un consultor de sistemas integrados del que he crecido leyendo los artículos.
Tiene una lista de sus artículos en línea, el primero que me gustaría que hicieras es sobre el ruido analógico en los sistemas integrados . El segundo artículo al que tengo que vincularlo trata sobre el uso de software para reducir el ruido en su sistema .
También sugeriría su artículo sobre suavizado de entradas digitales y sistemas de autocalibración . Después de pasar un tiempo trabajando con sistemas integrados, me costó mucho extraer parte de esta información de mis propios errores, pero realmente disfruté leyendo sus formas de pensar. El sistema de autocalibración fue muy obvio para mí, pero la forma en que sugirió hacerlo fue valiosa para mí. Puede que no necesites la información, pero sus artículos me han ayudado.
Descubrí que Digital Signal Processing and the Microcontroller de Grover y Deller es el único libro sobre filtros que puedo entender. Desafortunadamente, es difícil encontrar barato.
¿Su software sondea esta entrada o utiliza un esquema de interrupción para procesarla?
Si está sondeando, presumiblemente lee la entrada a una velocidad mucho mayor que los cambios esperados en la señal. Si el ruido está bien separado, picos de muy alta frecuencia, estos se verían como muestras aisladas de la polaridad 'incorrecta'. Puede mitigar esto conservando las N muestras más recientes y decidiendo leer la entrada como la polaridad mayoritaria. Es decir, si N=5, entonces si tiene 3, 4 o 5 bits '1', su entrada es un '1'; si tiene 0, 1 o 2 bits '1', su entrada es un '0'. Esto es realmente solo una especie de filtro de paso bajo en el software.
Si está utilizando la entrada para activar interrupciones en el cambio (ambos flancos), puede hacer que la rutina de interrupción (ISR) inicie un temporizador para provocar una segunda interrupción poco tiempo después, pero más larga que el tiempo de pico de ruido. En lugar de que el pin de entrada ISR acumule directamente bits de señal, tiene el temporizador ISR para que lo haga. Por ejemplo, si la señal es baja y aparece un pico alto, el flanco ascendente inicia el temporizador, pero antes de que expire el tiempo, el flanco descendente del pico lo restablece, de modo que cuando la interrupción del temporizador finalmente se apaga, usted Estamos mirando la señal, no el ruido. La señal, por otro lado, activará el temporizador solo una vez, y el temporizador ISR podrá captar el nuevo nivel de señal.
De estos dos, Polled vs Interrupt, personalmente optaría por el enfoque polled, b/c (1) las interrupciones son simplemente más complicadas, y (2) un par de picos colocados patológicamente aún podrían darte una entrada falsa.
Quizás el "ruido" sea un problema causado por la falta de codificación. Los transmisores y receptores simples requieren NRZ; a menudo se usa el código Manchester.
solojeff
jeremy
endolito
jeremy