0% acharam este documento útil (0 voto)

13 visualizações73 páginas

TCC Nathalia

Enviado por

natalia

Direitos autorais

Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.

Formatos disponíveis

Baixe no formato PDF, TXT ou leia on-line no Scribd

0% acharam este documento útil (0 voto)

13 visualizações73 páginas

TCC Nathalia

Enviado por

natalia

Direitos autorais

Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.

Formatos disponíveis

Baixe no formato PDF, TXT ou leia on-line no Scribd

UNIVERSIDADE FEDERAL DO AMAZONAS

FACULDADE DE TECNOLOGIA
GRADUAÇÃO EM ENGENHARIA ELÉTRICA

Desenvolvimento de um sistema sem fio aplicável ao monitoramento da água

de rios e lagos

Nathalia Damasceno Colares

MANAUS-AM
2024
Nathalia Damasceno Colares

Desenvolvimento de um sistema sem fio aplicável ao monitoramento da água de rios e

lagos

Trabalho de Conclusão de Curso apresen-

tado a Coordenação do Curso de Engenha-
ria Elétrica - Telecomunicações da Universi-
dade Federal do Amazonas, como parte das
exigências para a obtenção do tı́tulo de En-
genheira de Telecomunicações.

Orientador: Prof. Dr. Celso Barbosa Carvalho

MANAUS-AM
2024
Ficha Catalográfica
Ficha catalográfica elaborada automaticamente de acordo com os dados fornecidos pelo(a) autor(a).

Colares, Nathalia
C683d Desenvolvimento de um Sistema sem Fio Aplicável ao
Monitoramento da água em Rios e Lagos / Nathalia Colares . 2024
73 f.: il. color; 31 cm.

Orientador: Celso Barbosa Carvalho

TCC de Graduação (Engenharia Elétrica - Telecomunicações) -
Universidade Federal do Amazonas.

1. LoRa. 2. Qualidade da água. 3. React Native. 4. Temperatura.

5. pH. I. Carvalho, Celso Barbosa. II. Universidade Federal do
Amazonas III. Título
Nathalia Damasceno Colares

Desenvolvimento de um sistema sem fio aplicável ao

monitoramento da água em rios e lagos

Trabalho de Conclusão de Curso apresentado a

Coordenação do Curso de Engenharia Elétrica -
Telecomunicações da Universidade Federal do
Amazonas, como parte das exigências para a
obtenção do título de Engenheira de
Telecomunicações.

Aprovado em 29 de julho de 2024.

BANCA EXAMINADORA

________________________________________
Orientador(a)
Prof. Dr. Celso Barbosa Carvalho - UFAM

________________________________________
Examinador Interno(a)
Prof. Dr. Frederico da Silva Pinagé - UFAM

________________________________________
Examinador Interno(a)
Prof. MsC. Ademir de Jesus Lourenço - UFAM
Agradecimentos

Agradeço primeiramente a Deus pelo dom da vida e por ofertar toda a força para
buscar meus objetivos. Minha total gratidão aos meus pais, Arlindo e Adriana, por
sempre me proporcionar a oportunidade de estudar e crescer na vida, com humildade e
sabedoria.
Agradeço também ao meu professor orientador, Celso Carvalho, por todos os ensi-
namentos, paciência, conselhos e suporte durante o desenvolvimento deste trabalho que
foram imprescindı́veis para o projeto.
À instituição que ofereceu infraestrutura e apoiaram a pesquisa como: o Centro de
PD em Eletrônica e Tecnologia da Informação da Universidade Federal do Amazonas
(Ceteli-UFAM);
Aos meus queridos amigos, Lukas Moreira, Carlos Gabriel, pela grande amizade ao
longo de toda a graduação. Ao meu namorado, Raphael Nunes, pela paciência e todo
apoio.
Aos professores e demais servidores da Universidade Federal do Amazonas (UFAM)
pela contribuição em meu aprendizado.
Resumo

Foi desenvolvido neste trabalho de conclusão de curso um sistema de hardware e soft-

ware o qual utiliza sensores de baixo custo para monitorar a qualidade da água, através
dos parâmetros de água e pH, de rios ou lagos. Para tal, foi utilizado a tecnologia LoRa,
com a topologia Ponto a Ponto, que é capaz de transmitir dados em até 15Km em zonas
rurais. O sistema conta com uma aplicação mobile, criada com React Native, que sin-
croniza com o Banco de dados Firebase em tempo real e exibe para o usuário de forma
simples e prática, também possibilitando o mesmo acesso ao histórico das leituras. Foram
realizados testes dentro da Universidade Federal do Amazonas para validar o alcance e
qualidade do sinal LoRa, e utilizou-se amostras de água da Ponta Negra, Ponta Negra,
para validar o monitoramento de parâmetros da água, coletada na praia da Ponta Negra.
As medições foram comparadas com os resusltados de uma pesquisa realizada pelo INPA
e UFAM nas águas da região Amazônica. O sistema provou ser viável e preciso, além de
ser de baixo custo, para ser implemetado em locais remotos para monitorar a qualidade
da água.

Palavras-chave: LoRa, Qualidade da água, React Native, temperatura, pH.

Abstract

In this research project, a hardware and software system was developed using low-cost
sensors to monitor the water quality of rivers and lakes using water and pH parameters.
To do this, LoRa technology was used, with a point-to-point topology, which is capable
of transmitting data up to 15 km in rural areas. The system has a mobile application,
created with React Native, which synchronizes with the Firebase database in real time
and displays it to the user in a simple and practical way, also giving them access to the
history of the readings. Tests were carried out at the Federal University of Amazonas
to validate the range and quality of the LoRa signal, using water samples from the Rio
Negro, collected at Ponta Negra beach. The measurements were compared with studies
carried out on rivers throughout the Amazon region. The system proved to be viable
and accurate, as well as being low-cost enough to be implemented in remote locations to
monitor water quality.

Keywords: LoRa, Water quality, React Native, temperature, pH .

Lista de Figuras

3.1 Comparação entre tecnologias sem fio . . . . . . . . . . . . . . . . . . . . . 5

3.2 Comparação de LoRa Spreading Factor: SF 7 a SF 12 . . . . . . . . . . . 6
3.3 Topologias de rede LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Pinagem da ESP32 LILYGO LORA 915MHz . . . . . . . . . . . . . . . . . 10
3.5 Sensor de temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6 Sensor de pH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7 Estrutura de Banco de dados NoSQL . . . . . . . . . . . . . . . . . . . . . 15
3.8 Arquitetura do React Native . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 Fluxograma de funcionamento do protótipo . . . . . . . . . . . . . . . . . 20

4.2 Esquema elétrico do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Protótipo montado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Bateria LiPo 31865 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Teste de funcionamento do sensor de temperatura . . . . . . . . . . . . . . 25
4.6 Resultado da leitura do sensor de temperatura . . . . . . . . . . . . . . . . 25
4.7 Resultado da leitura do sensor de temperatura . . . . . . . . . . . . . . . . 26
4.8 Medição de tensão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.9 Medição das tensões com sensor PH4502C . . . . . . . . . . . . . . . . . . 28
4.10 Módulo LILYGO enviando pacotes . . . . . . . . . . . . . . . . . . . . . . 30
4.11 Variável readingID após o modo Deep Sleep . . . . . . . . . . . . . . . . 31
4.12 Variável readingID após reset forçado . . . . . . . . . . . . . . . . . . . . 32
4.13 Dados sendo reenviados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.14 Console do Firebase Realtime Database . . . . . . . . . . . . . . . . . . . . 37
4.15 Métodos de Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.16 Cadastro de regras do banco . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.17 Caminho do Realtime Database . . . . . . . . . . . . . . . . . . . . . . . . 40
4.18 Processo de atualização da aplicação . . . . . . . . . . . . . . . . . . . . . 41
4.19 Telas iniciais do ClearFlow Sentinel . . . . . . . . . . . . . . . . . . . . . . 42
4.20 Telas com leituras dos sensores . . . . . . . . . . . . . . . . . . . . . . . . 43
4.21 Telas do ClearFlow Sentinel . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1 Distância do Teste 1 entre transmissor e receptor . . . . . . . . . . . . . . 47

i
LISTA DE FIGURAS ii

5.2 Visualização das leituras no ClearFlow Sentinel . . . . . . . . . . . . . . . 48

5.3 Distância do Teste 2 entre transmissor e receptor . . . . . . . . . . . . . . 49
5.4 Visualização das leituras no ClearFlow Sentinel . . . . . . . . . . . . . . . 50
5.5 Coleta de água na Praia da Ponta Negra . . . . . . . . . . . . . . . . . . . 51
5.6 Medição da temperatura e pH . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.7 Módulo receptor TTGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.8 Exibição dos dados no aplicativo ClearFlow . . . . . . . . . . . . . . . . . 53
Lista de Tabelas

3.1 Especificações do módulo LILYGO/TTGO . . . . . . . . . . . . . . . . . . 9

3.2 Especificações do sensor DS18B20 . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Especificações do sensor PH4502C . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 Custo de equipamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Pinagem do sensor DS18B20 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Pinagem do sensor PH4502C . . . . . . . . . . . . . . . . . . . . . . . . . . 26

iii
Lista de Abreviaturas e Siglas

LoRa Long Range

IOT Internet of Things
CSS Chirp Spread Spectrum
IDE Integrated Development Environment
CR Code Rate
SF Spread Factor
BW Band Width
SPI Serial Peripheral InterfacE
GPIO General Purpose Input/Output
ADC Analog to Digital Converter
JSON Javascript Object Notation
SQL Structured Query Language
NoSQL Not Only SQL
SPIFFS SPI Flash File System
HTTP Hypertext Transfer Protocol
API Application Programming Interface
SDK Software Development Kit
UID SPI User Identification

iv
Sumário

1 Introdução 1

2 Objetivos 3
2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Objetivos Especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Fundamentação Teórica 4
3.1 Tecnologia LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 Modulação Chirp Spread Spectrum . . . . . . . . . . . . . . . . . . 5
3.1.2 Topologia Básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Módulo LILYGO/TTGO LoRa 915MHz . . . . . . . . . . . . . . . . . . . 8
3.3 Sensor de temperatura encapsulado DS18B20 . . . . . . . . . . . . . . . . 10
3.4 Sensor de pH PH4502C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Banco de dados Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Expo Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7 React Native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Metodologia 20
4.1 Arquitetura do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Microcontrolador e sensores . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 DS18B20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 PH4502C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5 Microcontrolador Transmissor LILYGO . . . . . . . . . . . . . . . . . . . . 30
4.6 Microcontrolador Receptor TTGO . . . . . . . . . . . . . . . . . . . . . . . 32
4.7 Plataforma de programação Visual Studio Code . . . . . . . . . . . . . . . 34
4.8 Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.9 Firebase Realtime Database . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.9.1 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.9.2 Cadastro de Regras . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.9.3 Sincronização dos dados . . . . . . . . . . . . . . . . . . . . . . . . 39
4.10 Desenvolvimento do aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . 40

