Universidade Federal de Pernambuco

Centro de Informática (Cin-UFPE)

Graduação em Engenharia da Computação

Uso de uma rede LoRaWAN em um

sistema de gerenciamento de lixo

Matheus Henrique Pinto Ramos

Trabalho de Graduação

Recife
02 de junho de 2019
 Universidade Federal de Pernambuco
Centro de Informática (Cin-UFPE)

Matheus Henrique Pinto Ramos

Uso de uma rede LoRaWAN em um sistema de

gerenciamento de lixo

Trabalho apresentado ao Programa de Graduação em En-

genharia da Computação do Centro de Informática (Cin-
UFPE) da Universidade Federal de Pernambuco como re-
quisito parcial para obtenção do grau de Bacharel em En-
genharia da Computação.

Orientador: Adriano Augusto de Moraes Sarmento

Recife
02 de junho de 2019
 Dedico este trabalho aos meus pais que sempre me
apoiaram e aos meus sobrinhos, Luisa, Luis Eduardo e
Rafael
 Agradecimentos

Gostaria de agradecer primeiramente a Deus por me dar paciência e forças para nunca
desistir.
Aos meus pais por sempre me apoiarem e nunca duvidarem da minha capacidade, as minhas
irmãs Paloma e Louise por todo o apoio dado.
Gostaria de agradecer ao professor Adriano Sarmento por aceitar ser meu orientador e estar
sempre disponível para tirar dúvidas e aconselhar.
E aos amigos da faculdade, em especial a Pedro Esposito, Gabriel Lima e Caio Burgardt
pela parceria ao longo dos últimos anos, e que sempre estiveram a disposição para ajudar.
Gostaria de agradecer também a João Paulo e Bruno pela oportunidade e confiança que me
deram de trabalhar com aquilo que mais gosto em um lugar em que está constantemente me
desafiando.

iv
“It’s the oldest story in the world. One day you’re 17 planning for someday
and then quietly, without you ever noticing, someday today. And then
someday yesterday. And this is your life.”
—NATHAN SCOTT (One Tree Hill)
 Resumo

Em IoT, frequentemente se faz necessário a transmissão de informações e dados, porém

em grande parte das vezes os sistemas estão embarcados e precisam fazer o racionamento de
energia pois devem funcionar durante dias e até anos sem ter que precisar de uma recarga
ou troca de bateria. Por isso, o uso de low-power wide-area network (LPWAN) se tornou
popular nesse meio, pois permite a comunicação sem fio de longa distancias por um baixo
custo energético. O objetivo deste trabalho é implementar um sistema para o monitoramento
em tempo real do volume de lixo em lixeiras subterrâneas, esse sistema utilizará o LoRa para
envio de informações de sensores a um gateway. O gateway, por sua vez, alimentará um banco
de dados que será consumido por um aplicativo para exibição em tempo real dos volumes das
lixeiras. O sistema foi implementado com sucesso e até a data que este trabalho foi escrito está
em funcionamento na Praça Alencastro em frente a prefeitura de Cuiabá.

Palavras-chave: IoT, Sistemas Embarcados, Comunicação via rádio, LoRa

vi
 Abstract

In IoT, it is often necessary to transmit information and data, however in most cases the
systems are embedded and need to save energy because they should work for months or even
years without having to recharge or replace the battery. Therefore, the use of the Low-Power
Wide-Area Network became popular, because it allow a long-range communication with a
low-power consumption. The objective of this work is to develop a system for the real-time
monitoring of the amount of garbage in a underground dumps, this system will use LoRa to
send sesnsor information to a gateway. The gateway, in its turn, will feed a database that will
be consumed by an application for a real-time display of the amount of garbage of the bins.
The system was successfuly implemented and until the date that this work was written is in
operation in the Alencastro Square, in front of Cuiabá city hall.

Keywords: IoT, Enbedded Systems, Radio Communication, LoRa

vii
 Sumário

1 Introdução 1
1.1 Contexto e Motivação 1
1.2 Objetivos 1
1.3 Estrutura do trabalho 2
2 Conceitos Básicos 3
2.1 LPWAN 3
2.2 LoRa e LoRaWAN 3
2.3 SPI 6
2.4 Criptografia AES 7
2.4.1 Funcionamento 7
3 Trabalhos relacionados 10
3.1 The Design and Implementation of Smart Trash Bin 10
3.2 Smart Waste Management using Wireless Sensor Network 11
4 Desenvolvimento do sistema 13
4.1 Arquitetura do Sistema 13
4.1.1 Visão Geral 13
4.1.2 Arquitetura de Hardware 13
4.1.2.1 Placa de Sensores 14
4.1.2.2 Gateway 18
4.1.3 Arquitetura de Software 19
4.1.3.1 Placa de sensores 19
4.1.3.2 Gateway 19
4.1.3.3 Servidor 20
4.1.3.4 Apresentação 20
4.2 Funcionamento do Sistema 21
5 Testes e Experimentos 24
5.1 Placa de Sensores 24
5.2 Gateway 25
5.3 Servidor 27

viii
 SUMÁRIO ix

6 Conclusão e Trabalhos Futuros 28

6.1 Conclusão 28
6.2 Trabalhos Futuros 28
 Lista de Figuras

2.1 Comparativo de protocolos de rede sem fio com relação ao alcance e largura de
banda 4
2.2 Topologia da rede LPWAN 5
2.3 Arquitetura da rede LoRaWAN 5
2.4 Esquema de conexão do protocolo SPI 7
2.5 Fluxograma do algoritmo AES 8
2.6 Estágios presentes na criptografia AES. A imagem (a) corresponde a Matriz de
substituição utilizada no estágio de SubBytes, e as imagens (b), (c), (d) e (e) são
exemplos de funcionamento dos estágios SubBytes, ShiftRows, MixColumns
e AddRoundKey respectivamente. 9

3.1 Diagrama de blocos Smart Trash Bin. Fonte: [Sam17] 10

3.2 Diagrama de blocos do Sistema de Gerenciamento de Resíduos proposto. Fonte:
[SMB16] 11

4.1 Visão geral do sistema. Na figura (a) o módulo de captação, composto pela
placa de sensores (b) e gateway (c), seguido do módulo WEB (d) e do módulo
de apresentação (e). Fonte: Autor 14
4.2 Design da placa de sensores. Fonte: Autor 15
4.3 Arquitetura da placa de sensores. Fonte: Autor 16
4.4 Funcionamento do sensor ultrassônico. Fonte: Newton C. Braga, acessado
em Jun 2019, https://www.newtoncbraga.com.br/index.php/
como-funciona/5273-art691. 16
4.5 Chip RFM95 utilizando paquímetro como referência. Fonte: Autor 17
4.6 Arquitetura do Gateway 18
4.7 Fluxograma da placa de sensores. Fonte: Autor 20
4.8 Fluxograma da arquitetura de software do gateway. Fonte: Autor 21
4.9 Telas do aplicativo para Android do módulo de apresentação. Sendo a imagem
(a), (b), (c) e (d) das telas principal, unidades, detalhes e alertas, respectiva-
mente. Fonte: Autor 22

5.1 Tela de configuração do Raspberry Pi. Fonte: Autor 26

5.2 Teste do alcance da comunicação do gateway com a placa de sensores. O ponto
0, a esquerda, é a localização do gateway e o ponto final é a localização da placa
de sensores. Fonte: Autor 26
5.3 Teste de inserção de dados na tabela de eventos do banco de dados. Fonte: Autor 27

