pontifícia universidade católica do paraná escola...

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 - Perfil de 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 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 58 - Alcance teste 10 – 1168 metros. Fonte: Os autores. ................................ 55


................................................................................................................................... 56





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

podem ser 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 os

detalhes 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 probabilidade de 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


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.


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 80R

SSI

nº de Pacotes

Teste 1 - 334 metros

45

Figura 37 - Alcance do 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



Mudando o local de testes para a avenida central do bairro, 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. 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.


-140

-120

-100

-80

-60

-40

-20

0

0 20 40 60 80 100 120 140

RS

SI

nº de Pacotes


47




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.


-140

-120

-100

-80

-60

-40

-20

0

0 5 10 15 20 25

RS

SI

nº do pacote


48


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.



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

RSS

I

nº do pacote


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.



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.



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.



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.


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

RS

SI

nº de pacotes


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.



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



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.


-100

-80

-60

0 20 40 60 80R

SSI

nº de pacotes


55


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.


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.


56


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.


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

RSS

I

nº de pacotes


57

aproximadamente 773 metros, e está sendo representada na figura 61, e o perfil

de elevação do terreno está mostrado na figura 62.



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


a recepção seja bem-sucedida, um valor extremamente satisfatório.


-100

-95

-90

-85

-80

-75

-70

-65

-60

0 20 40 60 80 100 120

RSS

I

nº de pacotes


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>

pontifícia universidade católica do paraná escola...

Documents