Arquivo da categoria ‘Assuntos Técnicos’

Por Giovanni Cerqueira – Publicado originalmente no Embarcados

Introdução

Todos que desenvolvem com Arduino certamente já estão familiarizados com a ferramenta Arduino IDE, software padrão para desenvolvimento com a plataforma Arduino. Contudo, este artigo apresentará uma alternativa muito interessante à IDE: a extensão PlatformIO IDE do VSCode (Visual Studio Code).

VSCode é um um programa open-source desenvolvido pela Microsoft com suporte para Windows, macOS e Linux. É um software livre e de código aberto, baseado no framework Electron. Além disso, é altamente customizável, permitindo que os usuários mudem o tema do editor, as teclas de atalho, entre outros aspectos. Ele é mais vantajoso em relação à IDE em vários aspectos, entre os quais:

  • Intellisense (Sintaxe Inteligente);
  • Debugging;
  • Git incorporado;
  • Muitas extensões (como a utilizada para programar o Arduino).

O PlatformIO IDE é um ecossistema de código-aberto para desenvolvimento em IoT. Tem suporte para diversos tipos de placas, entre elas Arduino e Raspberry Pi. Permite, portanto, que se use uma única ferramenta de desenvolvimento para diferentes microcontroladores. É escrito em Python e não necessita de nenhuma biblioteca ou ferramenta adicional. Foi nomeado para “Best Software and Tools in the 2015/16 IoT Awards“.

Instalação do VSCode

Aqui segue um passo a passo de como usá-lo a partir do Visual Studio Code:

Acesse este link e clique no botão verde para instalar, no qual já vai estar selecionado seu sistema operacional. No caso estou usando macOS mas, como descrito anteriormente, também há suporte para outros sistemas operacionais.

Figura 1 – Acessando a página do Visual Studio Code.

Já com o Visual Studio Code aberto, vá na coluna localizada no lado esquerdo do monitor e selecione o último ícone, o de extensões. Então digite no buscador “PlatformIO IDE” e selecione a primeira opção. Clique então em “Install“. A instalação demora um pouco.

Figura 2 – Instalando a extensão PlatformIO IDE no VSCode.

Clique no primeiro ícone do lado esquerdo do monitor. Logo ao lado, em “Open Editors“, deve aparecer “PIO Home“. Caso não apareça, volte na tela da Figura 2, e clique em “Reload” (Figura 3).

Figura 3 – Inicializando o PlatformIO.

 

Primeiros passos com o VSCode

 

1 – Após clicar em “PIO Home“, clique na interface que se abriu à direita, em “New Project”. Uma janela irá se abrir requisitando a placa e o framework. Selecione o modelo do Arduino que está sendo utilizado. No caso, estarei utilizando o UNO. Não é necessário alterar o framework. Clique em “Finish” (Figura 4).

Figura 4 – Criando o projeto PlatformIO no VSCode.

2 – Após isso, abaixo de “Open Editors“, irá aparecer o projeto criado (cujo nome pode ser alterado clicando em “PIO Home” → “Open Projects” → “Projects” → Selecionar o projeto → “Rename“), o qual deve ser clicado. Dentre os itens do projeto, clique em “src” e depois em “main.cpp” (Figura 5).

Figura 5 – Abrindo a sketch.

3 – Pronto! Agora você já pode começar a programar! Note que, diferentemente da sketch padrão, esse programa apresenta o comando:

# include <Arduino.h>

Isso se deve ao fato de que, como dito anteriormente, o PlatformIO IDE suporta outras plataformas além do Arduino.

4 – Por fim, os comandos de verificação, upload, abertura do monitor serial e etc.. estão localizados no canto inferior esquerdo. Para fins ilustrativos, fiz um Blink no PlatfomIO IDE. O aquivo do código encontra-se aqui (Figura 6).

Figura 6 – Exemplo de código usando PlatformIO e VSCode.

Conclusão e Agradecimento

Agora é a sua vez. Com esse conhecimento em mãos, passe a desenvolver com o seu Arduino usando e abusando das vantagens oferecidas pelo VSCode e pelo PlatformIO IDE.

Concluindo, gostaria de agradecer o Fábio Souza, que me proporcionou essa oportunidade.

Licença Creative Commons  

Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.

INTRODUÇÃO

 

Miroprocessadores, portas lógicas e periféricos devem sempre operar com a mesma tensão de alimentação. Isso nem sempre é possível. O problema é que as tensões padronizadas são várias e muitas vezes se faz necessário conectar dispositivos que operam em tensões distintas. Uma opção bastante acessível são os conversores de nível lógico oferecidos pelos revendedores de Arduino. Esses em geral são acondicionados em grupos de dois, quatro ou oito em módulos de circuito impresso. Há opções mais profissionais oferecidos pela Texas Instruments (da linha TBX… ) ou outros fabricantes de circuitos digitais. Algumas boas referências para você consultar:

COMO FUNCIONA?

 

Quando me deparei pela primeira vez com o módulo conversor de níveis lógicos, eu fiquei muito intrigado. Testei e funcionou perfeitamente. Mas para mim isso não era o suficiente. Encontrei o esquema elétrico do circuito, ilustrado na Figura 1 e fiquei ainda mais intrigado. Pensei: Mas não tem quase nada!!! Como funciona? Adoro soluções minimalistas. São muito robustas e confiáveis.

Figura 1 – Circuito do conversor de níveis lógicos

 

Resolvi realizar uma análise detalhada do circuito para entender a lógica da solução.

 

ANÁLISE

 

No circuito da Figura 1 podemos observar que cada conversor de lógica digital é constituído de 2 resistores de 10 kOhm e um MOSFET com diodo de proteção contra tensões reversas. Observe que a tensão mais baixa (p. Ex. 3,3 V) deve ser conectado do lado LV do circuito, enquanto a mais alta (p. Ex. 5 V) do lado HV. Para facilitar a análise, vamos separar a análise por direção de transmissão do sinal.

De LV para HV

 

Quando LV1 está em nível lógico 1, tanto o dreno quanto o gatilho estão na mesma tensão, provocando o corte do MOSFET. O efeito provocado em HV1 é que o seu nível é determinado pelo resistor R4 da Figura 2.

Figura 2 – Operação de LV1 para HV1 – nível lógico 1

Quando é aplicado nível lógico 0 em LV1, o dreno do MOSFET é conduzido ao GND enquanto o gatilho permanece em LV. Isso provoca a condução do MOSFET, ligando HV1 ao GND, transferindo o nível lógico zero para o outro lado (Figura 3).

Figura 3 – Operação de LV1 para HV1 – nível lógico 0

De HV para LV

 

Quando HV1 está em nível lógico 1, o efeito provocado em LV1 é que tanto o dreno quanto o gatilho estão na mesma tensão, provocando o corte do MOSFET e o seu nível é determinado pelo resistor R3 da Figura 4.

Figura 4 – Operação de HV1 para LV1 – nível lógico 1

 