v
SUMÁRIO vi

5 Cenários de teste e Resultados 46

5.1 Teste de alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.1 Teste de alcance na Faculdade de Tecnologia . . . . . . . . . . . . . 46
5.1.2 Teste de alcance no Setor Sul do Campus . . . . . . . . . . . . . . . 48
5.2 Teste de medição dos sensores . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Conclusão 54

Referências Bibliográficas 55

A Código principal 59
A.0.1 Módulo transmissor . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.0.2 Módulo receptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B Aplicativo 60
B.0.1 Código em React Native . . . . . . . . . . . . . . . . . . . . . . . . 60
Capı́tulo 1

Introdução

A água é uma substância necessária para a vida no planeta. A água doce, que compõe
rios e lagos, representa uma pequena porcentagem, cerca de 2% apenas no planeta. Elas
são as responsáveis pela origem dos alimentos e por manter a biodiversidade, como explica
Tundisi (2024).
Uma das maiores bacias hidrográficas do planeta, as águas dos rios Amazônicos, estão
sendo contaminados, é o que informa Chamorro (2021). Além da poluição já bem conhe-
cida nos igarapés da cidade de Manaus, há outro tipo de poluição muito mais perigosa e
pouco discutida, que é a contaminação quı́mica causada por agrotóxicos, microplásticos,
rejeitos farmacêuticos e o mais perigoso de todos, contaminação por mercúrio, devido ao
garimpo ilegal.
De acordo com Veiga (2023), o rio Madeira localizado na cidade de Manicoré, a apenas
331 Km da capital Amazonense, vem sofrendo severamente com o garimpo ilegal nos
últimos anos, o qual vem sendo intensificado as margens do rio. A problemática vem do
impacto a saúde pública, causado indiretamente do garimpo, que contamina as águas e
os peixes.
Um estudo realizado por Basta et al.(2023) entre diversos institutos como Fiocruz,
Iepé, Greenpeace, Instituto Socioambiental e World Wide Fund for Nature Brasil, avaliou
17 municı́pios da região amazônica, e mostrou que cerca de 21,3% dos peixes comercia-
lizados para consumo, apresentam nı́veis de Mercúrio acima do limite estabelecido pela
Organização para Alimentação e Agricultura das Nações Unidas (WHO).
O trabalho de Basta et al.(2023) ainda explica, que outro fator decisivo são os perı́odos
de estiagem, em algumas cidades ribeirinhas como Manicoré, o saneamento básico é de-
ficiente. O abastecimento de água é ofertado para apenas 44,43% da população. Nesse
perı́odo é notado números elevados de doenças agudas.
O estudo de Abregat-Safont et al.(2021) fez uma investigação a prevalência de farmacos
e drogas ilı́citas nos ecosistemas de água doce na Amazônia brasileira. A pesquisa utilizou
amostras do Rio Amazonas, em afluentes que cruzam os municı́pios de Manaus, Santarém,
Macapá e Belém. O estudo identificou cerca de 51 amostras de compostos metabólicos,
sendo a maioria das categorias de analgésicos, antibióticos e intorpecentes.

1
CAPÍTULO 1. INTRODUÇÃO 2

O monitoramento da qualidade da água é de extrema importância para garantir a

saúde pública e a preservação ambiental.
Sendo assim, o desenvolvimento de um sistema embarcado de monitoramento da qua-
lidade da água aplicável a locais remotos é fundamental, uma vez que pode possibilitar a
coleta de dados em tempo real em áreas de difı́cil acesso, facilitando a detecção precoce
de mudanças na qualidade da água. Tais capacidades do sistema são importantes para a
tomada de decisões rápidas e informadas, com o objetivo de mitigar impactos ambientais
e proteger a saúde humana. No presente trabalho, foi desenvolvido um sistema embar-
cado sem fio e aplicativo Android, aplicável ao monitoramento de águas de rios. Para
avaliar a proposta, foram realizados experimentos de qualidade de comunicação LoRa no
Campus da UFAM e, foram conduzidos experimentos de análise da água em laboratório
com amostras coletadas do Rio Negro, fornecendo uma base controlada para avaliação e
desenvolvimento da proposta.
Com o desenvolvimento do sistema, foi possı́vel constatar a viabilidade técnica de
utilizar tecnologias de transmissão sem fio para monitoramento da qualidade da água em
rios. Os resultados obtidos demonstraram que o sistema é capaz de coletar e transmitir
dados de temperatura e pH de forma precisa em condições controladas de laboratório.
Esta constatação abre caminho para futuras validações em campo, onde a robustez e
aplicabilidade do sistema poderão ser avaliadas em cenários reais, contribuindo para a
gestão sustentável de recursos hı́dricos e a proteção ambiental na região amazônica. Os
códigos desenvolvidos na pesquisa foram disponibilizados em repositório na Internet, a
fim de que outros estudantes ou pesquisadores possam aprimorar o trabalho realizado,
contribuindo assim, para o avanço cientı́fico e tecnológico.
Capı́tulo 2

Objetivos

2.1 Objetivo Geral

O presente trabalho tem como finalidade o desenvolvimento, e avaliação em ambientes
controlados, de um sistema embarcado e aplicativo Android aplicável ao monitoramento
em tempo real da temperatura e o pH da água em rios e lagos, utilizando a o protocolo
de comunicação sem fio LoRa para a transmissão de dados e o banco de dados Firebase
para o armazenamento e gerenciamento das informações coletadas.

2.2 Objetivos Especı́ficos

• Desenvolver um sistema embarcado composto de sensores e capaz de coletar dados
dos parâmetros temperatura e pH da água;

• Transmitir os dados coletados para um dispositivo receptor utilizando protocolo de

comunicação LoRa;

• Armazenar os dados do parâmetros da água monitorada em um banco de dados;

• Desenvolver uma aplicação Android utilizando tecnologia React Native e, capaz de

apresentar, em tempo real aos usuários, informações dos parâmetros temperatura e
pH da água sendo monitorados;

• Avaliar o desempenho da distância de comunicação LoRa no campus da UFAM.

• Avaliar o desempenho de medição dos parâmetros de temperatura e pH da água,

em um ambiente controlado.

3
Capı́tulo 3

Fundamentação Teórica

Neste capı́tulo, serão abordados os temas fundamentais para o desenvolvimento deste

trabalho, como os recursos de harware e software, e a aplicação onde será exibida os dados.

3.1 Tecnologia LoRa

A tecnologia LoRa, abreviação de Long Range, é uma tecnologia de transmissão wire-
less, a qual funciona por meio de radio frequência, desenvolvida pela Semtech que permite
estabelecer comunicação entre longas distâncias, com um consumo de energia baixo. Os
chipsets conectam sensores a nuvem e possibilitam uma comunicação em tempo real de
dados. Lora possibilita aumentar a eficiência e implementar em soluções IoT.(Semtech,
2021)
Para utilizar-se o LoRa, três caracterı́ticas devem ser atendidas, são elas:

• Baixo consumo de energia necessário

• Longo alcance de sinal

• Largura de banda

Como largura de banda e a capacidade máxima de transmissão de um canal estão

intrinsecamente relacionadas, para atingir um baixo consumo de energia e máximo alcance
do sinal, o LoRa estabelece um protocolo de comunicação que limita a largura de banda.
O tempo de transmissão de cada dispositivo é controlado, por isso que projetos que
necessitem uma alta taxa de transmissão de dados, o Lora deixa de ser adequado. Já
para algumas leituras que precisam ser realizada com o intervalo de alguns minutos por
exemplo, o Lora garante que os dados sejam transmitidos por longos perı́odos de tempo.
(Alfacomp, 2023)
Tratando-se de comunicação sem fio, um receptor necessita de um sinal forte e de uma
bola relação sinal-ruı́do para separar o sinal original da portadora. Os dois indicadores
de força do sinal mais utilizados são o RSSI e SNR. (Tapadyuti, 2023)

4
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 5

A Figura 3.1 mostra a comparação entre os diferentes tipos de comunicação sem fio e
o seu alcance.
O RSSI, que é a sigla para Received Signal Strength Indicator, é uma medida de
ajuda a determinar se o sinal recebido é forte o bastante para manter a comunicação
entre transmissor e receptor. Medido em dBm, quanto mais próximo de zero for o sinal
recebido, melhor. (The Things Network, 2024)
O SNR, sigla para Signal-to-Noise Ratio, é a relação entre a potência do sinal e o nı́vel
de ruı́do, como dito anteriormente, é um dos parâmetros mais utilizados para determinar
a qualidade do sinal. (The Things Network, 2024)

Figura 3.1: Comparação entre tecnologias sem fio

Fonte: Alfacomp (2023)

Existem diversas frequências utilizadas pelo LoRa ao redor do mundo: 433 MHz, 868
MHz e 915 MHz. A faixa de frequência que a ANATEL libera para uso livre no Brasil é
entre 902 a 928 MHz.(Teleco, 2021)

3.1.1 Modulação Chirp Spread Spectrum

O LoRa, é uma técnica de modulação de espectro de espalhamento, isso ocorre quando

uma onda de rádio é manipulada para codificar informações utilizando um formato chilre-
ado (CSS). Desenvolvida para aplicações em radar. Os sinais de Chirp possuem amplitude
constante e percorrem toda a largura de banda, variando sua frequência de forma linear
em um determinado tempo. (Giserman;Galves;Jaolino, 2019)
O Chirp é um sinal cuja freqênica aumenta ou diminui de maneira linear ao longo
do tempo. No CSS, os Chirps ascendentes, denominados de Up-chirps, e os descendetes,
também conhecidos por Down-chirps, são utilizados para codificados os dados, eles con-
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 6

ferem uma excelente sensibilidade do receptor e resistência à interferências. As técnicas

que compôe que CSS obtenha tamanha vantagem na transmissão dos dados, é a Largura
de Banda, e a resistividade do sinal ao efeito Doppler. O LoRa utiliza três larguras de
bandas: 125 KHz, 250 KHz e 500 KHz. (Giserman;Galves;Jaolino, 2019)

Figura 3.2: Comparação de LoRa Spreading Factor: SF 7 a SF 12

Fonte: (Tapadyuti, 2023)

O Spreading Factor, é outro parâmetro de suma importância para a modulação LoRa,

pois define a quantidade de espalhamento espectral aplicado ao sinal, isso influência dire-
tamente na robustez do sinal e na taxa de dados. A partir da figura 3.2, podemos observar
os fatores de espalhamento, e seu desempenho na frequênica pelo tempo. Um SF maior,
como de 12 por exemplo, aumenta proporcionalmente o alcance e a robustez do sinal,
porém reduz a taxa de dados, isso é occore pois mais bits são transmitidos por sı́mbolo,
tornando a comunicação mais forte. (Tapadyuti, 2023)
Em compensação um SF de 7, permite uma taxa de dados mais alta, porém implica em
um alcance de sinal menor e menos resistente a ruı́dos. Outro ponto que vale considerar
na escolha do SF, é o consumo de energia. Um SF menor, necessita de menos energia para
transmitir dados, diferentemente de um SF maior, isso é devido ao tempo de transmissão
que cada SF requer para completar o envio dos dados. (Tapadyuti, 2023)
A equação 3.1 abaixo, mostra o cáculo da taxa de transmissão de bits, relacionando o
fator de espalahamento utilizado e a largura de banda.
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 7

