Manual

do

Maker

.

com

Quarentena Maker - Dia 4: Comunicação remota sem Internet

Quarentena Maker - Dia 4: Comunicação remota sem Internet

Ontem fiquei olhando para o bitcômetro, afinal, não havia muito mais o que fazer. Acabei pegando no sono e sabe como é; sonho acontece de tudo. Sonhei que o vírus sofreu uma mutação tão terrível que contaminou a Internet. A Internet não resistiu ao vírus. Acordei tão assustado que imediatamente quis traçar um "plano B", ainda sabendo que aquilo não seria possível acontecer. Hoje veremos como fazer uma comunicação remota sem Internet.

Comunicação remota sem Internet

Quem não lembra do rádio amador? Hum, acho que a maioria de 2000 para cá, mas ok, explico.

Rádio PX

Antigamente tínhamos os rádios PX para fazer "amizades virtuais". Assim como na Internet, eventualmente as pessoas se conheciam pessoalmente.

radio_px-300x163.webp

Nas estradas, desde 1920 os caminhoneiros utilizam rádio PX para comunicação e todos podem utilizar, desde que esteja na frequência aproximada de 27MHz. Essa frequência é chamada de "Faixa Cidadão" e não tem custo de licença para uso.

Nesses rádios se utiliza o código Q e gírias como "fazer um macaco preto", "bater um falcão" (telefone) e outros como "dois metros horizontais" (dormir) etc.

Pager

Já na era digital, o mais bizarro dos meios utilizados foi o BIP (ou pager) nos anos 80 e 90, que era um bagulho que se transportava na cintura para receber mensagens que eram passadas a um tipo de atendente de telemarketing misturado com telefonista, então essa pessoa mandava a mensagem para o bip solicitado. Era um negócio sem controle. Ele utilizava o protocolo FLEX ou PCSAG. No auge de sua evolução havia comunicação bidirecional, mas como a história comprova, não foi uma tecnologia promissora.

pager-300x230.webp

Telefonia celular

Quando começaram a implementar telefonia celular móvel no Brasil (alguém lembra da BCP?), ainda era uma coisa bizarra, mas nessa época reinavam os torpedos.

first_cell-300x214.webp

A operação começou em 1998 usando a tecnologia TDMA. Já em 2003 foi comprada pela Telmex e hoje pertence à Claro. Ou seja, não melhorou nada. Ops, maldade.

Entrando como pioneira na chamada "Banda B", foi a primeira a usar tecnologia 100% digital.

Internet no Brasil

Não vou começar a tratar do assunto pela DARPA, vamos pular algumas décadas.

Para o público geral no Brasil, começamos a ver a cara da Internet em 1994. Antes ainda usávamos a BBS (quem lembra da MANDIC?). A Internet deu muito "pano pra manga", acho que como tudo no Brasil. Em 1996 que a coisa começou a tomar forma e os "hackers" brasileiros começaram a fazer ataques de "ping da morte" no Windows (nessa época até eu era "hacker", hoje tem que saber muita coisa pra merecer o título), acesso remoto a servidores que deixavam o Telnet habilitado com acesso anônimo e outras bizarrices (usei várias vezes o termo porque todas essas épocas foram bizarras mesmo).

Bem, não sei se haverá outro meio que não a Internet, mas ao menos sua divisão deverá acontecer um dia, considerando que todo o tráfego do mundo passa pelos EUA e o controle absoluto nos mantém reféns do detentor. Mas no caso de um colapso das redes de telecomunicação, de que outra forma poderíamos manter contato?

Solução "caseira" para comunicação remota sem Internet

No caso do rádio PX, é necessário uma base retransmissora. A fonte de transmissão pode ser rastreada (como qualquer outra) e um ponto de concentração seria frágil em um cenário apocalíptico. Uma maneira de fazer transmissão de dados utilizando do que dispomos hoje seria através de rádios LoRa, que pode ter um alcance superior a 10km. Como não se depende de um ponto de retransmissão ou como qualquer um pode ser retransmissor, em um cenário de caos poderia ser a solução de baixo custo ideal para comunicação.