Quando HV1 está em nível lógico 0, a conexão de LV1 com GND é fechada através do diodo de proteção do MOSFET, transferindo o nível lógico 0 para LV1 (Figura 5).

Figura 5 – Operação de HV1 para LV1 – nível lógico 0

 

CONCLUSÃO

 

A solução oferecida por esse circuito explora todos os recursos do MOSFET. Note que os níveis lógicos 1 são transferidos pelos níveis determinados pelos resistores, por conta do MOSFET estar cortado, e os níveis lógicos 0 através dos recursos do MOSFET. Não é genial? Deviam dar um prêmio para quem inventou isso! É simples, barato e funciona muito bem!

Por Olga Satomi Yoshida e Leonardo Fonseca Larrubia

 

INTRODUÇÃO

 

Este artigo é parte da série de artigos técnicos SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA. Neste artigo serão apresentados alguns resultados reais obtidos durante o projeto. Para melhor compreensão deste artigo leia antes o artigo técnico “SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA – Descrição do Sistema”.

 

ESTUDO DE CASO PRÉDIO 56

O sistema de medição foi instalado na toalete masculina na entrada do prédio 56 do IPT, que é utilizado pelos alunos de mestrado no período noturno, e durante o dia por colaboradores  majoritariamente do CIAM e da Secretaria Acadêmica do IPT..

Figura 1: Prédio 56 do IPT

Este sistema desagrega, em tempo real, o volume  consumido no toalete por aparelho sanitário, por turno ou hora e por atividade, caracterizando totalmente o consumo de água dos seus usuários, alunos dos mestrados e colaboradores do CIAM. Estas medições podem ser acompanhadas em tempo real na nuvem da Amazon Web Services – AWS,

A seguir são apresentadas as fotos das instalações do sistema de medição na toalete. Na sequência apresenta-se uma série de gráficos descrevendo os perfis de consumo na toalete.

Fotos das instalações e sensores

Figura 2:  Sensores 1,2 e 3,  instalados em 3 mictórios.

 

Figura 3: Sensores 4, 5 e 6, instalados nas mangueiras das torneiras.

 

Figura 4: Sensor no mictório e chave de fluxo.

 

Figura 5: Sensor em uma das torneiras.

 

Figura 6: Sensor contador passagem de pessoas na toalete.

 

Figura 7: Dispositivos medidores protegidos em uma caixa.

 

Figura 8: Dispositivos medidores.

Desagregação do consumo total por aparelho

Figura 9: Desagregação do consumo na toalete por aparelhos.

Perfil do consumo total por dia da semana

Figura 10: Consumo na toalete por dia da semana.

Perfil do consumo por horário

Figura 11: Consumo no toalete por hora do dia.

 

Perfil do consumo por turno

Figura 12: Consumo no toalete por turnos.

 

Base de dados de volumes consumidos dos aparelhos e correlações entre seus perfis de consumo

Este projeto gerou uma base dados referentes aos volumes (quase vazões) consumidos característicos de cada aparelho monitorado. Um resumo desta base é apresentado na Tabela 1, onde para cada aparelho sanitário monitorado tem-se estatísticas de volume consumido por acionamento. Tais informações e dados serão guardados para utilização em sistemas inteligentes de predição de consumo em aparelhos monitorados por chaves de fluxo somente em outras instalações.

 

Tabela 1: Volume (l) consumido por acionamento dos aparelhos

Aparelhos  

 n° de eventos/

 acionamento

Média Desvio Padrão Erro Padrão 1° Quartil Mediana 3° Quartil
Torneira 1 9300 0,426 0,449 0,005 0,179 0,287 0,502
Torneira 2 6289 0,660 0,525 0,007 0,380 0,480 0,829
Torneira 3 1457 0,692 0,932 0,024 0,054 0,363 0,889

Geral Torneiras

17046 0,535 0,548 0,004 0,215 0,399 0,658
Mictório 1 2680 0,575 0,594 0,011 0,202 0,487 0,701
Mictório 2 2252 0,737 0,579 0,012 0,388 0,666 0,882
Mictório 3 2310 0,692 0,525 0,011 0,443 0,591 0,816
Geral Mictórios 7242 0,663 0,572 0,007 0,335 0,585 0,796

 

Nas figuras  Figura 13 a Figura 16 tem-se os histogramas dos volumes consumidos por acionamento nos mictórios e torneiras.

 

Figura 13: Histogramas do volume (l) consumido por acionamento nos mictório 1 e 2.

 

Figura 14: Histogramas do volume (l) consumido por acionamento no mictório 3 e geral nos 3 mictórios.

 

Figura 15: Histogramas do volume (l) consumido por acionamento nas torneiras 1 e 2.

 

Figura 16: Histogramas do volume (l) consumido por acionamento na torneira 3 e geral nas 3 torneiras.

 

Nos gráficos de dispersão das  Figura 17 e Figura 18 vê-se o potencial preditivo do contador de pessoas que entram na toalete. Este potencial é utilizado para prever o consumo em todos os aparelhos sanitários, ver Figura 19Figura 22.

 

Figura 17:  Gráfico de dispersão dos volumes (l/dia) por número de pessoas nos mictórios 1, 2, 3 e soma dos volumes dos 3 mictórios.

 

 Figura 18: Gráfico de dispersão dos volumes (l/dia) por número de pessoas nas torneiras 4 e 5 e soma dos volumes das 2 torneiras.

 

Figura19: Predição de nº acionamentos dos mictórios em função do contador de pessoas.

 

Figura 20 Predição do volume consumido nos mictórios em função do contador de pessoas.

 

Figura 21: Predição de nº acionamentos nas torneiras em função do contador de pessoas.

 

Figura 22: Predição de volume consumido nas torneiras  em função do contador de pessoas.

COMPARAÇÃO DA SOLUÇÃO EXISTENTE COM A DESENVOLVIDA

 

 

 

Características das soluções

 

Solução existente

Solução desenvolvida

Hidrômetros com saída pulsada Sim Não
Sensores Sim no medidor hidrômetro Sim nos aparelhos de consumo de água.
Transmissores de rádio e concentradores Sim Sim
Armazenamento, disponibilidade e processamento de dados na nuvem Não, em geral os dados ficam sob custódia da empresa individualizadora, não ficam acessíveis aos contratantes do serviço de individualização. Sim, na nuvem e disponível para interessados em tempo real.
Solução de prateleira Sim Não
Intervenção local Sim. Muita intervenção. Não, nenhuma.
Pouco Visível Não Um pouco – ver fotos
Portabilidade: ajustável às características de outras instalações Não Sim
Baixo custo Não. O maior custo é das obras necessárias a instalação e depois da manutenção. Sim. Os sensores e a conectividade são baratos.
Inteligência e Aprendizado ou utilização de ferramentas analíticas. Não Sim
Sistema avisa aquando há erros em tempo real Não Sim
Rastreabilidade dos números em tempo real Não Sim
Sistema reajusta consumos de vido a erros nos pulsos em tempo real Não Sim
Sistema reajusta consumos devido ao não envio de dados Não Sim

 

