Estratégias de programação para portáteis

No projeto montado anteriormente há algumas melhorias que podemos fazer. Nesse caso será otimizar o código a partir da verificação de dados e, assim, adicionar o Modem Sleep.

Vamos observar o código e pensar um pouco…É fácil perceber onde pode ser melhorado e será exatamente onde o consumo é maior, na transmissão de informações pela internet (uso do WiFi). Ao adicionar uma verificação de dados, podemos ignorar dados irrelevantes e, assim, prolongar a vida da nossa bateria. Veja o que será feito:

• Adicionar a verificação da temperatura para enviar uma nova temperatura apenas se esta for diferente da última enviada, poupando, assim, envios desnecessários ao banco de dados e consumo desnecessário de energia com a transmissão WiFi;
• Na verificação de temperatura, a conexão com a internet não é necessária, então iremos ligar o WiFi apenas quando a verificação acima for verdadeira. Neste meio tempo o ESP32 ficará com o WiFi OFF (Modem Sleep).

Anteriormente, melhoramos o consumo aumentando o intervalo de sleep, entretanto a temperatura pode variar bem mais rapidamente dependendo do local. Logo, dormir por 2 horas não é interessante. Agora vamos melhorar o código e depois as explicações!

Código do projeto pode ser visto abaixo:

#include <DHT.h>
#include <WiFi.h>
#include <WiFiClientSecure.h>

DHT dht(23, DHT11);
WiFiClientSecure client;
float t = 0, u = 0;//Variaveis que armazenam a leitura ATUAL

RTC_DATA_ATTR float lt = 0;//Variavel alocada na RTC RAM da ultima temperatura lida (Last Temp)

//Variaveis alocadas na RTC RAM não são perdidas entre Deep Sleep, então
//usamos para guardar a ultima temperatura lida e fazer uma nova verificação
//no proximo Wake UP

void setup()
{
		pinMode(23, INPUT);//Pino de dados do DHT11
		dht.begin();//Inicializa o DHT11
		
		t = dht.readTemperature();//Atribui a temperatura atual na variavel "t"
		u = dht.readHumidity();//Atribui a umidade atual na variavel "u"


		if (lt != t)//Se a ultima temperatura lida for diferente da atual, irá enviar ao banco de dados
		{
			lt = t;//Iguala a ultima temp. com a temp. atual
			WiFi.mode(WIFI_STA);//
			WiFi.begin("SUA REDE", "SUA SENHA");//Conecta no WiFi

			for (int i = 0; i < 500; i++)
			{
				delay(10);
				if (WiFi.status() == WL_CONNECTED)//Se conseguir conectar no WiFi
				{
					if (client.connect("docs.google.com", 443) == true)//Se conseguir conectar no servidor da Google
					{
						String toSend = "GET /forms/d/e/1FAIpXXXf6EKACSqEhAsXXXKb3qDBiNSh6MXn6ck44TBj7zRYH72SXXX/formResponse?ifq";
						toSend += "&entry.634150418=";	toSend += t;
						toSend += "&entry.2106983911=";	toSend += u;
						toSend += "&submit=Submit HTTP/1.1";

						client.println(toSend);
						client.println("Host: docs.google.com");
						client.println();
						client.stop();
					}

					break;//Encerra o loop FOR()
				}
			}
		}

		
		ESP.deepSleep(300000000);//Dorme por 5 minutos


}

void loop()
{

}

O fluxograma está mais simplificado na parte de envio e conexão com WiFi (se comparado ao anterior), mas a ideia é apenas mostrar a condicional que verifica a última temperatura lida com a atual. Como vimos anteriormente, nos dados gerados pelo sensor, a temperatura se alterou 1°C a cada 2 horas, logo, percebemos que a “seta não” da condicional ocorrerá 24x mais que a “seta sim”, uma economia bem grande já que o maior consumo está no WiFi.

Foi feita uma nova medição do tempo de processamento para melhorar os cálculos e chegar a um novo e último consumo médio do projeto:

• Consumo médio em transmissão (WiFi): 150 mA;
• Consumo médio ao ler o sensor: 50 mA (clock a 240 MHz);
• Consumo médio em Deep Sleep: 75 uA (15 uA + 60 uA do DHT11);
• Tempo em transmissão (WiFi): 4,6 segundos;
• Tempo lendo o sensor: 23 ms;
• Tempo em Deep Sleep: 5 minutos.

Entretanto, devemos lembrar que a transmissão dos dados é ~24x menos frequente que a leitura do sensor. Logo, vamos dividir alguma das variáveis relacionadas com a transmissão por 24, iremos escolher o consumo em Deep sleep.

Consumo real do projeto IoT Portable:

Duração em horas do projeto (765 dias):

Você pode estar perguntando por que o consumo com as estratégias de programação deu um consumo maior (172uA) do que o último cálculo feito no artigo anterior (164uA). Isso se deve ao fato de que lá foi usado Deep sleep de 2 horas e, neste tempo, perdemos muitas leituras, inviabilizando vários tipos de projetos. Agora foi feito com Deep sleep de 5 minutos (24x mais frequente) e mesmo assim, podemos resumir que o consumo foi igual, mostrando como um código bem escrito e manipulado pode ser mais econômico do que usar sleep’s frequentes ou com tempo longo.

Observação importante: O consumo poderia ser facilmente reduzido aproximadamente 20-100x diminuindo a velocidade do clock, trocando por um sensor melhor e mais rápido e até usando o ULP.

Conclusão

Agora que nossa série chegou ao fim, podemos perceber a imensa importância de uma programação bem feita e principalmente os métodos de Sleep para o mundo de IoT, Sistemas embarcados e Wearables que fazem uso de baterias.

Aplicando os conceitos mostrados nesta série, você conseguirá criar inúmeros dispositivos portáteis que durem anos em uma barata e pequena bateria, o limite é sua imaginação.

Os conceitos mostrados aqui são aplicáveis a qualquer microcontrolador, desde PIC’s até ARM’s, diferenciando basicamente os consumos e nomes de Sleep’s.

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ã?