Analizamos el protocolo de mensajes de buscapersonas POCSAG, parte 2

Hola habr

En la primera parte , se consideró el protocolo de mensajes POCSAG. Se consideraron los mensajes digitales, ahora pasaremos a más mensajes "completos" en formato ASCII. Además, es más interesante decodificarlos, porque la salida será texto legible.


Para aquellos que estén interesados ​​en cómo funciona esto, continuó bajo el corte.

Recepción de la señal

Primero, se debe recibir la señal, para lo cual utilizamos el mismo receptor rtl-sdr y el programa HDSDR. Ya sabemos desde la primera parte que los mensajes de paginación pueden ser digitales (los contenidos son solo números 0-9, la letra U es "ugrent", un espacio y un par de paréntesis) y alfanuméricos, los contenidos son caracteres ASCII completos. Naturalmente, no sabemos de antemano el tipo de mensaje (todavía no es posible decodificarlos "de oído"), por lo que al grabar simplemente seleccionamos un mensaje que sea más auténtico.



El programa para convertir un archivo wav en una secuencia de bits ya se ha considerado, por lo que muestra inmediatamente el resultado: el mensaje de paginación en su conjunto se ve así:



Algunas características son visibles a simple vista, por ejemplo, se puede ver que la secuencia de inicio 01010101010101 se repite dos veces. Es decir Este mensaje no solo es más largo, sino que esencialmente consiste en dos "pegados", sin embargo, el estándar no lo prohíbe.

Decodificación

Para comenzar, recuerde los breves contenidos de la parte anterior . El mensaje de paginación comienza con un encabezado largo 0101010101, seguido de una secuencia de "paquetes" que se muestran en la imagen como Batch1..N:



Cada paquete comienza con una secuencia de inicio del Código de sincronización de trama (01111100 ...) seguida de bloques de 32 bits. Cada bloque puede almacenar una dirección o un cuerpo de mensaje.

La última vez que miramos solo mensajes digitales, ahora estamos interesados ​​en mensajes ASCII. En primer lugar, debe aprender a distinguirlos. Para hacer esto, necesitamos el campo "Bits de función": si estos 2 bits son 00, entonces el mensaje es digital, si es 11, luego texto.

Como puede ver en la figura, se asignan 20 bits al campo de mensaje, que se adapta perfectamente a los 5 códigos BCD de 4 bits si el mensaje es digital. Pero si el mensaje es texto, entonces una gran cantidad de texto no puede caber en 20 bits, y 20 no puede dividirse entre 7 u 8. Se puede suponer que la primera versión del protocolo (y fue creado ya en 1982) solo admitía mensajes digitales ( sí y es poco probable que los primeros buscapersonas de esos años en tubos nixie puedan mostrar más ), y solo entonces, en la próxima versión, se agregó soporte para ASCII. Pero desde ya no era posible violar el estándar de formato, era más fácil: el flujo de bits simplemente se combina como está (se extraen 20 bits de cada mensaje y se agregan al final del búfer), y solo entonces, al final, todo esto se decodifica en caracteres.

Considere un bloque de un mensaje recibido (se agregan espacios para mayor claridad):

0 0001010011100010111111110010010 1 00010100000110110011 11100111001 1 01011010011001110100 01111011100 1 11010001110110100100 11011000100 1 11000001101000110100 10011110111 1 11100000010100011011 11101110000 1 00110010111011001101 10011011010 1 00011001011100010110 10011000010 1 10101100000010010101 10110000101 1 00010110111011001101 00000011011 1 10100101000000101000 11001010100 1 00111101010101101100 11011111010 

En la primera línea, "0" en el primer bit indica que este es un campo de dirección, y "11" en los bits 20-21 indica que este mensaje es simbólico. Luego, solo tome 20 bits de cada línea y agréguelos juntos.