CONSIDERAÇÕES FINAIS

 

Pode-se verificar que a utilização de ferramentas analíticas sobre dados coletados em conjunto de sensores tem grande potencial quando os eventos do local monitorado têm padrões de comportamento que se correlacionam ao longo do tempo e padrões de correlação entre as variáveis medidas e monitoradas simultaneamente nos vários sensores.

Foram estas correlações percebidas pelas ferramentas analíticas que possibilitaram ao sistema de medição as seguintes capacidades:

  • Corrigir os erros nos pulsos acumulados coletados dos sensores e enviados a nuvem;
  • Prever o consumo nas válvulas de descarga a partir das torneiras e contagem de pessoas;
  • Prever o consumo nas torneiras e mictórios somente com a contagem de acionamentos dos aparelhos.

A principal característica da solução é o seu conceito de medidor analítico o que o faz ajustável a qualquer instalação hidráulica e consequentemente portátil; e por isto não é uma solução de prateleira.

A meta técnica para o sistema de medição deste projeto foi estabelecida em 10 % a 20 % como margem de erro para a desagregação do consumo. Considerando que a tolerância ao erro de medição para hidrômetros utilizados no faturamento de água das residências seja de 10 %, a margem de erro alcançada deste sistema de medição em 15 % foi bastante razoável.

Com exceção da mínima visibilidade o sistema de medição desenvolvido atendeu a todas as metas propostas: baixíssimo custo, portátil e não destrutivo. Apesar de não comporem as metas do projeto, as capacidades citadas nesta seção e alcançadas no decorrer da execução do projeto, via o aplicativo tipo dashboard na nuvem são as características mais inovadoras deste sistema de medição.

SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA

Outros artigos da série

 

Licença Creative Commons
Esta obra, “SISTEMA PORTÁTIL DE MEDIÇÃO DE PERFIS DE CONSUMO DE ÁGUA – Estudo de Caso“, de  Olga Satomi Yoshida e Leonardo Fonseca Larrubia está sob a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional.

 

Por Olga Satomi Yoshida e Leonardo Fonseca Larrubia

INTRODUÇÃO

 

Este artigo mostra com detalhes o desenvolvimento do Sistema de Medição Aplicativo utilizado no Sistema de Medição de consumo de água. A Figura 1 mostra a tela de abertura do sistema aplicativo. Na sequência serão apresentadas cada uma das funcionalidades desse sistema. Para melhor compreensão deste artigo leia antes o artigo técnico “SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA – Descrição do Sistema”.

 

Figura 1: Tela principal do sistema aplicativo.

SISTEMA DE MEDIÇÃO APLICATIVO

Armazenamento e processamento na Amazon Web Services (AWS)

Os dados coletados e enviados a nuvem pelo sistema físico de medição precisam ser corrigidos e analisados para gerar os perfis de consumo do local monitorado. Foi desenvolvido um aplicativo tipo dashboard com este proposito especifico, e que qualquer um, em qualquer lugar e a qualquer tempo possa acessar os resultados do aplicativo.

As seguintes tecnologias foram utilizadas para desenvolver o aplicativo.

 

Amazon Elastic Compute Cloud (EC2)

O Amazon Elastic Compute Cloud  (EC2) é um serviço web da Amazon Web Services (AWS) que disponibiliza capacidade computacional segura e redimensionável na nuvem.  A AWS oferece gratuitamente 750 horas de utilização do EC2 executando uma instância t2.micro Linux, RHEL ou SLES (1 GiB de memória e suporte para plataformas de 32 e 64 bits) durante 12 meses  (Figura 2 e a Figura 3).

Figura 2: Tela de Login da AWS.

Figura 3: Página do EC2-AWS que possibilita a administração dos computadores em nuvem.

 

Ubuntu Linux Server

É o sistema operacional (SO) para operar o recurso computacional na nuvem. O sistema é de uso é gratuito e seu código fonte é aberto.

 

R: The R Project for Statistical Computing

https://www.r-project.org/about.html

É uma linguagem e também um ambiente de desenvolvimento integrado para cálculos estatísticos e gráficos. O seu uso é gratuito, assim como o código fonte que está disponível sob a licença GNU GPL. O R possui uma vasta comunidade de usuários que disponibilizam variados “pacotes” (conjunto de rotinas, funções e/ou dados pré-programadas). Neste projeto são utilizados os seguintes pacotes:

    • shiny: cria aplicativos para web que permitem um certo grau de interação com o usuário;
    • shinydashboard: simplifica a criação de dashboard;
    • ggplot2: constrói variados tipos de gráficos;
    • plotly: constrói variados tipos de gráficos interativos;
    • rmarkdown: cria e formata documentos dinâmicos e páginas web estáticas;
    • dplyr: auxilia na manipulação e estruturação de dados;
    • stringi: auxilia na manipulação e formatação de textos;
    • lubridate: auxilia na manipulação e formatação de datas e horas.

 

RStudio Server

É um Ambiente de Desenvolvimento Integrado (IDE) para programação em R que é acessado via browser (navegador). Esse IDE permite uma melhor organização no desenvolvimento do sistema e facilita a programação (Figuras 4 e 5).

Figura 4: Tela de Login para acessar o RStudio Server via browser

Figura 5: Interface do ambiente RStudio Server

Shiny Server

É um servidor que permite a disponibilização online de aplicativos shiny. Possui recursos de escalabilidade, segurança e administração de nível corporativo.

Organização e funções do R

Foi criado um servidor com o sistema operacional (SO) Linux Ubuntu no EC2 da AWS que é responsável por disponibilizar recursos computacionais na nuvem. Nesse SO foi criado um sistema de diretórios para a organização do projeto de medição. Sua estrutura é presentada na Figura 6.

Figura 6: Organização dos diretórios para o projeto de medição de perfil de consumo de água.

Também foram instalados nesse SO os softwares R, RStudio Server e Shiny Server. Toda a programação para leitura, comandos e as análises dos dados foram realizadas usando o R. Os scripts com o códigos em R foram construídos e divididos de acordo com as funcionalidade exigida pelo sistema. Ao todo existem oito scripts, a seguir listados.

  • atualiza.R: conecta-se com a conta do pCloud, baixa, atualiza e faz uma estruturação e formatação inicial do conjunto de dados no diretório do computador da nuvem;
  • func_auxiliar.R: conjunto de funções genéricas de suporte que tem papel secundário nas análises;
  • func_carregaDados.R: conjunto de funções que carregam os dados dos diretórios e os estruturam numa única tabela;
  • func_corrigeDados.R: conjunto de funções que transformam as observações da base temporal de evento para hora, período do dia e dia. Também possuem funções que verificam a consistência e aplicam correções aos dados;
  • func_estatisticas.R: conjunto de funções que obtém informações estatísticas dos dados;
  • func_interface.R: conjunto de funções responsáveis pela construção da interface do aplicativo;
  • func_visualizacao.R: conjunto de funções que geram gráficos;
  • pacotes.R: conjunto de pacotes utilizados na programação e análise.