x
 Lista de Tabelas

2.1 Pinos básicos da conexão SPI 6

4.1 Especificação ATmega328p 15

4.2 Especificação do módulo JSN-SR04t 17
4.3 Especificação TP4056 18
4.4 Especificação Raspberry Pi 3 Model B 19

5.1 Característica do sistema da placa de sensores 25

xi
 C APÍTULO 1

Introdução

1.1 Contexto e Motivação

Um dos principais problemas ambientais no mundo hoje é a grande quantidade de resíduos

gerados diariamente, de acordo com a Associação Brasileira de Empresas de Limpeza Pública e
Resíduos Especiais (Abrelpe), o Brasil produziu em 2015 79,9 milhões de toneladas de lixo em
todo o País, e esse número vem crescendo ano após ano [Fra18]. Por isso a coleta de lixo é uma
preocupação para todas as prefeituras, pois quanto mais lixo nas ruas, mais vezes é necessária
a coleta, e, consequentemente, maior o custo. Uma forma de economizar seria ter a certeza
que os pontos de coleta estão, de fato, cheios, evitando viagens desnecessárias, economizando
dinheiro, tempo, combustível e pessoal. Com a crescente popularidade da Internet das Coisas
(IoT em inglês) em diversas áreas da tecnologia, fez-se necessário o desenvolvimento de uma
tecnologia de transmissão de dados que fosse capaz de suprir as necessidades de sistemas que
possuíam uma fonte de energia limitada. A low-power wide-area network (LPWAN) foi desen-
volvida exatamente para esse propósito, permitir a comunicação sem fio de longas distâncias
(chegando a 10 km dependendo da tecnologia aplicada) [Lin16] e uma baixa taxa de transmis-
são (menos de 5 Kbps)[Lin16] a um custo energético extremamente baixo, aumentando a vida
útil da bateria[Lin16][Mel17].
Na literatura foram encontrados alguns trabalhos que fazem o monitoramento remoto de
lixo, porém, muitas vezes são sistemas que são difíceis de serem aplicados a um nível munici-
pal, devido muitas vezes a restrição da tecnologia utilizada ou custo de produção.

1.2 Objetivos

O objetivo deste trabalho é desenvolver um sistema de monitoramento de volume de uma

lixeira subterrânea. O sistema irá fazer a leitura do volume de lixo através de sensores presentes
em sua tampa e enviará suas informações para um servidor de dados através do protocolo
LoRaWAN, que será explicado com mais detalhes nos próximos capítulos. As informações
coletadas estarão disponíveis através de um aplicativo onde poderá ser visualizado a localização
da lixeira e seu volume atual. Com essas informações as pessoas envolvidas poderão organizar
melhor horário de coleta de lixo, evitando viagens desnecessárias até o local.
Além disso, o sistema deverá ter um baixo custo de produção, baixo custo energético, pois
será instalado em lixeiras, portanto o fornecimento de energia será limitado, deverá ser es-
calável, capaz de suportar dezenas de unidades utilizando apenas uma única conexão com a
internet.

1
 1.3 ESTRUTURA DO TRABALHO 2

1.3 Estrutura do trabalho

Este trabalho está estruturado da seguinte maneira:

• Capítulo 2 - Apresenta alguns conceitos básicos para um melhor entendimento do traba-

lho proposto

• Capítulo 3 - Traz alguns trabalhos relacionados ao tema deste projeto

• Capítulo 4 - Apresenta o sistema proposto em detalhes, desde sua arquitetura até os

equipamentos utilizados

• Capítulo 5 - Apresenta os experimentos realizados para a validação do sistema proposto

• Capítulo 6 - Traz as conclusões e possíveis trabalhos futuros

 C APÍTULO 2

Conceitos Básicos

Neste capítulo serão apresentados alguns conceitos importantes para o entendimento do

trabalho proposto, conceitos como LPWAN, LoRa, SPI e AES serão explanados melhor nas
próximas seções. O conceito de LPWAN é importante para entender melhor a tecnologia uti-
lizada neste trabalho. O LoRa é a tecnologia utilizada neste trabalho para a transmissão de
dados, portanto entender seu funcionamento será importante. O conceito de SPI é importante
para se entender como o LoRa se comunica com os microcontroladores ou microcomputado-
res utilizados neste trabalho. E, por fim, o conceito de AES é importante pois é o algoritmo
escolhido para fazer a criptografia da informação que será transmitida pelo LoRa.

2.1 LPWAN

Low Power Wide Area Network ou simplesmente LPWAN é uma tecnologia de comuni-
cação sem fio de baixo custo energético, de longas distâncias e baixa taxa de transmissão, é
altamente utilizada em IoT para o envio de informações de sensores, a Figura 2.1 mostra um
comparativo do alcance e da largura de banda de algumas redes.
A rede LPWAN utiliza uma topologia do tipo estrela, ou seja, os nós da rede são conec-
tados diretamente ao gateway, conforme pode ser visualizado na Figura 2.2, evitando assim a
implementação de um protocolo de roteamento, além disso os nós podem agir como repetido-
res, aumentando, assim, a área de cobertura. Alguns exemplos de tecnologias que utilizam da
LPWAN são Nwave, Ingenu, SigFox e LoRa que foi a tecnologia escolhida para este trabalho. O
LoRa foi escolhido devido ao seu alcance e por ser mais popular do que as outras tecnologias
que também utilizam LPWAN, tendo vários chips disponíveis no mercado brasileiro, sendo
possível encontrar chips a partir de R$40,00, enquanto um módulo SigFox pode ser encontrado
por R$293,00.

2.2 LoRa e LoRaWAN

LoRa, abreviação de Long Range ou longo-alcance em português, é uma tecnologia de co-

municação via radiofrequência que permite a comunicação a longas distâncias, como o próprio
nome sugere, podendo chegar a 4 Km em áreas urbanas e a até 15 Km em áreas rurais [nov],
utilizando uma potência muito baixa, da ordem de 20dbm ou 100mW. Como dito anteriormente
a LoRa é uma LPWAN portanto todas as características apresentadas anteriormente valem tam-
bém para o LoRa. Ela se baseia em uma técnica conhecida como Chirp Spread Spectrum(CSS),
uma técnica de aumento ou diminuição de frequência ao longo do tempo, bastante utilizada

3
 2.2 LORA E LORAWAN 4

Figura 2.1: Comparativo de protocolos de rede sem fio com relação ao alcance e largura de
banda

há décadas em sistemas militares e de radares por possibilitar grande alcance e imunidade a

ruídos, mas que sempre envolveu sistemas muito críticos quanto a estabilidade de frequência e
altos custos. Com o avanço da tecnologia foi possível utilizar essa mesma técnica utilizando-se
componentes mais baratos, sendo a LoRa a primeira a ser desenvolvida para uso comercial.
Vale observar que LoRa é a implementação da camada física de comunicação, ou seja, como
a informação é transmitida, enquanto a especificação lógica ou o protocolo utilizado para ser-
vir de padrão para as comunicações que utilizam o LoRa recebe o nome de LoRaWAN. Esse
protocolo implementa todos os detalhes de funcionamento, segurança de dados, qualidade de
serviços, além de servir de padrão para comunicação com gateways. A arquitetura da rede
LoRaWAN consiste basicamente de módulos ou end-devices, gateways, servidores de rede e
servidor de aplicação conforme mostrado na Figura 2.3.
Os end-devices são os elementos básicos da rede, formados basicamente de sensores, bo-
tões, leitores de consumo etc. Os gateways são os responsáveis em receber os sinais enviados
pelos end-devices. O servidor de rede é o responsável em receber as informações enviadas pelo
gateway e armazená-las em um banco de dados para que estejam disponíveis quando forem
requisitadas pelo servidor de aplicação, que são programas específicos que recebem os dados
do servidor de rede e executam ações específicas, sejam elas de monitoramento, relatórios,
controle etc. Com relação a frequência de operação cada país tem sua regulamentação quando
se trata do espectro sub-GHz, mas que podem ser resumidos em dois grupos: os que seguem
 2.2 LORA E LORAWAN 5

