Site menu LoRaMaDoR: chat via rádio digital

LoRaMaDoR: chat via rádio digital

2020.04.19

Este artigo expressa a opinião do autor na época da sua redação. Não há qualquer garantia de exatidão, ineditismo ou atualidade nos conteúdos. É proibida a cópia na íntegra. A citação de trechos é permitida mediante referência ao autor e este sítio de origem.

Nada como a quarentena! Na procura do que fazer, acabei terminando a primeira versão "usável" de algo que tinha começado no início do ano passado: o LoRaMaDoR.

O que é o LoRaMaDoR?

O LoRaMaDoR é um sistema de comunicação baseado no rádio digital LoRa. O caso de uso mais óbvio é conversa ao vivo (chat), com potencial para muitas outras utilidades.

Como de costume, o código pode ser encontrado no GitHub.

Foi inspirado no AX.25, que hoje em dia sobrevive vestigialmente no APRS; e principalmente no LoRaHam, projeto com premissa semelhante ao nosso.

Assim como os projetos citados, o LoRaMaDoR é voltado a priori para radioamadores; o prefixo é o endereço de rede. Mas nada impede que interessados sem licença façam uso dele. E podem fazê-lo legalmente, já que o LoRa opera nas bandas ISM, isentas de licença (*).

Molhando os pés

No vídeo abaixo, estou rodando o LoRaMaDoR em alguns Arduinos, e estou interagindo com um deles via porta serial USB. Faço envio de mensagens "humanas", e também emito um "ping" que provoca resposta automática:

Uso da interface de texto (CLI). A porta serial a que o terminal está conectado, é um Arduino TTGO LoRa32.

Geralmente o radioamador tem apenas um prefixo. Assim como no APRS, se ele operar mais de uma estação, pode identificar cada uma por um sufixo numérico (SSID).

A ideia da interface via texto (CLI) é simplificar ao máximo a operação típica. Para mandar uma mensagem, basta digitar "prefixo mensagem"; o controlador se encarrega de completar as lacunas e produzir pacotes corretos.

O LoRaMaDoR também funciona sem um terminal serial conectado. Basta estar ligado para responder a PINGs e funcionar como repetidor. Poderia ser usado em sensores metereológicos, localizadores, etc.

Por que não usar o LoRaHam?

O projeto LoRaHam parecia meio parado há pelo menos dois anos, contando do dia que comecei a trabalhar no LoRaMaDoR.

Também achei simples demais o formato do pacote de rede. Não há uma seção de metadados (que utilizamos no PING, por exemplo) e não há um identificador do pacote (detectar duplicatas envolveria comparar as mensagens inteiras).

O LoRaHam não usa código de correção de erros (FEC), repetindo um erro cometido pelo AX.25 e pelo APRS. O LoRa tem correção de erros embutida, porém em meus testes determinei que ela é fraca. Mesmo na modalidade mais forte (50% de redundância) e nas melhores condições de transmissão, aparecem bytes errados aqui e ali.

Por que usar LoRa?

O rádio digital LoRa é de longe o melhor em diversas métricas. É fácil atingir um alcance de vários quilômetros com 100mW de potência e uma antena comum. O recorde mundial é 766km com apenas 25mW! É barato, fácil de achar e existem controladores Arduino que vêm com chip LoRa embutido.

A velocidade do LoRa é configurável numa ampla faixa. Quanto mais velocidade, menos alcance e vice-versa. Depois de muitos testes, adotei parâmetros que entregam em torno de 4000bps, com alcance de vários quilômetros.

O LoRa pode trabalhar em diversas bandas ISM; as mais comuns são 433MHz (70cm) e 915MHz (33cm). Note que estas bandas também podem ser usadas por radioamadores em caráter secundário. 70cm tem potencial de alcance maior, porém LoRa é "spread spectrum" e no Brasil a ANATEL proíbe o uso de spread spectrum em 70cm por radioamadores.

Claro que você pode usar LoRa em 433MHz como "civil", porém os aparelhos "civis" têm potência limitada (10-100mW). Vestir o chapéu de radioamador, e resignar-se a usar a banda de 915MHz, autoriza o uso de potências muito maiores (100-1500W).

Note também que o protocolo LoRaMaDoR não depende de nenhum recurso específico do LoRa. É perfeitamente possível usar outros rádios digitais. Por exemplo, o CC1101 funciona em 433MHz e é de "banda estreita". O Si4463 funciona até nas bandas de 1.3m e 2m.