O RStudio Server foi utilizado como um IDE auxiliar para a interação com o R, além de servir como uma interface de acesso ao servidor via browser. Já o Shiny Server é responsável por “disponibilizar” o aplicativo online, atendendo as requisições de acesso do usuário.

 

Componentes funcionais do aplicativo

De modo geral, o funcionamento do sistema na nuvem pode ser dividido em duas partes: atualização e formatação dos dados e a análise e apresentação dos resultados.  Na Figura 7, pode-se observar que o esquema desenvolvido simplifica todo esse sistema na nuvem: O esquema do processo da operacionalização dos dados na nuvem relacionando o uso de cada tecnologia. Em 1 o desenvolvedor cria toda a operacionalização e análise de dado na nuvem e faz ajustes quando necessário. Em 2 o sistema na nuvem conecta-se ao pCloud e baixa e atualiza os dados no computador na nuvem.  Em 3 o usuário solicita o acesso ao aplicativo quando acessa o endereço via web e recebe as informações e análises (Figura 7).

Figura 7: Esquema do processo da operacionalização dos dados na nuvem.

 

Atualização e formatação dos dados

Consiste em um script em linguagem R (atualiza.R) responsável por baixar os dados do pCloud e salvá-los em um diretório local do sistema operacional Ubuntu Linux. Os dados primários estão organizados em arquivos .csv que são definidos por sensor e por dia. Após serem baixados, esses dados são estruturados em uma única tabela e a quantidade de pulsos acumulada pelo sistema de medição em cada evento é transformada em volume de água consumida. Depois é aplicada uma análise de consistência e, por fim, a tabela é salva. O sistema operacional manda o R executar essa rotina a cada 15 minutos.

 

Análise e apresentação dos resultados no aplicativo

A seguir os resultados de consumo são organizados em três bases temporais: hora, período do dia (madrugada, manhã, tarde e noite) ou dia. Diversas análises estatísticas são aplicadas e vários gráficos são construídos para cada base temporal de consumo. As análises e o monitoramento do consumo são apresentados em um aplicativo do tipo dashboard. Esse procedimento é executado toda vez que um usuário acessa o aplicativo.

 

Inteligências inseridas no aplicativo

A primeira ação do aplicativo é a análise de consistência dos dados monitorados dos sensores. O objetivo é identificar e eliminar ruídos no conjunto de dados. Eventos que apresentam consumos acima de um limite máximo são considerados ruídos e são excluídos. Para as torneiras e mictórios foi fixado um volume máximo de 3600 litros por hora.

Devido a uma falha inerente de conectividade do sistema de medição, há sempre um delay no acionamento do sistema de medição, e portanto foi acrescentado um tempo médio de 2,5 segundos ao tempo de duração dos eventos.

O volume obtido para os eventos de cada ponto de medição é sempre corrigido pela curva média de erro de cada medidor de acordo com as calibrações realizadas em laboratório.

Nos vasos sanitários é registrado apenas a ocorrência de evento com sua respectiva duração, sem ser medido, de fato, o consumo de água em cada evento. Tal consumo é estimado pela multiplicação da vazão média de descarga (obtidas através de estudos anteriores) com a duração do evento.

Com os consumos de cada ponto já estimados e corrigidos parte-se para a fase de análises estatísticas, que procuram descrever o perfil de consumo de água no ambiente. Os consumos, que até então eram por evento, são agregados por hora, por período do dia e por dia. De acordo com cada uma dessas bases temporais são obtidas algumas estatísticas resumo como média, mediana, máximo, mínimo de consumo, entre outras.

Os gráficos de séries temporais exibem a história do consumo até o momento atual. Os gráficos de “pizza” mostram a participação de cada aparelho ou grupo de pontos no consumo total. Os gráficos de barras permitem desagregar o consumo de acordo com a base temporal selecionada, possibilitando a visualização dos picos horários de maior consumo, a verificação de consumo nas madrugadas, ou os dias de maior consumo na semana. Os gráficos  boxplot e histogramas descrevem a distribuição da dispersão dos consumos ocorridos, sendo possível perceber qual é a faixa de consumo mais frequente, se períodos de tempo de consumo elevados são recorrentes, quais os valores de consumo mais destoantes entre muitas outras funcionalidades de análises.

As falhas possíveis de ocorrer são:

  • Perda de dados em decorrência de falta de energia, falta de bateria, ou entupimento da mangueira de água provocando erros como ZEROS ou VAZIOS nos registros de pulsos; ou
  • erro no registro de pulsos tipo outlier impactando no volume calculado.

Foi desenvolvida uma inteligência de dados para gerar alarmes, identificar e corrigir estes erros em tempo real. Na Figura 8 os alarmes estão indicando perda de dados em 3 aparelhos, 2 mictórios e uma torneira. Para estes pontos, a inteligência do aplicativo estima um consumo para toda perda de dado.

Figura 8: No link, a direita indicação de que não está havendo registro de consumo em três aparelhos.

 

Interfaces de acesso às funcionalidades do aplicativo

O aplicativo permite ao usuário ter acesso às informações e análises do consumo de água de forma dinâmica, fácil, simples e em tempo real. O aplicativo apresenta uma interface em essencialmente duas partes: uma barra lateral de navegação  (Figura 9 – A) e um painel que exibe informações e análises de acordo com o item selecionado na barra lateral (Figura 9 – B).

Figura 9: – Tela inicial do aplicativo.

A barra lateral é composta por três itens (Figura 10 – A):

  • Monitoramento: exibe informações do consumo;
  • Informações técnicas: exibe informações mais técnicas sobre o projeto;
  • Sobre: breve descrição do projeto.

Monitoramento: agrupa seis subitens responsáveis por exibir o consumo de água de acordo com o local escolhido pelo usuário (Figura 10 – B):.

  • Global: relativo ao consumo de todo o ambiente.
  • Torneiras: relativo ao consumo das torneiras. Na parte inferior do painel que exibe o acompanhamento de consumo é possível selecionar e exibir as informações individualizadas de cada torneira.
  • Mictórios: relativo ao consumo dos mictórios. Na parte inferior do painel que exibe o acompanhamento de consumo é possível selecionar e exibir as informações individualizadas de cada mictório.
  • Vasos: relativo ao consumo dos vasos.
  • Frequência de pessoas: relativo à quantidade de pessoas que usam o ambiente.
  • Análise de correlação: permite o usuário fazer uma cruzar o perfil de consumo entre os pontos de monitoramento.

Além dos seis subitens há uma barra de seleção que permite o usuário selecionar a base temporal (hora, período do dia ou dia) na qual deseja exibir as informações e análises do consumo; há uma caixa de marcação que permite o usuário escolher se quer ou não considerar os períodos que não houve consumo na análise e, por fim, há dois campos de data em que o usuário pode definir a data de inicio e de fim do período que deseja acompanhar o consumo.

