Transferência da arquivos via LoRa é possível assim como qualquer outra modulação, mas existem desafios particulares nessa tarefa que em outras modulações podem ser mais fáceis.
Sobre a modulação LoRa
Antes mesmo de partimos para a transferência de arquivos via LoRa, é preciso entender que o LoRa não foi feito para esse tipo de aplicação e sim para dispositivos IoT, mesmo embora tenha uma taxa de bits por segundo de 30k.
Para transferir arquivos o mais rápido possível, quanto maior a taxa de bps melhor, mas isso implicaria no alcance e quando se trata de LoRa queremos que a informação parta do ponto A e chegue no ponto B mesmo em distâncias longas, afinal essa modulação carrega o longo alcance no próprio nome.
Então fazer uma transferência de arquivo através dessa modulação, é necessário achar um equilíbrio entre alcance e velocidade. Pois esse tipo de aplicação de transferência de arquivos pode ser útil para locais remotos que desproveem de outros métodos de comunicação.
Exemplos de aplicação
Existem inúmeras aplicações para esse tipo de projeto, principalmente para locais remotos que desproveem de outros meios de comunicação. Este projeto em si foi pensando para transferências de criptomoedas, mas como não foi encontrado nenhum método eficiente para fazer isso, foi mudado o foco para transferência de arquivos em geral.
Os Rovers espaciais como é o caso do persévérance, utilizam um método similar onde envia um pacote em 400MHz de marte até um satélite orbital que fica em marte e o satélite faz o repasse das informações para a terra, demorando em cerca de 5 a 20min a dependendo da posição dos planetas.
Como será feito a transmissão de arquivos via LoRa?
O sistema de transmissão de arquivos via LoRa é em tese muito simples, temos o hardware que vai se comunicar com o aplicativo que fará todo o trabalho de tornar essa aplicação possível. O aplicativo basicamente vai pegar o arquivo desejado a ser enviado, compactar, fatiar em uma quantidade especifica de bytes, transmitir essas fatias, receber os pacotes enviados, juntar as fatias, criar o arquivo e descompactar.
A grande sacada desse tipo de aplicação é justamente pegar o arquivo e compactar, desse forma o arquivo fica mais leve e demora menos para ser transmitido, em compensação se houver algum byte errado toda a transmissão fica corrompida. Além disso, o fato de usar um arquivo compactado, acaba não sendo necessário informar o tipo do arquivo e nem muito menos o nome dele, pois tudo isso já vai encapsulado dentro do arquivo zip.
Analogia de funcionamento
Talvez você possa estar com certa dificuldade em entender o principio do funcionamento do fatiamento, compressão e descompressão, então nada melhor do que trazer exemplos da nossa realidade para que fique mais fácil o entendimento.
Fatiamento de Bytes
Para entender melhor sobre o funcionamento de fatiamento desse sistema, vamos fazer uma pequena analogia com comida. Uma pessoa dificilmente vai conseguir bater um prato de feijão com uma única bocada, então comemos em pequenas partes até que a comida no prato se acabe.
Algumas pessoas podem comer mais quantidade de comida por colherada/garfada do que outras pessoas e na eletrônica é a mesma coisa, porém esse termo é defino por ‘bits por segundos’ ou bps. O bps que vai determinar quantos pacotes de X bytes serão necessários para acabar de enviar o arquivo, porém em RF é algo bastante relativo, pois mesmo embora que o LoRa consiga ter uma faixa de 30kbps que daria 3750B em um segundo isso reduziria absurdamente o alcance e o propósito dessa modulação.
Compressão e descompressão de arquivos
Na compressão de arquivos é algo bastante simples, vamos fazer uma analogia com bola de futebol/basquete/vôlei ou qualquer uma de sua preferência, mas que seja necessário enchê-las com ar.
Se pegarmos qualquer uma dessas bolas e fomos transportá-las com elas cheias o volume vai ser absurdamente maior do que o real volume (bola vazia), então reduzir o tamanho delas para o transporte e depois enche-las é muito mais eficiente do que transportá-las cheias.
Essa analogia funciona bem para entender o processo de compressão e descompressão para transporte de arquivos, mas nem tudo são flores, pois cada tipo de arquivo tem sua densidade e uns serão mais compressíveis que outros. Por exemplo, fazer uma bolinha com papel higiênico é mais fácil do que fazer com papelão, o mesmo vale para os arquivos.
Por exemplo tenho dois arquivos um é um código feito em C# e outro é uma música do Metallica, qual você acha que vai terá maior mudança de volume do arquivo original em relação com a compressão?
Acredito que a melhor forma de responder isso é de fato demonstrando na prática, primeiramente vamos ver um comparativo de um arquivo .cs antes e depois de ser compactado, veja só a diferença de bytes da imagem da esquerda para a imagem da direita.
Agora vamos repetir o mesmo processo para um arquivo .mp3, vou usar como base a música blackend do Metallica. Se você for fazer um comparativo com a compressão do arquivo .cs, vai ver que a diferença é muito grande, mas nesse arquivo aqui a diferença é muito pouca.
Desafios do projeto
A ideia do projeto em si é bastante simples, mas na prática as coisas mudam bastante. A ideia inicial era fazer uma rede com LoRaMesh da Radioenge para que fosse possível vários dispositivos conseguissem transacionar criptomoedas, porém a ideia inicial foi muito mais complexa do que os desafios iniciais como:
- A estrutura do LoRaMesh não permite que um “slave A” envie uma mensagem de forma direta para o “slave B”, a única forma possível é enviar para o master para que depois seja repassado;
- Um único master para gerenciar inúmeros dispositivos na rede simplesmente iria saturar rapidamente e toda rede iria colapsar;
- Alguns pacotes após um determinado ponto, simplesmente começava a se perder, mas isso foi uma série de fatores que ocasionaram isso;
- Intervalo de tempo de 5s entre cada pacote fazia com que a transmissão fosse demorada se considerado a capacidade de transação de bps;
- Lógica da estrutura muito dispersa e dívida em hardware e software, onde o mais correto era centralizar toda a operação no aplicativo e deixar o hardware apenas como uma extensão do app.
Por causa desses vários problemas, notei que a melhor forma de resolver tudo isso é mudar completamente a perspectiva sobre o projeto e começar do zero, apenas aproveitando o que de fato tinha sido validado.
Então troquei o módulo da Radioenge para um da Ebyte que é muito mais simples o uso e facilitaria a criação de uma lógica que fosse minimamente funcional, que após ser validada, ficaria mais fácil a implementação de outros hardwares. Além disso, tirei toda visão de vários dispositivos e foquei em transmitir de um ponto A a um ponto B.
Após várias tentativas e erros, consegui chegar a um modelo que de fato conseguia transmitir os arquivos, porém o que mais me incomodou é que o tempo entre uma fatia e outra tinha que ser necessariamente 30s para que ele funcionasse sem tropeçar nos pacotes, já que os módulos da Ebyte não tem um comando “envie”, simplesmente você transmite e quando para de transmitir o módulo automaticamente interpreta que está na hora de enviar.
Isso é um ponto interessante, mas não sei se de fato esse problema de tempo esteja totalmente relacionado a isso, possa ser alguns outros fatores mesclados, como por exemplo tempo de transmissão, porém é algo que deve ser testado.
Como eu não poderia dedicar muito tempo a isso para finalmente conseguir divulgar a ideia, deixei o app com algumas configurações para que qualquer pessoa ou até eu mesmo fosse realizar novos testes com outros hardwares e intervalos de tempo diferentes.
Montando a o sistema de Transferência de arquivos via LoRa
Como foi dito anteriormente, o sistema de transferência de arquivos via LoRa é compostos por duas partes, um é o hardware que contém um micro controlador e um LoRa e a outra parte é o software que gerência tudo. Todo o projeto está disponível no Github, para baixar bastar clicar aqui.
Hardware de comunicação
O hardware em si não é nada muito complexo, é o mais simples possível e possa ser que nem seja necessário o uso de microcontrolador, nesse caso em especifico foi utilizado o ESP32, mas pode ser qualquer um de sua preferência.
Diagrama esquemático
Como não tem nenhum fator em termos de hardware que faça com que haja uma distinção entre receptor e transmissor, então o hardware será o mesmo.
Código do transmissor
#include <EBYTE.h>
#define M0_LoRa 13
#define M1_LoRa 14
#define AUX_LoRa 4
EBYTE LoRa(&Serial2, M0_LoRa, M1_LoRa, AUX_LoRa);
void setup() {
Serial.begin(9600);
Serial2.begin(9600);
LoRa.init(); // Inicializa a comunicação e obtem todos os parâmetros do módulo
//LoRa.Reset(); // Reseta parâmetros para os de fábrica
LoRa.SetAirDataRate(ADR_1K); // Define a taxa de dados de transmissão
LoRa.SetAddress(1); // Define endereço da rede
LoRa.SetChannel(23); // Define canal como 23
LoRa.SaveParameters(TEMPORARY); // Salva todas as definições de forma temporária
//LoRa.PrintParameters(); // Imprime todos os parâmetros (configurações) obtidos do módulo
LoRa.SetMode(MODE_NORMAL); // Define modo de operação como normal
}
void loop() {
if(Serial.available()){
Serial2.write(Serial.read());
}
}
Código do Receptor
#include <EBYTE.h>
#define M0_LoRa 13
#define M1_LoRa 14
#define AUX_LoRa 4
EBYTE LoRa(&Serial2, M0_LoRa, M1_LoRa, AUX_LoRa);
void setup() {
Serial.begin(9600);
Serial2.begin(9600);
LoRa.init(); // Inicializa a comunicação e obtem todos os parâmetros do módulo
//LoRa.Reset(); // Reseta parâmetros para os de fábrica
LoRa.SetAirDataRate(ADR_1K); // Define a taxa de dados de transmissão
LoRa.SetAddress(1); // Define endereço da rede
LoRa.SetChannel(23); // Define canal como 23
LoRa.SaveParameters(TEMPORARY); // Salva todas as definições de forma temporária
//LoRa.PrintParameters(); // Imprime todos os parâmetros (configurações) obtidos do módulo
LoRa.SetMode(MODE_NORMAL); // Define modo de operação como normal
}
void loop() {
if(Serial2.available()){
Serial.write(Serial2.read());
}
}
Software gerenciador
A interface de funcionamento do aplicativo é bastante simples, sendo o mais óbvio possível e com alguns parâmetros de configuração para que viabilize novos testes.
Como você pode ver a imagem acima, o aplicativo é basicamente dividido em dois setores de funcionamento, o primeiro é de gerenciamento de arquivo e o outro é de configurações do app.
Gerenciamento de Arquivo
A parte de gerenciamento de arquivo trabalha em duas partes, um que é para selecionar o arquivo a ser enviado e a outra parte gera o arquivo baixado e exporta para o local desejado pelo usuário.
Upload File
Nessa parte o usuário deve selecionar um arquivo para ser enviado, quando o arquivo é selecionado o ícone de arquivo fica escuro e aparece o nome selecionado.
Assim que o arquivo é selecionado, é criado um arquivo temporário no local de onde o aplicativo está sendo usado, esse arquivo é uma compressão do arquivo original e estará dentro de uma pasta /temp/ com o nome “file.zip”, toda vez que um novo arquivo é selecionado, o anterior é subinscrito.
Download file
Aqui as coisas funcionam de forma diferente, só quando a transmissão de fato é finalizada que o arquivo é gerado, assim que é gerado o iconece de arquivo do download fica escuro indicando que tem um arquivo disponível, nome e formato também ficará visivel.
Ao clicar no ícone, você terá que selecionar um diretório e um nome para o arquivo e o formato do arquivo vai ser zip, porém assim que você salvar o app vai pegar e descompactar o arquivo e consequentemente o tipo e o nome real irá aparecer.
Todo download feito, mesmo embora o usuário não tenha salvado de forma manual, ainda assim os arquivos ficam salvos em uma pasta chamada downloaded que fica no mesmo diretório que a pasta temp do processo de upload, é importante salientar que em caso de arquivos com o mesmo nome e formatação, ele será subinscrito também dentro desta pasta
Configuração do aplicativo
No aplicativo é possível configurar 3 parâmetros, mesmo embora tenha 4, dois desses parâmetros são fundamentais para iniciar o processo de comunicação sendo eles:
- Port: Você deve escolher o hardware que está com o firmware destinado a operação que será definida pelo “Operation mode”;
- Operation mode: Define o modo de operação do aplicativo para que ele execute o algoritmo respectivo.
Os outros dois parâmetros são destinados para quem quiser fazer testes, porém o primeiro parâmetro ainda não foi implementado no código, mas já deixei no front end para ser implementado assim que possível.
- Bytes per slice: É o quantos de bytes cada pacote de transmissão vai ter, esse parâmetro está desativado, mas será útil para explorar ao máximo diferentes módulo em diferentes configurações de transmissão;
- Slice interval: É o tempo de envio entre cada pacote a ser enviado, por padrão é definido em 30s.
Transferindo arquivo via LoRa
Para demonstrar o funcionamento de toda essa estrutura, nada melhor do que um vídeo mostrando na prática. Como vocês poderão ver, primeiramente é selecionado um arquivo para ser enviado, configuro o aplicativo para ser transmissão e seleciono a porta COM desejada.
Porém antes de iniciar a execução da transmissão vou preparar primeiramente o receptor e inicializo a recepção e por fim início a transmissão.
Depois disso o vídeo fica acelerado em 10x para poupar o tempo de vocês assistindo, esse arquivo que foi enviado é o mesmo arquivo .cs de exemplo da analogia de compressão que comprimido da uns 5kB, no total da uns 14min para transmitir tudo.
