¿Implicaciones de transmisiones de ráfagas cortas en la radio? (SDR / gnu-radio)

No podemos transmitir de forma confiable paquetes individuales

Sí, yo tampoco. Si puede encontrar cualquier protocolo inalámbrico en cualquier lugar que nunca deje caer un paquete, háganoslo saber.

Supongo que estás trabajando bastante "cerca del metal" con este SDR, ejecutando experimentos simples en lugar de usar un protocolo probado y comprobado. Aquí hay un montón de cosas que a menudo veo mal. Quizás si tiene suerte, solo esté viendo uno de estos problemas, y es uno de los problemas más fáciles de solucionar. Casi todo el mundo está creando un protocolo inalámbrico desde cero en varios de estos problemas.

• Tal vez el cortador de bits está cortando bits de manera incorrecta. Los protocolos on-off más simples deben discriminar entre "on" y "off". La mayoría de los cortadores de bits asumen que un promedio simple de la señal en los últimos N bits está aproximadamente a medio camino entre "on" y "off" y es un buen punto de referencia. A mitad de un paquete, es una suposición bastante buena. Cuando no ha transmitido nada durante unos segundos, necesita transmitir algunos datos ficticios (un preámbulo) con un buen balance de 1 y 0 bits (a menudo 01010101 "UUUU" en los protocolos más simples). Los datos en el preámbulo se recibirán incorrectamente, pero empujan la referencia del cortador de bits a un punto donde los datos importantes en el paquete se pueden dividir adecuadamente.

• Quizás la ganancia del AGC no se haya configurado correctamente. Con ASK o una modulación de IQ más compleja, la ganancia en el AGC debe configurarse correctamente para decodificar los símbolos correctamente. Si no ha transmitido nada durante unos segundos, el AGC aumenta la ganancia hasta el final, y la mayoría de los símbolos (excepto los símbolos de amplitud máxima) se recibirán incorrectamente. Nuevamente, datos ficticios, un preámbulo, para impulsar la ganancia del AGC a un punto en el que los datos importantes en el paquete puedan decodificarse correctamente.

• Quizás la frecuencia central no sea exactamente correcta, o las fases I y Q están "rotadas". Hay formas de detectar y compensar esto, generalmente utilizando los patrones conocidos cerca del final del preámbulo.

• Quizás el tiempo de símbolo / bit es una fracción de un símbolo / bit desactivado. Para paquetes muy cortos, uno de los 7 códigos de Barker conocidos es útil para volver a alinear la sincronización de bits.

• Quizás su tiempo de bit es bueno, pero su alineación de bytes está desactivada por algún número entero de bits. Muchas personas utilizan 10 bits, un bit de inicio, 8 bits de datos y un bit de parada, incluso en sistemas de comunicación síncrona, porque hace que la depuración y la alineación de bytes sea mucho más fácil.

• Tal vez su alineación de bits y bytes esté bien, pero la estructura del paquete está desactivada: el software está recogiendo algunos bytes aleatorios en medio de un paquete, interpretándolos como "destino" y "longitud" Campos del encabezado del paquete. Algunas personas reservan el "carácter de nueva línea" para el carácter de inicio de paquete (el último byte en el preámbulo, o el primer byte del encabezado del paquete, dependiendo de su punto de vista), y prohíben que ese carácter ocurra dentro del paquete, para facilitar el enmarcar correctamente cada paquete y depurar cuando las cosas van mal.

Todos los problemas anteriores ocurren incluso cuando prácticamente no hay ruido externo. Con los problemas anteriores, si envía un paquete las veces suficientes, a veces el paquete se alineará y saldrá bien.

Si ocasionalmente recibe un poco de ruido, existen técnicas simples para solucionarlo: CRC, confirmación, reintento en el tiempo de espera. En los casos en que desenchufé accidentalmente la antena, o reinicié el receptor, el transmisor puede volver a intentar transmitir el mismo paquete cientos de veces antes de que reciba un buen acuse de recibo.

Si recibe mucho ruido, existen técnicas terriblemente complicadas para solucionarlo: modulación codificada en trellis, decodificación iterativa de Viterbi, corrección de errores hacia adelante, salto de frecuencia, detección y evitación de ruido, etc.

Programación en serie / Formación de paquetes de datos

