Construindo o projeto de IoT portátil

Este post faz parte da série Projeto IoT portátil. Leia também os outros posts da série:

Finalmente chegamos na parte de começar a dar vida ao projeto IoT portátil. Até aqui você já aprendeu a dimensionar a bateria pro seu projeto e também a calcular o consumo médio. Então vamos prototipar o projeto!

 

As referências sobre instalação do ESP32 na Arduino IDE e também como usar o Google planilhas para enviar dados do microcontrolador para planilha são importantes.

 

Já foi citado como o projeto funcionará, mas vamos relembrar. Será um Datalogger que enviará a temperatura e umidade do local para um banco de dados online, usaremos o Google planilhas pois dispensa um servidor para host, gratuito, permite compartilhar os dados facilmente com qualquer pessoa, aplicar fórmulas, desenhar gráficos e muito mais ao estilo Excel. Vamos programar logo e depois as explicações.

 

Código do projeto pode ser obtido aqui.

 

Protótipo simples do projeto portátil com bateria 18650.
Figura 1 – Protótipo simples do projeto portátil com bateria 18650.
Dados e gráfico gerado pelo projeto com DHT11.
Figura 2 – Dados e gráfico gerado pelo projeto com DHT11.
Fluxograma do projeto IoT portátil.
Figura 3 – Fluxograma do projeto.

 

Observações sobre os dados:

  • Intervalo entre leituras: 5 minutos;
  • Total de leituras: 92;
  • Tempo total de colheita: 9 horas
  • Apesar das leituras de umidade oscilarem bastante por motivos desde protoboard até sensor ruim, com a linha de tendência linear foi possível notar a redução da umidade conforme o aumento da temperatura.

 

Como em todo projeto de sistemas embarcados, as condições do ambiente a ser monitorado podem influenciar no funcionamento, dando margem a melhorias de desempenho (e, nesse caso, consumo energético). Observando o ambiente cuja temperatura foi monitorada, nota-se que a temperatura do local demorou aproximadamente 2 horas para variar 1°C e, neste meio tempo, foram enviados 24 valores iguais de temperatura. Para este projeto, estes 24 valores iguais de temperatura significam 24 envios de um mesmo valor de temperatura, levando à conclusão que estes envios causaram grande consumo energético desnecessário (uma vez que o grande “vilão” do consumo no projeto é a transmissão de dados por Wi-Fi, conforme visto na parte 1 desta série). Logo, poderíamos enviar apenas valores diferentes de temperatura, diminuindo, assim, o uso do Wi-Fi e, por consequência, aumentando a economia da bateria, nesse caso para 24x.

 

Vamos fazer algumas contas para dar um norte a esta nova informação, que deixará o ESP32 dormindo por 2 horas:

  • Capacidade da bateria: 3000mAh;
  • Consumo médio com 2 horas de sleep: 36uA;
  • Obs: A transmissão foi feita em média a cada 2 horas, portanto o ESP32 dormiu 2 horas e depois enviou.

 

Consumo médio com 2 horas de sleep:

 

Cm=0.151+0.00001572001+7200

Cm36uA

 

Tempo de duração da bateria com 2 horas de sleep:

 

T=30.000036

T=83333Horas

 

Veja que para este caso, com 2 horas de intervalo entre transmissões de dados, a bateria duraria (teoricamente) 9 anos e 200 dias! Incrível não?! Mas nem tudo são flores, todas contas desse projeto até agora foram apenas para dar um norte, excluindo todos componentes extras do circuito. O tempo real de execução do código ainda será calculado e o consumo provavelmente será bem maior por conta dos componentes extras no circuito.

 

Vamos começar a fazer alguns ajustes de tempo e consumo para que no próximo post seja calculado o tempo real de duração para nosso projeto.

 

Foi observado o tempo em que cada ação demora para ocorrer, separado por partes:

  • Conexão com Wi-Fi: 2.5 segundos (por causa do Wi-Fi – SCAN);
  • Comunicação com a planilha: 1.7 segundos;
  • Total: 4.26 segundos.

 

Agora precisamos do real consumo do circuito, que anteriormente foi levado em consideração apenas o ESP32. Entretanto, há um componente a mais, o DHT11. De acordo com o Datasheet do DHT11, o consumo é:

  • Em medições: 300uA;
  • Em Standby (sleep): 60uA.

 

As medições do DHT11 podem demorar até ~25mS, o restante do tempo ele se encontra em Standby. Logo, vamos arrumar o último cálculo de consumo do projeto (Figura 4).

 

Consumo médio do projeto que se aproxima a realidade:

 

Cm=0.154.26+0.00007572004.26+7200

Cm164uA

 

Tempo de duração da bateria que se aproxima à realidade:

 

T=30.000164

T18293Horas

 

Veja que arrumando as contas com novos tempos e componentes, o consumo ficou 4.5x maior que os anteriores, que eram apenas simulações para nos guiar. Entretanto, a bateria ainda irá durar ~2 anos, que é um bom intervalo.

 

Observações importantes em relação aos tempos do ESP32

 

  1. A conexão com Wi-Fi pode chegar até ~300mS, entretanto, como o ESP32 é reiniciado totalmente, é preciso configurar toda pilha Wi-Fi novamente. E o ESP32 faz o uso da LWIP, que não é muito otimizada em velocidade, e algumas mudanças, como IP fixo, podem melhorar esses tempo;
  2. Se você precisa de uma inicialização do Deep Sleep mais rápida, há inúmeras configurações que permitem isso, por exemplo, a calibragem do RTC_SLOW_CLK que leva por padrão 1024 ciclos do XTAL principal (~2.5uS) e o tempo extra de inicialização da FLASH (~2mS);
  3. Você pode notar alguma perda de “temporização” ao usar longos períodos de Deep Sleep, isso acontece pois o cristal do RTC é mais instável que o cristal principal. Você pode melhorar a precisão configurando uma calibragem maior (como citado na Obs 2), que é útil em Deep Sleep’s de longo período.
  4. A conexão com a planilha é relativamente lenta, pois a conexão ao servidor do Google planilhas é feita por SSL/TLS (HTTPS) e isso necessita de um processamento maior e maior número de trocas de mensagens entre cliente e servidor. Logo leva a um tempo de Wi-Fi ativo maior do que se comparado ao caso de uso de HTTP “simples” ou MQTT, por exemplo.

 

Nosso projeto finalmente está vivo e pronto, mas existe algo a mais que podemos fazer para melhorar o consumo e aumentar ainda mais a duração da bateria, caso seu projeto precise de extrema economia: estratégias de programação. Vamos melhorar a eficiência desse código apresentado, incluindo verificações de dados e um modo de economia a mais, o Modem Sleep.

 

Saiba mais sobre IoT

 

Enviando dados para a nuvem com Azure IoT Hub

IoT: Contexto geral, presente e perspectiva futura – Parte 1

Como conectar a DragonBoard 410C no IBM Watson IoT Platform

Editorial: IoT – Internet das Coisas – Mocinha ou Vilã?

 

Referências

 

Instalando ESP32 na Arduino IDE

Google planilhas para debug

Datasheet do DHT11

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *