, Visitante!
Já é Membro? Login ou Registe-se.



Conteúdos



Calendário

Junho 2017
D
S
T
Q
Q
S
S
    123
45678910
11121314151617
18192021222324
252627282930 
Ver Calendário Completo


Contador


O GMSK e o D-STAR





Noções básicas do stream GMSK e de como o D-STAR trabalha

 

As informações sobre o D-STAR estão dispersas por vários documentos e partindo de fontes diferentes, escritos por pessoas diferentes. É muito fácil para alguém desconhecedor do D-Star ser sobrecarregado por todos esses textos, especialmente porque a maioria destes documentos sobre D-Star não são relevantes para a construção de um receptor GMSK.


Nesta montanha de informações, há uma única a "especificação para o protocolo D-Star" (o documento "Shogen", apenas 11 páginas) que descrevem o nível do interface de rádio do D-Star. O problema é que está escrito para pessoas já experientes com este tipo de tecnologia. Para alguém que é novo no assunto tem informação excessiva e por outro lado não contém informação útil.

Vou tentar fornecer estas informações de uma forma mais simples e estruturada.
Existem agora várias maneiras de poder descrever um stream D-Star: usando especificações puras, como a matemática, o que se parece com um sinal de radiofrequência. A apresentação feita por este artigo deixa uma pergunta simples: "o que é um stream D-Star? e o que é preciso para que um programa de computador o possa descodificar?".

O objectivo deste texto é dar algumas dicas sobre o que é um stream GMSK de áudio, na verdade, como é que ele é estruturado, e baseado nesta informação, o que é necessário para escrever software para descodificá-lo. Ele utiliza certas “funções” para reduzir partes do código de programação (especialmente o código de DSP para fazer desmodulação GMSK e correção de erros).

Vamos analisar superficialmente o código neste artigo.

10 factos básicos


Se pesquisar na internet por “especificações
sobre D-Star” vai se deparar com algumas palavras e termos que para as pessoas que conhecem a comunicação digital são de uso comum. Estas palavras fornecem algumas informações básicas de que se deve estar ciente. Aqui estão os "10 factos básicos sobre GMSK e D-Star que deve saber e entender":

1.     Digital: O D-Star é um sistema de comunicação digital. Isto significa que a voz não é transmitida como um sinal analógico variável (como no FM, AM ou SSB), mas sim convertido e transmitido como uma serie de 0’s e 1’s ("bits").

2.     GMSK: Queremos transmitir a voz como uma série de 0s e 1s digitais, precisamos de fazer isso usando um equipamento de rádio analógico. Por essa razão os bits são convertidos em "tons" de modo que possam ser transmitidos através de um rádio analógico. Esta é a razão por que se sintonizar um rádio FM analógico na frequência de um repetidor D-Star o sinal ouvido será como "zumbidos". Existem mais sistemas de modulação digitais: FSK, PSK, ASK. O sistema utilizado pelo D-Star é o GMSK (Gaussian Minimum Shift Keying), um sistema relacionado com PSK (Phase Shift Keying).

3.     Modulação em FM: Como todos os radioamadores devem saber, o transporte de um sinal analógico por um rádio pode ser feito através de um número de diferentes tecnologias de modulação: AM, SSB ou FM. Assim como algumas outras tecnologias digitais (Packet e APRS), o GMSK usa modulação em FM. Isto explica porque é possível a utilização de um normal transceptor de FM para enviar e receber sinais GMSK.

4.     Porta de dados 9K6: Um das realidades que fazem a diferença entre um modem GMSK de uma comunicação de voz normal em FM (ou Packet e APRS), é que ele usa a porta de dados "9k6" do rádio, em vez do microfone e do altifalante. Essa porta é diferente das outras portas num transcetor de FM, ela ignora o filtro "emphasis/deemphasis" do circuito do rádio FM. Estes circuitos modificam o áudio de uma maneira que iriam alterar os tons GMSK e portanto, também alterar os bits que carregam. Assim para evitar esta situação um modem GMSK tem de ser ligado a uma porta de dados 9k6 de um emissor FM. Existe a possibilidade de alterar um equipamento que não tenha porta de dados, tendo que ser feito um bypass ao filtro “emphasis/deemphasis”.

