evertonjessica_lora_wan

Prévia do material em texto

Pontifícia Universidade Católica do Paraná 
Escola Politécnica 
Engenharia Elétrica – Ênfase em Telecomunicações 
Disciplina de Trabalho Final de Graduação II – 2° bimestre 
 
 
 
EVERTON RAUSIS CORDEIRO 
JÉSSICA ALINE KAROLESKI 
 
 
 
RELATÓRIO TÉCNICO FINAL 
Utilização de LoRa em redes para melhorar parâmetros de qualidade de 
distribuição de energia em zonas rurais. 
 
 
 
Orientador: VOLDI COSTA ZAMBENEDETTI 
________________________ 
 
 
 
 
CURITIBA, 
NOVEMBRO DE 2018 
1 
 
SUMÁRIO 
 
1. RESUMO ................................................................................................... 5 
2. INTRODUÇÃO ........................................................................................... 6 
2.1 Propagação de Espaço Livre ............................................................ 8 
2.2 Perda no espaço livre ....................................................................... 9 
2.3 Desvanecimento ................................................................................ 9 
3. DETALHAMENTO DO PROJETO .......................................................... 10 
3.1 Configurando Módulo LoRa Dragino ............................................... 10 
3.2 Configurando TheThingSpeak ......................................................... 13 
3.3 Configurando Gateway LG01 Dragino ............................................. 16 
3.4 Configurando Gateway ao Server ThingSpeak ............................... 21 
3.5 Arduino UNO ................................................................................... 21 
3.9 Protocolo LoRaWan ........................................................................ 23 
4. PROCEDIMENTOS DE TESTES E RESULTADOS ............................... 26 
4.1 Funcionamento geral da rede .......................................................... 26 
4.2 Códigos de Programação ................................................................ 27 
4.2.1 Programação dos nós LoRa ...................................................... 27 
4.2.2 Programação do Gateway – VEZ ............................................... 29 
4.2.2 Programação do Gateway – Divisão no Tempo ....................... 30 
4.2.4 Programação do Nó Sincronizador ........................................... 33 
4.2.5 Programação do Repetidor ........................................................ 35 
4.2.4 Filtro de Média Móvel ................................................................. 37 
4.2.5 CRC – Cyclic Redundancy Check e métrica ETX ..................... 38 
4.2.6 Modo Sleep LoRa ........................................................................ 40 
4.3 Testes de transmissão .................................................................... 41 
4.3.1 Ambiente externo ...................................................................... 42 
4.3.1.1 Teste 01 – Urbano ..................................................................... 42 
4.3.1.2 Teste 02 - Urbano ...................................................................... 44 
4.3.1.3 Teste 03 - Urbano ...................................................................... 46 
4.3.1.4 Teste 04 - Urbano ...................................................................... 47 
4.3.1.5 Teste 05 - Urbano ...................................................................... 48 
4.3.1.6 Teste 06 – Urbano ..................................................................... 49 
4.3.1.7 Teste 07 - Rural .......................................................................... 51 
4.3.1.8 Teste 08 - Rural .......................................................................... 52 
2 
 
4.3.1.9 Teste 09 - Rural .......................................................................... 54 
4.3.1.10 Teste 10 - Rural ........................................................................ 55 
4.3.1.11 Teste 11 – Rural ....................................................................... 56 
5. CONCLUSÃO .......................................................................................... 59 
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................ 61 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3 
 
LISTA DE FIGURAS 
 
Figura 1 - Hardware do Módulo Dragino. Fonte: WikiDragino. .................................... 10 
Figura 2 - Módulo LoRa com antena conectado ao Arduino UNO. .............................. 10 
Figura 3 - Testes dos módulos. Fonte: Os autores. .................................................... 12 
Figura 4 - Acompanhamento de testes pelo monitor Serial. Fonte: Os autores. .......... 12 
Figura 5 - Página inicial do ThingSpeak. Fonte: thingspeak.com ................................ 13 
Figura 6 - Meus canais – exibidos após logar no site. Fonte: thingspeak.com ............ 13 
Figura 7 - Criação de canais. Fonte: thingspeak.com ................................................. 14 
Figura 8 - Chaves do Canal. Fonte: thingspeak.com................................................... 15 
Figura 9 - Local para visualização de dados. Fonte: Os autores. ................................ 15 
Figura 10 - Diagrama de Blocos do Hardware do Gateway. Fonte: MANUAL 
GATEWAY. ................................................................................................................. 17 
Figura 11 - Modo Cliente Wi-Fi. Fonte: MANUAL GATEWAY. .................................... 18 
Figura 12 - Configuração como Cliente Wi-Fi. Fonte: Os autores. .............................. 18 
Figura 13 - Configuração LAN e DHCP. Fonte: Os autores. ....................................... 19 
Figura 14 - Desabilitar Access Point. Fonte: Os autores. ............................................ 20 
Figura 15 - Acesso ao roteador local e configuração de canal. Fonte: Os autores. ..... 20 
Figura 16 - Configurando Gateway ao ThingSpeak. Fonte: MANUAL GATEWAY ...... 21 
Figura 17 - Arduino UNO. Fonte: Divulgação. ............................................................. 22 
Figura 18 - Pinagem do controlador ATMEGA328. Fonte: EMBARCADOS. ............... 23 
Figura 19 - Bloco do protocolo LoRaWan mostrando AES128. Fonte: 
THOMASCLAUSEN.................................................................................................... 24 
Figura 20 - Bloco do protocolo LoRaWan. Fonte: THOMASCLAUSEN ....................... 25 
Figura 21 - Montagem da rede física. Fonte: Os autores. ........................................... 27 
Figura 22 - Diagrama simplificado do código de um nó. Fonte: Os autores. ............... 28 
Figura 23 - Diagrama simplificado do código do gateway. Fonte: Os autores. ............ 30 
Figura 24 - Esquema FDM. Fonte: Planificación y Administración de Redes, 2017. ... 31 
Figura 25 - Esquema TDM. Fonte: Planificación y Administración de Redes, 2017. ... 32 
Figura 26 - Diagrama simplificado do código do gateway. Fonte: Os autores. ............ 33 
Figura 27 - Montagem da rede física com sincronizador. Fonte: Os autores. .............. 34 
Figura 28 - Diagrama simplificado do código do sincronizador. Fonte: Os autores. .... 35 
Figura 29 - Diagrama simplificado do código do Repetidor. Fonte: os autores. ........... 36 
Figura 30 - Montagem da rede física. Fonte: Os autores. ........................................... 37 
Figura 31 - Coleta de dados RSSI sem filtro. Fonte: os autores. ................................. 38 
Figura 32 - Coleta de dados RSSI com filtro. Fonte: os autores. ................................. 38 
4 
 
Figura 33 - Número de pacotes entregues em função da distância. Fonte: Os autores.
 ................................................................................................................................... 42 
Figura 34 - Alcance teste 01 – 334 metros. Fonte: Os autores. .................................. 43 
Figura 35 - Perfilde elevação do terreno – teste 01 – 334 metros. Fonte: Os autores.43 
Figura 36 - Nº pacotes x RSSI do teste 01. Fonte: Os autores.................................... 44 
Figura 37 - Alcance do teste 02 – 213 metros. Fonte: Os autores. .............................. 45 
Figura 38 - Perfil de elevação do terreno – teste 02 – 213 metros. Fonte: Os autores.45 
Figura 39 - Nº pacotes x RSSI do teste 02. Fonte: Os autores.................................... 46 
Figura 40 - Alcance teste 03 – 926 metros. Fonte: Os autores. .................................. 46 
Figura 41 - Perfil de elevação do terreno – teste 03 – 926 metros. Fonte: Os autores.47 
Figura 42 - Nº pacotes x RSSI do teste 03. Fonte: Os autores.................................... 47 
Figura 43 - Alcance teste 04 – 332 metros. Fonte: Os autores. .................................. 47 
Figura 44 - Perfil de elevação do terreno – teste 04 – 332 metros. Fonte: Os autores.48 
Figura 45 - Nº pacotes x RSSI do teste 04. Fonte: Os autores.................................... 48 
Figura 46 - Alcance teste 05 – 586 metros. Fonte: Os autores. .................................. 49 
Figura 47 - Perfil de elevação do terreno – teste 05 – 586 metros. Fonte: Os autores.49 
Figura 48 - Alcance teste 06 – 485 metros. Fonte: Os autores. .................................. 50 
Figura 49 - Perfil de elevação do terreno – teste 06 – 485 metros. Fonte: Os autores.50 
Figura 50 - Alcance teste 07 – 771 metros. Fonte: Os autores. .................................. 51 
Figura 51 - Perfil de elevação do terreno – teste 07 – 771 metros. Fonte: Os autores.51 
Figura 52 - Nº pacotes x RSSI do teste 7. Fonte: Os autores ..................................... 52 
Figura 53 - Alcance teste 08 – 1218 metros. Fonte: Os autores. ................................ 53 
Figura 54 - Perfil de elevação do terreno – teste 08 – 1218 metros. Fonte: Os autores.
 ................................................................................................................................... 53 
Figura 55 - Nº pacotes x RSSI do teste 8. Fonte: Os autores. .................................... 54 
Figura 56 - Alcance teste 09 – 956 metros. Fonte: Os autores. .................................. 54 
Figura 57 - Perfil de elevação do terreno – teste 09 – 956 metros. Fonte: Os autores.55 
Figura 58 - Alcance teste 10 – 1168 metros. Fonte: Os autores. ................................ 55 
Figura 59 - Perfil de elevação do terreno – teste 10 – 1168 metros. Fonte: Os autores.
 ................................................................................................................................... 56 
Figura 60 - Nº pacotes x RSSI do teste 10. Fonte: Os autores.................................... 56 
Figura 61 - Alcance teste 11 – 773 metros. Fonte: Os autores. .................................. 57 
Figura 62 - Perfil de elevação do terreno – teste 11 – 773 metros. Fonte: Os autores.57 
Figura 63 - Nº pacotes x RSSI do teste 11. Fonte: Os autores.................................... 58 
 
 
5 
 