Abro um breve "parêntesis" para deixar claro que não estou pondo o atual cenário pandêmico como uma situação de caos, assim como não estou minimizando a gravidade da situação (veja vídeos da situação na Itália, onde estão entrando nas estatísticas pessoas entre 30 e 40 anos). Estou sim utilizando a condição de "pandemia" para imaginar uma situação hipotética (e possível) de uma situação mais grave onde deveríamos recorrer aos instintos de sobrevivência (ainda que não seja por algo como a Peste Negra, que matou 200 milhões de pessoas em uma época em que sequer tínhamos aviões para "agilizar" encontros).

Passo 1: Fazer comunicação serial e repasse por RF

Se usarmos módulos LoRa, o alcance será exponencialmente maior. Para facilidade e baixo custo, estou fazendo esse tutorial com o módulo HC-12, do nosso parceiro Fulltronic. Esse rádio é extremamente simples de configurar, uma vez que a comunicação é serial. Em contrapartida, seu alcance não deve ser maior que 1km com a antena que o acompanha. Sua frequência é 433MHz, bem inferior aos NRF24L01, que são 2.4GHz. Quanto maior a frequência, menor o alcance e vice-versa.

O alcance não é tão grande, mas é o suficiente para fazer a comunicação remota sem Internet.

Wiring HC-12

Já escrevi sobre esse módulo anteriormente, mas não falei de wiring porque, bem, é simples demais. Demais mesmo.

Esse módulo trabalha em 3v3 e 5v, portanto podemos utilizá-lo conectando-o a qualquer plataforma, incluindo um PC, por intermédio de um FTDI.

Na parte de trás do módulo estão especificadas as correspondências dos pinos. TXD vai ao RX e RXD vai ao TX. Isso porque "T" é transmissão e "R" é recepção; um envia e o outro recebe na outra ponta do fio. Sei que parece óbvio, mas muitas pessoas ainda não tem o conceito, principalmente iniciantes.

hc12-wiring-300x188.webp

Os módulos serão conectados aos notebooks através de conversores seriais.

Protocolo de comunicação

Precisamos definir um protocolo para que haja coerência na troca de mensagens. Normalmente trocam-se bytes na comunicação por rádio frequência, mas considerando que estamos no pior caso (que é a interface com o usuário), teremos um campo de mensagem de tamanho variável. Precisamos considerar os seguintes campos:

  • Sinalizador de início de mensagem ('^' é 0x5E).
  • Endereço do dispositivo (por exemplo, 0x01).
  • Flag de nova mensagem (0x00).
  • Flag de confirmação (0x00 para envio de nova mensagem e 0x01 para confirmar recebimento).
  • Tamanho da mensagem (Se for 3 bytes, 0x03).
  • Mensagem ("OLA").
  • Sinalizador de término de mensagem ('$' é 0x24).

Considerando o padrão de expressões regulares, vamos utilizar "^" como início de mensagem e "$" como final de mensagem de nossa comunicação remota sem Internet. Isso significa que não devemos mandar carinhas ASCII como "^)" e nem cobrar dinheiro por mensagem ("você me deve R$10,00 pela consultoria por rádio").

Considerando que cada campo corresponde a 1 Byte, não precisamos utilizar separadores de campo. O comprimento da mensagem precede o campo mensagem, mas nesse protocolo isso serve apenas para validar o tamanho total em Bytes. Por exemplo, uma mensagem "OLA" tem 3 bytes. Uma mensagem completa deve ficar nesse formato:

5E 01 00 00 03 4F 4C 41 24

Quando chegar do outro lado, a comparação byte a byte pode ser feita com uma condicional simples:

if (valor_lido == '$'){
    acabou a mensagem;
}

Então não precisamos realmente saber os valores hexadecimais, exceto tenhamos que depurar a mensagem na serial, por isso coloquei os valores.

Se precisar fazê-lo, pode consultar uma tabela online ou se tiver Python instalado, utilizar o interpretador. Particularmente utilizo o editor de fluxo bpython. Usando a função ordhex, já obtemos imediatamente o resultado:

bpython-ord.webp

HC-12 com Arduino

De um lado, conectarei o HC-12 diretamente ao notebook com a utilização de um adaptador FTDI. Apesar de ter outros adaptadores, não os encontro. Mas sem problemas, porque assim posso exemplificar a utilização do módulo com um Arduino fazendo a ponto entre o HC-12 e o outro notebook.

No notebook que tenho o FTDI, nenhum procedimento mais será necessário; bastará abrir a conexão serial.