O item Informações técnicas é composto por quatro subitens (Figura 10 – C)::

  • Sensores: exibe detalhes dos sensores e sobre seu funcionamento;
  • Modelagem: exibe informações sobre a modelagem aplicada aos dados;
  • Equipe: exibe a composição da equipe que participou do projeto;
  • Outros: exibe outras informações que podem ser relevantes.

O item Sobre exibe informações gerais sobre o projeto.

Figura 10: Detalhamento da barra lateral.

RESUMO

 

Este artigo apresentou com detalhes a solução desenvolvida para o Sistema de Medição Aplicativo e as diversas funcionalidades e ferramentas de análise que foram disponibilizadas aos usuários.

SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA

Outros artigos da série

 

Licença Creative Commons
Esta obra, “SISTEMA PORTÁTIL DE MEDIÇÃO DE PERFIS DE CONSUMO DE ÁGUA – Desenvolvimento de solução no Amazon AWS“, de  Olga Satomi Yoshida e Leonardo Fonseca Larrubia está sob a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional.

Por Ramon Vals Martin

INTRODUÇÃO

 

Este artigo é parte da série de artigos técnicos SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA. Neste artigo serão desenvolvidas diversas soluções alternativas para realizar a medição indireta do consumo de água em vasos sanitários ou outros pontos de entrega de água embutidos. Para melhor compreensão deste artigo leia antes o artigo técnico “SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA – Descrição do Sistema”.

 

PROTÓTIPOS DE SENSORES ALTERNATIVOS

 

No sistema para determinar o perfil de consumo de água, há situações em que não é possível medir diretamente o fluxo da água. Como exemplo, descargas de vasos sanitários sem caixa acoplada (descargas com válvulas Hydra) não permitem um acesso ao escoamento de forma não invasiva. Neste caso, o monitoramento de consumo pode ser feito pelo tempo de acionamento. Naturalmente, trata-se de uma estimativa em que dados de calibração preliminarmente medidos ou obtidos no catálogo do fabricante da válvula de descarga, ou torneira de acionamento momentâneo, são analisados em conjunto com dados de pressão na linha (coluna de água) e tempo de acionamento. O tempo de acionamento deverá ser determinado com auxílio de um sensor do tipo chave liga/desliga adaptado ao botão de acionamento da válvula, ou através de uma chave de fluxo.

A informação do tempo de abertura da válvula deverá ser transmitida sem fio, preferencialmente por sinal de rádio, para um centralizador que disponibilizará a conexão com a rede local de comunicação ou a publicação em ambiente de nuvem. O transmissor de rádio deverá ser compacto e com baixo consumo de energia para possibilitar a alimentação com bateria de longa duração.

PROTÓTIPO PULSADO  I

 Transmissor

O primeiro protótipo construído utilizava um módulo transmissor de rádio (modelo FS1000A – Módulos transmissor e Receptor de rádio [1]) operando em 433 MHz, modulado com pulsos de largura de 100 µs e taxa de repetição ajustável entre 20 Hz e 30 Hz. No acionamento da descarga, o dispositivo transmitia um burst de rf durante cada pulso.  A duração do evento era feita pela contagem de pulsos recebida no receptor. A Figura 1 mostra o circuito utilizado. A Figura 2 mostra o aspecto dos protótipos montados.

Figura 1: Diagrama esquemático do módulo transmissor

Figura 2: Aspecto da montagem dos circuitos

A alimentação dos circuitos foi feita com pequenas baterias de 12 V utilizadas normalmente em controles remotos. A avaliação de consumo e o efeito de carga da bateria podem ser visualizados nos gráficos da Figura 3. Quando a descarga não é ativada, o consumo do circuito é zero. Os protótipos foram instalados no banheiro masculino no andar térreo do prédio 56 do IPT.

Figura 3: Acima, consumo de corrente durante a transmissão dos pulsos. Abaixo, desvio da frequência em função da tensão da bateria, que pode ser utilizada como uma indicação de carga para programação de troca.

Receptor

O módulo de recepção é composto por um receptor de rádio de 433 MHz e um circuito condicionador de sinal para fornecer pulsos em níveis TTL para os estágios posteriores. O diagrama esquemático do circuito deste módulo é mostrado na Figura 4. O consumo deste módulo é de 20 mA, utilizando uma fonte linear de 5 V. Fontes chaveadas geram muito ruído de RF. Os pulsos de saída TTL tem largura ajustada em 1 ms, e repetem-se enquanto a descarga é acionada. Na Figura 5 é possível observar o aspecto da montagem dos circuitos.

Figura 4: Diagrama esquemático do circuito do receptor.

Figura 5: Aspecto da montagem dos circuitos do módulo do receptor.

Modos de Operação

O sistema pode operar em dois modos de operação:

Frequência única

Os quatro transmissores são ajustados para a mesma taxa se repetição de pulsos.  O receptor opera como totalizador, atribuindo um determinado volume para cada pulso recebido (Não identifica o vaso da descarga).

Frequências múltiplas

Os quatro transmissores são ajustados para quatro frequências diferentes (Ex.: 20 Hz, 23 Hz, 26 Hz, 29 Hz). Quando o primeiro pulso é recebido (placa Zigbee wake up) a totalização é feita em intervalos de tempo parciais (Ex.: A cada 0,5 s), enquanto a recepção de pulsos não cessar. Assim é possível identificar a origem de cada descarga, e atribuir coeficientes de calibração de vazão específicos para cada vaso.

Instalação

Os módulos transmissores foram instalados nos botões de acionamento das válvulas de descarga, conforme ilustrado na Figura 6 e na Figura 7. O módulo de recepção foi montado numa caixa de proteção, conforme a Figura 8. A sua instalação foi feita na parede, acima das pias, num ponto de distribuição de energia, como mostrado na Figura 9.

Figura 6: instalação do módulo transmissor no interior do “espelho” da válvula.

 

Figura 7: Aspecto final da instalação dos transmissores.

 

Figura 8: Montagem do módulo de recepção.

 

Figura 9: Módulo de recepção instalado na parede.

PROTÓTIPO II

Foram realizados diversos testes de funcionamento no sistema implementado, mas os resultados não foram satisfatórios, principalmente em relação à sua susceptibilidade aos ruídos eletromagnéticos ambientes. Numa nova tentativa, foi utilizado um controle remoto comercial de quatro canais, como mostrado na Figura 10. Os botões de acionamento do controle foram substituídos pelas chaves colocadas nas descargas.

Figura 10: Controle remoto de quatro canais, que foi modificado para transmitir informações sobre o acionamento de descargas.

PROTÓTIPO III

Novamente os resultados não foram satisfatórios, pois o sistema não permitia medir a duração do evento, apenas a sua ocorrência. Para sanar este problema, foi projetado um circuito baseado no Encoder PT2262 [2]  (Figura 11) e no Decoder PT2272 [3] (Figura 12). Estes dois circuitos integrados são customizados para aplicações de controles remotos, e permitem a identificação de mais de 8000 endereços de transmissores. Foi montado o circuito mostrado no diagrama esquemático da Figura 13 e Figura 14, que envia um trem de pulsos codificados para o início do evento, e outro trem de pulsos codificados para o final do evento. O diagrama de estados é mostrado na Figura 15. A contagem do tempo entre estes dois códigos é feita no módulo receptor.