Figura 2.2: Topologia da rede LPWAN

Figura 2.3: Arquitetura da rede LoRaWAN

a Europa e utilizam a frequência de 868 MHz, e os que seguem os Estados Unidos, utilizando
a frequência de 915MHz[Lin16]. A legislação brasileira permite o uso de equipamentos de
radiofrequência tanto na frequência utilizada na Europa como na dos Estados Unidos, contanto
que obedeçam determinadas condições [dT18]. Outros parâmetros presentes na tecnologia Lo-
RaWAN que influenciam sua transmissão são:

• Transmission Power(TP) - é a potência do sinal, pode ser configurado entre -4dbm e

20dbm [BR17];

• Carrier Frequency(CF) - é a frequência central em que o rádio LoRa pode ser configu-
rado, normalmente varia de 137MHz até 1020MHz com passos de 61Hz [BR17], mas
dependendo do chip utilizado pode ser limitado de 860 MHz à 1020 MHz

• Spreading Factor(SF) - define o número de chips por símbolo, um chirp é a mudança

da frequência para mais ou para menos. Pode ser configurado de 6 a 12, quanto maior o
 2.3 SPI 6

SF maior a sensitividade do receptor, aumentado o alcance e, consequentemente, aumen-

tando o tempo de permanência no ar[BR17].

• Bandwidth (BW)) - é a largura da frequência na banda de transmissão, quanto maior a

largura maior a taxa de transmissão e consequentemente menor o tempo de permanência
no ar, mas uma menor sensibilidade do receptor, portanto menor o alcance. Pode ser
escolhido entre 7.8 kHz até 500 kHz[BR17].

• Coding Rate(CR)) - o LoRa faz uso do Forward Error Correction (FEC) para superar
potenciais interferências, o CR é a taxa de FEC, podendo ser 4/5, 4/6, 4/7 ou 4/8, quanto
maior o CR maior a robustez do sinal e maior o tempo de permanência no ar[BR17]

2.3 SPI

Serial Peripheral Interface (SPI) traduzido de modo livre como Interface Serial de Perifé-
ricos no português, foi desenvolvido pela Motorola nos meados dos anos 1980 para oferecer
uma interface simples e de baixo custo entre microcontroladores e chips e se tornou um pa-
drão na indústria devido a sua simplicidade. É um protocolo de comunicação serial síncrono,
ou seja, depende de um sinal de clock para sincronizar a comunicação entre os dispositivos,
sendo denominado de Mestre o dispositivo gerador do sinal de sincronismo e escravo os de-
mais dispositivos conectados. O protocolo SPI opera em full-duplex, ou seja, toda troca de
dados acontece nas duas direções. São necessários apenas 3 fios mais 1 para cada escravo co-
nectado, sendo eles denominados CLK, MISO, MOSI e SS, a tabela 2.1 abaixo traz o significado
e alguns nomes alternativos encontrados e logo em seguida na Figura 2.4 um esquema típico
de conexão:

Tabela 2.1: Pinos básicos da conexão SPI

Pino Nome Significado Nome Alternativo

Do Master para o Slave MOSI Master Output Slave Input SDO, DO, SO
Do Slave para o Mater MISO Master Input Slave Ouput SDI, DI, SI
Clock SCLK Serial Clock SCK, CLK
Seletor de escravo SS Slave Select CS, nSS, nCS

Como pode ser observado na Figura 2.4, todos os pinos MISO e MOSI dos escravos estão
conectados ao mestre, isso significa que todos os escravos “escutam” o que o mestre fala,
mesmo que a mensagem tenha sido direcionada para um escravo em específico. Para evitar
que todos respondam ao mesmo tempo existe o sinal SS. O sinal de SS funciona como Seleção
de Escravo (Slave Select). É um sinal ativo em nível baixo, o que significa que o dispositivo
é selecionado quando este pino se encontra em nível baixo. No entanto, muitos dispositivos
utilizam este sinal como sincronismo de frame [Sac14].
 2.4 CRIPTOGRAFIA AES 7

Figura 2.4: Esquema de conexão do protocolo SPI

2.4 Criptografia AES

Advanced Encryption Standard, ou Padrão de Criptografia avançada no português, é uma

especificação de criptografia de chave simétrica estabelecida pelo Instituto Nacional de padrões
e tecnologia (NIST) dos EUA em 2001[Sta01]. O AES foi adotado após a realização de um
concurso iniciado em 1998 para decidir qual seria o substituto do antigo padrão, o Data En-
cryption Standard (DES) que estava ficando obsoleto. O AES faz parte do Rijndael, nome
original dado pelos seus criadores, Vincent Rijmen e Joan Daemen, uma família de cifras com
diferentes chaves e tamanhos de blocos, sendo o AES a versão do Rijndael de comprimento de
chave de 128, 196 ou 256 bits operando sobre um bloco de 128 bits.

2.4.1 Funcionamento
O AES opera sobre um arranjo de bytes de 4x4 posições denominado de matriz de estado.
Para realizar a criptografia cada uma das rodadas do AES, exceto a última, passam por 4 está-
gios, e a quantidade de rodadas depende do tamanho da chave, sendo 10 rodadas para a chave
de 128 bits, 12, para a chave de 196 bits e 14 para a chave de 256 bits(imagem). Na imagem 2.5
pode-se ver o fluxograma mais detalhado do funcionamento do AES e em seguida a descrição
de cada um dos estágios presentes no fluxograma.

• SubBytes - Neste estágio cada uma das posições da matriz de estado é substituída por
outro byte de uma matriz de substituição denominada de S-Box (Figura 2.6a)

• ShiftRow - Esta etapa opera nas linhas da matriz de estado, ela ciclicamente desloca a
linha para a esquerda de acordo com um offset r, esse offset é definido de acordo com o
número da linha (contando a partir do 0), portando 0 ≤ r ≤ 3, portando a primeira linha
não é deslocada pois seu offset é 0 (Figura 2.6c).
 2.4 CRIPTOGRAFIA AES 8

• MixColumns - Esta etapa opera nas colunas do estado, aqui cada coluna é multiplicada
por uma matriz (Figura 2.6d). Na última rodada esta operação não é realizada.

• AddRoundKey - Neste estágio é realizada uma operação de XOR do estado com uma
sub-chave de 128 bits gerada a partir da chave, e em cada rodada uma nova sub-chave é
gerada (Figura 2.6e).

Figura 2.5: Fluxograma do algoritmo AES

 2.4 CRIPTOGRAFIA AES 9

(a) S-Box

(b) SubBytes (c) ShiftRows

(d) MixColums (e) AddRoundKey

Figura 2.6: Estágios presentes na criptografia AES. A imagem (a) corresponde a Matriz de
substituição utilizada no estágio de SubBytes, e as imagens (b), (c), (d) e (e) são exemplos de
funcionamento dos estágios SubBytes, ShiftRows, MixColumns e AddRoundKey respectiva-
mente.
 C APÍTULO 3

Trabalhos relacionados

Neste capítulo será apresentado o estado da arte na área de sistemas de monitoramento de

resíduos existente na literatura. Todos os trabalhos apresentados abaixo possuem em comum
o desenvolvimento de um sistema para monitoramento de volume de lixo presente em uma
lixeira, mostrando o quão pertinente o objetivo proposto é na literatura.

3.1 The Design and Implementation of Smart Trash Bin

Neste trabalho Fady, 2017[Sam17] propõe um design de uma lixeira inteligente capaz de
medir o volume de lixo presente através de sensores ultrassônicos instalados na parte superior
da lixeira. Faz uso da placa Arduino Nano, uma placa de prototipação baseada no microcon-
trolador ATmega328, com suporte a comunicação serial através do USB e regulador de tensão
5V. Além disso o design proposto utiliza um módulo GSM SIM900L para enviar SMS quando
a lixeira estiver cheia, e um LED para alerta visual. O sistema também utiliza um módulo de
sensor de movimento PIR para detectar quando a lixeira está sendo utilizada e é capaz de repro-
duzir um arquivo de áudio armazenado em um cartão de memória, o qual também é utilizado
para armazenar as informações de uso da lixeira e de quando ela está cheia. O diagrama de
blocos do sistema é apresentado na Figura 3.1 abaixo.
A principal desvantagem desse sistema se dá no uso do GSM para comunicação com o
usuário, pois para cada unidade instalada deverá haver um chip GSM ativo com um pacote
de dados, aumentando o custo de instalação. O sistema também possui muitos componentes,
aumentando o consumo de energia.

Figura 3.1: Diagrama de blocos Smart Trash Bin. Fonte: [Sam17]

10
 3.2 SMART WASTE MANAGEMENT USING WIRELESS SENSOR NETWORK 11

3.2 Smart Waste Management using Wireless Sensor Network

Neste trabalho Tarandeep, Rita, Deepak, 2016 [SMB16], propõem um sistema de três ca-
madas para o gerenciamento inteligente de resíduos(Figura 3.2), em que a primeira camada
consiste em uma lixeira inteligente dotada de sensores ultrassônicos, acelerômetro, sensor de
umidade e temperatura e um módulo ZigBee para comunicação com a segunda camada. A se-
gunda camada consiste em um gateway que também possui um módulo ZigBee atuando como
um recebedor, e um módulo GPRS para envio das informações para a terceira camada, a estação
de controle. A estação de controle é um servidor onde está presente o banco de dados respon-
sável em armazenar as informações transmitidas do gateway, na estação de controle também
está presente uma página web para interação do usuário com o sistema.
Esse sistema possui uma arquitetura similar ao do trabalho proposto, tendo como diferença
a tecnologia de transmissão utilizado, o ZigBee. Apesar de também ser uma tecnologia de
transmissão via radiofrequência, o ZigBee possui um alcance menor em relação à tecnologia
utilizada neste trabalho, conforme pode ser visualizada na Figura 2.1 apresentada no capítulo
anterior. Além disso o sistema proposto por Tarandeep et al. também utiliza o GPRS para
comunicação do gateway com o servidor, necessitando de um chip GSM ativo com pacote de
dados para funcionar.

Figura 3.2: Diagrama de blocos do Sistema de Gerenciamento de Resíduos proposto. Fonte:

[SMB16]

É possível perceber que ambos os sistemas utilizam-se de sensores ultrassônicos para rea-
lizar a detecção do volume do lixo, característica essa também presente no sistema proposto.
O sistema proposto por Fady, utiliza diversos outros sensores o que acaba aumentando o custo
de produção, fazendo uma pesquisa de preços dos componentes utilizados chega-se a um valor
de aproximadamente R$150,00, apesar de ser mais barato que o sistema proposto o sistema
de Fady também necessita um chip GSM ativo com um plano de dados para cada unidade
instalada, aumentando o custo de escalabilidade do sistema.
 3.2 SMART WASTE MANAGEMENT USING WIRELESS SENSOR NETWORK 12

O sistema proposto por Tarandeep, Rita e Deepak, também necessita de um chip GSM ativo
com um pacote de dados, porém só é necessário no gateway, não influenciando na escalabili-
dade do sistema, porém o ZigBee possui um alcance bem menor que o LoRa (aproximada-
mente 100 metros), sendo necessário fazer uso de vários módulos se quiser cobrir uma área
maior utilizando-se o mesmo gateway, ou utilizar vários gateways, tendo como desvantagem a
necessidade de vários chips com pacotes de dados ativos, aumentando o custo de escalabilidade
do sistema.
 C APÍTULO 4

Desenvolvimento do sistema

A proposta deste trabalho é desenvolver um sistema de monitoramento de volume de lixo

de uma lixeira subterrânea, em ambiente urbano, para melhor gestão da coleta de lixo. No
Brasil, a coleta de lixo urbano é de responsabilidade da prefeitura, através de contratos com
empresas especializadas neste tipo de serviço. Após realizarem um estudo dos resíduos gerados
na cidade, a empresa decide como deve ocorrer a coleta, podendo algumas ruas receberem a
coleta diariamente e outras uma vez por semana. A empresa então calcula o custo do serviço
através da quantidade de vezes que precisará enviar um caminhão até determinada localidade,
além de custo de pessoal e combustível. Esse custo é repassado aos moradores do município
através de uma taxa de coleta de lixo, pago todo ano juntamente com o IPTU. Com o uso
do sistema proposto será possível monitorar o volume de lixo de uma lixeira em tempo real,
podendo verificar quando uma lixeira está cheia e necessitando da coleta.
O sistema utiliza um microcontrolador ATmega328p[atm] e um Raspberry Pi 3 Model B
[ras] para captação e processamento das informações obtidas de sensores, respectivamente, e a
comunicação entre eles é realizada utilizando um chip LoRa. Neste capítulo é apresentado todo
o design do sistema, sua arquitetura, bem como suas funcionalidades, além de ser apresentado
tudo que foi desenvolvido e implementado para se obter o protótipo do sistema.

4.1 Arquitetura do Sistema

Essa seção define toda a arquitetura do sistema, do ponto de vista de hardware, software e
banco de dados

4.1.1 Visão Geral

Na figura 4.1, podemos ver uma visão geral do sistema, composta por 4 módulos essen-
ciais: Captação, Figura 4.1a, composta pelos sensores para captação dos dados (Figura 4.1b)
e o transmissor LoRa para envio dos dados para o Gateway (Figura 4.1c), Web (Figura 4.1d)
responsável por armazenar os dados recebidos pelo gateway e enviar as informações solicitadas
pelo usuário na parte de apresentação (Figura 4.1e).

4.1.2 Arquitetura de Hardware

Nesta seção será mostrada com mais detalhes todos os componentes utilizados no módulo
de captação e suas respectivas funções

13
 4.1 ARQUITETURA DO SISTEMA 14

Figura 4.1: Visão geral do sistema. Na figura (a) o módulo de captação, composto pela placa
de sensores (b) e gateway (c), seguido do módulo WEB (d) e do módulo de apresentação (e).
Fonte: Autor

4.1.2.1 Placa de Sensores