5.     4800: É o número de bits por segundo que são enviados por um rádio D-Star. Estes bits podem ser divididos em três grupos: 2.400 bits/segundo de "voz", 1200 bits/segundo para o FEC (forward error correction), usado para proteger a voz em informações de transmissão de erros corrigindo-os se possível e 1200 bits/segundo para "slowdata", neste último é onde são transmitidas as mensagens de texto o indicativo de quem transmite e para onde.

6.     Estrutura: Embora seja possível ouvir um stream GMSK os bits de um stream GMSK têm uma estrutura fixa pré-definida. Em suma, trata-se de um frame de cabeçalho de 328 bits que contêm informações, tais como o indicativo do emissor e um número de data-frames de 12 octetos cada, um contém voz digital e o outro o slowdata.

7.     Sincronismo: para além da estrutura mencionada acima, o stream GMSK D-Star também contém algumas sequências de bits especiais que são necessários para o sincronismo. Estes são necessários para que o receptor possa escutar exatamente no momento exato em que o transmissor os envia. Os bits de sincronismo são usados ​​para marcar o início do stream (localizado na frente do frame de configuração D-Star), para marcar um stream que tenha terminado e também a cada 21 frames (ou seja, a cada 420 milissegundos) para manter o receptor "em sincronismo" com o remetente.

8.     20ms: Uma comunicação de voz, pode levar até minutos, não pode ser processada de uma só vez por um sistema de voz digital. Ela é cortada em pacotes de 20 milissegundos cada. Isto permite que a voz ao ser processada pelo "vocoder" (ver abaixo) é convertida em 9 octetos (6 octetos de dados de voz + 3 octetos de correção de erros). Estes 9 octetos, mais 3 octetos de "slowdata" prefazem os 12 octetos que entram em cada dataframe (ver acima).

9.     AMBE: 20 ms de informação de voz não processada, ​​normalmente levam até 160 octetos. Para se encaixar nos 6 octetos de voz e dados que o D-STAR pode carregar, precisava de ser convertido por um chamado "codec" (codificador / descodificador) ou "vocoder" (abreviação de "codificador de voz"). O vocoder usado pelo D-STAR é o "AMBE".

10.           DV-Dongle: O software do receptor GMSK não entende o vocoder AMBE. Ele apenas despeja o fluxo recebido num arquivo local e não processa o stream de áudio. O software que codifica ou descodifica o áudio utiliza um dispositivo externo para este fim (o chamado "DVdongle") lá dentro encontra-se o “chip” responsável pela codificação ou descodificação do stream de áudio.

 

 

Desmodulando um sinal

 

         Agora, como um bom jornalista precisa de ter pelo menos duas fontes independentes para poder confiar numa história. Então o que é que realmente o GMSK recebe deste stream de audio? Como o "receptor GMSK" tem uma opção "-dd" (dump more), é possível ver o que o programa realmente dentro do pacote recebido.

 

1.     A aplicação captura uma amostragem de áudio a cada 1/48000 seg.

2.     O valor da amostra é enviado para uma função do desmodulador GMSK, que o transforma em "0" ou "1".

3.     Como o valor da amostragem é de 48.000 amostras por segundo, mas o sinal GMSK só funciona em 4.800 bits por segundo (um décimo da taxa de amostragem), um código adicional é necessário para cuidar desse valor.

 

Então, de volta à amostra de áudio GMSK. Vamos desmodular e ver o que conseguimos. Em primeiro lugar a desmodulação do ruído. Este é o resultado:

 

00111000 10011100 00000010 00001000 00110111 11011111

00000000 10000001 00000000 00101101 10011111 10111111

11000001 11010010 01111010 01100001 00101000 00110100

00000000 01110100 10011010 00110000 00011000 10011011

00011101 10000111 10000111 11100111 10100011 11110101

11100000 11110000 11100110 11000001 01111101 10100001

(...)

 

(Note-se que a apresentação dos bits em grupos de 8 é apenas para tornar as coisas um pouco mais legíveis, não tem nenhum significado especial).

 

Conclusão: como o ruído é na verdade nada mais que níveis de tensão aleatórios, transformar isso num fluxo de bits de 0s e 1s apenas produz uma sequência aleatória de 0s e 1s. OK, até agora nada de novo.

 