Figura 11: Encoder PT2262.

Figura 12: Decoder PT2272.

 

Figura 13: Diagrama de blocos do sistema de transmissão por rádio.

 

Figura 14: Diagrama esquemático do circuito do módulo transmissor.

 

Figura 15: Diagrama de temporização do sistema.

PROTÓTIPO IV

O protótipo anterior foi construído e instalado no banheiro do prédio 56 do IPT, e encontra-se em fase de testes. Até o momento os resultados foram positivos, com alcance suficiente e imunidade ao ruído.  A monitoração do uso de uma descarga já está sendo feita em tempo real com acesso remoto ao tempo e duração do evento.

Para replicar este módulo em grande escala há alguns inconvenientes:  A necessidade de modificar totalmente o controle remoto apenas para aproveitar o transmissor de rádio e o chip de codificação;  A frequência deste transmissor não é permitida no Brasil (315 MHz) para esta aplicação; O chip de codificação é customizado, não permitindo alterações nos protocolos, e sua aquisição é mais difícil; Os processos de transmissão e recepção são lentos (alguns décimos de segundo); A contagem do tempo é feita no módulo receptor.  Para evitar estas limitações, esta sendo desenvolvido um novo módulo transmissor, que utiliza componentes padronizados de baixo custo e consumo, que são facilmente adquiríveis (contadores, portas lógicas e shift registers de tecnologia cmos).  Nesta nova configuração, a contagem do tempo é feita no próprio módulo transmissor. Este envia um código de 16 bits logo após o final do evento com a sua duração e a identificação da origem.  Este código é configurável por hardware. Exemplo de configuração: 2 bits de sinalização, contador de tempo de 9 bits (tempo máximo de evento de 10 s  com resolução de 20 ms), endereço de 5 bits (até 32 dispositivos).  Não há necessidade de decodificador no receptor de rádio. A saída do receptor já fornece o código de 16 bits de forma serial.

O protótipo do módulo transmissor nesta nova configuração já está em fase de construção para testes de desempenho e comparação com as configurações dos protótipos anteriores. 

 

SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA

 

Outros artigos da série

 

 Referências 

 

 Licença Creative Commons

Esta obra, “SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA – Soluções alternativas para medir fluxo de água“, de  Ramon Vals Martin está sob a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional.

Por Ícaro Gonçales e Henrique Frank Werner Puhlmann

INTRODUÇÃO

 

Este artigo é parte da série de artigos SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA. Neste artigo serão descritas algumas soluções exploradas para contar o número de pessoas que consomem a água monitorada para completar a estatística sobre esse monitoramento. Para melhor compreensão deste artigo leia antes o artigo técnico “SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA – Descrição do Sistema”.

 

DESENVOLVIMENTO DO TRABALHO

 

A maioria dos ambientes a serem monitorados tais como banheiros, refeitórios, vestiários etc, caracterizam-se por ter apenas uma entrada e saída pela mesma porta. Assim é possível instalar um único contador de passagem de pessoas para que se possa medir o fluxo de pessoas no ambiente. Há alguns critérios a serem considerados, especialmente por se tratar de monitoramento de ambiente público:

  • Equipamento tem que ser discreto;
  • Localizado preferencialmente na parte interna do ambiente a ser monitorado;
  • Que possa ser instalado em local que fique fora do alcance dos usuários;
  • Não pode parecer que é algum tipo de câmera;
  • Ser de baixo custo.

Por se tratar de ambiente com uma única entrada e saída, é desnecessário discriminar a entrada e a saída de pessoas. Um único contador registra o fluxo em dobro. Basta dividir por dois para obter o número de pessoas que estiveram no ambiente. Geralmente a porta desses ambientes abre-se para o lado de dentro. Isso precisa ser considerado quando se pensa em selecionar sensores. Sensores do tipo infravermelho ou barreiras ópticas teriam que ser instaladas do lado externo do ambiente.

Inicialmente, considerando os critérios apontados, escolhemos o módulo sensor ultrassônico HC-SR04 [1]  para essa tarefa, pois ele mede distâncias e, se instalado na parte superior da porta, a abertura dessa porta poderia facilmente ser identificada e ignorada pelo software. A passagem de pessoas seria detectada numa faixa de alturas pré-determinadas. Parecia que o problema estava resolvido. Quando iniciaram-se os testes práticos, constatou-se que havia situações bastante comuns em que o detector falhava e que esse tipo de situação era frequente. O sensor não funciona se utilizado para detectar materiais fofos. Por exemplo capuz de moletom, cabeleira farta, chapéus, bonés etc. Apenas os carecas seriam detectados. Na prática esse sensor mostrou-se ineficaz.

Foi realizada uma pesquisa na internet e foi encontrado um artigo técnico que descreve o mesmo problema, que foi solucionado com a utilização do sensor de movimento do tipo PIR (Passive Infrared Sensor) em condições adaptadas para operar como sensor de passagem. Trata-se do artigo técnico  Counting Human Activity with an Arduino [3].Testamos a solução sugerida no artigo técnico e funcionou bem. Foi desenvolvido um novo projeto utilizando-se o módulo sensor de presença do tipo PIR modelo HC_SR501 [2].

 

DISPOSITIVO CONTADOR DE PESSOAS

 

O Dispositivo Contador de Pessoas é composto por um Dispositivo Medidor, plataforma padrão desse projeto, com um firmware customizado para essa função, acoplado a um módulo sensor PIR  e alimentado por uma fonte de alimentação ligada à rede elétrica. Esse dispositivo não pode “dormir” para economizar energia. Foi necessário realizar uma pequena adaptação no Dispositivo Medidor original para viabilizar o uso da mesma plataforma para o contador de pessoas. Os detalhes podem ser observados na Figura 1.

Figura 1: Detalhes do Contador de Pessoas

 

O contador de pessoas foi desenvolvido a partir do módulo sensor HC-SR501, que pode ser visto na Figura 2. O sensor PIR detecta variações de níveis de radiação infravermelha. Ele possui dois sensores de infravermelho e dessa forma consegue capturar a passagem de uma pessoa de acordo com a diferença dos valores obtidos. Para ampliar a área de detecção, utiliza-se montado por cima do sensor uma lente de Fresnel, que permite aumentar o ângulo de detecção em até 100°. Os detalhes técnicos descritos aqui você encontra mais detalhados no Manual datalhado do módulo sensor HC-SR501 [2].

 

Figura 2 – Sensor PIR HC-SR501

O módulo sensor HC-SR501 permite que se realize alguns ajustes tanto nos tempos da operação quanto de sensibilidade. Para operar como contador de pessoas, posicionado próximo à porta do ambiente a ser monitorado, é necessário ajustar o sensor para que o alcance seja o menor possível e o tempo de acionamento também, de forma a otimizar a captura de passagem das pessoas. O sensor  possui 2 potenciômetros de ajustes, de acordo com a Figura 3, sendo o da esquerda é responsável por ajustar a sensibilidade, variando o alcance de detecção de 3 m até 7 m, e o da direita ajusta o sincronismo do pulso de saída, variando o tempo de acionamento de 2,5 s até 12,5 s.