1. RESUMO 
 
A nova tecnologia de rádio LoRa, é uma grande aliada à Internet das 
Coisas (IoT) do inglês Internet of Things e promete consolidar-se no ramo devido 
às aplicações com um baixo consumo de potência e longo alcance. É muito 
utilizada em países norte americanos e europeus, todavia, ainda, não é muito 
utilizada no nosso país. 
Utilizaremos essa tecnologia para produzir um sistema de monitoramento 
e verificar os parâmetros de transmissão para, se possível, coletar dados de 
sensores e medidores de energia, que seja eficiente e econômico, uma vez que 
as informações poderão ser adquiridas remotamente. Em uma implementação 
real, por exemplo, sem a necessidade de disponibilizar funcionários de uma 
empresa para realizar as medidas de sensores ou medidores in loco, o que é 
muito útil para empresas hoje em dia que procuram melhorar sua produtividade 
e qualidade de serviço. 
Serão apresentadas informações sobre os hardwares, softwares e os 
métodos que a equipe utilizou para a criação da rede de comunicação. Foram 
utilizados os microcontroladores Arduino ligados a módulos LoRa e Gateway 
LoRa da fabricante da Dragino. Um desenvolvimento realizado neste trabalho foi 
também um nó repetidor LoRa, uma vez que seu protocolo não prevê a formação 
de rede com repetidores. Serão apresentados ainda os testes práticos das 
medidas e coleta de dados que foram realizados em zona urbana e rural. Os 
testes de comunicação entre cliente e servidor apresentaram resultados dentro 
dos esperados, chegando a distância máxima de cerca de 1,0 quilômetro em 
zona urbana e 1,2 quilômetros em zona rural. 
 
 
 
 
 
 
 
 
 
6 
 
2. INTRODUÇÃO 
 
Visando manter a qualidade na prestação do serviço público de distribuição 
de energia elétrica, a Agência Nacional de Energia Elétrica (ANEEL) exige que 
as concessionárias mantenham um padrão de qualidade na prestação do serviço 
público de distribuição de energia elétrica, entre os principais indicadores de 
qualidade coletivos e individuais (FEC e DEC). Em todo o país em indicadores 
de qualidade impostos pela ANEEL, em zonas rurais são piores do que nas 
demais regiões, e o Paraná não é exceção. Os indicadores de Duração de 
Interrupção por Unidade Consumidora e de Frequência de Interrupção por 
Unidade Consumidora na zona rural são praticamente o dobro dos indicadores 
na área urbana (ANEEL, 2016). 
Entre as principais estratégias para redução desses indicadores de 
qualidade está no uso de comunicação de uma rede baseada em protocolo 
LoRaWAN cujo estudo foi realizado neste trabalho, tem a possibilidade de 
auxiliar no desenvolvimento do consumo inteligente entre os fornecedores de 
energia e os consumidores visando alcançar confiabilidade, eficiência e 
otimização em operações, planejamento, demanda de resposta, bem como na 
utilização de diversos recursos. 
Portanto o projeto consiste em uma rede que se propõe a introdução de 
elementos de monitoramento, medição e atuação que possam ser controlados 
remotamente, através de uma rede de comunicação sem fio, trazendo vantagens 
ao processo de gerenciamento da rede, melhorando significativamente robustez 
e eficiência da geração, transmissão e distribuição dos sistemas elétricos, 
possibilitando uma redução dos custos de medição, redução do tempo para 
localização e reparo de faltas e monitoramento contínuo da qualidade da energia 
elétrica. 
O projeto tem como premissa estudar e montar uma rede de rádios LoRa 
com sensores ou medidores para testar se essa tecnologia fornece uma solução 
eficaz e barata para aplicações de monitoramento remotos e longo alcance com 
foco na avaliação do desempenho do módulo de comunicação LoRa, avaliando 
distâncias de propagação em ambientes diversos e estudando fatores que 
influenciam na qualidade de comunicação de dados. 
7 
 
Utilizaremos essa tecnologia para produzir um sistema de monitoramento 
que seja eficiente e econômico, uma vez que os dados poderão ser adquiridos 
remotamente, por exemplo, em uma implementação real, sem a necessidade de 
disponibilizar funcionários para realizar as medidas in loco. Com o objetivo de 
manter a qualidade na prestação do serviço público de distribuição de energia 
elétrica. 
Isso poderá acarretar na diminuição dos indicadores de Duração e 
Frequência de Interrupção por Unidade Consumidora, uma vez que o sistema 
atual de identificação de interrupções na distribuição de energia depende que a 
população entre em contato com as companhias de distribuição através de 
telefone. Com a Distribuidora recebendo essa informação remotamente no 
mesmo instante da ocorrência da falha os problemas de distribuição poderão ser 
resolvidos em um prazo mais curto. 
O uso dessas redes é especialmente vantajoso em áreas onde existe pouca 
oferta de serviços de comunicação ou o custo desses serviços seja elevada e o 
acesso é mais difícil,como nas regiões com características rurais onde 
normalmente não existe previamente infraestrutura de comunicações já 
disponíveis. Esta ferramenta trará como benefício a redução do custo e do tempo 
de implantação de novos projetos, bem como a redução e riscos de que a rede 
de comunicação não atenda aos requisitos das aplicações planejadas. 
O projeto executivo determina a posição e os parâmetros ótimos de 
configuração dos equipamentos de comunicação. Distingue-se de outras 
ferramentas por projetar a rede utilizando métricas de protocolos de camadas 
superiores, como a contagem de transmissão esperada ETX (expected 
transmission count), que podem ser facilmente traduzidos em requisitos das 
aplicações. 
Modelo Teórico ETX é uma das métricas, que representa o número de 
transmissões necessárias para transmitir e retransmitir até que um pacote em 
um link sem fio seja reconhecido. A métrica ETX foi introduzido em: (“A high-
throughput path metric for multi-hop wireless routing”, 2003). E é definida 
matematicamente por: 
𝐸𝑇𝑋 =
1
𝑃𝐹𝑃𝑅
 𝐸𝑞. 1 
 
8 
 
Na qual 𝑃𝐹 é a medida da probabilidade que um pacote seja recebido pelo 
seu vizinho e 𝑃𝑅 é a medida da probabilidade de que o pacote de confirmação 
seja recebido como bem-sucedido. A métrica ETX é sensível à perda de pacotes, 
é afetada por dois principais componentes: a qualidade do canal sem fio e as 
colisões. 
O trabalho está organizado da seguinte forma: seção 2 que se refere a 
Introdução traz a discussão dos temas teóricos de propagação sem fio: espaço 
livre, perda no espaço livre e desvanecimento. A seção 3 consta o detalhamento 
do projeto, apresentado os softwares e hardwares utilizados e suas 
configurações no projeto. 
Os procedimentos de testes e resultados são apresentados na seção 4, 
nela está presente a descrição do funcionamento geral da rede e os esquemas 
com a programação utilizada, além da descrição e resultados dos testes 
realizados em ambiente urbano e rural. Por fim a conclusão dos assuntos 
discutidos se encontra na seção 5. 
 
2.1 Propagação de Espaço Livre 
Propagação de Espaço Livre é o modelo utilizado para predição da 
potência do sinal recebido quando não existe obstáculo entre a antena 
transmissora e receptora. A Potência do sinal recebido pode ser calculada 
seguindo a equação de Friiz, equação 2. 
𝑃𝑟 = 𝑃𝑡 + 𝐺𝑡 + 𝐺𝑟 + 20 log10(λ) − 20 log10(4𝜋) − 20 log10(𝑑) 𝐸𝑞. 2 
Na qual: 
𝑃𝑟(𝑑𝐵𝑚)- Potência recebida 
𝑃𝑡(𝑑𝐵𝑚)- Potência transmitida 
𝐺𝑡(𝑑𝐵𝑖) - Ganho da antena transmissora 
𝐺𝑟(𝑑𝐵𝑖) - Ganho da antena receptora 
λ (m) - Comprimento de onda 
𝑑(m) – Distância entre as antenas 
9 
 
Perdas de Propagação 
 Em um rádio enlace o sinal é transmitido de uma antena transmissora e 
propaga-se na forma de ondas de rádio (ondas eletromagnéticas) até a antena 
receptora. Ao se propagar o sinal é atenuado estando sujeito a diversos tipos de 
perdas. 
2.2 Perda no espaço livre 
 Apenas parte da energia transmitida através das ondas eletromagnéticas 
é captada pela antena receptora. Esta energia é tanto menor quanto maior a 
frequência e a distância. Esta perda, denominada perda no espaço livre é 
expressa em dB pela seguinte fórmula: 
𝑃𝐿(𝑑𝐵) = 10 . log10 [(
4𝜋𝑑
λ 
)
2
] 𝐸𝑞. 3 
2.3 Desvanecimento 
 
 Ao se propagar as ondas de rádio estão sujeitas a vários tipos de 
reflexões, como a do solo que pode provocar alterações na amplitude e caminho 
percorrido das ondas, ocasionando variações na potência do sinal recebido. 
Estas variações são denominadas desvanecimento (fading), que pode ser 
causado também por obstáculos na linha de visada direta, ou por atenuação 
devido a fatores ambientais como chuvas. 
Em frequências maiores que 8 GHz em regiões de clima tropical como o 
Brasil a atenuação por chuva é um fator relevante no dimensionamento de 
enlaces de rádio. Porém como os módulos LoRa utilizam uma frequência mais 
baixa, não é para a chuva ser um grande problema. Com frequências mais 
baixas é possível enlaces com distâncias maiores, o espectro encontra-se, no 
entanto, mais congestionado. (TELECO) 
 
 
 
10 
 
3. DETALHAMENTO DO PROJETO 
 
Nas subseções a seguir serão apresentados os diagramas de blocos e as 
configurações dos equipamentos que foram realizadas. 
3.1 Configurando Módulo LoRa Dragino 
 