Essa placa é a responsável por fazer a captação de dados dos sensores e transmissão dos
dados via rede LoRaWAN para o gateway. A placa foi projetada utilizando o software EAGLE
[eag] e na figura 4.2 pode ser visto com mais detalhes suas conexões. Os componentes utili-
zados foram um microcontrolador ATmega328p, responsável pelo controle dos sensores e do
chip transmissor, 3 sensores ultrassônicos JSN-SR04t, responsável pela leitura da profundidade
de cada uma das lixeiras, um chip LoRa RFM95[rfm], responsável por fazer a transmissão de
dados sempre que solicitado pelo gateway, antena UHF 900MHz SteelBras APC3900 [ap3],
um regulador de tensão LM7805 responsável em regular a tensão da fonte de entrada para 5V
para alimentar os sensores, um regulador AMS1117- 3.3 responsável em regular a tensão para
3.3V para alimentar o chip LoRa RF95 e o ATmega328p e um módulo TP4056 [tp4] para car-
regamento de bateria. Na figura 4.3 abaixo podemos ver melhor a arquitetura da placa e em
seguida a especificação de cada um dos componentes utilizados:

• ATmega328p: O ATMEGA328p é um microcontrolador de alta performance de propó-

sito geral bastante conhecido por sua utilização na placa Arduino UNO e Arduino Nano.
É fabricado pela Microchip[atm] e faz parte da família AVR-RISC de 8-bit, a tabela 4.1
abaixo contém suas principais especificações

• JSN- SR04t - O módulo JSN-SR04t é um sensor ultrassônico a prova d’água, de baixa

tensão e baixo consumo de potência e alta precisão [jsn]. O princípio de funcionamento
deste módulo é o mesmo de um sonar(referência), ou seja, um pulso de onda ultrassônica
é transmitido, esse pulso é refletido por um objeto e um receptor recebe a onda refletida
(figura 4.4), através do tempo necessário para capturar a onda refletida é possível calcular
a distância do objeto através da equação a seguir:
 4.1 ARQUITETURA DO SISTEMA 15

Figura 4.2: Design da placa de sensores. Fonte: Autor

Tabela 4.1: Especificação ATmega328p

Parâmetro Valor
Tipo de memória do programa Flash
Tamanho da memória 32KB
RAM 2048 bytes
Data EEPROM 1024 bytes
Velocidade CPU 20(MIPS/DMIPS)
Interfaces de comunicação digital 1 - UART, 2-SPI, 1-I2C
PWM 6
Temporizadores 2 x 8-bit, 1 - 16-bit
Comparadores 1
Temperatura de operação -40º à 85º C
Tensão de operação 1.8 à 5.5 V
Total de pinos 32
Low Power Sim

t ×v
x= (4.1)
2
 4.1 ARQUITETURA DO SISTEMA 16

Figura 4.3: Arquitetura da placa de sensores. Fonte: Autor

em que x é a distância, t o tempo que leva para a onda ir e voltar e v a velocidade do som.

Figura 4.4: Funcionamento do sensor ultrassônico. Fonte: Newton C. Braga, acessado em

Jun 2019, https://www.newtoncbraga.com.br/index.php/como-funciona/
5273-art691.

• RFM95 - O chip RFM95 é um modem LoRa capaz de prover uma comunicação spread-
spectrum de ultra longo alcance e alta imunidade contra interferências[rfm], é fabricado
pela HopeRF, a principal fabricante de componentes de IoT da China[hop]. O RFM95
opera na faixa de frequência de 868 até 915 MHz, e é facilmente integrável com diversos
tipos de microcontroladores e microcomputadores pois faz uso da comunicação SPI para
enviar e receber dados. Na tabela X abaixo temos algumas informações do chip RFM95
seguida de uma imagem do chip na Figura 4.5

• TP4056 - O TP4056 é um módulo carregador linear de corrente e tensão constante de

baterias íon-lítio. Esse módulo possibilita que baterias sejam recarregadas sem precisa-
rem serem retiradas do circuito da placa, no sistema ele é utilizado em conjunto com uma
 4.1 ARQUITETURA DO SISTEMA 17

Tabela 4.2: Especificação do módulo JSN-SR04t

Parâmetro Valor
Tensão de operação 3.0 - 5.5V
Corrente de operação <8mA
Frequência de sonda 40KHz
Alcance Máximo 600cm
Distância mínima 20cm
Precisão ± 1cm
Resolução 1mm
Ângulo de medição 75º
Conexão 5V (Alimentação +)
Trig (input) RX
Echo (output) TX
GND (Alimentação -)
Temperatura de operação -20º à 70º C
Tamanho (C x L x A) 42 x 29 x 12 mm

Figura 4.5: Chip RFM95 utilizando paquímetro como referência. Fonte: Autor

placa solar, fazendo com que durante o dia em que há sol, a placa solar alimenta a placa
de sensores e recarrega a bateria através do módulo TP4056, e durante a noite a bateria
alimenta a placa de sensores. A tabela abaixo traz as principais características do módulo
TP4056.
 4.1 ARQUITETURA DO SISTEMA 18

Tabela 4.3: Especificação TP4056

Parâmetro Valor
Tensão de Entrada 4.0 - 8.0 V
Tensão de saída 4.137 - 4.263 V
Temperatura de Operação -40º à 85º C
Corrente de saída Pino BAT <1200 mA

4.1.2.2 Gateway
O gatewayé o módulo responsável por fazer as requisições para a placa de sensores e re-
ceber e tratar as informações enviada por elas, além de enviar as informações recebidas para
o servidor onde serão armazenadas em um banco de dados. Esse módulo é composto de um
microcomputador Raspberry Pi 3 Model B(RP), escolhido devido a sua facilidade em se co-
nectar a internet pois é capaz de se conectar tanto via Wi-Fi quanto via ethernet, além de ser
bem compacto, além disso o RP permite acesso remoto via SSH o que torna a manutenção
do sistema mais fácil. Além disso o gateway também conta com um chip LoRa RFM95 para
enviar e receber informações da placa de sensores. Na figura 4.6 podemos ter uma visão mais
alto nível deste módulo.

Figura 4.6: Arquitetura do Gateway

• Raspberry Pi 3 Model B - É um microcomputador aproximadamente do tamanho de um

cartão de crédito, com suporte à Wi-Fi, conexão Ethernet, 4 portas USB’s, saída HDMI,
GPIO com 40 pinos com suporte a diferentes tipos de comunicação, entre elas SPI, I2C
e Serial. Dotado de uma CPU Broadcom BCM2837 de 64bit, Quad-Core de 1.2GHz e
1GB de memória RAM. Na tabela 4.4 abaixo podemos ver as especificações completas
do Raspberry Pi 3 Model B:
 4.1 ARQUITETURA DO SISTEMA 19

Tabela 4.4: Especificação Raspberry Pi 3 Model B

Quad Core 1.2GHz Broadcom BCM2837 64bit CPU

1GB RAM
BCM43438 wireless LAN e Bluetooth Low Energy (BLE)
100 Base Ethernet
GPIO extendida de 40 pinos
4 portas USB 2.0
4 Pole stereo output and composite video port
HDMI
Porta para camera CSI para conexão com o Raspberry Pi camera
Porta para display DSI, para conexão com o display touchscreen Raspberry Pi
Entrada para cartão Micro SD para carreamento do sistema operacional e armazenamento
Porta Micro USB de até 2.5A para alimentação

4.1.3 Arquitetura de Software

A seguir serão descritos em detalhes a arquitetura de software utilizada em cada um dos
módulos e as tecnologias e linguagens utilizadas em cada um deles