Obtenemos la siguiente secuencia de bits:

 00010100000110110011010110100110011101001101000111011010010011000001101000 11010011100000010100011011001100101110110011010001100101110001011010101100 000010010101000101101110110011011010010100000010100000111101010101101 

El protocolo POCSAG utiliza ASCII de 7 bits, por lo que solo divide la línea en bloques de 7 bits:

 0001010 0000110 1100110 1011010 0110011 1010011 ... 

Intentamos decodificar códigos de caracteres (la tabla ASCII se busca fácilmente en Google en Internet) y ... obtenemos basura en la salida. Una vez más, abra la documentación y busque la sutil frase "Los caracteres ASCII se colocan de izquierda a derecha (MSB a LSB). El LSB está transmitiendo primero ". Es decir primero, se transmite el bit de orden inferior y luego el bit de orden superior: para la decodificación correcta de los códigos ASCII, se deben voltear las cadenas de 7 bits.

Para evitar hacer esto manualmente, escribimos el código Python:

 def parse_msg(block): msgs = "" for cw in range(16): cws = block[32 * cw:32 * (cw + 1)] # Skip the idle word if cws.startswith("0111101010"): continue if cws[0] == "0": addr, type = cws[1:19], cws[19:21] print(" Addr:" + addr, type) else: msg = cws[1:21] print(" Msg: " + msg) msgs += msg # Split long string to 7 chars blocks bits = [msgs[i:i+7] for i in range(0, len(msgs), 7)] # Get the message msg = "" for b in bits: b1 = b[::-1] # Revert string value = int(b1, 2) msg += chr(value) print("Msg:", msg) print() 

Como resultado, obtenemos la siguiente secuencia (bits, códigos de caracteres y los propios caracteres):

 0101000 40 ( 0110000 48 0 0110011 51 3 0101101 45 - 1100110 102 f 1100101 101 e 1100010 98 b 0101101 45 - 0110010 50 2 0110000 48 0 0110001 49 1 0111001 57 9 0100000 32 0110001 49 1 0110011 51 3 0111010 58 : 0110011 51 3 0110001 49 1 0111010 58 : 0110100 52 4 0110101 53 5 0100000 32 0101010 42 * 0110100 52 4 0110111 55 7 0110110 54 6 0101001 41 ) 0100000 32 1000001 65 A 1010111 87 W 1011010 90 Z 

Combina los personajes y obtén la línea: "(03-feb-2019 13:31:45 * 476) AWZ". Como se prometió al comienzo del artículo, el texto es bastante legible.

Por cierto, otro punto interesante es que, como puede ver, el protocolo utiliza ASCII de 7 bits. Los caracteres cirílicos no encajan en este rango, por lo que la cuestión de cómo se mostró el idioma ruso en los buscapersonas permanece abierta. Si alguien lo sabe, escriba los comentarios.

Conclusiones

Por supuesto, el protocolo no se comprende completamente, pero la parte más interesante ya se ha hecho, y luego queda la rutina, que ya no es tan interesante. Como mínimo, no hay decodificación de las direcciones de los destinatarios (códigos de código) y no se implementa el soporte para un código de corrección de errores (BCH Check Bits); esto permitiría corregir hasta 2 bits "corruptos" durante la transmisión. Sin embargo, el objetivo no era hacer un decodificador completo: ya existen decodificadores de este tipo, y apenas se necesita uno más.

Aquellos que quieran probar la decodificación de mensajes usando rtl-sdr pueden hacerlo ellos mismos usando el programa gratuito PDW . No requiere instalación, después de comenzar es necesario redirigir la salida HDSDR a la entrada PDW usando el programa Virtual Audio Cable y seleccionar el dispositivo apropiado en la configuración de audio PDW.

El resultado del programa se ve así:



En este tema, los mensajes de paginación pueden considerarse cerrados. Aquellos que quieran estudiar el tema con más detalle pueden estudiar los códigos fuente del programa multimon-ng , que puede decodificar muchos protocolos, incluidos POCSAG y FLEX.