A descrição do Hardware do módulo LoRa está apresentada na figura 2. 
O módulo será conectado ao Arduino UNO, os jumpers na parte direita são 
colocados para fazer a ligação do Chip LoRa nas entradas digitais do Arduino. 
Os jumpers na parte esquerda estão habilitados nos pinos por default e habilitam 
comunicação via protocolo ICSP (In-Circuit-Serial-Programming) e utiliza os 
sinais de Clock (CLK) e protocolos MOSI e MISO. O módulo possui pinos 
analógicos Analog (0 a 5), para a conexão de sensores que possuem saídas 
analógicas. Serão utilizadas essas entradas para testes de sensores. Além 
disso, tem alimentação de 5V e 3.3V e entrada para antena externa. 
 
Figura 1 - Hardware do Módulo Dragino. Fonte: WikiDragino. 
 
 
Figura 2 - Módulo LoRa com antena conectado ao Arduino UNO. 
11 
 
Para teste, foram utilizados dois módulos LoRa de frequência 868MHz, 
um para transmitir e outro para receber o sinal. 
Cada módulo foi conectado a um Arduino UNO conforme figura 2 e ligados 
ao computador por meio do cabo USB. 
Utilizando o software Arduino IDE, em Ferramentas escolhe-se a Porta e 
a Placa a ser utilizada. 
Abre-se duas janelas do software, uma para o Código do Cliente e outra 
para o Código do Servidor. O Servidor irá enviar um pacote para o Cliente. 
Os códigos utilizados são em linguagem C, utilizando bibliotecas <SPI.h> e 
<RH_RF95.h>, sendo a <RH_RF95.h> própria para o modelo do módulo LoRa 
utilizado. 
Os códigos básicos são abertos para utilização, sendo encontrados no 
site de desenvolvedores como <github.com>. 
O código básico para implementações iniciais define alguns comandos que 
serão explicados a seguir: 
• rf95.setFrequency(frequency); 
Define a frequência de operação de acordo com o módulo, a frequência é 
definida por fábrica. No caso do projeto será utilizada 868MHz. 
• rf95.setTxPower(13); 
Define a potência de transmissão do módulo. 
• packet_id=1; 
Esse comando é iniciado em 1 e vai incrementando conforme os pacotes são 
transmitidos. 
• rf95.lastRssi(); 
Comando para capturar a potência de recepção do pacote. 
• rf95.lastSNR(); 
Comando para capturar a relação Sinal – Ruído da transmissão. 
• delay(2000); 
Define o intervalo em que os pacotes serão enviados. Tempo em 
milissegundos. 
Esses são alguns comandos básicos relacionados ao rádio LoRa. 
12 
 
Testando-os dois a dois módulos para verificar qual é o RSSI (potência 
recebida) a diferentes distâncias. Na figura 3 está mostrado o diagrama de 
ligação de como foram efetuadas as medidas. Primeiramente, os códigos Cliente 
e Servidor foram gravados em cada Módulo. O Módulo como o código do Cliente 
ficou conectado ao computador. O outro Módulo foi alimentado com bateria e 
disposto a distâncias d do computador para efetuar os testes. 
Acompanhando a transmissão pelo Monitor Serial do software, é possível 
observar na figura 4 os parâmetros recebidos no Módulo que contém o código 
do Cliente. 
 
Figura 3 - Testes dos módulos. Fonte: Os autores. 
 
 
Figura 4 - Acompanhamento de testes pelo monitor Serial. Fonte: Os autores. 
 
13 
 
3.2 Configurando TheThingSpeak 
 
O ThingSpeak é uma plataforma Internet of Things (IoT) que permite 
coletar e armazenar dados de sensores na nuvem e desenvolver aplicativos IoT. 
Desenvolvido pela Mathworks (mais conhecida como criadora do software 
MATLAB). Muitos dispositivos de IoT podem enviar dados para o Thingspeak 
(incluindo, mas não se limitando à Arduino, Raspberry Pi). Os dados coletados 
podemser analisados online, usando o MATLAB. 
Existe a opção de uma conta gratuita para testes e pequenos projetos não 
comerciais. O valor da licença fica em torno de 75 euros para projetos mais 
complexos. No projeto em desenvolvimento será utilizada a conta gratuita. 
Acessando o site: thingspeak.com é possível criar uma conta e logar em 
Sign In. Conforme figura 5. 
 
Figura 5 - Página inicial do ThingSpeak. Fonte: thingspeak.com 
 
Figura 6 - Meus canais – exibidos após logar no site. Fonte: thingspeak.com 
14 
 
Após logar com o usuário e senha, é exibida a tela de Canais, onde devem 
ser cadastrados conforme necessidade, para poder publicar os dados. Conforme 
figura 6. Na figura 7, há campos para preenchimento para criação de canais, 
como o nome do canal e os campos Fields, para preencher quais variáveis serão 
coletadas. 
 
 
Figura 7 - Criação de canais. Fonte: thingspeak.com 
 
Cada canal terá um número identificador ID e uma chave de leitura e de 
escrita conforme indicados na figura 8. O ID e a chave de escrita são utilizados 
para a configuração do Gateway. 
15 
 
 
Figura 8 - Chaves do Canal. Fonte: thingspeak.com 
 
O canal pode ser privado ou público. No caso do projeto, será mantido 
como privado. Na figura 9 é possível visualizar os dados obtidos em tempo real 
em Field Chart e também é possível exportar e importar em Data Import/Export. 
 
 
Figura 9 - Local para visualização de dados. Fonte: Os autores. 
16 
 
3.3 Configurando Gateway LG01 Dragino 
 
O Gateway utilizado LG01 da Dragino é um canal de código aberto. Ele 
permite conectar o LoRa sem fio para uma base de rede IP em Wi-Fi, Ethernet, 
3G ou 4G. Apresenta sistema LINUX embarcado, tem porta USB, duas portas 
RJ45 para cabo de rede configurando em LAN ou WAN e Wi-Fi 802.11 b/g/n. 
Esse dispositivo é muito flexível para diferentes tipos de redes conforme 
necessidade do usuário (MANUAL GATEWAY). 
 
Características: 
• Parte LINUX: 
Processador Atheros AR9331 de 400MHz; 
64MB de memória RAM; 
16MB de memória Flash. 
• Parte MCU: 
MCU: ATMega328P; 
32KB de memória Flash; 
• Parte LoRa: 
Banda de 868MHz; 
Sensibilidade de potência de -148dBm; 
Range de RSSI de 127dB; 
Taxa de bits programável até 300kbps; 
• Outras: 
Apresenta Open Source Linux. O usuário pode modificar ou compilar o 
firmware com recursos personalizados; 
Baixo consumo de potência; 
Compatível com Arduino IDE 1.5.4 ou superior; 
Suporta conexão de internet via LAN, Wi-Fi ou Dongle 3G/4G. 
 
O diagrama de blocos interno está apresentado na figura 10. Apresenta o 
Microcontrolador ATMega328P que está ligado ao bloco do Módulo SX1276 
LoRa por meio de comunicação com protocolo SPI (Serial Peripheral Interface), 
o microcontrolador se comunica também por protocolos SPI e UART (Universal 
Asynchronous Receiver/Transmitter) com o sistema Dragino HE baseado em 
17 
 
Linux, que é utilizado para configuração de Wi-Fi. HE é conectado às portas 
RJ45 e USB. 
 
Figura 10 - Diagrama de Blocos do Hardware do Gateway. Fonte: MANUAL 
GATEWAY. 
 
LG01 suporta redes flexíveis, com as seguintes topologias: 
 
• Modo de Internet da Porta WAN 
• Modo Cliente WiFi 
• Modo AP WiFi 
• Mesh WiFi Network 
• Modo Dial-up USB 
• Modo Ethernet USB 
 
Modo Cliente WiFi 
 
No modo de cliente WiFi, o Dragino atua como um cliente WiFi e obtém o 
DHCP do roteador de uplink via WiFi. Ele também compartilha a internet com 
sua porta LAN para outros dispositivos. A topologia está mostrada na figura 11. 
Essa topologia foi configurada para esse projeto. 
18 
 
 
Figura 11 - Modo Cliente Wi-Fi. Fonte: MANUAL GATEWAY. 
 
O gateway pode ser configurado para trabalhar com a rede Wi-Fi local e 
carregado um Arduino Sketch para o servidor ThingSpeak. Quando ligado pela 
primeira vez, o LG01-S começa como um ponto de acesso WiFi não seguro. A 
conexão com a porta LAN também é possível. Em ambos os casos, o gateway 
atua como um servidor DHCP, com seu IP definido como 10.130.1.1. Para 
conectar usa-se user: root e password: dragino. 
Para configurá-lo para ser executado como um cliente WiFi, vai ao menu 
Rede - Acesso à Internet. Então, define-se como cliente de Wi-Fi. 
 
 
Figura 12 - Configuração como Cliente Wi-Fi. Fonte: Os autores. 
 
19 
 
Conforme a figura 12, define-se Access como Wi-Fi Client, SSID é o Wi-
Fi no qual sua rede está conectada. Na figura 13, já configuração de LAN e 
DHCP com o IP address default do Gateway de 10.130.1.1. 
 
 
Figura 13 - Configuração LAN e DHCP. Fonte: Os autores. 
 
Desabilitar Acess Point para o Gateway e definir como canal 6 conforme figura 
14. 
20 
 
 
Figura 14 - Desabilitar Access Point. Fonte: Os autores. 
Em seguida, acessar as configurações do roteador local, utilizando 
192.168.0.1 e login e senha conforme fabricante do roteador, e definir canal 6 
nas propriedades de Wireless do roteador conforme figura 15. 
 
Figura 15 - Acesso ao roteador local e configuração de canal. Fonte: Os autores. 
 
21 
 
3.4 Configurando Gateway ao Server ThingSpeak 
 
A etapa de ligação do Gateway ao Server ThingSpeak está apresentada 
em um diagrama de blocos que mostra como a comunicação deverá ocorrer: 
 
Figura 16 - Configurando Gateway ao ThingSpeak. Fonte: MANUAL GATEWAY 
 
