¿Cómo implementar el código de línea?

Estoy buscando una manera fácil de implementar un código de línea (tanto las partes de codificación como las de decodificación). Esto podría ser algo como Biphase Mark Code, Differential Manchester o cualquier otra cosa que tenga las siguientes propiedades:

  • Una fluctuación considerable está bien (los tiempos de borde pueden estar desactivados en ~20% del tiempo de un bit)
  • No se necesita sincronización de reloj o reloj por separado (esto no puede usar SPI o UART, solo hay una línea que solo puede transmitir dos niveles)
  • 1 y 0 aproximadamente equilibrados (no peor que un desequilibrio de 2:1) y sin tiradas largas del mismo símbolo (no más de 3-5 1 o 0 consecutivos)
  • ¡Rápido! Necesita 1 Mbit/s o más. (Tengo microcontroladores 80MIPS en cada lado, pero la decodificación de software probablemente aún no sea práctica)
  • ¡Barato! Idealmente, algo que se pueda hacer con periféricos de microcontroladores o un IC codificador/decodificador económico.
Suena como USB, excepto por el número de líneas.
@IgnacioVazquez-Abrams: Un poco como USB, sí. También tal vez un poco como 10Mbit ethernet PHY, y mucho como IRDA.
¿A qué distancia, entre la codificación y la decodificación, debe funcionar esto? ¿Hay un terreno común? ¿Por qué sólo una señal? ¿Es eso una limitación de la MCU o del 'cableado'?
¿Cuál es el ancho de banda de la línea? ¿Es esa fluctuación entre un bit y el siguiente o variará más lentamente, o es una desviación constante de la frecuencia de reloj "ideal"?
¿De dónde viene el nerviosismo de todos modos? ¿Estás transmitiendo a lo largo de una línea y estás proporcionando un remitente y un receptor?
@gbulmer: Es óptico, básicamente un LED y un fotodiodo. Sin tierra común, sin cableado.
@HannoBinder: La fluctuación se produce principalmente porque el tiempo de subida y el tiempo de caída son asimétricos, y los umbrales bajo/alto del lado de recepción no están configurados de tal manera que lo compensen. En una secuencia ..00100.. el 1 aparece más largo que en el lado de recepción que cuando se envía; en una secuencia ..11011.. el 0 aparece más corto. Esto es bastante predecible pero bastante difícil de arreglar debido a la forma en que funciona el lado de recepción.
@HannoBinder: el ancho de banda es de aproximadamente 16-20 MHz.
¿Por qué no se puede usar un esquema de tipo UART o UART? El transporte unidireccional solo requiere una línea de datos. Además, ¿qué tipo de interfaces tiene disponible su procesador de 80 mips? Después de la recepción, ¿pueden registrarse los datos en un bus paralelo? ¿O necesita entrar en el procesador en una línea serial o???
@mkeith: UART no funciona cuando hay esta cantidad de inestabilidad; Lo intenté. Los procesadores tienen UART, SPI, I2C, I2S, (quizás) CAN,... todo lo estándar, pero nada que parezca aplicable aquí. Después de recibir los datos que salen por USB, solo necesito algo que pueda enviarlos por UART al chip puente USB (como FT232R, FT231X).
@mkeith: un poco más de detalles sobre UART no funciona: intenté enviar bytes que están balanceados 0-1 sobre UART (como 0xAA, 0x55, 0xA5, ...) y sin pausas entre bytes. El efecto es que algunos patrones se reciben bien, pero no todos, y no es 100% fiable incluso entonces.
No tiene sentido. Si cumplió con la especificación UART, debería funcionar. Usted dice que no hay pausa, pero asumo que usó una configuración de bits de inicio y parada correcta/válida. Si es así, no veo ninguna razón por la que no funcione. Si no fue así, entonces hay un problema misterioso y tampoco hay garantía de que algún otro esquema funcione. De todos modos, existen UART de alta velocidad que funcionan como periféricos. Pero pueden necesitar un bus paralelo. Buena suerte.
¿De cuántos microsegundos es su jitter? "~20% del tiempo de un bit", pero ¿es un bit a 1 megabit/segundo o 10 megabits/segundo?
@davidcary: Creo que lo medí a 2 Mbit/s, así que digamos 100 ns de fluctuación. Tendré que volver a comprobar.

Respuestas (1)

La mala noticia es que algunos problemas simplemente no se pueden solucionar en el software; debe relajar sus restricciones o agregar nuevo hardware.

Muchos sistemas de acoplamiento óptico tienen retardos de encendido que no son exactamente iguales a los retardos de apagado, como ya notó: "..00100.. el 1 parece más largo... ..11011.. el 0 parece más corto". En este sistema, el retraso de 1 a 0 es más largo que el retraso de 0 a 1. Si tiene suerte, esos retrasos son lo suficientemente consistentes como para compensarlos. Un extensor de pulsos puede ser tan simple como un diodo, un capacitor y un par de resistencias.