Objetivos extrínsecos

Diversas faixas são consagradas ao radioamadorismo, porém muitas ficam abandonadas. Usar rádio digital é uma forma simples de ocupar este espaço.

Existe pressão contínua para redestinação das bandas de radioamadorismo. Em particular, todas as faixas abaixo de 1GHz são consideradas o "filé" do negócio. Em alguns países, os radioamadores já perderam parte da banda de 1.3m (220MHz), e a tendência é perder a banda toda.

As bandas de 70cm e 33cm também são visadas, embora o perigo de redestinação seja menor porque existe sobreposição parcial com ISM.

Hardware de referência

No momento, utilizo apenas uma plaquinha compatível com Arduino: TTGO LoRa32, com controlador ESP32. A placa principal possui LoRa e um painel OLED. Os kits podem incluir antena, caixinha e/ou bateria.

No início do projeto, também empreguei o LoRa32u4. É uma plaquinha de excelente qualidade, porém esbarra nas limitações inerentes do AVR. Depois de algumas tentativas heróicas de otimização, acabei deixando-o de lado. (Alguns resquícios do suporte a LoRa32u4 ainda restam no código.)

Nada impede que o LoRaMaDoR rode em outras plataformas, tipo um Raspberry conectado a um chip LoRa. Meu esforço se concentra no TTGO porque é o hardware que possuo. Boa parte do código em C++ roda no Linux para fins de teste (cobertura e Valgrind), usando multicast para simular a camada de rádio.

Decisões de projeto

O aspecto mais atraente do AX.25, do APRS, e também do LoRaHam, é a legibilidade. Um ser humano consegue ler e entender os pacotes "crus", ainda que o consumidor final seja uma máquina.

Como disse o Temer, "precisa manter isto, hein?". Segue um exemplo de pacote LoRaMaDoR e sua interpretação:

PP5CRE-11<PU5EPX-11:21,PING,AAA=,BBB=CCC test 123

Destino:    PP5CRE-11
Origem:     PU5EPX-11
Sequencial: 21
Parâmetros: PING (sem valor)
            AAA, valor vazio
            BBB, valor CCC
Payload:    test 123

A outra metade da usabilidade é a linha de comando. O usuário nunca precisa digitar o pacote inteiro no formato acima. O sequencial e a origem são inseridos automaticamente. Tipicamente, para "pingar" a estação remota PP5CRE-11, o usuário digitaria apenas

PP5CRE-11:PING test 123

Note que até mesmo o payload (test 123) é opcional no PING. Se ele existir, é ecoado no PONG.

No screenshot abaixo, o usuário emite uma mensagem de broadcast, usando o pseudo-prefixo QC. O terminal está em modo debug, e mostra o formato final do pacote transmitido, bem como as duplicatas recebidas de repetidores:

Figura 1: Transmissão de mensagem geral (QC hello). O modo debug revela o pacote transmitido em seu formato final, bem como as retransmissões do nosso pacote feitas por outras estações.

No screenshot abaixo, não há ação do usuário, apenas a saída de debug relativa à recepção e retransmissão de um pacote "beacon" (QB) automático, vindo da estação PU5EPX-2:

Figura 2: Recepção de mensagem em modo debug. Uma estação vizinha é descoberta por conta do pacote QB, o pacote é retransmitido apenas uma vez, os demais `ecos` do mesmo pacote são ignorados.

Um grande erro do AX.25, herdado pelo APRS, é não empregar código de correção de erros. No LoRaMaDoR, cada pacote é transmitido com um sufixo Reed-Solomon (RS) de 20 bytes.

No início do desenvolvimento, fizemos alguns estudos de roteamento ad-hoc, e chegamos à conclusão que não vale a pena o esforço. Para redes pequenas, um simples roteamento por difusão é suficiente.

Para lidar com redes maiores, o caminho parece ser o já trilhado pelo APRS: gateways via Internet. Desenvolver os protocolos de gateway e limitar a difusão a um certo diâmetro de rede (no estilo do WIDE-n do APRS) são os próximos desafios de desenvolvimento.

Notas

(*) Nesta faixa você encontra portões eletrônicos, babás eletrônicas, telefones sem fio mais antigos, etc. Os aparelhos que operam na faixa ISM ainda precisam do "selo ANATEL", porém os usuários não precisam de licença individual de operação.