O primeiro bloco da figura 16 representa a parte do LoRa conectado ao 
Arduino e a um sensor para coletar dados. Os dados coletados são então 
transmitidos em (1) para a MCU (Microcontroller Unit) do gateway. No MCU 
estará rodando um programa feito no Arduino IDE e em (2) os dados serão 
enviados para a parte Linux para que eles sejam enviados via Wireless para o 
Server ThingSpeak e em (3) as informações estarão disponíveis em gráficos no 
site. Na parte (2), ou seja, na MCU estará rodando um programa feito na Arduino 
IDE que deverá conter parâmetros exigidos pelo ThingSpeak como a chave de 
leitura e ID do canal, como citados anteriormente. Há códigos de fonte aberta 
disponíveis em linguagem C e C++ para realizar a configuração entre o Gateway 
e o Server ThingSpeak. 
 
3.5 Arduino UNO 
 
É um microcontrolador Atmel AVR de 8 bits com linguagem de programação 
C e C++. É de baixo custo permitindo inúmeras aplicações. Existem 13 versões 
de Hardware do dispositivo, dentre elas: Arduino Nano, Arduino MEGA, Arduino 
Due, Arduino Leonardo e Arduino UNO. A utilizada no projeto será UNO devido 
à compatibilidade com o Hardware LoRa utilizado e à disponibilidade do material 
pela PUC-PR. 
22 
 
 
Figura 17 - Arduino UNO. Fonte: Divulgação. 
 
O microcontrolador ATMEL ATMEGA328 presente na placa Arduino, é um 
dispositivo de 8 bits da família AVR com arquitetura RISC avançada e com 
encapsulamento DIP28. Possui 32 KB de Flash, 2 KB de RAM e 1 KB de 
EEPROM. Opera na placa Arduino UNO em 16 MHz. 
Ele pode operar a 4MHz com tensões bem baixas, de até 1,8 V. Possui dois 
modos de consumo superbaixos, o Power-save Mode e o Power-down Mode. A 
corrente máxima por pino é de 40mA, mas a soma da corrente de todo o CI não 
pode ultrapassar 200mA. (EMBARCADOS). 
Possui: 
• Uma USART que funciona a até 250kbps 
• Uma SPI, que vai a até 5MHz, e uma I2C que pode operar até 400kHz. 
• Um comparador analógico interno ao CI 
• Diversos timers, 
• 6 PWMs. 
 
Possui 28 pinos, sendo que 23 desses podem ser utilizados como entrada ou 
saída. A figura 18 exibe a sua pinagem. 
 
 
23 
 
 
Figura 18 - Pinagem do controlador ATMEGA328. Fonte: EMBARCADOS. 
 
 
O software Arduino (IDE) de código open-source facilita a gravação de 
código e o upload para a placa. Ele é executado no Windows, Mac OS X e Linux. 
O ambiente é escrito em Java e baseado em Processing e outro software de 
código aberto. Este software pode ser usado com qualquer placa Arduino. 
 
3.9 Protocolo LoRaWan 
 
LoRaWan é o protocolo que define a arquitetura do sistema bem como os 
parâmetros de comunicação usando a tecnologia LoRa®. Ele implementa osdetalhes de funcionamento, segurança, qualidade do serviço, ajustes de 
potência visando maximizar a duração da bateria dos módulos, e os tipos de 
aplicações tanto do lado do módulo quanto do servidor. Para participar da rede, 
cada dispositivo deve ser personalizado e ativado. O LoRa suporta dois métodos 
de ativação, a Ativação pelo ar (OTAA – Over The Air Activation) e Ativação 
por personalização (ABP – Activation By Personalization). O processo de 
ativação dos dispositivos deve fornecer aos nós terminais as seguintes 
características: 
• Endereço do dispositivo final (DevAddr): um identificador de 32 no qual 
6 bits são usados como identificador de rede, e 25 bits são usados como o 
endereço de rede do dispositivo final. 
24 
 
• Identificador do aplicativo (AppEUI): um ID de aplicativo global no espaço 
de endereço IEEE EUI 64 (Extended Unique Identifier) que identifica o 
proprietário do dispositivo final. 
 • Chave de sessão de rede (NwkSKey): uma chave usada pelo servidor 
de rede e o dispositivo final para calcular e verificar o código de integridade de 
todas as mensagens. 
• Chave de sessão do aplicativo (AppSKey): É uma chave usada pelo 
servidor de rede e dispositivo final para criptografar e descriptografar as 
mensagens de dados. (AUGUSTIN, 2016) 
A segurança para a informação nos pacotes de dados é garantida, pois 
os dados a serem transmitidos (payload) são criptografados usando o algoritmo 
AES de 128 bits, com uma chave conhecida por "Application Session Key", 
conforme mostra a figura 19. 
 
 
 
Figura 19 - Bloco do protocolo LoRaWan mostrando AES128. Fonte: 
THOMASCLAUSEN. 
 
A Segurança na transmissão dos dados indicada na figura 20 é garantida 
pelo número MIC. Ele é gerado usando a mesma técnica de criptografia (AES de 
128 bits), mas com uma outra chave, conhecida por "Network Session Key". Esta 
chave serve para que o servidor de rede possa garantir que o pacote recebido 
não foi alterado por erros ou propositalmente. O servidor de rede não tem acesso 
25 
 
aos dados, pois não possui a 'Application Session key', ele pode apenas checar 
a integridade do pacote. 
 
 
Figura 20 - Bloco do protocolo LoRaWan. Fonte: THOMASCLAUSEN 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
26 
 
4. PROCEDIMENTOS DE TESTES E RESULTADOS 
 
Nessa seção serão apresentados o funcionamento geral da rede, blocos 
de programação dos códigos gravados nos dispositivos. 
 
4.1 Funcionamento geral da rede 
 
A rede física construída está demonstrada na figura 21, a qual consiste de 
nós ou módulos LoRa acoplados ao microcontrolador indicados com numeração 
de 1 a 5, estes estão ligados ao gateway LoRa indicado em 6, o qual recebe o 
sinal de rádio de todos os nós e foi configurado para enviar as informações para 
a internet. A porta LAN do gateway é utilizada para fazer configurações e a porta 
WAN para acesso à internet. O nó número 4 é denominado repetidor, pois ele 
fará o trabalho de receber o dado do nó 3 que se encontra fora de alcance do 
gateway e enviá-lo para o gateway. Todos os nós são identificados com um ID, 
que pode ser um número de três dígitos, por exemplo, o nó 1 tem o ID: 111. O 
gateway é programado para receber apenas pacotes de dados de nós pré-
programados, ou seja, ele apenas receberá pacotes de dados de dispositivos 
LoRa caso esses estejam com seus IDs presentes no código do gateway. Para 
receber esses dados, o gateway estará disponível para receber um pacote de 
cada nó com um período de tempo para cada ID, por exemplo: Nó 1 enviou um 
pacote, portanto, ele só enviará um pacote novo somente quando todos os outros 
nós acabarem de enviar. Com isso, evita-se que um único nó envie pacotes de 
uma vez só e os demais tenham que esperar intervalos maiores de tempo. Assim 
que o pacote de dados chega ao gateway, ele envia para o servidor web 
ThingSpeak para armazenamento e plotagem de gráficos para exibição de 
dados em tempo real. 
 
27 
 
 
Figura 21 - Montagem da rede física. Fonte: Os autores. 
 
4.2 Códigos de Programação 
 
Serão apresentados descritivamente os códigos de programação em 
linguagem C utilizados pelos nós e pelo gateway para proporcionar a 
transmissão de dados para o servidor web ThingSpeak. 
 
4.2.1 Programação dos nós LoRa 
 
O código de programação de cada nó LoRa está simplificado no diagrama da 
figura 22, em (1) se define a frequência em que será operado, no caso o módulo 
físico e o gateway suportam 868MHz, é também selecionada a potência de 
operação, para teste foi utilizada a potência máxima de 20dBm. Em (2) aguarda 
um período de tempo em que será executada a coleta e envio de dados ao 
gateway. Em (3) coleta-se os dados desejados, por exemplo para efetuar os 
testes foram coletados: Sinal recebido denominado RSSI (Received signal 
strength indication) que vai de -22dBm a -120dBm (de acordo com os testes 
28 
 
realizados) e a relação sinal-ruído denominado SNR, que é a relação entre o 
sinal enviado e o recebido, o valor máximo que pode ocorrer é 10. Esses 
parâmetros citados são utilizados para verificar a qualidade do sinal. Em (4) foi 
efetuada a filtragem desses dados, utilizando um filtro de média móvel que 
consiste em realizar média de dez valores coletados para evitar ruídos por 
exemplo no caso da coleta de RSSI para tornar a medição aprimorada. Em (5) 
define-se qual será o ID do nó em questão e é criado um vetor data[n] que 
contém o ID do nó e os demais valores que se deseja transmitir. Em (6) é 
chamada a função de envio dos pacotes e em (7) é aguardada a resposta do 
gateway: pacote recebido ou pacote perdido. Após isso, ele retorna ao passo (2) 
e segue continuamente. 
No caso do LoRa repetidor, conforme citado anteriormente, ele recebe os 
dados do nó que está fora de alcance do gateway e encaminha esses dados 
para o gateway. 
 
Figura 22 - Diagrama simplificado do código de um nó. Fonte: Os autores. 
29 
 
4.2.2 Programação do Gateway – VEZ 
 