4.1.3.1 Placa de sensores

Na placa de sensores por se tratar de um microcontrolador bastante utilizado nas placas
Arduino, foi utilizado a IDE do próprio Arduino para escrita, compilação e carregamento do
código no microcontrolador ATmega328p. A figura 4.7 abaixo ilustra o fluxo do programa
carregado no microcontrolador. As bibliotecas utilizadas foram arduino-LoRa [lor] para co-
municação do microcontrolador com o chip RFM95, essa biblioteca foi escolhida pela sua
compatibilidade com o chip escolhido e a AESlib para encriptação dos dados

4.1.3.2 Gateway
Para o gateway foi utilizado a linguagem Python 3.5 juntamente com os pacotes requests,
threading, time e SX127x. O pacote requests foi utilizado para realizar requisições http para
envio das informações recebidas da placa de sensores para o servidor, o pacote threading foi
utilizado para criação de múltiplos processos, time foi utilizada no uso de funções do timer
do microprocessador para contagem de tempo e por fim o pacote SX127x foi utilizado para
comunicação do Raspberry com o chip RFM95. A figura 4.8 abaixo mostra o fluxograma em
detalhes do software executado no gateway.
 4.1 ARQUITETURA DO SISTEMA 20

Figura 4.7: Fluxograma da placa de sensores. Fonte: Autor

4.1.3.3 Servidor
Para o servidor foi utilizado a linguagem Elixir [elx] juntamente com o Phoenix [phx], um
framework web para Elixir, para criação de uma API REST para fazer a integração com o banco
de dados. A linguagem elixir foi escolhida por ser uma linguagem altamente tolerante a falhas,
distribuída e concorrente, e também por ser uma linguagem com qual o autor deste trabalho tem
mais familiaridade na criação de API REST. O banco de dados utilizado para o armazenamento
das informações foi o PostgreSQL, ele foi escolhido por já ser o padrão utilizado no framework
Phoenix. O banco de dados consiste em duas tabelas, uma para armazenar as informações das
unidades como nome, endereço, volume máximo e coordenadas, e também um código iden-
tificador da unidade e a outra tabela responsável por armazenar as informações dos sensores,
assim como a data e hora que foram recebidas.

4.1.3.4 Apresentação
Para o módulo Apresentação foi desenvolvido um aplicativo mobile para Android utilizando
o React-Native [rea] um framework para desenvolvimento mobile nativo para Android, IOS e
Windows criado pelo Facebook, essa tecnologia foi escolhida por ser aquela com que o autor
deste trabalho tem mais experiência. O aplicativo conta com basicamente 4 telas, a primeira
tela(Figura 4.9a) é a tela inicial e mostra um mapa com a localização das lixeiras, a data e hora
da última atualização e três botões: Alertas, Unidades e Atualizar. A segunda tela (Figura 4.9d)
 4.2 FUNCIONAMENTO DO SISTEMA 21

Figura 4.8: Fluxograma da arquitetura de software do gateway. Fonte: Autor

pode ser acessada ao ser pressionado o botão de alertas, essa tela mostra em quais unidades
possui um alerta ativo, um alerta é criado quando o volume lido pelos sensores é maior que um
limite pré definido. A terceira tela (Figura 4.9b) é acessada pressionando o botão Unidades,
ela mostra todas as unidades existentes no qual podem ser acessadas ao serem pressionadas,
indo para a quarta e última tela(Figura 4.9c). Nesta tela podem ser vista informações como
localização, endereço e os volumes atuais das lixeiras presentes na unidade, que são mostrados
como uma barra horizontal que vão enchendo de acordo com o volume da lixeira, sendo o verde
quando o volume da lixeira está abaixo de 25% da capacidade máxima, amarelo é quando o
volume está entre 25% e 75% da capacidade máxima e vermelho quando está acima de 75%.

4.2 Funcionamento do Sistema

Após todos os módulos estiverem ligados e operacionais, o sistema funciona da seguinte

maneira: todo o processo começa a partir do gateway, que após inicializado realiza uma trans-
missão via LoRaWAN para a unidade desejada colocando seu endereço e o endereço de destino
no header do pacote a ser enviado e espera uma resposta, caso a resposta não chegue em um
intervalo de 10 segundos, a mensagem é retransmitida, caso contrário o gateway processa a
mensagem recebida verificando se o remetente é da unidade do qual foi requisitado e se o en-
dereço de destino da mensagem é igual ao endereço do gateway, caso afirmativo o payload da
mensagem é lido e descriptografado. Por fim, os valores recebidos são enviados para o ser-
vidor através de uma requisição http, passando como parâmetros o id da unidade e os valores
 4.2 FUNCIONAMENTO DO SISTEMA 22

(a) Tela inicial (b) Unidades

(c) Detalhes (d) Alertas

Figura 4.9: Telas do aplicativo para Android do módulo de apresentação. Sendo a imagem (a),
(b), (c) e (d) das telas principal, unidades, detalhes e alertas, respectivamente. Fonte: Autor

recebidos, repetindo-se todo o processo a cada 10 minutos.

Em relação a placa de sensores o funcionamento é mais simples. Após inicializar os sen-
sores e o chip RFM95 ela fica esperando uma mensagem chegar, a mensagem quando chega
aciona uma interrupção que é tratada imediatamente. No tratamento da interrupção é verificado
se o endereço de destino da mensagem recebida é igual ao endereço da placa e se o remetente da
 4.2 FUNCIONAMENTO DO SISTEMA 23

mensagem é o gateway. Caso essas verificações se confirmem é realizada a leitura dos sensores
ultrassônicos, quanto menor o valor lido, mais cheia estará a lixeira. Caso a distância do lixo
até o sensor seja menor que a distância mínima para o funcionamento do sensor (vide Tabela
4.2), o valor retornado pela leitura do sensor é um valor aleatório maior que 1000, portanto,
essa distância foi adotada como o limite máximo da lixeira, e uma leitura do sensor acima de
1000 indica que a lixeira está cheia. Em seguida o payload da mensagem a ser transmitido é
montado separando-se os valores lidos por “/”. O payload é criptografado utilizando o algo-
ritmo AES128 e o pacote é montado com o endereço de destino do gateway, o endereço da
placa e o payload. Por fim a mensagem é transmitida. Caso a mensagem recebida pela placa
não tenha ela como destinatário a mensagem é retransmitida do mesmo jeito que foi recebida.
O servidor por sua vez fica aguardando uma requisição, podendo ela ser originada do ga-
teway ou do aplicativo de apresentação, caso a requisição seja realizada pelo gateway, a função
do servidor é de basicamente armazenar os valores recebidos no banco de dados. Se for origi-
nalizada pelo aplicativo de apresentação o servidor tem como função responder de acordo com
o que for solicitado pelo aplicativo. O servidor é responsável também por fazer a verificação
dos valores recebidos. Caso esse valor esteja acima de um limite, o servidor envia um alerta
para o aplicativo com as informações da lixeira.
O aplicativo de apresentação funciona da seguinte maneira: ao inicializar o aplicativo é re-
alizada uma requisição ao servidor solicitando os dados de todas as unidades, e na tela inicial é
mostrado um mapa com as localizações das lixeiras através de um marcador. Ao tocar em qual-
quer marcador o aplicativo faz uma requisição ao servidor com o id da unidade selecionada,
que por sua vez responde com as informações da unidade e dos volumes atuais das lixeiras. O
aplicativo então redireciona para a tela da unidade, onde é mostrado os dados da unidade sele-
cionada, como endereço, nome da unidade e os volumes atuais das lixeiras presentes naquela
unidade4.9b. Caso uma lixeira esteja cheia um alerta pode ser visualizado na tela de alertas
4.9d e o marcador da lixeira fica vermelho. Todas as telas podem ser visualizadas na Figura 4.9
acima.
 C APÍTULO 5

