A Jornada do Hardware: Construindo o Protótipo do pikoAQI

Introdução

Eu queria criar um projeto de hardware, mas não tinha nenhuma habilidade técnica em eletrônica ou desenvolvimento de hardware. Então, comecei este projeto para aprender no caminho, sabendo que a inteligência artificial poderia me dar uma força.

O projeto é um sensor de qualidade do ar vestível e portátil. Escolhi essa ideia porque eu mesmo precisava de um, e o nível de dificuldade é perfeito: não é preciso fazer pesquisa e desenvolvimento de sensores, já que eles existem no mercado, mas também não é fácil demais, pois várias funções precisam operar juntas em um formato compacto e com baixo consumo de energia.

Comprando as peças do protótipo

Para começar, expliquei minha ideia ao Claude (a IA), que me ajudou a debater ideias e a escolher os componentes eletrônicos.

Aqui está o meu primeiro pedido na loja de eletrônicos:

Por que escolhi esses componentes

• ESP32: um microcontrolador de entrada, mas muito capaz, com Wi-Fi/Bluetooth integrados, tamanho compacto e poder de processamento suficiente para uso em produção.
• Tela e-ink: consumo de energia extremamente baixo. Só precisa de energia durante as atualizações da tela e mantém a imagem quando desligada.
• Módulo GPS: funcionalidade básica de GPS para rastreamento de localização.
• Sensor de qualidade do ar (SDS011): detecta material particulado (PM2.5, PM10) no ar.
• Sensores BME280/BME680: medem temperatura, pressão, umidade e compostos orgânicos voláteis (COVs).

Trabalhando com a tela e-ink

A primeira peça que testei foi a tela e-ink. A que eu encomendei não tinha documentação técnica, apenas um exemplo para Arduino. Passei isso para o Cursor como contexto, e ele conseguiu fazê-la funcionar no meu código.

A tela se comunica via SPI. A placa ESP32 deveria ter uma implementação SPI integrada, mas não consegui fazê-la funcionar com a tela. Por isso, mantive a implementação SPI personalizada do exemplo da documentação.

O problema da tecnologia e-ink é a taxa de atualização: é muito lenta. Uma mudança completa na tela pode levar até 2 segundos.

A tela possui dois modos: "atualização parcial" e "atualização completa". A atualização parcial é mais rápida, pois não precisa reescrever a tela inteira. Usei isso para criar um modo de atualização "rápido":

1. Fazer uma atualização parcial para uma tela toda branca, limpando a imagem atual
2. Fazer uma atualização parcial para desenhar a nova imagem

Pode ocorrer algum efeito fantasma (ghosting), então o modo rápido serve apenas para casos em que isso não seja um problema.

Resultados dos testes:

• Atualização completa: 2 segundos
• Atualização "rápida": 1,1 segundos

O que aprendi

• Existem diferentes modos de exibir uma imagem (atualização parcial / atualização completa)
• As telas e-ink são lentas para renderizar o conteúdo
• Essa tela pode atender às minhas necessidades, mas provavelmente consigo encontrar uma mais barata e mais rápida
• Ainda preciso entender por que o SPI nativo não funciona com ela

Trabalhando com o GPS

O GPS foi bem mais tranquilo. O Claude sabia como fazer as conexões, e a documentação recomendava a biblioteca TinyGPS++.

Os LEDs físicos no chip do GPS (POWER e PPS) também facilitaram muito a depuração. Na minha primeira tentativa, o GPS não estava recebendo energia corretamente (um problema na fiação).

No começo, não entendi por que não estava recebendo dados de localização. Depois descobri que o GPS precisa sincronizar primeiro, e a primeira inicialização pode demorar bastante (mais de 5 minutos). Para mim, demorou mais, provavelmente porque o sinal no meu quarto é fraco.

O LED PPS pisca exatamente uma vez por segundo assim que o GPS consegue fixar o sinal. Foi um jeito muito fácil de entender que a falta de dados de localização não era um erro no código: o GPS só precisava sincronizar.

O GPS que comprei suporta 10Hz (módulos normais rodam a 1Hz) e é feito para drones. Eu não preciso de todo esse desempenho. O que eu preciso é de alta precisão, mesmo dentro de prédios, e de um preço menor. Vou encomendar um modelo mais adequado para o próximo protótipo.

O que aprendi

• O GPS pode levar um tempo para sincronizar: vários minutos em uma inicialização a frio, e mais de 30s em uma inicialização a quente
• Não preciso de um GPS de 1 a 10Hz; não estou construindo um avião ou um dispositivo em alta velocidade
• Preciso de um GPS que funcione melhor em ambientes internos
• Preciso procurar uma alternativa mais barata e mais potente

Trabalhando com o BME680 (sensor de ar)

Tive bastante dificuldade para me comunicar com este sensor. O Cursor não conseguiu escrever uma implementação funcional, mesmo com exemplos. Por sorte, a Adafruit criou uma biblioteca específica para esse sensor, e foi a que usei. Eles têm bibliotecas para muitos sensores diferentes, o que quebra um galho enorme.

O sensor de COV precisa de calibração e oscila bastante no início, então os valores só ficam confiáveis após as primeiras 48 horas de uso. Vai ser difícil integrar isso em um dispositivo, já que os clientes não têm como calibrar o aparelho facilmente. Terei que usá-lo em conjunto com outros sensores para validar os dados.

O que aprendi

• O sensor de COV exige calibração. Ainda não tenho certeza de como resolver isso para os usuários finais; talvez eu o utilize apenas para monitorar as variações.

Bateria

Pesquisei baterias LiPo e Li-Ion. O formato LiPo é bem melhor, e é o que os dispositivos vestíveis usam quando tamanho e peso são cruciais, como em notebooks e celulares.

Mas a maioria das baterias LiPo tem 3,7V, e a placa ESP32 que estou usando precisa de 5V. Eu poderia elevar a tensão, mas isso adiciona complexidade e desperdiça energia.

As baterias também podem ser perigosas: são muito sensíveis a danos físicos, e uma célula LiPo pode pegar fogo se for perfurada, superaquecida, descarregada excessivamente e afins.

Então, por enquanto, estou usando um power bank comum com um cabo USB-C.

O que aprendi

• A maioria das baterias LiPo pequenas fornece 3,7V
• Normas e regras de segurança são fundamentais ao trabalhar com baterias

Implementação do software

Estive trabalhando na parte do software e na sincronização de dados.

O objetivo é fazer com que o ESP32 funcione como um servidor Bluetooth Low Energy (BLE), com um cliente no meu computador para recuperar os dados.

No início, eu nem conseguia enviar o código para o microcontrolador porque era muito grande. Depois de pesquisar um pouco, descobri que a biblioteca BLE padrão não é nada leve e estava consumindo 75% da memória flash disponível. Mudei para a NimBLE, que é cerca de 50% mais leve, com a desvantagem de suportar apenas BLE e não o Bluetooth clássico. Sorte a minha, já que não pretendo usar o Bluetooth clássico.

Fique de olho nas próximas novidades enquanto continuo trabalhando no sensor vestível pikoAQI!