A primeira tentativa de sincronização adotada e testada para configurar 
tempos de transmissão entre gateway e nós foi utilizando-se a “VEZ”. O código 
de programação do gateway LoRa está simplificado no diagrama da figura 23, 
em (1) se define a frequência e potência de operação, conforme citado 
anteriormente, em (2) são definidos o canal e a chave de escrita no site 
ThingSpeak para armazenamento e plotagem de gráficos. Em (3) define-se um 
variável denominada “vez”, que será utilizada para controlar o recebimento de 
dados de cada nó LoRa, ela inicia em 1 para todos os IDs cadastrados no código, 
assim que cada ID envia seu pacote, ela irá sendo zerada, após todos os nós 
tenham transmitido dados, ele novamente fica em 1, ou seja, vez igual a 1 
demonstra que o pacote está pronto para ser recebido. Em (4) o gateway inicia 
um processo de aguardo, devido à limitação do servidor ThingSpeak, pois ele só 
recebe dados a cada 15 segundos no mínimo. Portanto, define-se esse delay 
para que a plotagem de dados no site seja efetiva. Em (5) o gateway fica 
aguardando o recebimento de um pacote, assim que ele recebe (6), verifica o ID 
do nó que enviou e se a vez desse nó é igual a 1, se o ID estiver com a vez igual 
a 1, ele lê os dados e envia-os para o servidor web. Também envia uma 
mensagem ao ID confirmando o recebimento desse pacote. (7 e 8). O ID recebe 
vez igual a zero, e o gateway retorna ao passo 4 e segue continuamente. Porém, 
essa primeira tentativa mostrou-se ineficaz, por exemplo, caso haja desconexão 
de apenas um nó do sistema, toda a rede fica inoperante. 
30 
 
 
Figura 23 - Diagrama simplificado do código do gateway. Fonte: Os autores. 
 
4.2.2 Programação do Gateway – Divisão no Tempo 
 
A multiplexação é uma operação que consiste em agrupar vários canais 
de informação que não estão relacionados, para transmiti-los simultaneamente 
em um mesmo meio físico, sem que haja interferência ou mistura dos canais.A 
demultiplexação é a separação desses canais. Existem três tipos de 
31 
 
multiplexação, que são por divisão do espectro de frequências (FDM), a 
multiplexação por divisão do tempo (TDM) e a multiplexação por divisão de 
comprimento de onda(WDM), que é utilizada em sistema com fibras óticas, em 
conjunto com a multiplexação TDM, visando ampliar o uso da fibra com taxas de 
transmissão maiores. Fonte: Moecke, 2006. 
Na multiplexação por divisão de frequências é designada uma faixa de 
frequência para cada canal, resultando em uma sobreposição no tempo dos 
sinais, o esquema da divisão FDM é mostrado na figura 24. 
 
Figura 24 - Esquema FDM. Fonte: Planificación y Administración de Redes, 2017. 
 
Na multiplexação por divisão de tempo, os canais ficam separados no 
tempo e sobrepostos em frequência, essa divisão está esquematizada na figura 
25. Como o tempo é um valor relativo, a TDM necessita de um ponto de 
referência no quadro, para que o receptor possa ser sincronizado em frequência 
e fase de forma a poder extrair o sinal correspondente a cada canal. Este 
sincronismo é obtido pelo envio periódico de um sinal de referência. Fonte: 
Moecke, 2006. 
32 
 
 
Figura 25 - Esquema TDM. Fonte: Planificación y Administración de Redes, 2017. 
 
Como o Gateway (GW) utilizado no projeto possui apenas um canal de 
frequência a única opção disponível para receber pacotes de diferentes rádios é 
a multiplexação por divisão no tempo. 
Foi definido que a melhor maneira não é controlar o tempo de leitura dos 
canais do GW e sim controle do tempo do envio dos pacotes de dados pelos nós. 
Devido a limitação do servidor ThingSpeak que será utilizado, o gateway só 
recebe e faz a verificação subindo os dados para a nuvem a cada 15 segundos 
no mínimo, por isso foi definido já com uma margem para pequenos atrasos, 
levando em conta que cada microcontrolador pode ter uma contagem de tempo 
um pouco diferente, o tempo entre cada transmissão que deverá chegar no 
gateway será de 20 segundos. Ficando então o Gateway apenas com a função 
de receber os pacotes, sem se preocupar com os tempos o fluxograma do código 
está representado na figura 26. E para que isso ocorra os nós LoRa 
transmissores deverão ser sincronizados, para essa sincronização utilizaremos 
um nó sincronizador que terá apenas o papel de enviar os pacotes de 
sincronização. 
33 
 
 
Figura 26 - Diagrama simplificado do código do gateway. Fonte: Os autores. 
 
4.2.4 Programação do Nó Sincronizador 
 
Para a sincronização todos os nós estarão aguardando receber um pacote 
do sincronizador, o código foi feito para ser executado apenas uma vez a 
mensagem de sincronização. 
34 
 
 
Figura 27 - Montagem da rede física com sincronizador. Fonte: Os autores. 
 
O tempo que cada nó envia é calculado de acordo com seu ID. A espera 
inicial em milissegundos de cada nó pode ser calculada pela equação a 4. Na 
qual há subtração do -1 é para que o nó ID 1 já inicie transmitindo seu pacote, 
sem o delay. 
Espera_Inicial = (< ID do nó > - 1) * 20000 Eq. 4 
O tempo de envio de um pacote, foi medido pela função milis() no código 
chegando a um tempo de 47 milissegundos para a transmissão de um pacote 
quando não se está imprimindo dados na porta serial. Para garantir ainda a 
sincronização, de acordo com o número total de nós na rede o intervalo entre 
cada transmissão de um mesmo nó foi calculada pela equação 5. 
Intervalo = Nós_Total * 20000 Eq. 5 
Sendo assim demora 20 segundos a mais para cada nó transmitir, a cada 
nó adicionado na rede. O Fluxograma do código usado para o sincronizador está 
ilustrado na figura 28. 
35 
 
 
 
Figura 28 - Diagrama simplificado do código do sincronizador. Fonte: Os autores. 
 
4.2.5 Programação do Repetidor 
 
O diagrama da programação do repetidor é semelhante ao da Figura 22 – 
Diagrama simplificado do código de um nó. Está representado na figura 29. 
 
36 
 
 
Figura 29 - Diagrama simplificado do código do Repetidor. Fonte: os autores. 
 
Para os testes são enviados valores pré-determinados ou valores 
advindos de sensores no código dos clientes (Nós) para serem visualizados. A 
comunicação é monitorada pela porta serial do microcontrolador conectado ao 
módulo LoRa e pelo servidor ThingSpeak. São utilizados os dados coletados em 
tempo real para plotagem de dados no ThingSpeak. 
37 
 
Para verificação da a comunicação entre os módulos e demonstrado o 
funcionamento do repetidor, é montada a rede da Figura 30. 
 
Figura 30 - Montagem da rede física. Fonte: Os autores. 
 
 Nessa figura, é ligado um cliente (ID = 443), composto de um 
microcontrolador e um módulo LoRa, que transmite valores fixos pré-
determinados no código e valores de RSSI, que indicam o nível de potência 
recebido após qualquer perda possível a nível de antena por exemplo. Os dados 
do cliente são recebidos pelo repetidor, composto de um microcontrolador e um 
módulo LoRa, que encaminha esses dados para o Gateway, o repetidor vai 
funcionar como cliente também enviando seus próprios dados de RSSI e valores 
pré-determinados no código. O repetidor recebe um pacote pelo ID = 444 e envia 
pelo ID = 555. O Gateway de teste, composto de um microcontrolador e um 
modulo LoRa, apenas mostrará os pacotes que foram recebidos do Repetidor, e 
nenhum tratamento desses valores ou armazenamento será feito. 
Os dados são verificados apenas pela porta serial do Microcontrolador 
Arduino. E os módulos são ligados há uma bateria externa de 9V para fazer 
testes com os valores de RSSI. Nesses testes quanto maior for a distância entre 
o transmissor e o repetidor, menor será o RSSI (menor a potência de recepção). 
 
4.2.4 Filtro de Média Móvel 
 
Para eliminar ou diminuir algum ruído indesejável em um sinal, é 
necessário filtrá-lo, um filtro muito comum e de fácil implementação é o de média 
móvel. Esse filtro é obtido calculando-se a média de N valores, sempre se 
adicionando um novo valor ao conjunto e se descartando o mais velho 
(BORGESCORPORATION, 2013). No caso do projeto, foi utilizado esse filtro no 
código em linguagem C do cliente, calculando-se a média de 10 valores de RSSI 
conforme esses dados eram coletados. Foi realizada uma coleta de dados 
38 
 
considerando-se esse filtro. O resultado é representado nas figuras 31 e 32. Na 
figura 31, não há utilização do filtro, ocasionando variação brusca de valores de 
RSSI, variando de -75dBm a -90 dBm. Já na figura 32 observa-se a variação 
gradual do RSSI devido à utilização do filtro, variando de -85dBm a -92 dBm. 
 
Figura 31 - Coleta de dados RSSI sem filtro. Fonte: os autores. 
 
Figura 32 - Coleta de dados RSSI com filtro. Fonte: os autores. 
 
4.2.5 CRC – Cyclic Redundancy Check e métrica ETX 
 
O CRC é uma técnica de detecção de erros muito utilizada em 
computação. Uma mensagem deve ser enviada com o código CRC calculado 
para que possa ser verificada no receptor. O cálculo é realizado através de 
operações com números binários. As operações lógicas são realizadas com o 
XOR (Exclusive OR). 
Quando uma palavra código é recebida ou lida, o dispositivo compara seu 
código de verificação anexado com um novo, calculado a partir da mensagem, 
39 
 
ou aplica o CRC sobre toda a palavra-código e compara o resultado com uma 
constante residual pré-definida. Se os códigos CRC não são semelhantes a 
mensagem contém erros de dados. O dispositivo pode realizar ações corretivas 
como reler a mensagem ou requisitar um novo envio da mesma. 
Nesse projeto é utilizado um CRC16 de 17 bits. O tipo utilizado e o polinômio 
realizados para as operações binárias é o seguinte: 
Tipo Hexadecimal Polinômio 
CRC-CCITT 0x1021 x16 + x12 + x5 + 1 
 
Utilizando-se o CRC, é possível encontrarmos o ETX de uma transmissão 
de dados. Conforme citado na eq. 1, o ETX relaciona a probabilidade de os 
dados serem recebidos com a probabilidadede os dados serem recebidos com 
integridade. Utilizando-se o CRC é possível checar a integridade dos pacotes, 
com isso determinando a métrica de qualidade ETX. 
Foi realizado um teste durante 12 horas em ambiente interno com 
distância de aproximadamente 30 metros (entre andares de um prédio) onde 
foram enviados 1639 pacotes pelo LoRa cliente. No receptor, houve recepção 
de 1630 pacotes, ou seja, apenas 9 pacotes foram perdidos durante esse 
período. Verificando-se o CRC, houve 1609 com a integridade confirmada pelo 
receptor. De acordo com a equação 1, a 𝑃𝐹 que é a medida da probabilidade 
que um pacote seja recebido pelo seu vizinho é de 0,994509 e a e 𝑃𝑅que é a 
medida da probabilidade de que o pacote de confirmação seja recebido como 
bem-sucedido é de 0,981355. Substituindo-se esses valores na equação tem-
se: 
 
𝐸𝑇𝑋 =
1
(0,994509)(0,981696)
 = 1,024269 𝐸𝑞. 6 
 
O resultado indica que o pacote deve ser enviado 1,024699 vezes para que 
a recepção seja bem-sucedida. 
Já em outro teste, realizado em ambiente urbano em uma distância de 
aproximadamente 500 metros, durante 1 hora, houve 629 pacotes enviados pelo 
40 
 
cliente, sendo recebidos no receptor 588, ou sejam 41 pacotes foram perdidos 
nesse período. Verificando-se o CRC, 570 recebidos com integridade. 
Substituindo-se esses valores na equação tem-se: 
𝐸𝑇𝑋 =
1
(0,934817)(0,969388)
 = 1,103509 𝐸𝑞. 7 
 
O resultado indica que o pacote deve ser enviado 1,103509 vezes para que 
a recepção seja bem-sucedida. 
 
4.2.6 Modo Sleep LoRa 
 
Para economizar energia, é necessário implementar ações no módulo 
LoRa e microcontrolador para fazer com que ambos entrem em modo Sleep no 
momento em que não estão recebendo e enviando dados. Isso pode reduzir 
muito a corrente, prolongando assim o tempo de vida da bateria. Foram 
realizadas programações para diminuir a corrente, porém sem muita eficácia 
devido ao modelo de microcontrolador utilizado. A seguir seguem os testes 
realizados: 
Utilizando Bateria Alcalina de 9V com capacidade de 1200mAh, foi 
medida a corrente de entrada de alimentação do Microcontrolador Arduino UNO 
+ Módulo LoRa: 
• 60mA (ligado) e 75mA (ao enviar pacote de dados). 
Se cada pacote de dado é enviado a cada 30 segundos, com duração de 0,5 
segundo de envio, a duração da bateria citada acima é de: 
Em 1 hora: 3540s consumindo 60mA e 60s consumindo 75mA. Ou seja: 
60,25mAh 
𝐷𝑢𝑟𝑎çã𝑜 𝑑𝑎 𝐵𝑎𝑡𝑒𝑟𝑖𝑎 = 
1200
60,25
= 19,9 ℎ𝑜𝑟𝑎𝑠 𝐸𝑞. 8 
Utilizando-se o mesmo sistema, e programando-se o modo Sleep, a corrente não 
decaiu de forma significativa, a melhor corrente foi de 35mA (ligado em modo 
Sleep) em comparação aos 60mA citados anteriormente. Isso devido ao 
hardware utilizado, que necessita de um consumo elevado devido a certos 
41 
 
componentes: Led On, Regulador. Para se economizar energia, pode-se realizar 
a troca do hardware para o Arduino Mini. Esse modelo consome corrente: 
• 14mA (ligado) e 6,2uA (Modo Sleep) 
Adotando-se 30mA de corrente de Arduino + Módulo LoRa 
Se cada pacote de dado é enviado a cada 30 segundos, com duração de 0,5 
segundo de envio, a duração da bateria é de: 
Em 1 hora: 3540s consumindo 0,0062mA e 60s consumindo 30mA. Ou seja: 
0,51mAh 
𝐷𝑢𝑟𝑎çã𝑜 𝑑𝑎 𝐵𝑎𝑡𝑒𝑟𝑖𝑎 = 
1200
0,51
= 2352,9 ℎ𝑜𝑟𝑎𝑠 = 98 𝑑𝑖𝑎𝑠 𝐸𝑞. 9 
Com a troca de hardware pode afetar significativamente no tempo de duração 
da bateria, porém também é possível utilizar o módulo conectado a uma fonte de 
5V a 9V. 
4.3 Testes de transmissão 
 
A verificação da comunicação entre os módulos e o Gateway, a forma na 
qual esses dados serão recebidos, quantia de pacotes de dados recebidos e 
perdidos. Perdas de uma mensagem ou de uma parte dela é sempre muito 
provável, tendo uma taxa alta de probabilidade de ocorrência. Por isso, a perda 
é sempre uma grande preocupação, na comunicação entre rádios LoRa. 
 
Os testes de transmissão foram realizados nos seguintes passos: 
I. Montagem da rede; 
II. Configuração do gateway; 
III. Funcionamento do repetidor; 
IV. Visualização de dados pela porta serial do pacote enviado e pacote 
recebido ou diretamente no servidor web; 
V. Validação do Filtro de Média Móvel; 
VI. Validação do CRC; 
VII. Validação da Sincronização entre Módulos e Gateway; 
VIII. Distâncias de transmissão máximas obtidas. 
42 
 
4.3.1 Ambiente externo 
 
Utilizando dois módulos LoRa ligados ao Arduino Uno, um gravado o 
código que transmite pacotes e o outro que recebe, um dos dispositivos foi ligado 
ao computador para coleta dos dados por meio da porta seriais enquanto o outro 
foi conectado a uma bateria de 9V .Os testes foram realizados nas proximidades 
da residência de um dos integrantes da equipe localizado na região 
metropolitana de Curitiba no Bairro Vila Maria Antonieta. 
Para verificar a distância máxima um dos integrantes caminhou com o 
módulo pelas ruas enquanto o outro verificava os pacotes recebidos pela serial 
informando o parceiro via telefone. Ao testar em variadas distâncias, todos os 
pacotes transmitidos serão verificados se foram entregues e qual a taxa de perda 
de pacotes. 
A figura 33 representa uma constatação encontrada pela equipe. A 
relação entre a distância e o número de pacotes entregues apresenta uma curva 
de decaimento súbito. A transmissão se mantém estável até certa distância e 
após isso não é entregue mais nenhum pacote. 
 
 
Figura 33 - Número de pacotes entregues em função da distância. Fonte: Os autores. 
4.3.1.1 Teste 01 – Urbano 
 
No teste 01, a distância máxima devido aos bloqueios de residências de 
até dois andares de altura foi de aproximadamente 334 metros, ao caminhar um 
pouco mais adiante, se afastando, os pacotes recebidos cessam imediatamente, 
retornando assim que o módulo volte para o alcance. No momento das medidas 
o tempo estava seco e ensolarado, as medidas foram realizadas ao nível da rua, 
43 
 
como o módulo estava sendo carregado, aproximadamente um metro e meio do 
solo. De 72 pacotes enviados, 18 não foram recebidos, exatamente 25%. O 
alcance Máximo está representado na figura 34, e o perfil de elevação do terreno 
na figura 35. 
 
 
Figura 34 - Alcance teste 01 – 334 metros. Fonte: Os autores. 
 
 
Figura 35 - Perfil de elevação do terreno – teste 01 – 334 metros. Fonte: Os autores. 
Os dados obtidos da relação do RSSI em dBm com o número do pacote 
transmitido esta apresentada no gráfico da figura 36. 
44 
 
 
Figura 36 - Nº pacotes x RSSI do teste 01. Fonte: Os autores. 
 
Houve muita variação de RSSI, devido ao afastamento do módulo em 
relação ao servidor, e às obstruções encontradas pelo caminho. 
4.3.1.2 Teste 02 - Urbano 
Outro teste na mesma residência e logo em seguida da medição anterior, 
a distância máxima foi de aproximadamente 213 metros, porém o sinal 
atravessou dois quarteirões pelo meio conforme mostra a figura 37, e o perfil de 
elevação do terreno na figura 38 feitas com o Google Earth. Após ser localizada 
a distância máxima alcançada nessa região plana e com prédios que não 
ultrapassam dois andares o integrante da equipe ficou aproximadamente 20 
minutos parados coletando os dados, nesse tempo foram enviados 132 pacotes, 
sendo que 18,9% deles não chegaram, totalizando 25 pacotes perdidos. 
-140
-120
-100
-80
-60
-40
-20
0
0 10 20 30 40 50 60 70 80
R
SS
I
nº de Pacotes
Teste 1 - 334 metros
45 
 
 
Figura 37 - Alcance do teste 02 – 213 metros. Fonte: Os autores. 
 
 
Figura 38 - Perfil de elevação do terreno – teste 02 – 213 metros. Fonte: Os autores. 
 
Os resultados obtidos na forma da relação do RSSI em dBm com o 
número do pacote transmitido estão apresentados na figura 39. 
46 
 
 
 
Figura 39 - Nº pacotes x RSSI do teste 02. Fonte: Os autores. 
 
4.3.1.3 Teste 03 - Urbano 
Mudando o local de testes para a avenida central do bairro, foi possívelrealizar as medidas em área plana e sem interferências de construções. Um dos 
integrantes ficou dentro do carro com um dos módulos LoRa conectado ao 
notebook para a coleta dos dados. Para esse teste foi utilizada uma antena com 
cabo de três metros que foi colocado na parte de cima do carro, enquanto isso o 
outro integrante se afasta gradualmente enquanto é informado dos pacotes 
recebidos, por telefone, a distância máxima alcançada antes da perda total da 
comunicação foi de 926 metros, aproximadamente 1 km, que está representado 
na figura 40. O perfil de elevação do terreno esta mostrado na figura 41. 
 
Figura 40 - Alcance teste 03 – 926 metros. Fonte: Os autores. 
-140
-120
-100
-80
-60
-40
-20
0
0 20 40 60 80 100 120 140
R
S
S
I
nº de Pacotes
Teste 2 - 230 metros
47 
 
 
Figura 41 - Perfil de elevação do terreno – teste 03 – 926 metros. Fonte: Os autores. 
 
 
Figura 42 - Nº pacotes x RSSI do teste 03. Fonte: Os autores. 
 
4.3.1.4 Teste 04 - Urbano 
 
Foi realizado um teste durante período de chuva. A distância obtida está 
na figura 43 e seu respectivo perfil de elevação do terreno é representado na 
figura 44. 
 
Figura 43 - Alcance teste 04 – 332 metros. Fonte: Os autores. 
-140
-120
-100
-80
-60
-40
-20
0
0 5 10 15 20 25
R
S
S
I
nº do pacote
Teste 3 - 926 metros
48 
 
 
 
Figura 44 - Perfil de elevação do terreno – teste 04 – 332 metros. Fonte: Os autores. 
 
Realizando o mesmo teste em um tempo de chuva foram verificados a 
perda de muitos pacotes, em um total de 77 pacotes enviado, 26 foram perdidos, 
aproximadamente 33,8% dos pacotes. 
O módulo receptor ficou dentro do automóvel fechado para a proteção da 
chuva (o que pode ter comprometido um pouco mais a qualidade de 
comunicação) enquanto um dos integrantes da equipe saiu caminhando com o 
módulo transmissor e um guarda-chuva até o ponto que o receptor para de 
receber pacotes, um total de 332 metros. Os dados coletados são apresentados 
na figura 45. 
 
Figura 45 - Nº pacotes x RSSI do teste 04. Fonte: Os autores. 
 
4.3.1.5 Teste 05 - Urbano 
 
Foi realizado mais um teste durante período de chuva. A distância obtida 
está na figura 46 e seu respectivo perfil de elevação do terreno é representado 
na figura 47. 
-120
-100
-80
-60
-40
-20
0
0 10 20 30 40 50 60 70
R
SS
I
nº do pacote
Teste 4 - 332 metros
49 
 
O teste foi realizado com o modulo receptor no mesmo local que no teste, 
ele ficou dentro do automóvel, desta vez com o carro aberto e a antena apontada 
para fora, o que possibilitou uma distância máxima de aproximadamente 76,5% 
maior que no teste anterior, chegando a 586 metros. 
 
 
Figura 46 - Alcance teste 05 – 586 metros. Fonte: Os autores. 
 
 
Figura 47 - Perfil de elevação do terreno – teste 05 – 586 metros. Fonte: Os autores. 
 
4.3.1.6 Teste 06 – Urbano 
 
Mudando o local de testes para a Rua Aristeu de Castro Fernandes nas 
proximidades da casa de um dos integrantes da equipe no bairro Maria Antonieta 
em Pinhais, foi possível realizar as medidas em área plana e sem interferências 
de construções. Um dos integrantes ficou dentro do carro com um dos módulos 
LoRa conectado ao notebook para a coleta dos dados, enquanto isso o outro 
integrante se afasta gradualmente enquanto é informado dos pacotes recebidos, 
por telefone. Foi realizada a coletas de dados para a verificação de quantos 
pacotes não chegam ao destino e quantos os pacotes chegam, porém são 
recusados pelo Gateway, com esses dados foi possível calcular o ETX. A 
distância na qual a medida foi realizada foi de aproximadamente 715 metros, e 
50 
 
está sendo representada na figura 48, e o perfil de elevação do terreno está 
mostrado na figura 49. 
 
 
Figura 48 - Alcance teste 06 – 485 metros. Fonte: Os autores. 
 
 
Figura 49 - Perfil de elevação do terreno – teste 06 – 485 metros. Fonte: Os autores. 
 
Foi realizada uma coleta de dados de aproximadamente 1 hora em uma 
distância inferior a distância máxima, na qual foram enviados 629 pacotes pelo 
cliente e foram recebidos 588 pacotes pelo servidor. Foram perdidos um total de 
41 pacotes, cerca de 6,5%. O RSSI médio medido na prática foi de 
aproximadamente: -79,3308 dBm. 
Por meio do CRC foi verificado que desse total de pacotes recebidos, 570 
foram recebidos com integridade e outros 18 sem integridade, o que resulta na 
desconsideração do pacote pelo receptor. De acordo com a equação 1 do cálculo 
do ETX, tem-se o valor do ETX para este teste: 
 
𝐸𝑇𝑋 = 
1
(0,934814)(0,969388)
= 1,103509 𝐸𝑞. 10 
51 
 
O resultado indica que o pacote deve ser enviado 1,103509 vezes para 
que a recepção seja bem-sucedida, um valor extremamente satisfatório para os 
testes. 
4.3.1.7 Teste 07 - Rural 
 
Com o sétimo teste externo iniciamos a coleta de dados em zona rural. A 
primeira coleta foi realizada na rua Humberto de Alencar Castelo Branco, no 
bairro Jardim Amélia, na cidade de Pinhais. A distância máxima obtida foi de 
aproximadamente 771 metros. O local de medida e sua distância está 
representado na figura 50 e o perfil de elevação do terreno pala figura 51. 
 
 
Figura 50 - Alcance teste 07 – 771 metros. Fonte: Os autores. 
 
 
Figura 51 - Perfil de elevação do terreno – teste 07 – 771 metros. Fonte: Os autores. 
 
Além de ser o primeiro teste em zona rural, o perfil de elevação do terreno 
representado na figura 51 não é mais plano, havia um pequeno pico interferindo 
na linha de visão do transmissor e do receptor do sinal. 
52 
 
No teste foram encaminhados 48 pacotes no total, o qual 16 desses foram 
perdidos, portanto 32 foram recebidos com sucesso. Dando uma taxa de 
aproximadamente 33% de pacotes perdidos. Nesse teste também foi obtido os 
valores das potências recebidas de cada pacote, o qual resultou em uma média 
de -95,28 dBm, para a distância de 771 metros. Os dados de RSSI coletados são 
apresentados na figura 52. 
 
 
Figura 52 - Nº pacotes x RSSI do teste 7. Fonte: Os autores 
 
Devido a interferência da elevação do terreno foi decidido realizar 
novamente uma medida para chegar a um novo alcance máximo que será 
apresentada na seção a seguir 4.3.1.8. 
 
4.3.1.8 Teste 08 - Rural 
 
Conforme comentado na seção 4.3.1.7, novamente foi realizado a medida 
na rua Humberto de Alencar Castelo Branco, porém como o perfil de elevação 
do terreno na figura 54 mostra, as medidas foram realizadas no ponto mais alto 
do terreno, tendo agora uma linha de visão livre entre o nó transmissor e o 
receptor. A distância máxima obtida com esse teste foi de 1218 metros, porém 
-110
-100
-90
-80
-70
-60
0 10 20 30 40 50
R
S
S
I
nº de pacotes
Teste 7 - 771 metros
53 
 
como mostra na figura 53 a medida pegou parte se um bairro urbano, portanto 
foi um teste com ambos as duas zonas presentes, rural e urbana. 
 
Figura 53 - Alcance teste 08 – 1218 metros. Fonte: Os autores. 
 
 
Figura 54 - Perfil de elevação do terreno – teste 08 – 1218 metros. Fonte: Os autores. 
 
Nesse teste foram enviados um total de 87 pacotes, medindo os valores 
de potência do recebimento dos pacotes. Os Dados coletados são apresentados 
na figura 55, nos quais foram perdidos 22 pacotes, dando uma porcentagem 
aproximada de 25,28% de pacotes perdidos. O valor medido de RSSI deu uma 
média de aproximadamente -87,85 dBm. 
 
54 
 
 
 
Figura 55 - Nº pacotes x RSSI do teste 8. Fonte: Os autores. 
 
4.3.1.9 Teste 09 - Rural 
 
O teste 09 foi realizado na zona rural, na região da estrada Pinhais para 
Graciosa no bairro Jardim das Nascentes, na cidade de Pinhais – PR. O local 
dos pontos onde foi identificado a distância máxima está mostrado na figura 56 
e o perfil de elevação do terreno na figura 57. 
 
Figura 56 - Alcance teste 09 – 956 metros. Fonte: Os autores. 
 
-100
-80
-60
0 20 40 60 80
R
SS
I
nº de pacotes
Teste 8 - 1218 metros
55 
 
 
Figura 57 - Perfil de elevação do terreno– teste 09 – 956 metros. Fonte: Os autores. 
A distância máxima alcançada com os testes, que foi de 
aproximadamente 956 metros mesmo que a linha de visão entre o transmissor e 
o receptor obstruída. Os pontos de localização do transmissor e receptor são 
sempre marcados com a ajuda de um GPS do celular para ter as distâncias o 
mais extas possíveis. 
4.3.1.10 Teste 10 - Rural 
 
Ainda na estrada Pinhais para Graciosa em Pinhais, no mesmo local do 
teste 09 da seção 4.3.1.11, porem mudando o receptor de posição, localizado na 
parte superior da figura 58 e estando na área mais baixa, mostrado no perfil de 
elevação do terreno da figura 59, enquanto isso o transmissor foi se afastando 
do receptor, chegando a uma distância máxima de 1168 metros antes que o 
receptor perdesse totalmente o sinal do transmissor. 
 
Figura 58 - Alcance teste 10 – 1168 metros. Fonte: Os autores. 
56 
 
 
 
Figura 59 - Perfil de elevação do terreno – teste 10 – 1168 metros. Fonte: Os autores. 
 
Nesse teste foi monitorado o RSSI por meio do envio de 225 pacotes totais 
dos quais 58 deles, aproximadamente 25,78% foram perdidos. Os dados 
coletados são mostrados na figura 60. 
 
Figura 60 - Nº pacotes x RSSI do teste 10. Fonte: Os autores. 
 
4.3.1.11 Teste 11 – Rural 
 
O último teste foi feito utilizando o código para confirmação do CRC, para 
verificar que dados de dentro do pacote foram perdidos, fazendo o Gateway não 
aceitá-lo. Foi realizada a coletas de dados, na mesma região dos testes 09 e 10, 
para a verificação de quantos pacotes não chegam e quantos os pacotes 
chegam porém são recusados pelo gateway, com esses dados foi possível 
calcular o ETX. A distância na qual a medida foi realizada foi de 
-102
-100
-98
-96
-94
-92
-90
-88
-86
0 50 100 150 200
R
SS
I
nº de pacotes
Teste 10 - 1168 metros
57 
 
