¿Por qué cambia el tiempo en el marco de datos usando la codificación Manchester?

Recibí con éxito un par de tramas de datos de un transmisor de RF. Comparé un par de fotogramas consecutivos y la desviación de tiempo entre ellos es marginal, por lo que estoy convencido de que tiene una precisión razonable con una resolución de 50 µs.

Creo que está utilizando la codificación Manchester y una de las propiedades de la codificación Manchester es la capacidad de recuperar la señal del reloj. Por lo tanto, esperaría que el preámbulo de la señal obedezca el reloj de los datos.

ingrese la descripción de la imagen aquí

(haga clic para ampliar la imagen)

Aparte del porche delantero (-5,5 ~ 0 ms), esperaría que el preámbulo (-38 ~ -5,5 ms) obedezca al mismo reloj que los datos (a partir de 0), pero no es así. El reloj de preámbulo es aproximadamente un 10% más rápido que el reloj de datos.

¿Cuál es el razonamiento detrás del cambio de relojes? ¿No está eso en contradicción con las propiedades de recuperación del reloj de Manchester?

El extremo del receptor es un TDA-5200 combinado con un ATmega32L protegido, las partes internas del transmisor son probablemente similares pero actualmente desconocidas.

Respuestas (2)

La mayoría de los receptores tienen cortadores de datos que se ajustan dinámicamente a la intensidad de la señal entrante. Como resultado, siempre obtiene un flujo de bits, incluso cuando no hay una señal transmitida para cortar. En ese caso, el cortador de datos solo está cortando el ruido.

De una forma u otra, el receptor debe ser capaz de identificar el inicio de un mensaje de Manchester, aunque los 1 y los 0 se escupan continuamente del cortador de datos. Hay una serie de esquemas, pero generalmente requiere que cada mensaje esté precedido por algo que sea identificable pero que garantice que no estará contenido en ninguna parte dentro de un mensaje válido. Este algo se conoce generalmente como el preámbulo .

El decodificador siempre está buscando esta firma de preámbulo especial, ya sea en medio de la decodificación de un mensaje o no. Detectar el preámbulo incluso cuando el decodificador cree que está en lo más profundo de un mensaje es importante por dos razones. Puede estar en el mensaje erróneamente, y podría estar en un mensaje débilmente recibido que está siendo pisoteado por un nuevo mensaje fuertemente recibido. En el último caso, el mensaje original nunca se puede decodificar de todos modos. Lo mejor que puede hacer es que el mensaje parcial original no lo distraiga de decodificar el mensaje posterior que puede decodificar.

Hay muchos esquemas de preámbulo. Aparentemente, en este caso, usaron deliberadamente una frecuencia de reloj diferente para que se detecte como un mensaje no válido después de algunos ciclos. Esa es una forma válida de hacer las cosas.

Usualmente uso el mismo reloj pero una larga secuencia de sucesivos niveles largos, que serían 000000.... o 111111... dentro de un mensaje real. Sin embargo, utilizo un esquema de relleno de bits en el cuerpo del mensaje para que no sea posible más de un número predeterminado de niveles largos consecutivos. Por ejemplo, si las reglas de relleno de bits permiten como máximo 7 bits consecutivos del mismo valor, entonces puede haber como máximo 14 niveles largos consecutivos dentro de un mensaje válido. Mi preámbulo viola deliberadamente esta regla. Tan pronto como el decodificador ve el decimoquinto nivel largo consecutivo, aborta la lógica en la que se encontraba y pasa al estado de detección de preámbulo, esperando un bit de inicio de la polaridad correcta.

Agregado sobre el corte de datos

El corte de datos se refiere a la interpretación de la señal analógica entrante en una señal digital. Idealmente, la señal analógica que sale del receptor de radio en bruto ya parece una señal digital, pero eso no sucede en realidad por una variedad de razones. Incluso si lo hiciera, la amplitud de esa señal dependería bastante de la distancia desde el transmisor, solo para enumerar una variable. Como resultado, la señal de radio sin procesar no puede ser interpretada directamente por una puerta lógica digital. El proceso de pasar de la señal analógica recibida a una verdadera señal digital se denomina corte de datos .

Los antiguos cortadores de datos analógicos eran poco más que un comparador con la señal recibida en una entrada y una versión filtrada de paso bajo de esa señal en la otra. La frecuencia del filtro de paso bajo se estableció lo suficientemente baja como para no reaccionar mucho a los bits individuales, pero encontrar el promedio de CC en unos pocos bits. Luego, esto se usó como el nivel medio medio de la señal para decidir si la señal instantánea era alta o baja.