1
Rb = SF · 2SF
[bits/s] (3.1)
BW

Já a equação 3.2 abaixo, refere-se ao cáculo do tempo de transmissão de bits, com ela,
é possı́vel determinar a frequência se os parâmetros de fator de espalhamento e largura
de banda correspondem as necessidades de projeto.

2SF
Ts = [s] (3.2)
BW

3.1.2 Topologia Básica

A escolha da topologia mais adequada a um sistema com LoRa, deve levar em con-
sideração o alcance a cobertura da rede, escalabilidade e consumo de energia. O LoRa
suporta quatro topologias de rede bastante comuns, são elas:

Figura 3.3: Topologias de rede LoRa

(a) Ponto a Ponto (b) Multiponto (c) Estrela (d) Mesh

Fonte: InternationalIT (2022), adaptado.

• Ponto a Ponto: conecta dois dispositivos de comunicação com apenas um link, o

que é chamado de unicast, ou seja, há um link direcionado entre um par - transmissor
e receptor - especı́fico. É bastante utilizada principalmente por ser simples, quando
há necessidade de conectividade em dois dispositivos entre si, e não é necessário a
divisão da banda utilizada, garantindo uma estabilidade na conexão. Como pode
ser visto na Figura 3.3-a. (DCA, 2022).

• Multiponto: é utilizada quando é necessário estabelecer comunicação entre dois

ou mais dispositivos, porém neste caso, um único link é enviado para todos os
dipositivos, desta forma, a largura de banda é dividida entre todos os dispositivos
na rede. Como pode ser visto na Figura 3.3-b. (DCA, 2022).
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 8

• Estrela: também uma configuração bastante comum, nesta configuração a rede é

organizada com que todos os dispositivos estejam conectados entre uma central, que
atua como servidor. Essa central é responsável pelo gerenciamento das transmissões
de dados pela rede. Como pode ser observado na Figura 3.3-c. (Internationa-
lIT,2022).

• Mesh: Nesta configuração de rede, todos os dispositivos estão interconectados di-

retamente, o que oferece como consequência, diversos caminhos para entregar os
dados. Sempre utilizando o caminho mais curto disponı́vel para a transmissão. A
rede Mesh garante com que nenhum dispositivo da rede fique desconectado, além
de ser estável. A Figura 3.3-d exibe esta topologia. (InternationalIT,2022).

3.2 Módulo LILYGO/TTGO LoRa 915MHz

O Esp32 LoRa LILYGO é um módulo bastante disseminado para projetos eletrônicos e
embarcados, que possui três formas de comunicação: WiFi, Bluetooth e LoRa em apenas
um módulo. Conta com um microprocessador dual-core Xtensa 32-bits LX6 com baixo
consumo de energia, além de dois núcleos de CPU, uma memória de 520KB de SRAM e
4MB de memória Flash. (MakerHero, 2024).
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 9

Tabela 3.1: Especificações do módulo LILYGO/TTGO

Especificações técnicas Valor Unidade

Tensão de alimentação 5 Volts
Faixa de medição -40 a 85° °C
Precisão ±0,5 °C
Dimensão do cabo 90 cm
Corrente máxima fornecida 500 mA
Corrente máxima suporta pela GPIO 40 mA
Potência de transmissão +20 dBm
Sensibilidade do receptor 118 a 139 dBm
Frequência de operação 915 MHz
Corrente em modo sleep 0.2 uA
Entrada da bateria 3.7 a 4.2 V
Fonte: UsinaInfo (2023)

A partir da tabela 3.1 acima, pode-se analisar as especificações da placa LILYGO/TTGO,

por conta dessas caracterı́sticas fundamentais, foi escolhido o seguinte módulo.
Partindo para comunicação LoRa possui integrado o chip SX1276 da Semtech, que
opera na frequência de 915 MHz, além de suportar também as modulações Spread Spec-
trum, FSK, GFSK, MSK, GMSK. Além disso, consegue ser utilizada em uma gama de
sensores por conter portas analógicas e digitais. Na Figura 3.4 abaixo podemos observar
a distribuição dos pinos da LILYGO.
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 10

Figura 3.4: Pinagem da ESP32 LILYGO LORA 915MHz

Fonte: UsinaInfo(2023)

Os módulos ESP32, possuem o sistema de gerenciamento de arquivos SPI, que pode

ser acessado através da biblioteca SPIFFS, que viabiliza utilizar a memória Flash para
ler, gravar e excluir arquivos, onde é necesssário armazenar arquivos de forma persistente.
Além de serem bem versáteis e de fácil programação, pois podem ser configurados em
IDE’s como Arduino ou PlatformIO, que é uma extensão do Visual Studio Code. (Miller,
2021).

3.3 Sensor de temperatura encapsulado DS18B20

O sensor de temperatura DS18B20 é um componente desenvolvido para ser utilizado
em diversos ambientes, capaz de realizar leituras entre -55°C a 125°C. Possui uma interface
de comunicação de apenas um único fio, conhecida como One Wire, que possibilita integrar
diversos sensores de temperatura em uma única saı́da do microcontrolador. A figura 3.5
mostra o sensor utilizado.
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 11

Figura 3.5: Sensor de temperatura

Fonte: UsinaInfo (2024)

O modelo do sensor utilizado é a versão encapsulada, desta maneira, pode ser utilizado
para medir a água sem causar danos ao componente. Seu esquema de ligação é composto
por 3 fios, um VCC e GND para alimentação e outro para Dados. Quando ligado, na
saı́da do sensor DS18B20 ocorre uma variação de tensão de acordo com a temperatura do
ambiente ou do liquı́do, o sensor então envia um sinal anaçógico para o microcontrolador
que fará a conversão dessa tensão que representa a temperatura em graus Celsius. (Portal
Vida de Silı́cio, 2018).

Tabela 3.2: Especificações do sensor DS18B20

Especificações técnicas Valor Unidade

Tensão de alimentação 3.3 a 5 Volts
Faixa de medição -55 a 125 °C
Precisão ±0,5 °C
Dimensão do cabo 90 cm
Corrente de trabalho 1 mA
Fonte: Portal Vida de Silı́cio (2018)

Como pode-se observar na tabela de especificações 3.2, o sensor DS18B20 atende com
as necessidades do projeto e do microcontrolador.
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 12

3.4 Sensor de pH PH4502C

O módulo sensor de pH para microcontroladores PH4502C é extremamente preciso e
prático para análise de alcalinidade e acidez de soluções. O módulo é composto por um
eletrodo que pode ser submerso em recipientes para realizar as leituras.

Figura 3.6: Sensor de pH

Fonte: Straub (2022)

Este sensor mostra-se eficiente em leituras em soluções lı́quidas dos mais variados
tipos, sua informações técnicas principais podem ser observadas na tabela abaixo. Como
podemos observar na Figura 3.6, o sensor é constituı́do de uma haste, cuja é feita de vidro
e em seu interior contendo uma membrana, esta haste geralmente é preenchida com uma
solução tampão. Este tampão serve para manter ı́ons H+ em seu interior e sirvam como
referência para outra leituras.
Quando o sensor é colocado na solução desejada, os ı́ons de hidrogênio que estão pre-
sentes no lı́quido realizam uma troca com os ı́ons carregados positivamente da membrana
de vidro, criando um potencial eletroquı́mico, que converte em sinais para ser feita a
leitura pelo módulo, como explica (Straub, 2022).
O sensor opera comparando o potencial elétrico de um sistema sensı́vel ao pH com
o potencial de um sistema de referência estável. O sistema de deteção utiliza um bolbo
de vidro sensı́vel ao pH que altera a tensão proporcionalmente à concentração de iões
de hidrogénio. Um elétrodo de deteção mede o potencial do bolbo de vidro. O sensor é
enchido com uma solução de cloreto de potássio (KCl) que conduz eletricidade entre o
vidro sensı́vel ao pH e o elétrodo de deteção. (Straub, 2022).
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 13

Tabela 3.3: Especificações do sensor PH4502C

Especificações técnicas Valor Unidade

Tensão de alimentação 5 Volts
Corrente de trabalho 5 a 10 mA
Tempo de resposta 5 s
Faixa de medição 0 a 14 -
Precisão ±0,5 -
Dimensão do cabo 70 cm
Fonte: UsinaInfo (2022)

A partir da tabela 3.3 de especificações do sensor de pH acima, pode-se perceber que

o sensor tende a ser bastante preciso, e adequado para o projeto.
O sistema de referência, separado do sistema de detecção, utiliza uma junção de re-
ferência substituı́vel para estabelecer contato elétrico com a amostra, protegendo o sistema
interno. Ao contrário do vidro sensı́vel ao pH, a junção de referência mantém um potencial
constante independente das variações de pH. Um eletrodo de referência mede o potencial
da solução através desta junção, preenchida com uma solução recarregável de prata/clo-
reto de prata (Ag/AgCl) que conduz eletricidade entre a junção e o eletrodo de referência.
(Straub, 2022).

3.5 Banco de dados Firebase

O banco de dados, nada mais é do que um sistema de armazenamento de informaçõs
que possibilita a coleta, armazenamento e manipulação de informações de maneira estru-
turada, que é fundamental para diversas empresas por exemplo que manejam um grande
volume de dados. O banco de dados, são frequentemente utilizados para armezanar da-
dos que sustenta muitas aplicações, sistemas e websites que permite a interoperabilidade
entre diferentes partes de um sistema, também permitem que vários usuários acessem e
compartilhem informações de forma controlada. (Oliveira, 2024)
Alguns dos tipos de bancos de dados existentes são:

• Banco de Dados Relacional (RDBMS): Utilizam tabelas para armazenar da-

dos, com linhas e colunas. São baseados no modelo relacional e usam SQL (Struc-
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 14

tured Query Language) para consultas e manipulação de dados.

• Banco de Dados Não Relacional (NoSQL): Não utilizam o modelo tabular

tradicional. Em vez disso, podem usar estruturas como documentos, grafos, chave-
valor e colunas.

• Banco de Dados em Nuvem: estes como o nome já remete, são hospedados em
nuvem, onde simplificam o provisionamento e a escalabilidade de bancos de dados.

• Banco de Dados Distribuı́do: Distribuem dados por múltiplos servidores ou

locais para redundância e alta disponibilidade, além de ser imutável.

O banco de dados Firebase, é um banco de dados NoSQL, ou seja, este modelo de

banco não segue modelo de tabelas e os relacionamentos utilizados nos bancos de dados
relacionais, como explica Calanca (2023). Basicamente, tratam as informações como um
nó pai, baseado na ideia de uma árvore, com vários nós filhos. Os bancos de dados não
relacionais possuem alguns modelos como: colunar, grafo, chave-valor e modelo orientado
a documentos. Dentro do NoSQL, exitem diversos modelos de dados, alguns dos principais
são:

• Colunar: Este modelo é uma abordagem onde os dados são armazenados como
colunas ao invés de linhas, este modelo é mais recomendado quando há uma grande
quantidade de dados e é exigida uma alta performance, e desta forma é eficiente em
economizar processamento.

• Orientado a documentos: neste modelo, os dados são armazenados em documen-

tos no formato JSON(Javascript Object Notation). Onde cada documento é iden-
tificado por uma chave única, que pode contar com informações de atributos e sub-
documentos. Este modelo é recomendado quando é necessário lidar com aplicações
que exigem flexibilidade na estrutura dos dados e grandes volumes de informações.

• Chave-valor: Já neste modelo, os dados são armazenados em pares de chave-valor,

ou seja, como o próprio nome sugere, cada dado é identificado por uma chave única.
É utilizado em aplicações que exigem uma alta performance em leitura e gravação
dos dados, como aplicações de cache ou armazenamento de sessões de usuários.
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 15

• Grafos: Neste modelo, os dados são usados para guardar dados interconectados,
pois torna possı́vel buscas detalhadas nas relações entre os dados

Figura 3.7: Estrutura de Banco de dados NoSQL

Fonte: Dezembro (2018)(1), adaptado

O firebase Realtime Database é um banco de dados hospedado na nuvem, onde os

dados são armazenados como JSON e sincroniza os dados em tempo real. Os benefı́cios
de utilizar o banco de dados não relacional em aplicações eatá pelos fatores de aplicações
que trabalham com cache e sistemas de catálogos ou estruturas flexı́veis. A figura 3.7
mostra como funciona a estrutura de um banco com modelo de dados do tipo orientado
a documentos. (Calanca, 2023)
Ao invés de utilizar solicitações HTTP, o Firebase usa a sincronização de dados, ou seja,
toda vez que os dados são modificados, todos os dispositivos que estiverem conectados
recebem a atualização. O Firebase tabém tem capacidade de peramencer responsivo
mesmo offline, pois seu SDK mantém os dados no disco, e quando a conectividade é
reestabelecida o usuário recebe as alterações e realiza a sincronização com o servidor.
(Calanca, 2023).
Outro benefı́cio de utilizar o Firebase, é que ele pode ser acessado diretamente de
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 16

um dispositivo móvel, ou pela Web, não sendo necessária um servidor de aplicativos. A

segurança e validação dos dados podem ser definidas através das regras de segurança
baseadas em expressão do próprio Firebase, tais regras servem para garantir a segurança
do banco sobre quem pode ler e escrever os dados. Além disso, o Firebase fornece serviços
como:

• Authentication: fornece métodos de autenticação fáceis de usar, como e-mail/senha,

autenticação de telefone, provedores de identidade federados como Google, Facebook
e Twitter, e integração com provedores de identidade personalizados.

• Cloud Firestore: escalável e flexı́vel para desenvolvimento de aplicativos móveis,

web e servidor. Ele armazena dados em documentos, que são organizados em
coleções. Como consequência torna a estrutura flexı́vel, também permite sincro-
nização em tempo real e consultas complexas e filtros.

• Storage: é um serviço que permite armazenar e servir arquivos gerados pelo usuário,
como fotos, vı́deos e outros tipos de conteúdo, com segurança e escalabilidade. Al-
gumas das suas vantagens é a escalabilidade e permite controle de acesso com o
serviço de autenticação.

• Cloud functions: este é um serviço de execução de código backend sem servidor

que é acionado por eventos do Firebase ou de terceiros. Algumas das suas vantagens
é a escalabilidade e integração com outros serviços do Firebase.

3.6 Expo Framework

O Expo é uma plataforma que auxilia no desenvolvimento de aplicativos utilizando
React Native, facilitando o acesso às APIs nativas dos dispositivos sem a necessidade de
adicionar dependências extras ou modificar o código nativo. Ele suporta as linguagens
JavaScript e TypeScript.(Fernandes, 2018).
De acordo com Fernandes (2018), a ferramenta proporciona uma ampla variedade de
API’s e funcionalidades nativas essenciais, permitindo um controle integrado da aplicação.
Por exemplo, utilizar recursos como câmera e microfone torna-se mais simples. Além disso,
o Expo inclui o Expo Go, um emulador Android próprio que possibilita testar e analisar
a aplicação em desenvolvimento de maneira prática e em tempo real .
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 17

Fernandes (2018), ainda explica que o Expo é mais recomendado para iniciantes no
desenvolvimento mobile que desejam criar aplicativos para Android e/ou iOS. Uma das
vantagens de usar o Expo é a facilidade na compilação do projeto para ambas as platafor-
mas, além de já oferecer diversos pacotes pré-compilados necessários para diversas APIs
utilizadas nas aplicações.

3.7 React Native

O react native é um framework de código aberto, muito utilizado por inúmeras em-
presas ao redor do mundo, alguns exemplos delas são Uber, Microsoft e o Facebook. O
react native é uma ferramenta para criação de aplicativos móveis que são renderizados
nativamente no Android ou IOS. Foi lançado em 2015 pela empresa Facebook, e após
alguns anos tornou-se uma das soluções mais utilizadas em questões de desenvolvimento
de aplicações móveis.
Segundo Fernandes (2024), dos motivos por ser preferı́vel por várias empresas, está
na chamada programação hibrı́da. A programação hibrı́da nada mais é do que quando
o mesmo código, pode funcionar em plataformas diferentes sem ser necessário alterá-
lo. Outra razão é devido ao fato do React Native ter sido construı́do baseado em uma
biblioteca do JavaScript, o React. O JavaScript, traz a flexibilidade e dinamismo que
juntamente com o TypeScript, que fornece uma camada de segurança e escalabilidade,
trazem como consequência uma aplicação funcional e de fácil desenvolvimento.
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 18

Figura 3.8: Arquitetura do React Native