Mas, com um pouco mais de código, as coisas ficam mais interessantes.

 

(...)

10000110 00010000 00000001 00010111 11010110 10010100 (48 bits = 20 ms)

00111111 10100111 00100011 00111101 00111100 10111111

11101000 10000001 11111101 11101010 11101101 10111111

00010000 11101011 11110000 00000000 11111110 10000000

00001000 11000001 01111100 11111000 10111101 11111111

11111100 00011111 11111111 11111111 11111111 11111111

11111111 11111111 11111111 11111111 11111111 11111111

11111111 11011101 01111101 01010101 01010101 01010101

01010101 01010101 01010101 01010101 01010101 01010101

01010101 01010101 01010101 01010101 01010101 01010101

01010101 01010101 01010101 01010101 01010101 01010101

01010101 01010101 01010101 01010101 01010101 01010101

01010101 01010101 01010101 01010101 01010101 01010101

01010101 01010101 01010101 01010101 01010101 01010101

01010101 01010101 01010101 01010101 01010101 01010101

01010101 01010101 01010101 01010101 01010101 01010101

01010101 01010101 01010101 01010101 01010101 010....

11101100 10100000

 

Como podemos ver, num determinado momento um padrão fixo começa a surgir: primeiro todos os "1" e depois uma repetição de "1010". Vamos dar uma olhada na especificação do que isso significa. Consulte a página 3 do documento "Shogen":

 

«…

2.1 Wireless Communication Packet

2.1.1 Frame structure of a packet: The explanation of the data frame structure the Radio Header follows.

(1) Bit Syn. (Bit synchronization): Repeated standard 64-bit synchronization pattern (for GMSK 1010). (...)

…»

 

 

Então o que estamos vendo aqui é o início de um stream D-STAR: nos primeiros dados o receptor e o GMSK precisavam de algum tempo para se sincronizarem, mas depois de cerca de 20 ms, o valor fixo "1010" aparece.

Isto não só é exactamente como as especificações dizem, como deve também corresponder ao áudio na amostragem. Como cada linha no bitdump acima corresponde a 20 ms, o processo inteiro de sincronismo leva cerca de 120 ms (6 linhas) que também é mostrada no dump do ficheiro de áudio.

 

Então o que vem a seguir? Bem, vamos voltar a olhar para a especificação:

 

«…

2.1 Wireless Communication Packet

2.1.1 Frame structure of a packet: The explanation of the data frame structure the Radio Header follows.

(...)

(2) Frame Syn. (Frame synchronization) : 15bit pattern (111011001010000_).

(...)

…»

 

Finalmente olhando novamente o dump, o padrão de 15 bits do frame de sincronismo é encontrado!

O frame de sincronismo não é nada mais que uma “marca” na estrutura do frame que diz “aqui acaba o sincronismo e começa a próxima parte: O cabeçalho de encapsulamento D-Star

 

HEADER DUMP:

FLAG1: 00 - FLAG2: 00 - FLAG3: 00

RPT 2: DIRECT

RPT 1: DIRECT

YOUR : CQCQCQ

MY : CT1JIB /

Check sum = E441 (OK)

 

 

Como se pode ver, esta é apenas a mesma informação que se tem que preencher num transceptor de D-STAR, além de 3 octetos de flag e um 2 octetos para o checksum.

 

Com base nisso, podemos dizer que o cabeçalho tem um comprimento de 328 bits (41 octetos * 8), no entanto, que não é o caso. O cabeçalho tem que ter 660 bits. Para entender a razão para isto vamos ter de olhar para o código fonte do descodificador GMSK (simplificada).

 

 

 

No código de programação, processar os 660 bits recebidos após a sequência do quadro de sincronismo, encontramos o seguinte:

 

scramble(radioheaderbuffer_in,radioheaderbuffer_temp1);

deinterleave(radioheaderbuffer_temp1,radioheaderbuffer_temp2);

length=FECdecoder(radioheaderbuffer_temp3,radioheaderbuffer_out);

 

 

O processamento dos bits recebidos do cabeçalho, dão origem a três diferentes funções: scrambling, deinterleaving e FECdecoding

 