aproximadamente 773 metros, e está sendo representada na figura 61, e o perfil 
de elevação do terreno está mostrado na figura 62. 
 
 
Figura 61 - Alcance teste 11 – 773 metros. Fonte: Os autores. 
 
 
Figura 62 - Perfil de elevação do terreno – teste 11 – 773 metros. Fonte: Os autores. 
 
Foi realizada uma coleta de dados de aproximadamente 40 minutos em 
uma distância de 773 metros, que é inferior a distância máxima testada 
anteriormente. Foram enviados 154 pacotes pelo cliente e foram recebidos 151 
pacotes pelo servidor. Foram perdidos apenas três pacotes, aproximadamente 
2% do total. O RSSI médio medido na prática foi de aproximadamente -90,2586 
dBm e os dados capturados estão mostrados na figura 63. A potência recebida 
teórica considerado perca em espaço livre é de -63,1182 dBm. 
Por meio do CRC foi verificado que desse total de pacotes recebidos, 144 
foram recebidos com integridade e outros 7 sem integridade, com essas 
informações e usando a equação 1 tem-se o valor do ETX para este teste: 
 
𝐸𝑇𝑋 = 
1
(0,980519)(0,951389)
= 1,07198 𝐸𝑞. 11 
58 
 
O resultado indica que o pacote deve ser enviado 1,07198 vezes para que 
a recepção seja bem-sucedida, um valor extremamente satisfatório. 
 
 
Figura 63 - Nº pacotes x RSSI do teste 11. Fonte: Os autores. 
 
 
 
 
 
 
 
 
 
 
 
 
 
-100
-95
-90
-85
-80
-75
-70
-65
-60
0 20 40 60 80 100 120
R
SS
I
nº de pacotes
Teste 11 - 773 metros
59 
 
5. CONCLUSÃO 
 
A rede LoRa implementada está sendo desenvolvida e necessita de 
alterações nas programações dos nós e no gateway. A maneira encontrada de 
se programar o gateway foi utilizando períodos de tempo, ou seja, quanto maior 
o número de nós que ele atender, maior será o tempo de processamento e de 
transmissão de todos. Uma limitação encontrada é o fato do servidor ThingSpeak 
permitir armazenamento de dados a cada 15 segundos, por isso deve-se 
programar todos os nós e gateway para obedecer a esse mínimo de tempo 
necessário. Esse servidor permite o armazenamento gratuito de 3 milhões de 
mensagens, o que será mais que suficiente para testes e aplicação que está 
sendo desenvolvida. Outro ponto é a formatação dos dados, nesse servidor não 
há disponibilidade para plotagem de gráficos de maneira diversificada, cabendo 
apenas uma variável para cada gráfico. 
No gateway, a primeira maneira encontrada para permitir que ele receba 
dados de todos os nós e cada um de uma vez, foi utilizando uma variável 
denominada “vez” que fica igual a “zero” quando um nó com certo ID acabou de 
enviar seus dados e fica igual a “um” quando certo ID está pronto para enviar. 
Essa solução é inviável pois quando um nó deixa de funcionar o gateway travará 
e não aceitará pacotes de nenhum outro nó pois todos estarão com sua vez igual 
a “zero”. Na maneira encontrada para sincronizar os nós utilizando-se períodos 
de tempo para cada um, é mais eficaz, porém não completamente, pois 
dependem de programações rígidas para que não haja atrasos na comunicação. 
Essa foi utilizada para programação dos módulos ligados ao gateway. Um 
módulo específico é designado para enviar a mensagem de sincronização para 
os outros nós da rede. 
Com o sucesso no desenvolvimento do nó repetidor foi verificado que este 
recebe o pacote de um nó inalcançável pelo gateway, e o transmite para o 
gateway. O próprio repetidor possui também a possibilidade de ser um nó que 
também envia seus próprios dados juntamente com os dados do nó que está 
utilizando-o para chegar ao gateway. 
Com o filtro, foi possível verificar que ao coletar dados, há melhoria na 
análise quando se implementa um filtro no código, portanto é indispensável 
utilizá-lo em coleta de dados. 
60 
 
Com o CRC, é possível verificar a integridade dos dados, pois caso haja 
interferência durante a propagação, é calculado o CRC no receptor, e o pacote 
é descartado se vier corrompido. 
Nos cálculos da métrica ETX, utilizando-se o CRC e os dados coletados 
em ambientes rurais e urbano, foram encontrados valores próximos de 1, o que 
é o ideal, portanto verificou-se que se pode enviar apenas 1 vez os pacotes de 
dados, e caso necessário reenviar 1 vez caso o pacote não seja confirmado ou 
apresente CRC incorreto. 
Os testes de transmissão em zonas rural e urbana resultou em uma 
distância máxima de transmissão de 1218 metros (posicionamento com maior 
parte em zona rural), o que é uma distância consideravelmente longa. Nos testes 
01 e 02, pode-se observar que casas (obstruções) causam a perda significativa 
de sinal, reduzindo grandemente a distância em relação à distância máxima 
obtida. Os testes também demonstraram que a propagação é melhor, tanto em 
termos de distância quanto em RSSI e métrica ETX para zona rural, devido à 
baixa obstrução. 
Na questão de economia de energia, infelizmente o hardware adotado não 
é o melhor indicado, sendo necessário utilizá-lo ligado à tomada, pois uma 
bateria comum dura no máximo 20 horas. Realizado um estudo que a melhor 
opção para poupar energia deixando o LoRa e o microcontrolador em modo 
Sleep é o Arduino Mini. 
 
 
 
 
 
 
 
 
 
61 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
• ARDUINOCC. Arduino. Disponível em:c 
<https://www.arduino.cc/en/Main/Software> 
• BIGMESSOWIRES. Raspberry Pi GPIO Programming in C. Disponível 
em: <https://www.bigmessowires.com/2018/05/> 
• CYTRON.IO. Setting Raspberry PI 3 as LoRa Gateway. Disponível 
em: <https://tutorial.cytron.io/2017/09/15/lesson-2-setting-raspberry-pi-3-
LoRa-gateway-hat-lrgw-915/> 
• D. S. J. De Couto, D. Aguayo, J. Bicket, and R. Morris. “A high-
throughput path metric for multi-hop wireless routing” in Proceedings 
of the 9th Annual International Conference on Mobile Computing and 
Networking, ser. MobiCom ’03. New York, NY, USA: ACM, 2003, pp. 134–
146. [Online]. 
• Disponível em: <http://doi.acm.org/10.1145/938985.939000> 
• DRAGINO. LoRa Gateway. Disponível em: 
<http://www.dragino.com/products/LoRa/item/119-lg01-s.html> 
• EMBARCADOS. Arduino UNO. Disponível em: 
<https://www.embarcados.com.br/arduino-uno/>• EMBARCADOS. LoRa e LoRaWAN. Disponível em: 
<https://www.embarcados.com.br/conheca-tecnologia-LoRa-e-o-
protocolo-LoRawan/> 
• HOPERF. RFM95W. Disponível em: 
<http://www.hoperf.com/upload/rf/RFM95_96_97_98W.pdf> 
• LAMMERTBIES. CRC Calculation. Disponível em: 
<https://www.lammertbies.nl/comm/info/crc-calculation.html> 
• MANUAL GATEWAY DRAGINO. Manual do Usuário. Disponível em: 
<http://www.dragino.com/downloads/downloads/UserManual/LG01_LoR
a_Gateway_User_Manual.pdf> 
• MATHWORKS. Importação ThingSpeak. Disponível em: 
<http://www.mathworks.com/help/thingspeak/channel-
settings.html#import> 
62 
 
• METERING. Padrões de protocolo de comunicação. Disponível em: 
<https://www.metering.com/wpcontent/uploads/Fernando%20Alvim%20D
iorio.pdf 
• MOBILEFISH. LoRaWAN. Disponível em: 
<https://www.mobilefish.com/developer/LoRawan/LoRawan_quickguide_
build_LoRa_gateway.html> 
• PLANIFICACION. Planificacion Administracion Redes. Disponível em: 
<https://planificacionadministracionredes.readthedocs.io/es/latest/Tema0
6/Teo> 
• SEEEDSTUDIO. Dragino LoRa Shield. Disponível em: 
<https://www.seeedstudio.com/Dragino-LoRa-Shield-support-868M-
frequency-p-2651.html> 
• SILVA, G. V. F.; BARRADAS, O. C. M. Sistemas Radiovisibilidade. 2 
ed., Rio de Janeiro: Livros Técnicos e Científicos Editora S.A., 1978. 
• TECHTUDO. Criar próprio console. Disponível em: 
<http://www.techtudo.com.br/dicas-e-tutoriais/noticia/2016/06/como-criar-
seu-proprio-console-retro-por-menos-de-r-300.html > 
• THINGSPEAK61. Importar Dados ao ThingSpeak. Disponível em: 
<http://thingspeak61.rssing.com/chan-59222027/all_p20.html> 
• THOMASCLAUSEN. Study Of LoRa Long Range. Disponível em: 
<http://www.thomasclausen.net/wp-content/uploads/2016/09/2016-A-
Study-of-LoRa-Long-Range-Low-Power-Networks-for-the-Internet-of-
Things.pdf> 
• TINDIE. LoRa Gateway. Disponível em: 
<https://www.tindie.com/products/edwin/lg01-LoRa-openwrt-iot-
gateway/> 
• TUDE, E. Enlace Rádio Digital Ponto a Ponto. Disponível em: 
<http://www.teleco.com.br/pdfs/tutorialrdig.pdf> 
• USINAINFO. Arduino. Disponível em: 
<http://blog.usinainfo.com.br/arduino-standalone-com-protoboard-um-
projeto-diy-para-quem- deseja-construir-o-seu-proprio-arduino/> 
• WIKIDRAGINO. LoRa Shield. Disponível em: 
<http://wiki.dragino.com/index.php?title=LoRa_Shield>