Muchos códigos de línea parecen cumplir con sus criterios, incluida la codificación 4B5B , la codificación 8b/10b (o cualquiera de los códigos 3b/4b o 5b/6b que se usan normalmente), la codificación 6b/8b , la codificación Manchester y sus variantes, como Diferencial Codificación Manchester , Tres de Seis, Fibra Óptica , Modulación de posición de pulso , etc.

compensación de software

Supongo que ya tiene configurado un hardware de comunicación óptica de espacio libre que es un poco peculiar, y está tratando de compensar las peculiaridades del hardware por completo en el software.

Un esquema rápido y sucio es:

  • Envíe un preámbulo justo antes de enviar cada paquete de datos, normalmente un patrón "equilibrado", tal vez caracteres 'U' (0101_0101 binario), para ayudar al cortador de bits en el hardware de recepción a encontrar el punto de referencia apropiado para distinguir entre 0 y 1.
  • Envíe bytes (quizás usando el UART o el periférico SPI en el remitente) de una lista corta que son "fácilmente discriminados" en el receptor. He visto algunos sistemas que envían solo dos bytes únicos a un UART configurado como 8N1 -- 0x00 (es decir, 9 bits cero seguidos de 1 bit uno) y 0xFF (es decir, 1 bit cero seguido de 9 bits uno). (Tienen solo 2 bytes en esa lista). Si tiene suerte, puede usar una lista más grande.
  • El receptor, por cada byte recibido (quizás usando el periférico UART), usa una tabla de búsqueda para decodificarlo en los bits apropiados. Con el ejemplo anterior, el receptor decodifica pulsos "cortos" de ceros como un bit 1 y pulsos "largos" de ceros como un bit 0.

Muchos códigos de línea se pueden aproximar adecuadamente dividiendo los bytes en una secuencia de dígitos hexadecimales (nybbles), dígitos cuaternarios o dígitos binarios individuales (bits) y luego diseñando una tabla de búsqueda que transforme ese dígito en 8, 10, 16 o más. bits (chips) que, cuando se envían al UART o al periférico SPI, se aproximan adecuadamente a ese código de línea.

Quizás su sistema pueda distinguir de manera confiable entre 16 bytes transmitidos diferentes, por lo que cada byte transmitido puede decodificarse en 4 bits de datos: su transmisor usa uno de los 16 bytes en su lista corta. Cuando envía un byte con un 1 bit aislado, y el hardware lo estira lo suficiente como para que el receptor a veces vea un patrón con un solo 1 bit y otras veces ve un patrón con dos 1 bits, ambos patrones deben decodificarse en el mismo 4 bits de datos. (Además, el receptor debe desechar de algún modo cualquier ruido entre paquetes, desechar los bits de preámbulo 'U', etc.).

pre-énfasis

A veces, puede insertar un extensor de pulsos en algún lugar del hardware del transmisor y ajustar las resistencias en el transmisor de modo que, en el punto crítico del receptor, el retraso de 1 a 0 sea prácticamente el mismo que el retraso de 0 a 1. .

post-énfasis

A veces, puede insertar un extensor de pulsos en algún lugar del hardware del receptor y ajustar las resistencias del receptor de manera que, en el punto crítico del receptor, el retraso de 1 a 0 sea prácticamente el mismo que el retraso de 0 a 1. .

Implementaciones existentes

Hay varias implementaciones existentes de comunicación óptica de espacio libre que se ejecutan a 1 megabit/segundo o más rápido.

  • Asociación de datos infrarrojos (IrDA) ; si tiene suerte, su microcontrolador ya tiene soporte de hardware para IrDA)
    • MIR a 1 Mbit/s (?)
    • FIR a 4 megabits/segundo (Al buscar en http://Digikey.com/ "irda fir", sin comillas, aparece un montón de módulos transceptores. Tal vez "¿Se puede conectar el módulo IrDA FIR (A) directamente al SPI o UART pines del microcontrolador (B)?" sería una buena pregunta independiente? (¿Alguno de los diagramas de circuito en la hoja de datos LT1328 funcionaría para usted?).
    • VFIR a 16 Mbit/s
  • RONJA (dúplex completo de 10 megabit/s)
  • Li-Fi ("1,6 Gbit/s"?)

¿Te serviría uno de esos?

¡Gracias, una respuesta estelar! Tienes razón, tengo hardware óptico que funciona pero es un poco raro. No creo que la camilla de pulsos funcione porque el jitter no es tan consistente (pero ciertamente lo intentaré). Un codificador-descodificador IrDA (endec) probablemente funcionaría bien, pero no he podido encontrar ningún circuito integrado FIR/VFIR endec.
¿Cómo implementar el código de línea?
RespuestasAquíPolítica de privacidad1y, 0v