Para o notebook com Arduino, primeiro precisamos fazer um sketch que repasse a mensagem recebida na serial. Estou utilizando o Arduino Leonardo, que possui uma serial para a USB e outra serial nos pinos 0 e 1. Poderia ser um Arduino UNO sem problemas, bastaria utilizar a biblioteca SoftwareSerial. Estou utilizando o Leonardo porque está bem aqui do meu lado.

Como o tratamento será feito pelo chat (que devo escrever para o próximo artigo), podemos controlar apenas o início e o fim da mensagem, que fica mais parecido com o papel da MCU, que é a comunicação. Como a interface com o usuário é o desktop, não há razão para encher a MCU de instruções.

#include <Arduino.h>

//garanta que nao vai acumular para sempre (dentro da função msgParser).
#define MAX_MSG_SIZE 250

char msg[250] = {0};
char chararray[250] = {0};
uint8_t i = 0;

//essa função receberá cada byte que chegar na serial e deve ser chamada dentro do loop.
void msgParser(){
    //se for qualquer coisa diferente do inicio e era pra ser o primeiro byte...
    if (msg[0] != '^' && i == 0){
        memset(msg,0,MAX_MSG_SIZE);
        i = 0;
        return;
    }

    //enquanto não for o finalizador, acumula na string.
    //é bom definir um buffer máximo para não ter overflow.
    if (msg[i] != '$'){
        //Ainda não é o fim da mensagem. Verificar se pode acumular então:
        if (sizeof(msg) > MAX_MSG_SIZE){
            strcpy(msg,"MESSAGE TOO BIG");
            memset(msg,0,MAX_MSG_SIZE);
            return;
        }
        
        Serial.print("DEBUG: ");
        Serial.println(msg);
        return;
    }
    i++;


    /*
    Aqui adicionamos tratamento para a mensagem, caso não seja enviada para o computador.
    Se for enviada para o computador, deixemos o tratamento para ser feito pelo chat em Qt.
    */

   //Se a mensagem tem o inicio e fim, o resto do tratamento e feito pelo chat. Se a mensagem
   //estiver maior que o buffer, exibe "MESSAGE TOO BIG". Isso é para previnir trolls enviando mensagem DDOS, porque
   //o próprio chat em Qt se encarregará de informar que o limite da mensagem foi excedido.
   if (msg[i] == '$'){
       i = 0;
       memset(msg,0,MAX_MSG_SIZE);
       Serial.println(msg);
   }
}

void setup(){
    Serial.begin(9600);
    Serial1.begin(9600);

}

void loop(){
    while (Serial1.available()){
        Serial1.readBytesUntil('$',msg,MAX_MSG_SIZE);
        msgParser();
    }

    //aqui é o "lado de dentro". O que chegar pela serial interna é supostamente confiável.
    while (Serial.available()){      
        Serial.readBytesUntil('$',chararray,MAX_MSG_SIZE);

    }

    if (strcmp("$",chararray) <= 0){
        Serial1.println(chararray);
        memset(chararray,0,sizeof(chararray));
    }
    delay(100);
}

No código acima temos o tratamento para envio e recepção da mensagem, que resulta em algo como:

quarentena_maker-4-chat.webp

Fazer o chat separado desse artigo me pareceu uma boa ideia porque o farei em Qt, aí ia ficar grande demais o artigo. Acompanhe, a brincadeira será divertida.

Vídeo

Deixarei o vídeo para mostrar junto com o chat. Coisas que são apenas prova de conceito sem maiores detalhes estou colocando no Instagram. Aproveite para nos seguir por lá também!

Dessa vez será vídeo no Youtube porque é algo mais elaborado, então inscreva-se em nosso canal DobitaobyteBrasil no Youtube e clique no sininho para receber notificações.

Quarentena Maker - Dia 4: Ok, não ficarei mais sem comunicação remota se faltar a amada Internet. Resta encontrar alguém na vizinhança que tenha HC-12 para me adicionar, mas sentirei falta dos likes do Facebook. Dia 4 passado com sucesso!

 

Revisão: Ricardo Amaral de Andrade

Inscreva-se no nosso canal Manual do Maker no YouTube.

Também estamos no Instagram.

Nome do Autor

Djames Suhanko

Autor do blog "Do bit Ao Byte / Manual do Maker".

Viciado em embarcados desde 2006.
LinuxUser 158.760, desde 1997.