Esto puede parecer una tontería, pero ¿has intentado usar un protocolo documentado y probado de forma previa? Existen varios métodos y protocolos de transmisión que ya están en uso y que al menos demostrarían que el lado del hardware se está comportando correctamente. Una vez que tenga un enlace operable con un protocolo existente en su frecuencia / ancho de banda elegido, sabrá que el hardware no es su problema. Desde este punto en adelante, puede medir efectivamente los resultados de cada cambio realizado en su nuevo software. ¡Recuerde documentar cuidadosamente CADA cambio que haga antes de cambiar cualquier otra cosa! Ok, sé que suena aburrido pero puede ser increíblemente útil para hacer referencia a los cambios realizados anteriormente en el desarrollo. ( No importa cuánto lo intentes, no recordarás todos los detalles más adelante cuando lo necesites. A lo largo de los años, a menudo he encontrado que los documentos antiguos de desarrollo han sido útiles al trabajar en nuevos proyectos. ) Al configurar los enlaces de datos, hemos descubierto que es muy útil tener un tercer sistema independiente que controle las transmisiones para que pueda "ver" sus señales. Un buen analizador de espectro sin duda ayuda, pero no todos tienen uno a mano, incluso un simple receptor o escáner puede proporcionar una respuesta audible útil. La extensión de la longitud del preámbulo también ha demostrado ser muy útil durante la configuración / depuración, y se reduce nuevamente para el funcionamiento general una vez que el enlace está activo.

Es interesante que tengas este problema. Mi compañero de laboratorio está trabajando con una radio GNU (USRP1) en este momento y descubrió que los paquetes muy cortos solían ser basura. Él fue capaz de reducirlo a un par de cosas, pero en última instancia no se ha dado cuenta de por qué está sucediendo y ahora solo se está enfocando en paquetes más largos.

Primero que nada, cada vez que las radios inician una transmisión, el receptor tiene que volver a sincronizarse con el transmisor. Por lo general, hay un preámbulo en el paquete que permite que esto suceda, pero existe la posibilidad de que las radios no puedan obtener una sincronización completa en paquetes muy cortos.

2º, estaba extrayendo todos sus datos de un archivo. Creía que el sistema podría haber comenzado a transmitir antes de que los datos salieran del archivo y el tiempo de configuración de un disco duro para recuperar el archivo causó un "jitter" en la transmisión.

Si el paquete llega finalmente, significa que tienes algún problema de interferencia. Algunas posibilidades, basadas en la suposición de que sus transferencias continuas no son realmente tan continuas (datos caídos, como usted indica):

1) Fuente fuerte de interferencia en la misma frecuencia que está utilizando para la transmisión. Esto se puede resolver moviéndose a otra frecuencia.

2) Antena no coincidente. En este caso, la antena no puede pasar suficiente cantidad de la señal recibida a USRP (o desde USRP). Necesita un mejor diseño de antena o una mejor adaptación.

3) No está recibiendo suficiente señal. En este caso la señal se enterrará en el ruido. Puede resolverse usando más potencia en el lado de transmisión.

4) No hay suficiente filtrado en el lado receptor. La señal puede ser inundada por otras señales recibidas por la antena, incluso si están en otras frecuencias. La relación señal / ruido / interferencia se puede aumentar al filtrar la señal a través del filtro de paso de banda que seleccionará la señal y suprimirá las otras señales que no le interesan. Idealmente, dicho filtro se colocará entre la antena y el USRP. Como en 2) el filtro tiene que ser la impedancia adaptada a la antena en un lado, y al USRP en el otro lado. Se debe utilizar otro filtro de banda estrecha en el lado del software para reducir aún más la selección.

El hecho de que esté transmitiendo en ráfagas no desempeña ningún papel, a menos que tenga algún problema de tiempo al cambiar entre transmisión y recepción. La calidad del hardware de USRP tampoco debería ser un problema.

Puedes intentar experimentar con 1) y 3), y si no funciona, entonces necesitarás que alguien con backgroung en diseño de RF haga 2) o 4) por ti.

ACTUALIZACIÓN:

Dado el análisis de los amigos de Kellenjb, esto realmente parece ser un problema con el software GNU Radio. Mire qué otras posibilidades le brinda tanto para transmitir como para recibir, y trate de usar otras modulaciones, los métodos de proporcionarle los datos, etc. para abordar el problema. Otra posibilidad es depurar el software.