Para explicar este resultado é mais fácil se olharmos para o que acontece no lado oposto, no transmissor. Por lá vemos os mesmos processos mas em ordem inversa: FECencoding primeiro, depois interleaving e finalmente scrambling.

 

Passo zero:

 

O primeiro passo neste processo é um pouco estranho. Antes da transformação, dois bits (contendo 0) são adicionados no fim dos 328 bits de cabeçalho. Estes bits na verdade, não têm qualquer utilidade particular (daí o "passo 0"), eles fazem aumentar o cabeçalho de tamanho de 328 para 330 bits.

 

Passo um: FEC

 

O primeiro passo real no processamento do cabeçalho no lado remetente é o "FECencoding". FEC significa "Forward Error Correction" e ele faz exatamente o que o nome indica. Ele cria uma referência para poder ser tratada como um erro, mesmo antes de transmiti-lo.

 

A ideia é muito simples. Ao adicionar bits num stream que está sendo enviado quando houver desvio de bits durante a recepção o receptor (na realidade o algoritmo FECdecoding no software do receptor) pode usar estes dados adicionais para corrigir as falhas. Como o FEC realmente trabalha internamente é algo que vamos ver mais à frente.

 

O que é interessante saber é que o protocolo D-Star, usado no cabeçalho, cria um bit adicional para cada bit de dados, daí a duplicação do tamanho do cabeçalho de 330 para 660 bits.

 

Passo dois: Interleaving

 

O segundo passo é um processo chamado de Interleaving (não tendo uma tradução muito real para o Português vamos aqui referir como "entrelaçamento"), que é apenas uma palavra chique para a "atribuição e distribuição de bits". Isto significa alterar completamente a ordem pela qual os bits são transmitidos. Se o cabeçalho tivesse apenas 4 bits em vez de enviar os bits como "1 - 2 - 3 - 4"  irá envia-los como "1 - 3 - 2 - 4". Isto pode parecer uma coisa muito estranha de se fazer, mas de facto há uma razão muito boa para isto. Ela está relacionada com o mecanismo de Forward Error Correction descrito mais acima.

 

Como mencionado acima, o algoritmo FEC tenta fazer um stream mais forte pela adição do bit de erro/correcção no stream. No entanto, estes bits de correcção de erros estão localizados mesmo junto a dados de bits. No nosso exemplo de cabeçalho de 4 bits, os bits 1 e 2 formam um par de FEC e os bits 3 e 4 de dados.

 

Agora todos estes quatro bits são enviados sequencialmente. imaginem que, durante a transmissão existe um pulso de interferência que não só limpa o bit 1 como também o bit 2, os dois bits do par de FEC serão corrompidos e o sistema FEC não será capaz de corrigir esta situação. É então aqui que o sistema de  "entrelaçamento" actua. Ao espalhar os 660 bits do cabeçalho torna-o menos vulnerável ​​a esse tipo de interferência.

Em termos de programação o Interleaving é muito fácil de implementar com a utilização apenas de uma simples tabela de pesquisa.

 

 

Passo três: Scrambling

 

Embora o que o nome possa indicar “Scrambling” não tem nada a ver com criptografia.

Este processo também conhecido como randomização está relacionado com a forma como os sistemas de comunicação de dados se mantêm auto sincronizados.

A desmodulação GMSK usa o tempo das transições 0-1 e 1-0 para manter o processo de desmodulação e receber o GMSK em sincronismo com o remetente. Estas marcas de tempo exactas são utilizadas como marcadores para evitar a perda de sincronismo de receptor de GMSK. Por essa razão, as sequências longas de 0’s ou 1’s são algo que devem ser evitadas.

 

O que o processo de Scrambling faz é converter um pouco de uma sequência numa outra sequência (predeterminada), tornando estes 0’s e 1’s menos favoráveis. Afortunadamente, existe código aberto para implementação do Scrambling por isso não precisa de se preocupar muito sobre isso.

Note-se que a codificação do processo do lado do servidor é exactamente o mesmo no lado receptor. Não existe a função “DeScrambling”.

 

Sumário:

 

  1. O cabeçalho do D-Star contém informação, como por exemplo o indicativo, que é necessário para rotear o pacote.
  2. Para fazer isto menos susceptível de erros de transmissão três processos são aplicados, resultando numa estrutura que é o dobro do tamanho original.
  3. Existe software de código aberto para estas funções.
  4. A 4800 bps o envio do cabeçalho leva 137,5 ms.

 

 

A Voz

 

Vamos olhar para o documento “shogen”, a página 5 fornece a resposta: uma sequência de voz e dados de texto (slowdata).

A estrutura desta parte do stream é muito simples. A cada 20 ms, 96 bits (12 octetos) são enviados:

• 72 bits (9 octetos) de voz codificada AMBE

• 24 bits (3 octetos) de dados texto (slowdata)

 

 

Olhando para a extracção do stream de dados, não existe nada de significativo à primeira vista:

 

11011111 11010000 00011000 00011001 11100110 10010100

10110111 11111111 10011101 10101010 10110100 01101000

 

01111101 01010000 01100000 00011111 10100100 11011100

10001001 01100010 10100111 00001100 00100000 10000011

 

01011111 10010001 01010000 00000011 10100100 11111100

10011111 11100000 10100101 10011100 00111000 11100011

 

(...)

 

Cada linha (contendo 12 octetos) representa 20 ms. Os restantes 9 octetos contém a voz digital + FEC. Os 3 octetos, à direita, contêm o “slowdata”.

 

Final

 

Após o cabeçalho do fluxo de voz e a voz real e do stream de “slowdata”, chegamos à última parte do stream: o fim.

Uma das vantagens de um stream de comunicação digital é que eu posso realmente marcar o fim de um stream dentro dele próprio. Não preciso de depender do “carrier” da portadora. Ao dizer "o stream pára aqui", isso permite que o stream possa ser terminado muito mais correctamente.

Mais uma vez, vamos olhar para a especificação shogen e ver o que ela diz. Na página 6 do documento, lemos o seguinte:

 

"The last data frame, which requires a means of terminating the transmission, is a unique synchronizing signal (32 bit + 15bit “000100110101111” + “0”, making 48 bits) as defined by the modulation type.".

 

 

Olhando vemos que este "sinal de sincronismo único" é equivalente ao seguinte padrão de bit:

 

• Os últimos 3 octetos de um frame contêm o padrão "10101010 10101010 10101010"

• Os primeiros 3 octetos do próximo frame contêm o padrão 10101010 00010011 01011110 "

 

Mais uma vez olhamos para a saída do programa receptor GMSK, e vemos isto:

 

11011001 10110000 00101101 00001101 11000011 11000110

00111111 01100110 01010110 10000100 00110000 01000011

 

00111011 10010011 00000101 10001000 01101011 01111111

11110001 11001100 10010111 11111110 10101010 10101010

 

10101010 00010011 01011110 END

 

Agora, se olhar com cuidado verá que o padrão não corresponde completamente. O octeto 10 do último quadro completo deve conter "10101010", mas contém algo mais. No entanto, ainda que o padrão seja correctamente visto como um marcador "END" válido, ele deve detectar o fim de um fluxo.

A razão é a de que estas funções sejam codificadas de tal maneira que possam lidar com pequenos erros. Neste caso, permite-se a 3 erros de bits. Se isto não fosse possível, um único biterror na extremidade da transmissão poria em risco a recepção perdendo por completo o fim do stream.

 

Isto põe um fim a este artigo sobre a estrutura de um stream de D-STAR. Espero que tenha sido um pouco instrutivo.

No final, acredite ou não, vai ver que compreender um stream de D-Star não é assim tão difícil.

 




 


O código de programação para esta aplicação, receptor GMSK, pode ser encontrada aqui (https://github.com/on1arf/gmsk/tree/master/gmskmodem_dstar_raw/gmskmodem).

 

 

 

 

 

 

 

 

 

 

 

Bibliografia:

 

ARRL – Shogun Specification

Kristoff Boone – Wat is D-Star? (http://www.dstarvlaanderen.be/blog/?page_id=14)

Denis - DL3OCK - D­STAR radio frame structure in DV mode

MX COM Inc. - Practical GMSK Data Transmission








CT1JIB - 2006~2014



//
www.hrdlog.net