Analisamos o protocolo de mensagens de pager POCSAG, parte 2

Oi Habr!

Na primeira parte , o protocolo de mensagens POCSAG foi considerado. As mensagens digitais foram consideradas, agora passaremos para mais mensagens "completas" no formato ASCII. Além disso, é mais interessante decodificá-los, porque a saída será um texto legível.


Para aqueles que estão interessados ​​em como isso funciona, continuaram sob o corte.

Recepção de sinal

Primeiro, o sinal deve ser recebido, para o qual usamos o mesmo receptor rtl-sdr e o programa HDSDR. Já sabemos desde a primeira parte que as mensagens de paginação podem ser digitais (o conteúdo é apenas os números de 0 a 9, a letra U é "ugrent", um espaço e um par de colchetes) e alfanumérica, o conteúdo é de caracteres ASCII completos. Naturalmente, não sabemos antecipadamente o tipo de mensagem (ainda não é possível decodificá-los "de ouvido"), portanto, ao gravar, simplesmente selecionamos uma mensagem mais autêntica.



O programa para converter um arquivo wav em um fluxo de bits já foi considerado, então mostre imediatamente o resultado - a mensagem de paginação como um todo se parece com isso:



Alguns recursos são imediatamente visíveis a olho nu - por exemplo, pode ser visto que a sequência inicial 01010101010101 é repetida duas vezes. I.e. Essa mensagem não é apenas mais longa, mas consiste essencialmente de duas "coladas" juntas, no entanto, o padrão não a proíbe.

Decodificação

Para começar, lembre-se do breve conteúdo da parte anterior . A mensagem de paginação começa com um cabeçalho longo 0101010101, seguido por uma sequência de "pacotes" mostrados na figura como Lote1..N:



Cada pacote começa com uma sequência de início do Frame Sync Code (01111100 ...) seguida por blocos de 32 bits. Cada bloco pode armazenar um endereço ou um corpo da mensagem.

A última vez que analisamos apenas mensagens digitais, agora estamos interessados ​​em mensagens ASCII. Primeiro de tudo, você precisa aprender a distinguir entre eles. Para isso, precisamos do campo “Function Bits” - se esses 2 bits forem 00, a mensagem será digital, se 11, e então texto.

Como você pode ver na figura, 20 bits são alocados no campo da mensagem, que se encaixa perfeitamente nos 5 códigos BCD de 4 bits, se a mensagem for digital. Mas se a mensagem é texto, muito texto não pode ser ajustado em 20 bits e 20 não pode ser dividido por 7 ou 8. Pode-se supor que a primeira versão do protocolo (e já foi criada em 1982) suportasse apenas mensagens digitais ( sim e é improvável que os primeiros pagers daqueles anos em nixie-tubes possam exibir mais ), e somente então, na próxima versão, foi adicionado suporte para ASCII. Mas desde não era mais possível violar o padrão de formato, era mais fácil - o fluxo de bits é simplesmente combinado como está (20 bits são extraídos de cada mensagem e adicionados ao final do buffer), e só então, no final, tudo isso é decodificado em caracteres.

Considere um bloco de uma mensagem recebida (espaços são adicionados para maior clareza):

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 

Na primeira linha, "0" no primeiro bit indica que este é um campo de endereço e "11" nos bits 20-21 indica que esta mensagem é simbólica. Em seguida, basta pegar 20 bits de cada linha e adicioná-los.

Temos a seguinte sequência de bits:

 00010100000110110011010110100110011101001101000111011010010011000001101000 11010011100000010100011011001100101110110011010001100101110001011010101100 000010010101000101101110110011011010010100000010100000111101010101101 

O protocolo POCSAG usa ASCII de 7 bits, portanto, apenas divida a linha em blocos de 7 bits:

 0001010 0000110 1100110 1011010 0110011 1010011 ... 

Tentamos decodificar códigos de caracteres (a tabela ASCII é facilmente pesquisada na Internet) e ... obtemos lixo na saída. Mais uma vez, abra a documentação e encontre a frase sutil "Os caracteres ASCII são colocados da esquerda para a direita (MSB para LSB). O LSB está transmitindo primeiro. " I.e. primeiro, o bit de ordem inferior é transmitido e, em seguida, o bit de ordem superior - para a decodificação correta dos códigos ASCII, as strings de 7 bits devem ser trocadas.

Para evitar fazer isso manualmente, escrevemos 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, obtemos a seguinte sequência (bits, códigos de caracteres e os próprios 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 

Combine os personagens e pegue a linha: "(03-feb-2019 13:31:45 * 476) AWZ". Como prometido no início do artigo, o texto é bastante legível.

A propósito, outro ponto interessante é que, como você pode ver, o protocolo usa ASCII de 7 bits. Os caracteres cirílicos não se encaixam nesse intervalo, portanto a questão de como os pagers exibiam o idioma russo permanece em aberto. Se alguém souber, escreva nos comentários.

Conclusões

Obviamente, o protocolo não é totalmente compreendido, mas a parte mais interessante foi feita e a rotina permanece, o que não é mais tão interessante. No mínimo, não há decodificação de endereços de destinatários (capcodes), e o suporte ao código de correção de erros (BCH Check Bits) não é implementado - isso permitiria corrigir até 2 bits "estragados" durante a transmissão. No entanto, o objetivo não era criar um decodificador completo - já existem esses decodificadores, e dificilmente é necessário mais um.

Aqueles que desejam tentar decodificar mensagens usando o rtl-sdr podem fazer isso sozinhos usando o programa PDW gratuito. Não requer instalação, após o início, é necessário redirecionar a saída HDSDR para a entrada PDW usando o programa Cabo de áudio virtual e selecione o dispositivo apropriado nas configurações de áudio do PDW.

O resultado do programa é algo como isto:



Neste tópico, as mensagens de paginação podem ser consideradas fechadas. Quem quiser estudar o tópico com mais detalhes pode estudar os códigos-fonte do programa multimon-ng , que pode decodificar muitos protocolos, incluindo o POCSAG e o FLEX.