Nous analysons le protocole des messages pager POCSAG, partie 2

Salut Habr!

Dans la première partie , le protocole messager POCSAG a été étudié. Les messages numériques ont été pris en compte, nous allons maintenant passer à plus de messages "à part entière" au format ASCII. De plus, il est plus intéressant de les décoder, car la sortie sera un texte lisible.


Pour ceux qui sont intéressés par la façon dont cela fonctionne, continue sous la coupe.

Réception du signal

Tout d'abord, le signal doit être reçu, pour lequel nous utilisons le même récepteur rtl-sdr et le programme HDSDR. Nous savons déjà de la première partie que les messages de pagination peuvent être numériques (le contenu n'est que des nombres 0-9, la lettre U est "ugrent", un espace et une paire de crochets) et alphanumérique, le contenu est des caractères ASCII complets. Naturellement, nous ne connaissons pas à l'avance le type de message (il n'est toujours pas possible de les décoder «à l'oreille»), donc lors de l'enregistrement, nous sélectionnons simplement un message plus authentique.



Le programme de conversion d'un fichier wav en un flux binaire a déjà été envisagé, alors montrez immédiatement le résultat - le message de pagination dans son ensemble ressemble à ceci:



Certaines caractéristiques sont immédiatement visibles à l'œil nu - par exemple, on peut voir que la séquence de départ 01010101010101 est répétée deux fois. C'est-à-dire Ce message est non seulement plus long, mais consiste essentiellement en deux «collés» ensemble, mais la norme ne l'interdit pas.

Décodage

Pour commencer, rappelez le bref contenu de la partie précédente . Le message de pagination commence par un long en-tête 0101010101, suivi d'une séquence de «paquets» montrée dans l'image comme Batch1..N:



Chaque paquet commence par une séquence de début de code de synchronisation de trame (01111100 ...) suivie de blocs de 32 bits. Chaque bloc peut stocker une adresse ou un corps de message.

La dernière fois que nous avons examiné les messages numériques uniquement, nous nous intéressons maintenant aux messages ASCII. Tout d'abord, vous devez apprendre à les distinguer. Pour ce faire, nous avons besoin du champ «Function Bits» - si ces 2 bits sont 00, alors le message est numérique, si 11, puis texte.

Comme le montre la figure, 20 bits sont alloués au champ de message, qui s'intègre parfaitement dans le code BCD 5 à 4 bits, si le message est numérique. Mais si le message est du texte, alors beaucoup de texte ne peut pas être adapté en 20 bits, et 20 ne peut pas être divisé par 7 ou 8. On peut supposer que la première version du protocole (et il a été créé déjà en 1982) ne supportait que les messages numériques ( oui et il est peu probable que les premiers téléavertisseurs de ces années sur nixie-tubes puissent afficher plus ), et seulement alors, dans la prochaine version, le support pour ASCII a été ajouté. Mais depuis il n'était plus possible de violer la norme de format, c'était plus facile - le flux binaire est simplement combiné tel quel (20 bits sont extraits de chaque message et ajoutés à la fin du tampon), et alors seulement, à la fin, tout cela est décodé en caractères.

Considérez un bloc d'un message reçu (des espaces sont ajoutés pour plus de clarté):

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 

Dans la première ligne, "0" dans le premier bit indique qu'il s'agit d'un champ d'adresse et "11" dans les bits 20-21 indique que ce message est symbolique. Ensuite, prenez simplement 20 bits de chaque ligne et ajoutez-les ensemble.

Nous obtenons la séquence de bits suivante:

 00010100000110110011010110100110011101001101000111011010010011000001101000 11010011100000010100011011001100101110110011010001100101110001011010101100 000010010101000101101110110011011010010100000010100000111101010101101 

Le protocole POCSAG utilise ASCII 7 bits, il suffit donc de diviser la ligne en blocs de 7 bits:

 0001010 0000110 1100110 1011010 0110011 1010011 ... 

Nous essayons de décoder les codes de caractères (la table ASCII est facilement googlé sur Internet), et ... nous obtenons des ordures à la sortie. Encore une fois, ouvrez la documentation et recherchez la phrase subtile "Les caractères ASCII sont placés de gauche à droite (MSB à LSB). Le LSB transmet en premier. ". C'est-à-dire tout d'abord, le bit de poids faible est transmis, puis le bit de poids fort - pour un décodage correct des codes ASCII, les chaînes de 7 bits doivent être retournées.

Pour éviter de le faire manuellement, nous écrivons du code 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() 

En conséquence, nous obtenons la séquence suivante (bits, codes de caractères et les caractères eux-mêmes):

 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 

Combinez les personnages et obtenez la ligne: "(03-feb-2019 13:31:45 * 476) AWZ". Comme promis au début de l'article, le texte est assez lisible.

Soit dit en passant, un autre point intéressant est que, comme vous pouvez le voir, le protocole utilise ASCII 7 bits. Les caractères cyrilliques ne rentrent pas dans cette gamme, donc la question de savoir comment les téléavertisseurs ont flashé la langue russe reste ouverte. Si quelqu'un le sait, écrivez dans les commentaires.

Conclusions

Bien sûr, le protocole n'est pas entièrement compris, mais la partie la plus intéressante a été faite, puis la routine reste, ce qui n'est plus si intéressant. Au minimum, il n'y a pas de décodage des adresses des destinataires (capcodes), et la prise en charge du code de correction d'erreur (BCH Check Bits) n'est pas implémentée - cela permettrait de corriger jusqu'à 2 bits «gâtés» pendant la transmission. Cependant, l'objectif n'était pas de créer un décodeur à part entière - il existe déjà de tels décodeurs, et un autre n'est guère nécessaire.

Ceux qui veulent essayer de décoder des messages en utilisant rtl-sdr peuvent le faire eux-mêmes en utilisant le programme PDW gratuit. Il ne nécessite pas d'installation, après le démarrage, il est nécessaire de rediriger la sortie HDSDR vers l'entrée PDW à l'aide du programme Virtual Audio Cable et de sélectionner le périphérique approprié dans les paramètres audio PDW.

Le résultat du programme ressemble à ceci:



Sur ce sujet, les messages de pagination peuvent être considérés comme fermés. Ceux qui veulent étudier le sujet plus en détail peuvent étudier les codes sources du programme multimon-ng , qui peuvent décoder de nombreux protocoles, y compris POCSAG et FLEX.