Fonte: Fernandes ((? )

A arquitetura do React, que pode ser observada na figura 3.8, é composta por três
camadas adicionais, que combinam a praticidade e a reatividade do desenvolvimento da
aplicação:

• JavaScript : Nwesta camada é onde o código da aplicação é construı́do, utilizando

JavaScript e o React.(Fernandes, 2024).

• Bridge : também conhecida como ponte, é uma camada de comunicação que co-
necta o código JavaScript feito com o código nativo do dispositivo. (Fernandes,
2024).

– Shadow T ree: é a estrutura de dados que o React Native utiliza para re-
presentar a interface do usuário de forma abstrata antes de ser renderizada
nativamente.

– JSON : sigla de JavaScript Object Notation, é um formato leve de poder

trocar os dados, para serializar e deserializar dados entre o JavaScript e o
código nativo, ou seja, converter objetos do JSON em Strings.
CAPÍTULO 3. FUNDAMENTAÇÃO TEÓRICA 19

– N ativeM odules: Esses componentes são escritos em código nativo, podendo

ser Java,Kotlin ou Swift,que expõe as funcionalidades da plataforma para o
códido Javascript

• Nativa : camada responsável onde o código para cada plataforma do dispositivo

mobile é executado, seja iOS ou Android, o React Native ”traduz”mos componentes
do React para os componentres UI nativos.(Fernandes, 2024)
Capı́tulo 4

Metodologia

4.1 Arquitetura do sistema

A arquitetura do sistema de monitoramento de qualidade da água visa avaliar o estado
de rios e lagos, onde realiza as leituras através dos sensores e do microcontrolador trans-
missor, onde este por sua vez, envia os dados por protocolo Lora para o receptor, onde
posteriormente é distribuı́do para o banco de dados onde finalmente pode ser observado
através da aplicação android construı́da com o React Native. A arquitetura do sistema é
dividida em 5 partes, que pode ser observada na figura 4.1 abaixo:

Figura 4.1: Fluxograma de funcionamento do protótipo

Fonte: autor.

1. Sensores: nesta seção encontram-se todos os sensores para leituras do sistema,

sendo eles PH4502c e DS18B20. Os sensores se comunicam com o microcontrolador
enviando os dados a partir dos pinos analógicos do módulo LILYGO T-Beam.

20
CAPÍTULO 4. METODOLOGIA 21

2. Módulo LILYGO T-Beam LoRa: o módulo ESP32 possui módulo LoRa in-
tegrado SX1276 e antena para transmissão com frequência de 915 MHz, os dados
processados dos sensores são então enviados pelo protocolo de comunicação LoRa.

3. Módulo TTGO T-Beam LoRa: este microcontrolador ESP32 possui módulo

SX1276 LoRa integrado e antena para transmissão com frequência de 915 MHz.
Sua função é receber os dados e transmitir por protocolo WiFi para o banco de
dados.

4. Banco de dados: Tem a função de receber e armazenar os dados das leituras

recebidas pelo módulo transmissor e enviar para o banco de dados.

5. Aplicação: é onde o usuário é capaz de acessar e verificar de fato, todos os valores

e parâmetros da água. Os dados do banco são enviados de acordo com o caminho
estabelecido, um nó pai que possui vários nós filhos, que são os timestamps, os
timestamps funcionam como os ID’s únicos daquele nó filho, portanto, enviando as
informações de um nó de cada vez.

Tabela 4.1: Custo de equipamentos

Equipamento Quantidade Valor (R$)

ESP32 LILYGO 2 404,00
DS18B20 1 30,00
PH4502C 1 180,00
Jumpers 10 15,00
Protoboard 1 40,00
Total - 654,00
Fonte: autor.

A tabela 4.1 acima mostra o custo do sistema, sendo a maior parte do custo é devido
aos microcontroladores utilizados, seguido pelo sensor de pH. O valor total necessário para
desenvolvimento do projeto é de aproximadamente R$ 654,00.
CAPÍTULO 4. METODOLOGIA 22

4.2 Microcontrolador e sensores

A construção do protótipo de monitoramento de qualidade da água é relativamente
simples, visto que é necessário apenas as conexões de alimentação e dados entre os sensores
e o microcontrolador. Os pinos de dados são interligados nos pinos analógicos da LILYGO
T-Beam, e esta por sua vez, por já ter o módulo LoRa integrado, não requer mais nenhuma
ligação adicional para tal.

Figura 4.2: Esquema elétrico do sistema

Fonte: autor.

Como podemos observar o esquema elétrico da Figura 4.2, o sensor de tempera-

tura encapsulado (DS18B20) para seu funcionamento, requer uma alimentação de apenas
3.3VDC, desta forma, é necessário apenas ligar diretamente com o pino 3.3VDC do módulo
LILYGO. No entanto, como pode-se observar na tabela 3.3, o sensor PH4502C necessita
de uma alimentação de 5V DC para seu funcionamento.
O módulo LILYGO, é capaz de fornecer essa faixa de tensão através do seu pino Vin
ou 5V. Todavia, as GPIOS não são capazes de suportar uma tensão acima de 3.3V, como
explica Albuquerque(2020). Desta forma, foi-se necessário realizar um circuito simples de
divisor de tensão.
Para o divisor de tensão foi-se utilizado um resistor de 1KΩ em série com um resistor
de 2KΩ para que não fosse causado dano a GPIO que desejava-se receber os dados do
sensor. A partir do esquema, foi-se possı́vel realizar as ligações, resultando no circuito da
CAPÍTULO 4. METODOLOGIA 23

figura 4.3

Figura 4.3: Protótipo montado

Fonte: autor.

As ligações do circuito, restringiram-se basicamente a alimentação e comunicação de

dados. Os pinos de dados são interligados nos pinos analógicos ADC, GPIO 2 e GPIO 4
para o sensor PH4502C e DS18B20, respectivamente, da LILYGO T-Beam. O envio das
leituras para a aplicação mobile é através da antena LoRa a qual trabalha na frequência
de 915 MHz.

Figura 4.4: Bateria LiPo 31865

Fonte: autor.

A fim de garantir uma maior independência do sistema, foi utilizada bateria de Lı́tio
31865 de 3.7V e 1500 mAh, que pode ser vista na figura 4.4, acoplada ao módulo LILYGO,
permitindo que todo o sistema receba a alimentação necessária.
CAPÍTULO 4. METODOLOGIA 24

4.3 DS18B20
O sensor de temperatura encapsulado DS18B20, foi alimentado por uma tensão de
3.3VDC e possui apenas três pinos, VCC, GND e Data e requer um resistor de 4.7KΩ
entre o pino de VCC e de Dados, que serve como pull-up no barramento de dados, isto é,
para garantir que mantenha-se em nı́vel lógico alto no pino de Data e realize as leituras
normalmente. Através da tabela 4.2 abaixo, podemos ver a descrição dos pinos do sensor:

Tabela 4.2: Pinagem do sensor DS18B20

Pino Função
1 Ground
2 Saı́da analógica
3 Vin

Para verificar o funcionamento do sensor, foram realizados dois testes simples utili-
zando uma água em uma temperatura baixa e posteriormente uma água em temperatura
elevada, como pode-se observar na figura 4.5. O objetivo era analisar se a leitura dos sen-
sor estaria condizente com a sua real temperatura. Para utilizar o DS18B20 foi necessário
baixar e instalar as bibliotecas: OneWire.h na versão 2.3.8 e a biblioteca DallasTempera-
ture.h na versão 3.11.0.
CAPÍTULO 4. METODOLOGIA 25

Figura 4.5: Teste de funcionamento do sensor de temperatura

Fonte: autor.

Para o primeiro teste, pegou-se água mineral onde manteve-se em um refrigerador e

depois colocado em um recipiente para poder ser feita a leitura. Alguns segundos após
as leituras estabilizarem, o sensor retorna uma temperatura de cerca de 9.4 °C, que pode
ser observado pela figura 4.6.

Figura 4.6: Resultado da leitura do sensor de temperatura

Fonte: autor.

Após o primeiro teste, de forma similar, pegou-se água mineral e ferveu por alguns
minutos. Depois foi colocado em um recipiente onde foi posicionado o sensor de tempe-
CAPÍTULO 4. METODOLOGIA 26

ratura encapsulado e deixou-se as leituras estabilizarem por alguns segundos. As leituras

retornaram uma temperatura de 43.5 °C, como mostra a figura 4.7.

Figura 4.7: Resultado da leitura do sensor de temperatura

Fonte: autor.

4.4 PH4502C
O sensor PH4502C, foi alimentado por uma tensão de 5VDC e possui seis pinos, dos
quais foram necessários serem utilizados apenas três, VCC, GND e P0. A tabela 4.3
abaixo mostra o mapa dos pinos do sensor.

Tabela 4.3: Pinagem do sensor PH4502C

Pino Função
1 Ground
2 Saı́da analógica
3 Saı́da Digital (não utilizado)
4 Vin
5 1 - Conexão do módulo
6 2 - Conexão do módulo
7 3 - Conexão do módulo
8 4 - Não utilizado
Fonte: UsinaInfo (2022)
CAPÍTULO 4. METODOLOGIA 27

Após concluı́da a ligação dos pinos no módulo LILYGO, foi realizado leituras da tensão
do pino utilizando a função analogRead(). O objetivo era verificar qual a tensão de saı́da
na porta GPIO do módulo para então, com base nesses valores, poder estabelecer uma
equação que satisfaça a relação entre Tensão em V olts e o pH. A figura 4.8 mostra os
testes realizados com a solução de pH neutra 4.8(a), e a solução de pH ácida 4.8(b).

Figura 4.8: Medição de tensão

(a) Medição de tensão com solução de pH 6.80

(b) Medição de tensão com solução de pH 4.01

Fonte: autor.

Primeiramente, foi utilizado o solução com pH 6.8, e então foi calculada a tensão no
pino analógico, o valor da tensão de 1.55 V olts obtida pode-se ser observado na Figura
4.9(a). Depois, utilizando o solução de pH 4.01, a tensão obtida foi de 1.32 V olts, como
mostra Figura 4.9(b).
CAPÍTULO 4. METODOLOGIA 28

Figura 4.9: Medição das tensões com sensor PH4502C

(a) Tensão obtida com solução de pH 6.80

(b) Tensão obtida com solução de pH 4.01

Fonte: autor.

O cálculo para estabelecer o pH, foi utilizando a técnica de regressão polinomial, para
se ajustar aos valores de tensão encontrados, criando uma relação entre pH e tensão.
Primeiramente, para encontrar a equação que descreve o pH a partir da tensão no pino
ADC, utilizou-se a equação geral descrita, cuja forma é:
CAPÍTULO 4. METODOLOGIA 29

y =a+b·x (4.1)

A partir dos pontos obtidos (0,0) , (1.32, 4) e (1.55, 6.8) foi possı́vel encontrar uma
equação para satisfazer a relação aplicando interpolação polinomial utilizando o método
de Lagrange.

(x − 1.32) · (x − 1.55) (x + 0) · (x − 1.55) (x + 0) · (x − 1.32)

L(x) = 0· +4.01· +6.8·
(0 − 1.32) · (0 − 1.55) (1.32 + 0) · (1.32 − 1.55) (1.55 + 0) · (1.55 − 1.32)

x · (x − 1.55) x · (x − 1.32)
L(x) = 4.01 · + 6.8 · (4.2)
1.32 · (−0.23) 1.55 · 0.23
Simplificando a equação acima, temos:

(x2 − 1.55 · x) x2 − 1.32 · x

L(x) = 4.01 · + 6.8 ·
−0.3036 0.3565

L(x) = −13.20 · (x2 − 1.55 · x) + 19.07 · (x2 − 1.32 · x) (4.3)

Agora, multiplicando os termos em evidência:

L(x) = (−13.20 · x2 + 20.47 · x) + (19.07 · x2 − 25.17 · x)

L(x) = 5.866 · x2 − 4.705 · x (4.4)

Onde, L(x) representa o valor de pH da solução, e x representa a tensão obtida na

porta ADC. Sendo assim, a equação que irá no código do módulo transissor, é representado
pela equação 4.5:

pH = 5.866 · V 2 − 4.705 · V (4.5)

Portanto, a cada ciclo de leituras o microcontrolador transmissor irá calcular o valor

do pH, de acordo com a tensão obtida na GPIO pela equação 4.5 encontrada.
CAPÍTULO 4. METODOLOGIA 30

4.5 Microcontrolador Transmissor LILYGO

O módulo LILYGO que funciona como o módulo transmissor LoRa, recebe os sinais
dos sensores DS18B20 e PH4502C, interpreta e realiza o envio desses dados para o módulo
TTGO receptor através do protocolo LoRa. A topologia de rede escolhida para ser uti-
lizada no sistema foi a topologia Ponto a Ponto, considerando a quantidade de módulos
conectados, que são apenas dois, e por ser prática e eficiente. A programação do micro-
controlador para realização do envio foi simples, a figura 4.10 mostra os pacotes sendo
enviados pelo módulo. Foi implementado a função sendReadings(), que pega as vari-
aveis readingID e tempAgua e ph, as quais representam respectivamente, o contador
para envio, valor da temperatura e valor do pH. A função sendReadings() então converte
essas variáveis que são do tipo F loat e as converte para o tipo String, onde armazena
tudo em uma única variável, LoRaM essage e utilizando as funções LoRa.beginP acket() e
LoRa.endP acket() da bilbioteca LoRa.h efetua o envio. As funções do microcontrolador
transmissor encontram-se no Apêndice A.

Figura 4.10: Módulo LILYGO enviando pacotes

Fonte: autor.

Considerando eficiência energética da bateria, foi implementado o modo Deep Sleep,

a partir da função esp deep sleep start(). Desta forma, toda vez que o módulo termina
as leituras e as envia o microcontrolador ”dorme”por 5 minutos, até o ciclo ser realizado
novamente.
CAPÍTULO 4. METODOLOGIA 31

Figura 4.11: Variável readingID após o modo Deep Sleep

Fonte: autor.

Ainda que módulo seja alimentado por bateria, em uma eventual falta de energia,
causada por uma falta de carga na bateria 31865, ou toda vez que o módulo acordasse do
modo Deep Sleep, o contador readingID seria resetado para o valor inicial ”1”, uma vez
que a energia no módulo fosse reestabelecida. Tal condição causaria uma imprecisão no
cálculo de Perda de pacote, realizada pelo módulo receptor TTGO. Desta forma, foram
implemetadas duas funções, saveReadingID() e loadReadingID(), a primeira, cria um
arquivo e o abre para salvar o valor correspondente da variável readingID a qual é
incrementada toda vez que um ciclo de leituras é concluı́do. Já a função loadReadingID()
é excutada assim que o módulo inicia, a função é responsável por abrir o arquivo criado na
memória Flash, lê o valor da variável e este valor é passado novamente dentro do código,
como mostra a figura 4.11.
CAPÍTULO 4. METODOLOGIA 32

Figura 4.12: Variável readingID após reset forçado

Fonte: autor.

Como pode-se observar pela figura 4.12 mesmo com um reset forçado, podemos obser-
var que “Sending Packet” - que representa a quantidade de dados que foram transmitidos
pelo LoRa - recebe a variável readingID, permanece atualizando a partir do seu último
valor registrado.

4.6 Microcontrolador Receptor TTGO

Nesta seção, de forma quase similar, foi realizado a programação do módulo para
receber os dados e enviar para o Realtime DataBase. O módulo TTGO, através da
função LoRa.parseP acket(), também da biblioteca LoRa.h percebe quando um novo
pacote chega, e então atualiza o contador pacotesRecebidos, que nada mais é que uma
variável do tipo F loat, muito importante para calcular a taxa de perda de pacotes. O
link para o código para o módulo receptor encontra-se no Apêndice A.
Inicialmente, foi necessário implementar uma função para estabelecer a conexão WiFi
entre o módulo transmissor.A função initW iF i() é aonde as configurações da rede são
definidas como ssid e senha, e o módulo tenta realizar a conexão.
A função getLoRaData() foi implementada com a finalidade de ler a variável rece-
CAPÍTULO 4. METODOLOGIA 33

bida LoRaM essage, que incialmente é do tipo String onde é separado cada valor de
readingID, tempAgua e ph em novas variaveis do tipo F loat. Ainda dentro da função
getLoRaData() é realizado o cálculo da taxa de perda de pacote, pela equação 4.6 abaixo.

pacotesRecebidos
P erdas = 1 − · 100 (4.6)
readingID
Da mesma forma, a biblioteca LoRa.h fornece equações para obter o RSSI e SNR de
cada mensagem, utilizando as funções LoRa.packetRssi() e LoRa.packetSnr(), respec-
tivamente. Esses valores são então passados para as variáveis rssi e snr para também
serem enviados para o banco.
A função send data() implementada, é responsável pelo envio das variáveis para o Re-
altime Database, a partir da função json.set(), que recebe como parâmetro as variáveis
e os seus respectivos caminhos para o banco de dados, resultando em:

json.set(tempAguaPath.c_str(), temperature);
json.set(phPath.c_str(), valor_ph);
json.set(rssiPath.c_str(), rssi);
json.set(packlossPath.c_str(), perdas);
json.set(snrPath.c_str(), snr);
json.set(timePath, String(timestamp));

Outras duas funções foram implementada considerando problemas na conexão de rede

ou mesmo uma falha na execução da função send data(). Quando esses erros aconteciam,
os dados recebidos eram perdidos, foi ai que teve-se a ideia de salva-los localmente, também
utilizando o armazenamento de arquivos da ESP32, com a biblioteca SPIFFS. A função
salvarDadosLocalmente() como o prórpio nome sugere, salva as variáveis de temperature
e valor ph convertendo-as para String.
CAPÍTULO 4. METODOLOGIA 34

Figura 4.13: Dados sendo reenviados

Fonte: autor.

A figura 4.13 nos mostra que quando executada a função reenviarDados(), o arquivo
foi criado pela função salvarDadosLocalmente(), e depois é aberto e lido, e as informações
são reenviadas novamente para o Banco de dados.

4.7 Plataforma de programação Visual Studio Code

Visual Studio Code é uma plataforma de código aberto, desenvolvida pela empresa
Microsoft. O Visual Studio Code, trás consigo as funcionalidades de edição de código,
que suporta diversas linguagens de programação como Python, C++, C#, Javascript,
Typescript e muitas outras; terminal de comandos integrado, bem como controle de versão.
(Devmedia, 2016)
Justamente por sua versatilidade em diversas linguagens de programação, que foi
escolhida para o desenvolvimento de todo o trabalho, desde o sistema embarcado, que
utiliza a linguagem Arduino, e a aplicação mobile, que utiliza Javascript e elementos do
Typescript. (Devmedia, 2016)
A sua extensão, o PlatformIO, permite configurar e desenvolver códigos para sistemas
embarcados para microcontroladores, como é o caso da ESP32 nos módulos LILYGO e
TTGO. Além disso, possui gerenciador de bibliotecas e monitor serial, que nos permite
ver os dados que estão sendo coletados pelo módulo, dessa forma podendo acompanhar
CAPÍTULO 4. METODOLOGIA 35

as leituras no primeiro momento em que é feita a calibração dos sensores e testes inici-
ais.(Devmedia, 2016).

4.8 Bibliotecas
Para o completo funcionamento do código do sistema embarcado, que compõem os mi-
crocontroladores e sensores são: LoRa.h, SPI.h, Firebase ESP Client.h, WiFi.h, OneWire.h,
DallasTemperature.h e SPIFFS.h.

• Biblioteca LoRa : Imprescindı́vel para facilitar a comunicação entre dispositivos

LoRa, servindo para estabelecer a inicialização, configuração de parâmetros – lar-
gura de banda, taxa de espalhamento, taxa de decodificação – e o envio de dados.

• Biblioteca SPI : Esta biblioteca é necessária afim de estabelecer a comunicação com

dispositivos periféricos que utilizam protocolo SPI.

• Biblioteca WiFi : Responsável por estabelecer a comunicação do protocolo de co-

municação sem fio WiFi, tornando possı́vel o módulo ter acesso a rede e enviar os
dados via WiFi.

• Biblioteca Firebase ESP Client : Responsável por conectar os módulos de ESP32 e

ESP8266 e interagir com os serviços do banco de dados Firebase, permitindo ler e
escrever no Realtime Database.

• Biblioteca OneWire: Serve para garantir a comunicação de dados serial unidireci-

onal que requer um único fio, geralmente utilizada para sensores de temperatura
DS18B20.

• Biblioteca DallasTemperature: Esta biblioteca é uma extensão da OneWire, para

sensores de temperatura DS18B20 produzidos pela Maxim Integrated, serve para fa-
cilitar a comunicação serial entre múltiplos DS18B20 utilizando o protocolo OneWire.

• Biblioteca SPIFFS.h : é bastante usada para poder-se acessar o sistema de arquivos

SPI Flash File System, servindo para guardar dados de forma persistente, como
configurações.
CAPÍTULO 4. METODOLOGIA 36

4.9 Firebase Realtime Database

Para ser possı́vel obter um histórico dos dados coletados pelo sistema, foi de extrema
importância utilizar um banco de dados, e que fosse hospedado em nuvem cujos dados
fossem sincronizados em tempo real. O Firebase é uma plataforma BaaS (Backend-As-
A-Service) criada pela Google, portanto é um conjunto de serviços que hospeda bancos
de dados, serviços, autenticação e integração para uma variedade de aplicativos e API
prontas para serem utilizadas. A plataforma fornece diversos serviços são eles Firestore,
Authentication, Cloud Storage, Crashlytics, entre outros. (Ribeiro, 2023).
Sendo assim, foi criado ao módulo receptor TTGO, o código para poder realizar o
envio das leituras recebidas através do protocolo de comunicação LoRa. A figura abaixo,
mostra o banco de dados após algumas leituras terem sido recebidas. Primeiramente foi
criado as variáveis que contém os caminhos de cada leitura e informação desejada. Neste
caso, foi criado caminhos para armazenar as variáveis de pH, temperatura, RSSI, SNR,
perda de pacote e o timestamp, ficando respectivamente:

• phPath= ”/ph”

• tempAguaPath = ”/tempAgua”

• rssiPath = ”/rssi”

• snrPath = ”/snr”

• packlossPath = ”/packloss”

• timepath = ”/timestamp”
CAPÍTULO 4. METODOLOGIA 37

Figura 4.14: Console do Firebase Realtime Database

Fonte: autor.

Posteriormente para inicialização do Firebase no módulo receptor, é realizada as con-

figurações de horário, autenticação do usuário, URL do banco de dados, uma vez que
esse procedimento foi feito e o módulo possui conexão com a rede WiFi, o módulo espera
receber os dados do módulo transmissor e uma vez que foram recebidos, os dados são
convertidos em variáveis do tipo String e associadas a sua respectiva variável, sendo esta
última em um objeto formato JSON que será enviado para o determinado caminho da
variável. Desta forma, quando os dados são efetivamente enviados para o banco, pode-se
observá-los no Console, como mostra a figura 4.14.

4.9.1 Autenticação

Durante a criação do banco foi necessário determinar o método de autenticação para

o banco pelos provedores de login, a plataforma oferece várias opções, desde provedores
ativos como: email/senha, número de celular, mas oferece também de outros provedores
como acesso por Facebook, Google, Microsoft, Twitter, entre outros. Visando que o
protótipo deva ser acessado somente por pessoas autorizadas, o método de email e senha
foi escolhido.
CAPÍTULO 4. METODOLOGIA 38

Figura 4.15: Métodos de Autenticação

Fonte: autor.

Para adicionar os usuários, foi-se na aba Authentication, como pode-se observar na

figura 4.15, onde foi apenas necessário informar o email que será utilizado e criar uma
senha. Após a adição de um novo usuário a plataforma do Firebase gera então um UID
(User Identification). É através desse UID que conseguimos definir regras de acesso ao
banco.

4.9.2 Cadastro de Regras

Outro passo extremamente importante durante a criação do banco de dados é definir

as regras de segurança do mesmo. Sua função é garantir a integridade e confidencialidade
dos dados armazenados, controlando o acesso para apenas usuários permitidos, os quais
sejam autorizados a realizar ações como ler e/ou escrever dados no banco. Na figura 4.16
abaixo, é possı́vel observar a definição das regras.
CAPÍTULO 4. METODOLOGIA 39

Figura 4.16: Cadastro de regras do banco

Fonte: autor.

A definição da regra de leitura ”.read”: ”auth != null”, estabelece que apenas usuários
que sejam cadastrados no sistema do Firebase sejam capazes de acessar via Web ou
pela aplicação Android. Já para escrita, a regra ”.write”: ”auth.uid === ’hRzYA-
OiVKXORcDpTYieB1Hkw4x13’”estabelece que apenas o usuário com uid ’hRzYAOiVK-
XORcDpTYieB1Hkw4x13’, que neste caso é o módulo Receptor TTGO T-Beam seja ca-
paz de escrever no banco.

4.9.3 Sincronização dos dados

A primeira função referente ao banco de dados a ser executada no módulo receptor

é initF irebase(), essa função é responsável justamente pela inicialização do serviço, na
função são passados a chave API, URL do banco de dados e email e senha do ”usuário”que
o módulo será conectado. O módulo se conecta através do usuário ”[email protected]”que
tem um UID único. Feito isso, a conexão com o Firebase foi estabelecida com sucesso.
Depois do módulo receptor receber todos os dados do transmissor e fazer a manipulação
dos dados de força de sinal, os dados estão prontos para serem enviados. A função
responsável por isso é a send data()
CAPÍTULO 4. METODOLOGIA 40

Figura 4.17: Caminho do Realtime Database

Fonte: autor.

Os paths ou caminhos, foram definidos da seguinte forma, o caminho padrão U sers/4 e

então o T imestamp, que indica a data e o horário, dentro desse caminho são adicionados
os valores obtidos daquela leitura especı́fica. Por exemplo, tendo o senguinte caminho
/U sers/4/01 − 07 − 2024 19 : 42 , onde o U sers/ representa o nó mais alto, a raı́z do
Path, a figura 4.17, exemplifica a estrutura do caminho no banco. O trecho 4/ é nó pai,
e o T imestamp, utilizando o exemplo descrito, 01-07-2024 19:42 é o nó filho. Portanto,
todos os nós de T imestamp, também serão todos os nós filhos do nó 4. Desta forma,
quando há uma atualização no nó 4, ou seja, uma nova leitura foi encaminhada pelo
módulo receptor para o Firebase, pelo caminho padrão U sers/4 a aplicação é capaz de
perceber essa atualização e então sincroniza os dados, e exibe na aplicação.

4.10 Desenvolvimento do aplicativo

Considerando que para muitas atividades como aquicultura, piscicultura, hidroponia
e etc, há uma demanda maior no gerenciamento dos parâmetros da água, seja, salinidade,
pH, turbidez, ou temperatura para garantir a qualidade da mesma para o devido uso e/ou
destino, visou-se então criar uma aplicação, o ClearFlow Sentinel, tanto para os sistemas
CAPÍTULO 4. METODOLOGIA 41

operacionais Android e iOS, pensada em facilitar a análise e monitoramento em tempo

real dos parâmetros da água, de uma forma ágil, prática e eficiente. A figura 4.18 mostra
como é o processo de sincronização entre o banco de dados e a aplicação.

Figura 4.18: Processo de atualização da aplicação

Fonte: Cloud Firestrore, adaptado.

A arquitetura da aplicação é composta por quatro telas, as quais podem ser observadas
nas figuras abaixo. A primeira tela é a Splash Screen, vista na figura 4.19(a), que nada
mais é do que uma tela de carregamento da aplicação, que em seguida conduz o usuário
a uma tela de Login, como podemos ver na figura 4.19(b), composta por autenticação.
Considerando um sistema restrito, a única forma para o usuário obter acesso ao aplica-
tivo, é sendo cadastrado previamente diretamente pelo banco de dados, e uma vez que
preenchidos os dados de Email e Senha corretamente, basta clicar no botão “Entrar” para
ser direcionado a página inicial.
CAPÍTULO 4. METODOLOGIA 42

Figura 4.19: Telas iniciais do ClearFlow Sentinel

(a) Splash Screen (b) Tela de Login

Fonte: autor.

Para este tipo de tela, foi utilizado o tipo de navegação Stack. Dentro da Tela de
navegação de Login, a mesma recebe como parâmetro o setIsLoggedIn que nada mais
é do que uma variável do tipo Bool, que verifica se existe um usuário logado, que por
padrão é setada como False. Ainda dentro da função LoginScreen() foi implementada
uma função de SignIn() que é responsável por fazer o casamento dos dados de Email
e Senha, que são informados pelo usuário. Caso os dados sejam verdadeiros, ou seja, o
usuário esteja cadastrado e informações de Email e Senha estejam corretos, a variável
setIsLoggedIn é definida como T rue, e então o usuário é redirecionado para a tela inicial
de Home.
CAPÍTULO 4. METODOLOGIA 43

Figura 4.20: Telas com leituras dos sensores

(a) Tela de Home (b) Tela de Histórico

Fonte: autor.

O restante da aplicação foi utilizado a navegação Bottom Tabs que tem por carac-
terı́stica possuir uma barra onde é possı́vel navegar entre as telas da aplicação direta-
mente. A primeira tela é a de Home, como pode ser vista na figura 4.20(a), nesta tela,
o usuário consegue ver os valores da última leitura de temperatura e pH. Para tal, foi
implementado dentro da função de HomeScreen() o método onV alue() que adiciona um
listener, ou seja, sempre que houver alteração nos dados no caminho do banco de dados
referenciado o listener é acionado.
Quando o usuário se direciona para a próxima tela, a de Histórico, que pode ser obser-
vada na figura 4.20(b), é possı́vel observar todas as leituras dos sensores disponı́veis, bem
como data e hora de cada leitura. Esse procedimento é realizado da mesma forma que na
tela anterior, utilizando também o método onV alue() e utilizamos o método reverse()para
que as leituras mais recentes sejam as primeiras a aparecer e as mais antigas apareçam
ao fim da tabela. Também foi utilizado o método setCurrrentP age() para que todos
os dados da tabela não ficassem em uma única página, pois foi considerado um grande
CAPÍTULO 4. METODOLOGIA 44

volume de dados no banco, o que tornaria difı́cil a legibilidade e usabilidade, e posteri-

ormente a renderização do grande volume de informações causaria uma interface lenta e
não responsiva, o que prejudicaria o desempenho. (React Native, 2024).

Figura 4.21: Telas do ClearFlow Sentinel

(a) Tela de informações LoRa (b) Tela de informações Gerais

Fonte: autor.

Já nesta segunda parte do aplicativo, mostrou-se interessante trazer informações ex-
plicativas sobre o sistema geral. A figura 4.21(a) mostra a tela de Informações Técnicas,
traz informações especı́ficas sobre o protocolo de comunicação utilizado, o LoRa. Alguns
parâmetros foram setados, como o Fator de Espalhamento, Largura de Canal e Code
Rate. Tais configurações são imutáveis, ou seja, foram definidos no código embarcado
do sistema apenas uma vez. Outros dados como RSSI, e SNR e a Perda de pacote, são
calculados a cada leitura recebida e então enviados também ao Realtime Database.
Já na figura 4.21(b), podemos ver a tela de informações gerais, sobre o tipo dos sen-
sores que estão sendo utilizados, os parâmetros ideais de leituras de cada um, bem como
acesso ao banco de dados do projeto dentro do RealTime Database. A tela de informações
foi construı́da no componente SettingsScreen, a qual recebe a variável setIsLoggedIn. O
CAPÍTULO 4. METODOLOGIA 45

componente conta com um botão de Logout, caso o usuário deseje sair da conta cadas-
trada. Para isso foi implementado a função signOutApp, que é acionada quando o botão
de \Logout” é pressionado, redirecionando o usuário a tela inicial de Login.
Capı́tulo 5

Cenários de teste e Resultados

5.1 Teste de alcance

Nesta etapa do trabalho,para que fosse possı́vel ter uma fiel compreensão e análise
crı́tica quanto a cobertura e qualidade do sinal LoRa, recebido utilizando os módulos
citados. Os testes foram realizados na UFAM. Utilizou-se o sof tware do GoogleEarth
para poder verificar posições estratégicas para a avaliação.
Os locais para a realização dos testes foram escolhidos em relação ao desempenho
em ambientes urbanos com a presença de obstruções, sendo que para este teste o local
definido foi a Faculdade de Tecnologia, localizada no Setor Norte da Universidade. E a
localização do segundo teste, foi definido com base na semelhança com o ambiente que o
protótipo se propõe a solucionar, sendo este, um ambiente com presença de vegetação e
relevo naturais. Desta forma foi escolhido o Setor Sul da Universidade, o Mini Campus.

5.1.1 Teste de alcance na Faculdade de Tecnologia

Em um primeiro momento, decidiu-se analisar os valores de RSSI e SNR, em um

ambiente urbano, neste caso, escolheu-se a própria Faculdade de Tecnologia do Setor
Norte do Campus. O ponto de origem, onde posicionou-se o módulo transmissor LoRa,
foi próximo à Lanchonete Neide, e o ponto 2, onde posicionou-se o módulo receptor
LoRa, em frente ao Laboratório de IoOT, sendo este localizado no CETELI. Na figura
5.1 podemos verificar a localização dos pontos utilizando o Software do Google Earth.

46
CAPÍTULO 5. CENÁRIOS DE TESTE E RESULTADOS 47

Figura 5.1: Distância do Teste 1 entre transmissor e receptor

Fonte: autor.

Assim que o módulo transmissor foi alimentado, o mesmo começou a estabelecer a

comunicação e efetuar o envio dos dados. Utilizando o software do Google Earth, pode-se
verificar que a distância alçada nesse teste foi de 160 metros.
CAPÍTULO 5. CENÁRIOS DE TESTE E RESULTADOS 48

Figura 5.2: Visualização das leituras no ClearFlow Sentinel

Fonte: autor.

Para tal, utilizou-se um SpreadF actor de 12, considerando o ambiente em questão, a

expectativa era de que o sinal possuı́sse uma boa qualidade, e fosse resistente ao ruı́do. Ao
realizar o teste, foi observado que a qualidade do sinal manteve-se estável, apresentando
um RSSI variando entre -116 dBm a -117 dBm, como podemos observar na Figura 5.2.

5.1.2 Teste de alcance no Setor Sul do Campus

O próximo teste realizado foi considerando um ambiente que se aproximasse o máximo

possı́vel ao que o trabalho propõe solucionar, um ambiente com arborização e vegetação
densa presente. O local definido como ponto de origem, o qual posicionou-se o módulo
transmissor, foi o campo de futebol, e o ponto 2 onde fixou-se o receptor, foi na Oficina de
Marcenaria da faculdade de Design, como podemos observar na figura 5.3, a localização
dos pontos também com o Software do Google Earth.
CAPÍTULO 5. CENÁRIOS DE TESTE E RESULTADOS 49

Figura 5.3: Distância do Teste 2 entre transmissor e receptor

Fonte: autor.

Uma vez estabelecida as conexões, e o módulo alimentado, o mesmo começou nova-

mente a transmitir os dados. Neste teste, observou-se que o RSSI foi de -112 dBm, com
um SNR de -16.25 dB, onde o alcance foi de 540 metros. Os resultados deste teste podem
ser observados na Figura 5.4 que representa a tela de informações técnicas do ClearFlow
Sentinel.
CAPÍTULO 5. CENÁRIOS DE TESTE E RESULTADOS 50

Figura 5.4: Visualização das leituras no ClearFlow Sentinel

Fonte: autor.

5.2 Teste de medição dos sensores

Afim de avaliar o comportamento do sistema e sua precisão, foi realizado uma co-
leta de água do Rio Negro, na Praia da Ponta Negra, utilizando uma garrafa PET de
aproximadamente 2 litros, como mostra o registro na figura 5.5 abaixo.
CAPÍTULO 5. CENÁRIOS DE TESTE E RESULTADOS 51

Figura 5.5: Coleta de água na Praia da Ponta Negra

Fonte: autor.

Visto que o protótipo visa coletar dados e monitorar corpos d’água naturais, foi co-
letada uma amostra de água baixo Rio Negro, localizado na Praia da Ponta Negra. O
objetivo da coleta desta amostra foi realizar as leituras com os sensores analógicos. Para
tal, foi utilizado apenas uma pequena quantidade da água coletada, a qual foi depositada
em um recipiente plástico, como mostra a figura 5.6, para que fosse possı́vel a realização
dos testes.

Figura 5.6: Medição da temperatura e pH

Fonte: autor.

Uma vez que o circuito foi montado, a ponta do sensor DS18B20 e a sonda do sensor
PH4502C foram submersas no recipiente plástico onde foi depositada a amostra de água
coletada do Rio Negro. Ao iniciar o módulo transmissor LILYGO, conectado a bateria de
lı́tio, o mesmo já inicializou e começou as leituras de temperatura e pH da amostra.
CAPÍTULO 5. CENÁRIOS DE TESTE E RESULTADOS 52

Figura 5.7: Módulo receptor TTGO

Fonte: autor.

O módulo transmissor então envia as informações obtidas para o módulo receptor,

que pode ser observado na figura 5.7, onde este, que encontra-se em um ponto conectado
estratégico, com uma rede WiFi presente, faz a manipulação dos dados recebidos, calcula
as métricas de força do sinal como RSSI, SNR e a perda de pacote, e posteriormente envia
todas essas informações para o Realtime Database. Sendo então todas as informações de
parãmetros da água e de força do sinal, exibidas na aplicação do ClearFlow Sentinel.
CAPÍTULO 5. CENÁRIOS DE TESTE E RESULTADOS 53

Figura 5.8: Exibição dos dados no aplicativo ClearFlow

Fonte: autor.

Como pode-se observar na figura 5.8 os resultados obtidos pelas leituras dos sensores,
a temperatura da água foi de aproximadamente 24.63°C. Como o local de medição foi um
ambiente externo ao corpo d’água, ou seja, como a medição não ocorreu no próprio Rio
Negro, a temperatura da água apresenta uma diferença de acordo com o estudo de Silva
et al. (2013).
O pH, no entanto apresentou um valor condizente com o estudo deSilva et al. (2013),
que refere a um pH de 4.95, apresentado uma pequena variação. As leituras realizadas
com o sensor PH4502C apresentaram valores de pH entre 4.80 e 5.01, descrevendo um
meio ácido.
Capı́tulo 6

Conclusão

Diante dos resultados obtidos pelo sistema de monitoramento, constatamos que a tec-
nologia LoRa, utilizando a topologia Ponto a Ponto, é plenamente viável para a coleta
de dados. As coletas de dados na banda de 915 MHz com um Spreading Factor de 12
tanto em ambientes urbanos, como em ambientes com vasta vegetação, foram satisfatórias,
apresentando resistência ao ruı́do e um alcance de 540 metros. Os sensores integrados ao
sistema demonstraram alta eficiência durante os testes utilizando amostras coletada do
Rio Negro. A aplicação mobile desenvolvida com React Native mostrou-se facilmente
implementável e robusta para o sistema de monitoramento remoto, tornando-se uma ex-
celente escolha tanto para o desenvolvimento do aplicativo quanto para a experiência do
usuário, graças à sua interface intuitiva e desempenho consistente. A utilização do LoRa,
especialmente em regiões remotas onde não é possı́vel estabelecer uma conexão direta com
a internet, revelou-se uma solução prática e eficaz. Portanto, para aplicações na área de
Internet das Coisas, a tecnologia LoRa se destaca como uma opção robusta e confiável,
permitindo a implementação de sistemas de monitoramento eficientes e acessı́veis. Para
trabalhos futuros recomenda-se a utilização de mais soluções padrão de pH, obtendo então
mais pontos para refinar a equação estabelecida entre pH e Tensão, utilizando o método
de regressão polinomial. Também recomenda-se a integração de mais sensores como o
de Oxigênio Dissolvido e Turbidez para tornar o sistema mais completo e a utilização de
equipamentos mais baratos para diminuir ainda mais o custo do sistema.
(2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (1) (15) (16) (17) (18) (19) (20)
(21) (22) (23) (24) (25) (26) (27) (28) (29)

54
Referências Bibliográficas

[1] DEZEMBRO, J. P. Firebase — como, quando e porque utilizar esse Banco de Da-
dos do Google. 2018. Disponı́vel em: url: https://medium.com/@dezembro/firebase-
como-quando-e-porque-utilizar-esse-banco-de-dados-do-google-f65ab5ae182a. Acessado
em: 07 julho 2024.

[2] ALFACOMP. O que são o LoRa e o LoRaWAN. 2023. Disponı́vel em: url:
https://alfacomp.net/2023/08/30/lora/. Acessado em: 09 julho 2024.

[3] CALANCA, P. SQL e NoSQL: trabalhando com bancos relacionais e não relacio-
nais. 2023. Disponı́vel em: url: https://www.alura.com.br/artigos/sql-nosql-bancos-
relacionais-nao-relacionais. Acessado em: 09 julho 2024.

[4] OLIVEIRA, D. Banco de Dados: o que é, principais tipos e um guia para iniciar. 2024.
Disponı́vel em: url: https://www.alura.com.br/artigos/banco-de-dados. Acessado em:
09 julho 2024.

[5] TAPADYUTI, B. Understanding of LoRa. 2023. Disponı́vel em: url:

https://medium.com/@arghyabaral/understanding-of-lora-066d89ed7bf4. Acessado
em: 09 julho 2024.

[6] BASTA, P. et al. AnÁlise regional dos nÍveis de mercÚrio em peixes consumidos pela
populaÇÃo da amazÔnia brasileira. Fundação Oswaldo Cruz, v. 13, n. 2, p. 163–174,
2013.

[7] DCA. Diferença entre a conexão ponto a ponto e a conexõ multiponto. 2022. Dis-
ponı́vel em: url: https://www.dca.com.br/diferenca-entre-a-conexao-ponto-a-ponto-e-
a-conexao-multiponto/. Acessado em: 08 julho 2024.

[8] DEVMEDIA. Introdução ao Visual Studio Code. 2016. Disponı́vel em: url:
https://www.devmedia.com.br/introducao-ao-visual-studio-code/34418. Acessado em:
09 julho 2024.

[9] FABREGAT-SAFONT, D. et al. Wide-scope screening of pharmaceuticals, illicit drugs

and their metabolites in the amazon river. Elsevier, v. 200, n. 117251, 2021.

55
REFERÊNCIAS BIBLIOGRÁFICAS 56

[10] DEVMEDIA. Como programar o Arduino com o Visual Studio Code e Platfor-
mIO IDE. 2018. Disponı́vel em: url: https://embarcados.com.br/arduino-vscode-
platformio/. Acessado em: 08 julho 2024.

[11] MILLER, F. SPIFFS o sistema de arquivos do ESP8266/32. 2021. Disponı́vel em:

url: https://embarcados.com.br/spiffs-o-sistema-de-arquivos-do-esp8266-32/. Acessado
em: 08 julho 2024.

[12] BASTA, P. C. et al. Análise Regional dos Nı́veis de Mercúrio em Peixes Consumidos
pela População da Amazônia Brasileira. 2023. Disponı́vel em: https://informe.
ensp.fiocruz.br/assets/anexos/2441a041be660fb7575f8fe0bf6f8f34.PDF?mc_
cid=ae25a10157&mc_eid=289d4247be. Acessado em: 09 julho 2024.

[13] IT, I. Topologia de Rede: Conheça os principais tipos. 2021. Disponı́vel em: url:
https://www.internationalit.com/post/topologia-de-rede-conhe. Acessado em: 08 julho
2024.

[14] MAKERHERO. Placa ESP32 TTGO T-Beam com Suporte de Bateria, GPS e LoRa.
2024. Disponı́vel em: url: https://www.makerhero.com/produto/modulo-wifi-esp32-
com-suporte-de-bateria-gps-e-lora-915mhz/. Acessado em: 08 julho 2024.

[15] CHAMORRO, P. Poluição invisı́vel nas águas amazônicas

ameaça populações e biodiversidade. 2021. Disponı́vel em: url:
https://acervo.socioambiental.org/acervo/noticias/poluicao-invisivel-nas-aguas-
amazonicas-ameaca-populacoes-e-biodiversidade. Acessado em: 09 julho 2024.

[16] NATIVE, R. Optimizing Flatlist Configuration. 2024. Disponı́vel em: url:

https://reactnative.dev/docs/optimizing-flatlist-configuration. Acessado em: 08 julho
2024.

[17] RIBEIRO, A. O que é Firebase? Para que serve, principais carac-

terı́stica e um Guia dessa ferramenta Google. 2023. Disponı́vel em: url:
https://www.alura.com.br/artigos/firebase. Acessado em: 08 julho 2024.

[18] FERNANDES, D. Expo: o que é, para que serve e quando utilizar? 2018. Disponı́vel
em: url: https://blog.rocketseat.com.br/expo-react-native/.
REFERÊNCIAS BIBLIOGRÁFICAS 57

[19] FERNANDES, D. O que é e o que você precisa saber sobre o React Native. 2024.
Disponı́vel em: url: https://blog.rocketseat.com.br/o-que-e-e-o-que-voce-precisa-saber-
sobre-o-react-native/. Acessado em: 09 julho 2024.

[20] MARIA, S. et al. Classificação dos rios da amazônia: Uma estratégia para preservação
desse recurso. HOLOS Environment, v. 13, n. 2, p. 163–174, 2013.

[21] TELECO. Frequências no Brasil. 2021. Disponı́vel em: url:

https://www.teleco.com.br/freq no brasil.asp. Acessado em: 07 julho 2024.

[22] NETWORK, T. T. RSSI and SNR. 2024. Disponı́vel em: url:

https://www.thethingsnetwork.org/docs/lorawan/rssi-and-snr/. Acessado em: 09
julho 2024.

[23] GISERMAN LUIZ; GALVES, B. J. A. Modulação e protocolo LoRaWAN.

2019. Disponı́vel em: url: https://www.gta.ufrj.br/ensino/eel878/redes1-2019-
1/vf/lora/modulacao.html. Acessado em: 08 julho 2024.

[24] STRAUB, M. Sensor de PH Arduino como calibrar e configurar? 2022. Disponı́vel

em: url: https://www.usinainfo.com.br/blog/sensor-de-ph-arduino-como-calibrar-e-
configurar/. Acessado em: 09 julho 2024.

[25] USINAINFO. LILYGO Meshtastic T-Beam. 2023. Url: Disponı́vel em:

https://www.usinainfo.com.br/lora/lilygo-meshtastic-t-beam-v12-lora-868915mhz-
gps-neo-6m-com-suporte-para-bateria-18650-display-oled-096-8383.html. Acessado em:
09 julho 2024.

[26] USINAINFO. Sensor de Temperatura DS 18B20. 2024. Disponı́vel em: url:

https://www.usinainfo.com.br/sensor-de-temperatura/sensor-de-temperatura-ds-
18b20-a-prova-d-agua-2645.html. Acessado em: 09 julho 2024.

[27] ALBUQUERQUE, Y. ESP32 pinout – Guia Básico de GPIOs. 2020. Disponı́vel em:
url: https://blog.smartkits.com.br/esp32-pinout-guia-basico-de-gpios/. Acessado em:
09 julho 2024.

[28] SILı́CIO, P. V. de. DS18B20 – Sensor de temperatura inteligente. 2018. Disponı́vel

em: url: https://portal.vidadesilicio.com.br/sensor-de-temperatura-ds18b20/. Aces-
sado em: 08 julho 2024.
REFERÊNCIAS BIBLIOGRÁFICAS 58

[29] VEIGA, J. Garimpo impacta saúde de comunidades ribeirinhas no Amazo-

nas. 2023. Disponı́vel em: https://oeco.org.br/reportagens/garimpo-impacta-saude-de-
comunidades-ribeirinhas-no-amazonas/. Acessado em: 07 jul. 2024.
Apêndice A

Código principal

A.0.1 Módulo transmissor

O código completo utilizado do módulo transmissor :

https://github.com/ndamasc/Esp-Sender-Lora

A.0.2 Módulo receptor

O código completo utilizado do módulo receptor :

https://github.com/ndamasc/Esp-Receiver-Lora

59
Apêndice B

Aplicativo

B.0.1 Código em React Native

https://github.com/ndamasc/ClearFlow-Sentinel-app