Figura 3: Ajuste do sensor PIR

 

O jumper de ajuste de função pode ser configurado na função H (Figura 3), que faz com que o pino de saída permaneça em nível lógico alto enquanto há movimento. Já a configuração L faz com que o pino de saída seja acionado em um tempo pré-definido, de acordo com o potenciômetro do sincronismo de saída.

Foi utilizada a configuração do jumper na posição L e utilizado a configuração mínima dos potenciômetros, regulando a sensibilidade para 3 m e após a passagem de  uma pessoa, ficando a saída acionada por 2,5 s.

Após alguns testes, concluiu-se que esses tempos ainda estavam altos para a aplicação de contagem de pessoas. Demorava muito para o sensor ficar pronto novamente para capturar uma nova passagem. Foi necessário diminuir esse tempo. No Manual datalhado do módulo sensor HC-SR501 [2] está descrito um procedimento para otimizar ainda mais alguns tempos do módulo sensor alterando o valor de alguns resistores para isso. O potenciômetro de sincronismo de saída está em série com um resistor, estando ambos em paralelo a um capacitor. O tempo de descarga desse RC define quanto tempo ficará acionada a saída, por isso foi modificada a resistência, original de 1,5 kΩ para 100 Ω, alterando assim o tempo de acionamento de 2,5 s para 2 s. Também foi modificado o resistor de espera, de 1 MΩ para 120 kΩ, alterando o tempo de espera de 5 s para 0,6 s,  resultando num período total de 2,6 s . Esses resistores são mostrados na Figura 4.

Figura 4: Resistores de controle de tempo

 

Foi construído um circuito eletrônico para casar a interface de saída do módulo sensor com a entrada do módulo com microcontrolador cuja finalidade é de casar os níveis lógicos dos módulos, indicar o acionamento do sensor através de um LED, e para a proteção mútua tanto do microcontrolador quanto do módulo sensor O esquema elétrico dessa interface está ilustrado na Figura 5.

Figura 5: Esquema eletrônico do circuito de interface

 

A Figura 6 mostra a placa de teste com o circuito eletrônico da Figura 5 montado.

Figura 6: Placa de teste para coleta de dados do sensor

 

Foi realizada uma adaptação na placa do Dispositivo Medidor de forma que se possa utilizar o contador por hardware como contador acumulador de passagem de pessoas. Quando o módulo sensor detectar a passagem de uma pessoa, o microcontrolador registra essa passagem e aciona o clock do contador para incrementar a contagem de 1 se e quando o software determinar que houve mais uma passagem. A adaptação pode ser vista na Figura 7.

Figura 7 – Configuração na placa de comando para acumular a contagem via hardware

 

A função desse projeto é somente detectar a passagem de pessoas pela porta do banheiro do ambiente escolhido para testes. De acordo com a sugestão dada no artigo técnico Counting Human Activity with an Arduino – [3], foi utilizado um dispositivo tubular para focar a área de atuação do sensor, como é mostrado na Figura 8. Trata-se de um papelão de um rolo de papel higiênico, que tem as dimensões exatas para essa aplicação. (Destino poético para o tubo de papelão… Bastante adequado para monitorar um banheiro)

Figura 8: Dispositivo com a finalidade de focar a área de atuação do sensor de presença

 

Na Figura 9 pode-se observar a local onde o Contador de Pessoas foi instalado (bem próximo à porta). O movimento da porta não aciona o módulo sensor..

Figura 9: Local de instalação do módulo sensor PIR

Descrição da operação do Contador de Pessoas

Eventos previstos

  • Detecção de passagem de pessoas;
  • Atuação por tempo de inatividade, para sinalizar que o contador está operante (heartbeat).
  • Registro de que o Contador de Pessoas foi Ligado / Religado ou “ressetado” por algum motivo.

Descrição da operação após cada evento

  • Passagem de pessoa –  O contador de pessoas registra a passagem e transfere imediatamente a contagem acumulada ao concentrador. Monitora essa operação com um temporizador (time-out).

RESUMO

 

Neste artigo técnico foi apresentada uma solução simples para a realização de um contador de passagem de pessoas utilizando-se um módulo sensor PIR HC-SR501 e um tubo de papelão para restringir a área de atuação do sensor a um cone bastante estreito permitindo que o sensor de presença funcione como um sensor de passagem.

 

SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA

Outros artigos da série

 

Referências

 

Licença Creative Commons
Esta obra, “SISTEMA PORTÁTIL DE MEDIÇÃO DE PERFIS DE CONSUMO DE ÁGUA – Contador de pessoas utilizando PIR“, de  Ícaro Gonçales e Henrique Frank Werner Puhlmann está sob a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional.

Por Henrique Frank Werner Puhlmann

INTRODUÇÃO

 

Este artigo é parte da série de artigos SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA. Neste artigo será descrita a solução adotada para implementar um Dispositivo Medidor versátil. Para melhor compreensão deste artigo leia antes o artigo técnico “SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA – Descrição do Sistema”.

 

ESPECIFICAÇÕES

 

O Dispositivo Medidor versátil é a porta de entrada para o sistema de medição de consumo de água desenvolvido. Ele possui recursos que permitem medir por meio de sensores o consumo de água em tempo real. Na Figura 1 podemos observar um diagrama simplificado do sistema completo.

Figura 1: Diagrama do Sistema

Observe que o Dispositivo Medidor é instalado em cada ponto de entrega de água, quando possível.

O sistema eletrônico para medição de água deverá atender aos seguintes requisitos técnicos:

  • Ser de baixíssimo consumo;
  • Que opere alimentado por baterias;
  • Fácil troca de baterias;
  • Dimensões reduzidas;
  • Discreto;
  • Permitir a instalação individual nos pontos de entrega de água;
  • Facilmente reconfigurável;
  • Que se comunique com um gateway por meio de uma rede sem fio;
  • Etc.

DESENVOLVIMENTO DO TRABALHO

 

Ficou decidido que seria realizado um projeto eletrônico customizado para atender a esses requisitos. Inicialmente foi realizada uma pesquisa de possíveis plataformas de desenvolvimento candidatas para o projeto. Essas plataformas deveriam atender aos seguintes requisitos:

  • De baixo consumo de energia (bateria/pilha);
  • Dimensões reduzidas;
  • Estar acondicionado em módulo autônomo por conta do prazo para o desenvolvimento;
  • Possuir interface para contador interno, ou permitir utilizar um externo;
  • Relógio interno de tempo real;
  • Entradas digitais;
  • Interface com rádio no módulo, Wi-Fi, Bluetooth, Zigbee ou LoRa;
  • Bom alcance da comunicação sem fio, mesmo quando operado com baterias;
  • Encapsulamento fácil de ser soldado em placa de suporte desenvolvida no IPT;
  • Possuir kit de desenvolvimento de baixo custo para desenvolver a PoC;
  • Software de desenvolvimento gratuito ou de baixíssimo custo;
  • Kits de desenvolvimento para acelerar o aprendizado e o desenvolvimento propriamente dito;
  • Outros.