Testes e Experimentos

Este capítulo apresenta alguns testes realizados a fim de garantir o funcionamento de cada
parte do sistema e por fim um teste utilizando todas as partes em conjunto

5.1 Placa de Sensores

O primeiro teste realizado tinha como objetivo verificar o funcionamento do circuito pro-
jetado. Para isso, primeiro o circuito da placa foi montado em uma protoboard a fim de testar
os componentes, alimentação, e sinais de entradas e saídas do microcontrolador ATmega328p.
A fim de se economizar energia da bateria, foi decidido utilizar o cristal interno do microcon-
trolador, pois, de acordo com os testes realizados, foi o único que funcionou sem problemas
ao alimentar o microcontrolador com 3.3V. Em seguida foi realizado um teste para verificar o
funcionamento, alcance e precisão dos sensores ultrassônicos, para isso foi feito um programa
em C++ utilizando a IDE do Arduino para realizar a leitura dos sensores em diferentes posi-
ções e distâncias, e os valores foram comparados utilizando-se uma trena, foi observado que
os valores se diferenciavam de no máximo alguns centímetros dependendo da distância, não
ultrapassando 4cm.
Em seguida foi realizado o teste do chip RFM95 com o jetivo de verificar a comunicação
com a placa e seu funcionamento, para isso foram utilizados dois Arduinos uno, um funci-
onando como transmissor e outro como receptor e colocados lado a lado a fim de testar se
realmente estavam funcionando. Após isso o chip RFM95 foi montado numa placa juntamente
com o ATmega, para testar o funcionamento real de como seria o sistema, até então nenhuma
antena estava sendo utilizada e por isso o alcance não passava de 50 metros. Foram realizados
vários testes de alcance com diferentes antenas, entre elas uma antena GPRS, antena de rotea-
dores e uma antena de GPS. Algumas funcionaram melhor que outras, chegando a um alcance
de 400 metros, porém nenhuma foi feita para operar na frequência de 915MHz, foi decidido
adquirir uma antena apropriada para a frequência de operação do LoRa, com isso o alcance
aumentou para mais de 700 metros.
Por fim foi realizado um teste cujo objetivo era avaliar a duração da bateria, primeiramente
foi utilizado uma bateria de 600mAh e 4.2V para alimentar a placa que ficou ligada realizando
leitura dos sensores e enviando as informações para o gateway a cada hora, foi constatado que
a bateria não estava durando mais que 12 horas. Para mitigar este problema foi realizado uma
verificação no código do programa, e foi constatado que o microcontrolador estava realizando
algumas operações desnecessárias além de algumas funções desnecessárias, como conversor
ADC, estarem habilitadas e consumindo energia. Após isso foi testado novamente a bateria,

24
 5.2 GATEWAY 25

porém agora foi dobrado a quantidade de leituras, diminuindo o intervalo para 30 minutos,
foi verificado que a duração da bateria tinha aumentado para 15 horas. Como a placa seria
alimentada por uma placa solar de 24V foi decidido que 15 horas seriam suficientes, mas,
mesmo assim, foi decidido aumentar a bateria para 1200mAh. Os resultados obtidos, além do
custo aproximado da produção da placa podem ser conferidos na Tabela 5.1 abaixo.

Parâmetro Valor
Bateria 600mAh 15 horas
Bateria 1200 mAh ± 30 horas
Alcance obtido ±700 metros
Custo aproximado R$380,00

Tabela 5.1: Característica do sistema da placa de sensores

5.2 Gateway

Para o gateway foram realizados testes com objetivo de testar a comunicação SPI com o
chip RFM95. Primeiro foi preparado um Raspberry Pi 3 Model B com o sistema operacio-
nal Raspbian Lite. Em seguida foi feita a instalação de todos os pacotes necessários para o
funcionamento do sistema. Um dos pacotes instalados foi o SX127x, responsável por fazer
a comunicação com o chip RFM95. Depois de instalar e fazer a configuração do pacote, foi
verificado que o chip não estava sendo reconhecido, e ao investigar as conexões do chip foi
percebido que uma das conexões SPI do chip não estavam em contato com o Raspberry Pi.
Outro problema encontrado foi a necessidade de se ativar a comunicação SPI no Raspberry,
pois ela vem desabilitadas por padrão. Utilizando-se o comando "sudo raspi-config"é possível
entrar na ferramenta de configuração do Raspberry Pi(Figura 5.1) e através da opção 5 é pos-
sível ativar a comunicação SPI e também outras formas de comunicação como Serial, I2C e
SSH, que também foi ativada.
Após a habilitação do SPI o chip foi reconhecido como deveria. Em seguida foi configu-
rada a conexão com a internet, que também pode ser realizada utilizando comando mostrado
anteriormente, porém agora na opção 2 (Network Options), onde será solicitado o país, o SSID
e a senha. Após todas as configurações do sistema terem sido realizadas foi testado o funcio-
namento do chip RFM95 em conjunto com a placa de sensores utilizando-se o pacote SX127x
para a linguagem Python versão 3.5.
Para o teste do gateway foi criado um script em Python responsável por enviar uma mensa-
gem para a placa de sensores, localizada a poucos metros de distância, a mensagem consistia
da palavra "Hello"juntamente com um número, que ao ser recebida pela placa de sensores
respondia com a mesma mensagem, porém incrementando o número final. A mensagem era
transmitida a cada 10 segundos. Após 10 minutos não foi constatado perda na transmissão,
por isso foi resolvido aumentar a distância entre o gateway e a placa e mais uma vez testar
o alcance, após separar aproximadamente 700 metros (Figura 5.2) foi constatado as primeiras
perdas, resultado semelhante ao obtido pela placa de sensores.
 5.2 GATEWAY 26

Figura 5.1: Tela de configuração do Raspberry Pi. Fonte: Autor

Figura 5.2: Teste do alcance da comunicação do gateway com a placa de sensores. O ponto
0, a esquerda, é a localização do gateway e o ponto final é a localização da placa de sensores.
Fonte: Autor
 5.3 SERVIDOR 27

5.3 Servidor

Para o teste do servidor foram realizadas 3 requisições, cadasto, modificação e remoção

de uma unidade, sendo a primeira o cadastro de uma unidade de testes, que funcionou sem
nenhum problema. Em seguida foram repetidas as três requisições, sendo feita uma tentativa
de adicionar uma unidade com o mesmo nome e endereço da unidade adicionada anteriormente,
na expectativa de que daria um erro, pois não deveria poder existir duas unidades com o mesmo
nome e endereço, porém a unidade foi cadastrada com sucesso devido a um erro na criação
da tabela de unidades que não estavam com os campos Nome e Endereço como "UNIQUE",
parâmetro necessário para que só exista uma única instância com uma determinada combinação
de nome e endereço. Aproveitando-se do erro anterior, foi testada a requisição de exclusão
de uma unidade, que também funcionou sem nenhum problema, pois a exclusão é realizada
passando-se um identificador da unidade que é criado automaticamente na hora de sua inserção.
Após a correção do erro anterior, não foram mais encontrados nenhum problema na tabela de
unidades.
Tendo as requisições de inserção, alteração e exclusão de unidades funcionado como es-
perado, foi a vez de se testar a tabela de Eventos, responsável por armazenar as informações
provindas dos sensores e enviadas pelo gateway, essas requisições também funcionaram sem
problemas, e a Figura 5.3 abaixo mostra as informações armazenadas, como os volumes das li-
xeiras, os dados da unidade, o volume máximo da lixeira e a data e hora que ocorreu a inserção.