Una de las razones por las que la codificación Manchester es popular con este tipo de señales es que cada bit es alto la mitad del tiempo y bajo la mitad del tiempo, con un promedio de nivel medio en cada bit. Aún así, los cortadores de datos analógicos necesitaban algunos bits para establecerse correctamente y comenzar a producir la señal digital correcta después de un gran cambio en el nivel de la señal recibida. Esta es otra razón más para el preámbulo, que es dar tiempo a la segmentación de datos para que se asiente.

Hoy en día, con los microcontroladores fácilmente disponibles y probablemente decodificando la señal de corte de datos de todos modos, la señal demodulada sin procesar se puede alimentar directamente al micro y el corte de datos se realiza en el firmware. Esto permite emplear fácilmente operaciones no lineales en la segmentación de datos que serían difíciles en hardware analógico.

Un esquema que he usado algunas veces es muestrear la señal analógica recibida alrededor de 10 veces por bit Manchester. Mantengo un búfer de solo un poco más de un bit de muestras, encuentro su mínimo y máximo, y uso el promedio de ellos como el umbral de corte. Dado que un nivel alto o bajo nunca dura más de 1 bit de tiempo en un flujo de Manchester, esto garantiza que tanto el nivel alto como el bajo estén en el búfer cuando importa. Una ventaja de este esquema es que el establecimiento de la segmentación de datos es mucho más rápido que si se utilizara un filtro de paso bajo analógico.

A menudo, ayuda aplicar quizás dos polos de filtrado de paso bajo al flujo de lecturas A/D antes de cualquier otro procesamiento. Esto ayuda a reducir el ruido aleatorio y un poco del ruido de cuantificación. El filtro debería asentarse en torno al 80-90 % en 1/2 bit de tiempo.

Lo anterior se hace en la rutina de interrupción A/D. Después de cortar, la interrupción A/D puede enviar el resultado a un FIFO drenado por el decodificador que se ejecuta en primer plano, o puede clasificar cada nivel como largo, corto o no válido, y enviarlo a un FIFO para que lo maneje el decodificador.

He implementado este algoritmo en un dsPIC con un A/D de 12 bits que decodifica un flujo Manchester de 10 kbit/s. Funcionó tan bien que decodificó correctamente paquetes completos donde la amplitud alta/baja era solo unos pocos LSB. No pude distinguir bits en el osciloscopio, pero la cortadora de datos digital los recogió de todos modos y el decodificador pudo decodificar el paquete. El paquete contenía una suma de verificación CRC de 20 bits, que es como sé que el decodificador decodificó el paquete correctamente.

Hay una muy buena razón por la cual el preámbulo es diferente. ¿Cómo sabría cuándo comenzar correctamente el tiempo rx para el primer byte de los datos de carga útil? Si el preámbulo obedecía al mismo tiempo que los datos, no podría detectar fácilmente el inicio del byte uno.

Puede usar la misma velocidad de datos para el preámbulo, pero el final del preámbulo debe estar "marcado" con algo que sea un byte único e inconfundible. Para hacer esto, envié un byte con un bit adicional (rellené una paridad 0) y el uart lo marca como un error de paridad y listo, sé que el siguiente byte es el primer byte de la carga útil.

Hay muchas maneras de hacer esto y alterar el tiempo es solo una forma. Tenga en cuenta también que el último byte del preámbulo en su imagen es claramente diferente a otras partes del preámbulo.

Pensaría que para los datos codificados en Manchester, un preámbulo de algo como 1101100100 repetido sería ideal, ya que ese patrón de bits no podría aparecer en los datos codificados en Manchester, pero aún tiene una longitud de ejecución máxima de dos y sin sesgo de CC neto.
Diría que el 'porche delantero' (-5.5 ~ 0 ms) marca claramente el final del preámbulo debido a la duración, ¿sería un buen indicador dónde comienzan los datos reales? ¿Es eso a lo que te refieres como 'el último byte del preámbulo'?
@supercat DC-bias está claramente roto con 'front porch' (-5.5 ~ 0 ms) y postámbulo (bajo durante casi 20 ms). Interesante observación Por cierto, nuevamente la señal LF entre TDA-5200 y AVR está acoplada a CC.
@jippie sí, a eso me refiero como el último byte del preámbulo.