Os resultados dessa pesquisa, realizada no início de 2017, encontram-se na Tabela 1. Considerando a velocidade em que surgem novas tecnologias e desaparecem tecnologias aparentemente sólidas, os dados dessa tabela podem estar obsoletos após quase dois anos.

Tabela 1 – Comparativo das plataformas pré-selecionadas

Aplicando os critérios de seleção e alguns critérios internos de investimento em tecnologias inovadoras, foi selecionada a plataforma para o LoPy da Pycom. O LoPY possui internamente módulos prontos para comunicação Wi-Fi, Ble e LoRa. Para maiores detalhes técnicos, consulte o Manual do LoPy [1].

Utilizando essa plataforma como base do desenvolvimento, foi projetada uma placa eletrônica para acomodar a maioria dos critérios pré-estabelecidos. O Dispositivo Medidor, mostrado na Figura 2, é composto por diversos blocos funcionais. Ele é alimentado por pilhas ou baterias recarregáveis, dispostas em gabinete externo e ligado à placa por meio de um conector. A tensão de alimentação passa pelo bloco de Fonte de Alimentação, que basicamente cuida da segurança contra sobrecargas e inversão de polaridade para proteção do Dispositivo. Paralelamente é medido o nível de tensão da bateria para que se possa monitorar a carga da bateria e sinalizar quando a bateria está fraca.

Figura 2: Detalhes do Dispositivo Medidor

Há um módulo integrado, que gerencia o Dispositivo Medidor, e que contém um poderoso microprocessador e módulos de rádio integrados no mesmo bloco (LoPy). Os módulos de rádio permitem a comunicação por meio de Wi-Fi, Bluetooth e LoRa, sendo que a seleção e configuração é simples. Neste projeto foi utilizado um módulo de rádio adicional de comunicação ZigBee do tipo XBee.

Para medir a vazão de água foram selecionados dois tipos de medidores a serem utilizados conforme a necessidade: Uma chave de fluxo, que fecha um contato quando o fluxo de água é maior do que um determinado patamar e um medidor do tipo roda d’água que gera pulsos conforme a água vai passando pelo medidor.

Os pulsos gerados pelo medidor de vazão são acumulados num contador para que estejam disponíveis para leitura quando o microprocessador o solicitar. Foi prevista a inclusão de um detector de pulsos, que gera um sinal ao microprocessador quando houver pulsos vindos do medidor de vazão com a finalidade de acordar o microprocessador, se este estiver “dormindo”. Esse recurso serve para conservar a energia das baterias, e para sinalizar o início e fim do fluxo de água.

Outro recurso disponível no dispositivo são mini chaves programáveis para atribuir um endereço para a placa  e selecionar a configuração para medição usada no dispositivo. A placa resultante do projeto pode ser observada na Figura 3.

Figura 3: Vista da placa do Dispositivo Medidor

As chaves destacadas em amarelo, compõem o endereço atribuído à placa, 32 endereços possíveis (0 a 31). As chaves destacadas em azul correspondem à programação de função de operação da placa, permitindo sinalizar até 8 funções distintas. A seguir, algumas funções já definidas:

  • Medidor de vazão com sensor do tipo roda d’água;
  • Medidor de vazão com sensor de fluxo;
  • Medidor combinado: Fluxo e Vazão;
  • Medidor Especial para vasos sanitários;
  • Contador de pessoas;
  • Datalogger;
  • Reserva;
  • Contador de pessoas sempre ligado.

Obs:   As funções já vêm pré-programadas no firmware desenvolvido para o dispositivo. Não há a necessidade de se programar um novo firmware quando for trocada a função de operação.

O sistema de medição foi instalado na toalete masculina na entrada do prédio 56 do IPT, que é utilizado pelos alunos de mestrado no período noturno, e durante o dia por colaboradores majoritariamente do CIAM e da Secretaria Acadêmica do IPT. Na Figura 4 pode-se observar detalhes da instalação de testes. Note que cada ponto de entrega de água tem um medidor de fluxo de água e uma placa eletrônica associados.

Figura 4: Vista das placas acomodadas numa caixa de proteção e dos pontos monitorados.

Especificação da operação dos Dispositivos Medidores 

Como os Dispositivos Medidores são operados com pilhas ou baterias recarregáveis, eles passam a maior parte do tempo em estado de espera, “dormindo”, consumindo um mínimo de energia até que ocorra um evento. O evento é processado e enviado imediatamente ao concentrador.

Eventos previstos para acordar o Dispositivo Medidor

  • Quando operando na configuração de atuação por chave de fluxo, ocorre a detecção de fluxo de água (Fecha-se o contato);
  • Quando operando na configuração de medição de vazão com medidor do tipo roda d’água, ocorre a detecção de vazão no medidor (Geração de pulsos digitais);
  • Por tempo, a cada 1 Hora após o último evento, para sinalizar que o dispositivo está operacional (Heartbeat), ou num intervalo de tempo menor a ser definido, 15 minutos, por exemplo, quando está operando no modo de Aquisição de Dados;
  • Registro de que o Dispositivo foi Ligado / Religado ou “ressetado” por algum motivo.

 

COMENTÁRIOS

 

O módulo LoPy, quando adquirido, não estava muito maduro. Apresentou diversos problemas ao longo de sua utilização. Só para citar alguns:

  • A corrente consumida no estado de sono profundo (deep sleep) fica em torno de 12 mA;
  • Tivemos diversos problemas com as ferramentas de desenvolvimento de software, travamentos etc;
  • O módulo apresentou um comportamento estranho de alguns pinos de I/O durante as fases de dormir e acordar do estado de deep sleep;
  • O módulo demora entre 2 a 3 segundos para acordar do deep sleep;
  • A memória reservada para os scripts de MicroPython é pequena. Comporta no máximo 32 kBytes de tamanho;
  • A documentação de modo geral é bem precária e a assistência técnica quase nula.

Por outro lado, o sistema se mostrou bastante versátil, poderoso e fácil de programar. Apesar do consumo de corrente elevado, utilizando-se baterias recarregáveis de 2.500 mAH, a carga da bateria dura até 6 dias quando se tem um uso moderado dos equipamentos e no mínimo 2 dias com um uso constante. Atualmente (2018) o LoPy já ficou obsoleto, entrando o LoPy4 em seu lugar. Numa primeira leitura me parece que muitos desses problemas foram corrigidos.

SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA

Outros artigos da série

 

Referências

 

Licença Creative CommonsEsta obra, “SISTEMA PORTÁTIL DE MEDIÇÃO DE PERFIS DE CONSUMO DE ÁGUA – Dispositivo Medidor versátil“, de  Henrique Frank Werner Puhlmann está sob a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional.