Ajuste do BER no MMDVM

 

O BER (bit error correction ou “bit para correção de erros”), é parte do código usado em sistemas digitais que permitem por alguma forma a correção do mesmo, esta correção sendo “exagerada” não vai preencher as lacunas mas sim elimina-las.

Como a maioria dos utilizadores usam a aplicação ‘pi-star’ no seu hotspot vamos tentar explicar o BER, já sabendo o que ele provoca, e como resolver. Todos já ouviram emissões com cortes ou até mesmo serem denunciados por outros em que a nossa emissão por vezes falha, isso deve-se por duas razões, ou falha do acesso internet, micro cortes, ou por um BER alto, acima de 1,5%.

Os hotspots tem componentes, que sendo de qualidade garantiriam que a frequência marcada como sendo de emissão/receção fosse unica, esse elemento é o TCXO, oscilador a cristal controlado por temperatura. O facto de se adquirirem modelos mais baratos levam a que a qualidade seja posta de lado, temos aquilo que comprámos.

No mesmo sentido temos os rádios, a qualidade é diretamente proporcional ao custo do mesmo, existe exactamente o mesmo componente e a sua qualidade é factor determinante da estabilidade e frequência apresentada.

Assim quando configuramos o nosso rádio para a frequência de 433.450 (vulgo na maioria dos utilizadores) supostamente, digo supostamente porque está dependente da qualidade do material empregue no rádio, será suposto então que ele transmita e receba nos 433.450, acontece que essa mesma qualidade de material pode levar a que o rádio não esteja nos 433.450 e sim nos 433.449917 por exemplo. No outro lado temos o nosso hotspot na mesma frequência, mas que pelasmesma razão escuta em 433.450760 em vez dos 433.450, temos então entre estes equipamentos a seguinte diferença:

 

 

hotspot – 433.450760

radio – 433.449917

+83 em relação ao hotspot

-760 em relação ao hotspot

 

Não nos vamos prender com a exatidão do rádio, o que nos interessa é que o nosso hotspot receba bem o nosso rádio, pelo visto acima seria introduzirmos o valor a corrigir de -760 (os valores são sempre em ciclos/seg). No entanto como vimos pelo apresentado o rádio também tem um desvio de 83 c/s para mais, isto tomando como base a frequência central de 433.450, assim que -760+83 = -677, ou seja -670 ou -680 como base.

Obviamente que os valores demonstrados acima seriam adquiridos com equipamentos de laboratorio que nem todos têm, vamos mostrar uma de duas formas fáceis de o poder fazer, qualquer delas precisa do aplicativo ‘putty’ ou ‘bitvise’ para aceder a raspberry via terminal ssh (o velhinho VT100 sem ecrã verde).

 

Usando o ‘Putty’ ou o ‘Bitvise’

 

Muito importante, o hotspot deve estar no mínimo a 3 mts do rádio em potência baixa

(por este motivo dizemos não fazer nenhum sentido terem display)

 

Qualquer destes aplicativos permitem o acesso SSH (um protocolo de comunicação IP) para aceder em modo terminal (um ecrã preto) ao nosso Raspberry. Pessoalmente prefiro usar o Bitvise pela possibilidade do multi terminal sem muito esforço, o mesmo se aplica ao modo sFTP, transferir, de e para, ficheiros. O putty permite o mesmo mas com mais comandos.

Lembem-se sempre que Linux não é Windows, para executarmos algo em Linux devemos sempre (há algumas excepções) usar o user root, só assim é garantida a execusão de um aplicativo com direitos plenos.

Para  acedermos ao nosso Raspberry vamos abrir, seja o Putty ou o Bitvise, uma sessão onde devemos colocar alguns dados, são eles o host, que é o IP que a Raspberry tem, a porta, por defeito a porta shh é a 22, o user, que por defeito é ‘pi-star’ (no caso do pi-star, numa instação mais pessoal é ‘pi’) e a password, que por defeito é raspberry.
A diferenção entre o uso do Putty e do Bitvise é que no Putty tanto o user como a palavra passe são introduzidas já no terminal que aparece no nosso ecrã, no Bitvise esses dados estão na aplicação e podem ser guardados para sempre, dando a que ao aparecer o modo terminal já temos o login feito.
Após a entrada no modo terminal devemos mudar o utilizador para root, isso é visível na propria raiz do terminal.

 

 

Usando o comado sudo –s resultará em:

 

Notem à esquerda na linha de comando a indicação do utilizador da conta.

 

Para informação o (ro) visivel quer dizer que qualquer pretença alteração que queiram fazer não é aceite pelo sistema, está em ‘read only’ ou seja só permite leitura, se acaso, e após o teste de BER, quiserem alterar o valor no ficheiro mmdvmhost  deverão antes de o fazer executar no terminal ‘rpi-rw’ para preparar o sistema a suporte de escrita, isto não é necessário se o fizerem via dashboard no PC.

Neste terminal  vamos executar o comando pistar-mmdvmcal, irá dar algo semelhante a imagem abaixo:

 

 

Este quadro leva algum tempo a ser visualizado, isto porque a aplicação vai parar o mmdvmhost e todas as ligações que estivessem presentes na altura.
Devemos ter o nosso rádio preparado para o que usamos como hotspot, como disse por norma costuma será os 433.450, mas terá que ser sempre algo com o color code = 1. Com base no teste ao nosso rádio vamos começar digitando a letra E e inscrevendo a frequência do nosso rádio, por exemplo 433450000, sem  pontos ou espaços. Isto vai preparar o aplicativo a receber do nosso rádio a emissão.
De seguida escolhemos a opção b e premimos o PTT nunca menos que 30 seg. Irá dar uma lista de pacotes recebidos concluindo com o valor lido do BER. Neste teste escolhi a frequencia, através da tecla E, e depois dos dados introduzidos, a letra b, o valor foi o seguinte:

 

 

Como se pode ver o valor é alto, 2.1%, subi 150 c/s na frequência usando a tecla F e voltei a premir o PTT por 30 seg. Resultando no visivel:

 

Ainda não foi desta, mas pelo menos percebi que o desvio em frequência não era para mais mas sim para menos. Assim reduzi a frequência, usando a tecla f (a mesma mas em minisculas) para os mesmos 150 c/s no caso abaixo da inscrita.

 

Novo teste, agora com frequência abaixo dos 433.450

 

 

Novamente PTT durante 30 seg e agora sim.

 

Se deixar ficar por este valor de 0.5% de BER é o que irei inserir no campo RXOffset do MMDVMHost (abaixo já explico como aceder a esta parte), o valor a colocar será então -150 que foi a deriva informada pelo aplicativo MMDVMCal.
O RXOffSet é a frequência de receção do vosso Hotspot (às vezes é confuso entender isto), o TXOffSet será o mesmo para a emissão, no caso poderá haver ou não o mesmo desvio, há muita informação na net dizendo que se deve por o mesmo valor e pela lógica seria o acertado, mas não, o facto do nosso rádio ter um desvio em TX não significa que tenha exactamente o mesmo em RX e para o uso em questão não é importante. Seria importante se “pretendessemos” escutar o nosso hotspot a kms da posição, ai o factor ‘desvio de frequência’ daria uma menor cobertura. Mas relembro que um hotspot só deve ser usado pelo próprio e limitado em distância para não cairmos na ilegalidade de ser uma estação de uso comum, vulgo repetidor, para a qual não tendo licença é ilegal.

 

 

Alterando o pi-star para o melhor BER via dashboard

Deve usar o TG 9

 

Vamos passar para o PC e abrir a página do pi-star, intoduzimos o mesmo IP e clicamos no link “Configuration” ou “Configuração”, de seguida no apresentado escolhemos “Expert” e em seguida em “MMDVMHost”, rolamos o ecrã até a configuração “Modem”. Procuramos a caixa RXOffSet e nela introduzimos o valor achado com a aplicação, no caso que apresentei será -150 e salvamos a alteração. Como disse não há necessidade alguma de introduzir o mesmo valor na caixa TXOffSet, mas mal também não faz.

 

Imagem identificativa, o valor difere dos resultados apresentados neste documento

 

 

Pi-star e o “meu rádio”

 

O valor de BER achado é exclusivo do rádio que esteve sob teste, se acaso pretendem usar mais algum rádio que tenham no mesmo hotspot o valor de BER poderá ser bem diferente resultando em perdas ou até na impossibilidade de o hotspot “ouvir” o rádio. Não é impossível de ser feito, representa muito mais tempo para encontrar um meio termo de ajuste entre ambos os equipamentos. Ás vezes poderá mesmo ser impossível.

Referi acima que havia duas possíveis formas de o fazer, sendo a anterior a primeira e com mais recursos a serem usados, existe também a possibilidade de o fazerem no prprio dashboard do pi-star. Seguindo o que foi apresentado até aqui e acedendo a sessão Modem, depois expert->mmdvmhost, será o colocarmos nós valores possíveis na caixa RXOffSet e salvarmos, depois do pi-star ter reinciado verificamos no dashboard qual o valor de BER na coluna respectiva.

 

 

Alteramos o valor que colocamos no RXOffSet até o mesmo ser o melhor objectivo.

 

 

Tenham presente este ponto, cada configuração de BER é só para o rádio que testaram, poderá surgir a casualidade de outro ser perfeitamente aceite, mas é bem possível que não, mesmo em equipamentos do mesmo fabricante/modelo e da mesma série de produção.

 

 

 

Formações DMR ** atualização **

 

Novas formações

 

Iniciámos no mês de Março a aplicação prática de uso da rede DMR. A segunda ação de formação incidiu sobre o CPS e a elaboração de um codeplug. Foi solicitado aos presentes um envio de um pequeno ‘codeplug’ que demonstrasse a aquisição dos conhecimentos adquiridos.

Esta primeira fase foi ultrapassada por alguns e é para esses agora que será apresentado o que alguns CPS’s e rádios podem oferecer em uso na rede DMR Brandmeister, bem como sugestões de uso na rede DMR.

Estas sessões irão ser divididas por modelos em exclusivo, o CPS de um não é igual para todos, há rádios que permitem roaming sendo que a maioria o não possibilita. Terá também como novidade o poder ser interactiva, ou seja o utilizador tem acesso a partilhar o seu ecrã e assim poder identificar a sua dificuldade ou a questão que queira colocar.

 

Contamos ser este o plano de ação:

  • Para a primeira sessão as inscrições para os rádios da marca Anytone, mod. D878 ou D578 e até mesmo o 868 embora algumas das funcionalidades não estejam presentes.
  • Para a segunda sessão será inscrições para os rádios da marca Tytera, mod. MD380/390, MD380UV/390.
  • Para a terceira sessão será inscrições para os rádios da marca Retevis, mod, RT3, RT3s, RT82.

 

O facto de não incluírmos o CPS do GD77 é tão somente pelo facto de na sua versão original ser igual ao Tytera MD380 ou Baofeng e na versão de Roger Clark o próprio CPS ter perdido informação sendo que o utilizador terá que a inserir manualmente. Por este facto e por ser um equipamento de entrada de gama muitas das funções possíveis na rede DMR não estão disponíveis no mesmo e por essa razão não o apresentamos neste workshop.

 

Serão enviados email’s a todos os inscritos nas sessões anteriores, para quem pretenda inscrever-se de novo deve identificar qual a sessão pretendida se a 1ª, 2ª ou 3ª, para as inscrições anteriores o procedimento é o mesmo, muito embora possam estar presentes em todas elas se acaso vejam justificação para tal, é capaz de não fazer muito sentido assistir a um workshop sobre o Anytone, muito embora possa ser útil saber o que outros equipamentos podem permitir em relação ao que tenha atualmente e ser um fator a ter em conta em uma futura escolha quando o nosso tual equipamento é um Retevis, por exemplo, mas será sempre uma escolha do próprio utilizador.

Devem confirmar a vossa presença reenviando o email de convite identificando qual o workshop a que pretendem estar presentes. As sessões não deverão ultrapassar 1H, podendo contudo ser estendidas no tempo havendo solitações de colegas e dependente da aquisição de conhecimento geral e/ou individual.

Para os colegas que tiveram uma avaliação positiva na formação sobre CPS e que fizeram envio do codeplug de teste será enviado um “Certificado de Presença” e avaliação que não conferindo nenhum grau académico é representativo do tempo e do conhecimento adquirido, sendo também uma forma de agradecimento da nossa parte pelo vosso tempo e paciência.

 

 


 

Foi então lançado o desafio e estipuladas datas, será sempre aos domingos e sempre com início as 15:00 locais. Os colegas que pretendam assistir terão previamente que o solicitar através do email ‘team.dmr.pt@gmail.com’ que funciona tão somente para recolha dos vossos email para envio do convite para as sessões em Zoom.

 

Nesta primeira fase foram apresentados os seguintes temas;

1 º Ação – 28/02 – 15H
• Breve descrição do funcionamento do sistema DMR, relacionamento entre uma rede de voz digital e uma rede informática.
• Apresentação das diversas plataformas usadas em DMR. Como proceder, o que conhecer sobre elas.
o Brandmeister.network site, Selfcare, wiki de Portugal e RadioID
• Como consultar dados na rede, relativos a contactos, TG’s e outros.
o Brandmeister.network, aprenda a criar consultas sobre contas, TG’s e outros.
2ª Ação – 07/03 – 15H
• Filosofia de um codeplug, o que é necessario sabermos.
o A composição de um codeplug deve ser pensada, quais os repetidores que eu alcanço?, que nomes lhe vou chamar? devo criar uma zona unica e ponho la tudo?
• Contrução em blocos do que iremos necessitar, isto para um melhor entendimento.
• Utilização do software de programação, vulgarmente chamado de CPS (Customer Programming Software – software de programação cliente). Iremos focar sobre os mais usados.
o Iremos ver a construção desde o “zero” de um codeplug e como utilizar ferramentas externas para nos ajudar na construção.

  

Link para as gravações:

 

1ª Ação: Formação 1ªação

2ª Ação: Formação 2ªação 

1º workshop: Anytone “tweaks” dia – 02/Maio

2º workshop Tytera MD380/390 UV380/390 – 09/Maio

3º workshop Retevis RT3s RT82 – 16/Maio

 

 

 

Obrigado a todos os que estiveram presentes.