Figura 5.3: Teste de inserção de dados na tabela de eventos do banco de dados. Fonte: Autor
 C APÍTULO 6

Conclusão e Trabalhos Futuros

6.1 Conclusão

Neste trabalho foi proposto um sistema de monitoramento de volume de resíduos de uma

lixeira utilizando a tecnologia LoRaWAN. Esse sistema foi composto por uma placa de senso-
res responsável por fazer a captação dos dados e envio das informações via LoRa, um gateway
responsável por fazer a requisição dos dados a um intervalo de tempo definido e enviar as in-
formações recebidas para um servidor responsável por armazenar os dados, e, por fim, uma
aplicação Android responsável por exibir informações das lixeiras como localização e os vo-
lumes em tempo real. O LoRaWAN funcionou como uma ótima alternativa ao GSM, pois é
mais barato e não necessita de um plano de dados, apenas uma conexão com a internet para o
gateway. Uma das principais dificuldades encontradas no trabalho proposto foi em relação ao
alcance de comunicação do sistema, que depende de váios fatores, como topografia do relevo,
antena utilizada, posição da antena e parâmetros utilizados na configuração do chip. Foi pos-
sível observar que o uso de antenas incompatíveis com a frequência utilizada reduz o alcance
do sistema, sendo recomendado sempre o uso de uma antena apropriada. O sistema proposto
está, até a data de escrita deste trabalho, em funcionamento sem nenhum problema detectado,
operando 24 horas por dia na lixeira subterrânea da praça Alencastro em frente a prefeitura de
Cuiabá, com previsão de implantação de mais 2 unidades.

6.2 Trabalhos Futuros

A partir do sistema desenvolvido é possível obter informações importantes a partir do histó-

rico que é armazenado. Utilizando alguma técnica de aprendizagem é possível prever melhores
horários para se fazer a coleta e prever o volume de lixo em determinada hora do dia, e utili-
zando a localização das unidades, é possível gerar rotas e otimizar trajetos, etc. Além disso o
próprio sistema ainda pode ser melhorado, aumentando-se o alcance de comunicação é possí-
vel cobrir uma área maior utilizando-se um único gateway, podendo ser feita também uma rede
Mesh para ampliar o alcance.

28
 Referências Bibliográficas

[ap3] Antena mÓvel uhf 5/8 de onda whip 900 mhz - ap3900-ap39001-ap39002. Acessado
em 15 de Junho de 2019, https://www.steelbras.com.br/produto/antena-movel-uhf-
58-de-onda-whip-900-mhz/.

[ard] Arduino aeslib. Acessado em 15 de Junho de 2019,

https://github.com/DavyLandman/AESLib.

[atm] Atmega328p. Acessado em 10 de Junho de 2019,

https://www.microchip.com/wwwproducts/en/ATmega328P.

[BR17] Martin Bor and Utz Roedig. Lora transmission parameter selection. 06 2017.

[dT18] Agência Nacional de Telecomunicações. Resolução radiofrequên-

cia, December 2018. Acessado em 03 de Junho de 2019,
http://www.anatel.gov.br/legislacao/resolucoes/2018/1220-resolucao-705.

[eag] Eagle pcb design made easy. Acessado em 10 de Junho de 2019,

https://www.autodesk.com/products/eagle/overview.

[elx] Elixir language. Acessado em 15 de Junho de 2019, https://elixir-lang.org.

[Fra18] FragMaq. Descubra a quantidade de lixo produzido no brasil e a

porcentagem do que é reciclado, March 2018. Acessado em 03 de
junho de 2019, https://www.fragmaq.com.br/blog/descubra-quantidade-de-lixo-
produzido-no-brasil-e-porcentagem-do-que-e-reciclado/.

[hop] Hoperf. Acessado em 18 de Junho de 2019, https://www.hoperf.com/.

[jsn] Datasheet jsn-sr04t. Acessado em 18 de Junho de 2019,

https://www.jahankitshop.com/getattach.aspx?id=4635Type=Product.

[Lin16] LinkLabs. A COMPREHENSIVE LOOK AT Low Power, Wide Area

Networks For ‘Internet of Things’ Engineers and Decision Makers. Lin-
kLabs, 130 Holiday Court, Suite 100, Annapolis, MD 21401, 1 edition, 2016.
http://cdn2.hubspot.net/hubfs/427771/LPWAN-Brochure-Interactive.pdf.

[lor] Arduino-lora. Acessado em 15 de Junho de 2019,

https://github.com/sandeepmistry/arduino-LoRa.

29
 REFERÊNCIAS BIBLIOGRÁFICAS 30

[Mel17] Pablo Melo. Introdução ao LPWAN (Low Power Wide Area Network), January 2017.
Acessado em 03 de Junho de 2019, https://www.embarcados.com.br/introducao-ao-
lpwan/.

[nov] novida. Rede lora: o que é e quais são as aplicações? Acessado em 03 de Junho de
2019, https://novida.com.br/blog/rede-lora.

[phx] Phoenix framework. Acessado em 15 de Junho de 2019,

https://phoenixframework.org/.

[pyc] Pycrypto. Acessado em 15 de Junho de 2019, https://github.com/dlitz/pycrypto.

[ras] Raspberry pi 3 model b. Acessado em 10 de Junho de 2019,

https://www.raspberrypi.org/products/raspberry-pi-3-model-b/.

[rea] React native. Acessado em 15 de Junho de 2019, https://facebook.github.io/react-

native/.

[rfm] Rfm95/96/97/98(w) - low power long range transceiver module. Acessado em 10

de Junho de 2019, https://www.digikey.com/en/datasheets/rf-solutions/rf-solutions-
rfm95_96_97_98w.

[Sac14] Francesco Sacco. Comunicação spi – parte 1, May 2014. Acessado em 03 de Junho
de 2019, https://www.embarcados.com.br/spi-parte-1/.

[Sam17] Fady Samann. The design and implementation of smart trash bin. Academic Journal
of Nawroz University, 6:141–148, 01 2017.

[SMB16] Tarandeep Singh, Rita Mahajan, and Deepak Bagai. Smart waste management using
wireless sensor network. International Journal of Innovative Research in Computer
and Communication Engineering, 4:10343–10347, June 2016. Acessado em 10 de
Junho de 2019.

[Sta01] Federal Information Processing Standards. Announcing the ADVANCED

ENCRYPTION STANDARD (AES). National Institute of Standards and
Technology, November 2001. Acessado em 10 de Junho de 2019,
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf.

[sx1] Python lora. Acessado em 15 de Junho de 2019,

https://github.com/rpsreal/pySX127x.

[tp4] Tp4056 1a standalone linear li-lon battery charger with ther-

mal regulation in sop-8. Acessado em 10 de Junho de 2019,
https://dlnmh9ip6v2uc.cloudfront.net/datasheets/Prototyping/TP4056.pdf.
Este volume foi tipografado em LATEX na classe UFPEThesis (www.cin.ufpe.br/~paguso/ufpethesis).