asma, lítio descartado e um purificador de água que devia virar caso de estudo em qualquer faculdade de Engenharia da Computação
Li a matéria do Catracalivre.com.br sobre o Zabeer Zarif Akhter, o estudante de 17 anos de Bangladesh que montou um purificador de água movido a energia solar usando baterias velhas de notebook, placas quebradas e peças de TV antiga, e fiquei parado alguns minutos pensando: isso aqui é Engenharia de Software disfarçada de Hardware. É a mesma mentalidade que a gente aplica em sistemas embarcados — extrair o máximo de utilidade de componentes que o mercado já descartou, com restrição severa de orçamento e zero tolerância a dependência de infraestrutura externa.
O que me chamou a atenção não foi apenas o lado humanitário (óbvio e louvável), mas o conjunto de decisões técnicas que sustentam o projeto. Tem gerenciamento de energia, eletrônica de potência, química de descarga elétrica, e uma camada de autonomia operacional que, traduzindo para o mundo dev, é basicamente edge computing rodando sem rede elétrica. Vou destrinchar isso.
O mecanismo central: descarga elétrica gerando plasma em alta tensão
O purificador do Zabeer usa o que engenheiros eletricistas chamam de tratamento por plasma não-térmico. Quando você aplica uma diferença de potencial alta o suficiente entre dois eletrodos imersos (ou próximos) da água, o campo elétrico ioniza o meio e cria canais condutores — plasma. Esses canais liberam radicais livres como ozônio (O₃), peróxido de hidrogênio (H₂O₂) e espécies reativas de oxigênio que destroem membranas celulares de bactérias, vírus e protozoários.
Traduzindo para quem trabalha com software: pense nisso como um garbage collector de patógenos. A alta tensão é a “marca-e-varredura” do processo, e os radicais livres são os ponteiros que vasculham a heap biológica desfragmentando o que não deveria estar lá. A grande sacada é que isso acontece sem reagentes químicos caros — é literalmente ar, água e eletricidade controlada.
Os eletrodos de carbono vindos de placas reaproveitadas são engenhosos. Carbono é barato, condutor, e tem vida útil razoável sob descarga. Se você já abriu um notebook antigo, sabe que essas placas têm trilhas de cobre e pads com banho de carbono justamente por facilitar soldagem e condução — material perfeito para o experimento.
Por que isso me interessa como dev (e por que deveria interessar você também)
Na minha experiência com sistemas embarcados, vejo três lições que atravessam o projeto do Zabeer e o dia a dia de quem programa firmware:
- Energia é a restrição-mãe. Em qualquer projeto IoT sério, você consome 90% do tempo otimizando consumo. O purificador solar acerta em cheio: a bateria de notebook dá densidade energética decente (Li-ion de 18650 é ~2500 mAh por célula), e os painéis fotovoltaicos suprem o restante. É a mesma matemática que faço com ESP32 em modo deep sleep alimentado por painel de 6V.
- Autonomia real significa zero dependência de rede. Esse sistema não consulta API, não depende de cloud, não loga em servidor central. Quando a enchente chega, a rede elétrica cai, a internet cai — e o purificador continua funcionando. Isso é exatamente o que a gente busca em edge devices industriais: a lógica tem que rodar local, ou o sistema morre junto com a infraestrutura.
- Reciclagem de hardware não é gambiarra — é engenharia de restrição. Quando você projeta com orçamento de US$ 5 por unidade, cada componente precisa justificar sua existência. Essa mentalidade afia o raciocínio de qualquer dev que já precisou enxugar arquitetura para caber em hardware chinfrim.
Na Prática: modelando o sistema de controle de um purificador a plasma
Imagine que você recebeu a missão de instrumentar o purificador do Zabeer com um microcontrolador para medir tensão, corrente, turbidez e acionar o relé de alta tensão apenas quando seguro. Um setup plausível seria Arduino Uno + módulo de relé + sensor de turbidez + divisor de tensão para monitoramento. Aqui vai um esboço funcional de leitura de sensor e decisão de acionamento:
// Controle de purificador a plasma — versão simplificada
// Hardware: Arduino, sensor de turbidez (analógico), divisor de tensão, relé HV
const int PIN_TURBIDITY = A0; // saída analógica do sensor (0–1023)
const int PIN_VOLTAGE = A1; // divisor resistivo 1:1000, tensão HV
const int PIN_RELAY_HV = 7; // aciona transformador de pulso
const int PIN_SOLAR_EN = 8; // habilita carga solar
const float TURBIDITY_THRESHOLD = 300.0; // NTU * fator — ajuste empírico
const int MIN_HV_READING = 700; // tensão mínima esperada para descarga estável
struct PurifierState {
float turbidity;
int hvVoltage;
bool solarReady;
bool plasmaActive;
unsigned long lastDischargeMs;
};
PurifierState state = {0.0, 0, false, false, 0};
void setup() {
Serial.begin(115200);
pinMode(PIN_RELAY_HV, OUTPUT);
pinMode(PIN_SOLAR_EN, OUTPUT);
digitalWrite(PIN_RELAY_HV, LOW);
digitalWrite(PIN_SOLAR_EN, LOW);
}
void readSensors() {
int rawTurb = analogRead(PIN_TURBIDITY);
int rawVolt = analogRead(PIN_VOLTAGE);
// Mapeamento de tensão: 5V ADC com divisor 1:1000 + margem
state.hvVoltage = (rawVolt * 5.0 / 1023.0) * 1000;
state.turbidity = rawTurb * (1000.0 / 1023.0); // normalização ilustrativa
state.solarReady = (rawVolt > 400); // painel gerando tensão útil
}
bool shouldActivate() {
if (!state.solarReady) return false;
if (state.turbidity < TURBIDITY_THRESHOLD) return false;
if (state.hvVoltage < MIN_HV_READING) return false;
unsigned long now = millis();
if (now - state.lastDischargeMs < 3000UL) return false; // cooldown de segurança
return true;
}
void loop() {
readSensors();
if (shouldActivate()) {
digitalWrite(PIN_RELAY_HV, HIGH);
state.plasmaActive = true;
state.lastDischargeMs = millis();
Serial.print(F("[PULSE] turb="));
Serial.print(state.turbidity);
Serial.print(F(" hv="));
Serial.print(state.hvVoltage);
Serial.println(F("V"));
} else {
digitalWrite(PIN_RELAY_HV, LOW);
state.plasmaActive = false;
}
delay(250);
}
Esse código é deliberadamente conservador. Em produção real, eu adicionaria: watchdog timer (no AVR, o wdt_enable()), interrupção para parada de emergência, log em EEPROM dos ciclos, e um sensor de corrente para confirmar que a descarga realmente ocorreu (não basta acionar o relé, tem que fluir corrente). E mais importante: isolação galvânica entre a parte de potência e a parte lógica. Nada de meter MCU no mesmo ground do estágio HV.
Comparando com alternativas comerciais
No mundo real, purificadores a plasma existem — a Siemens e a Bionics entre outros já vendem sistemas industriais. Mas o preço? Dezenas de milhares de dólares. O que o Zabeer fez foi olhar o mesmo princípio físico e remover 95% do custo reaproveitando o que o lixo eletrônico oferece. É exatamente a mesma estratégia que a gente aplica em homelab: por que pagar US$ 500 num appliance quando um NUC reacondicionado + Proxmox resolve?
Outras tecnologias para tratamento de água em regiões remotas incluem:
- UV-C germicida: eficiente, mas precisa de lâmpada funcional e energia constante. Sem lâmpada reserva, sistema morre.
- Osmose reversa: cara, requer membranas caras que entopem com água turva, e gasta água no rejeito.
- Cloro/dicloro: barato, mas tem custo logistico e gera subprodutos halogenados indesejáveis.
- Filtração por cerâmica filtrante (tipo filtro de velas): baratíssima, mas não remove vírus.
O plasma tem a vantagem de matar vírus também, não só bactérias. Isso é diferencial enorme em regiões com surtos de hepatite ou cólera depois de enchentes.
O que evitar: erros comuns que devs cometem quando embarcam em hardware de potência
Não é a primeira vez que vejo projeto promissor de estudante ir pro brejo por desconsiderar física básica. Anota essa lista:
- Esquecer a curva de descarga da bateria. Li-ion não entrega tensão constante até o fim. Ela cai de 4.2V para 3.0V ao longo do uso. Se seu circuito depende de tensão mínima, ele para de funcionar muito antes da bateria chegar a "zero". Solução: boost converter ou pack com células em série.
- Ignorar EMI gerada pela descarga. Plasma é uma fonte brutal de interferência eletromagnética. Sem blindagem e desacoplamento, o MCU trava a cada pulso. Na minha experiência, colocar capacitor de 100nF cerâmico direto nos pinos de alimentação do relé resolve 80% dos resets aleatórios.
- Subdimensionar a seção de cobre. Corrente de pico na descarga pode passar de 10A por alguns microssegundos. Cabo AWG 22 derrete. Use AWG 14 ou 16 no estágio HV.
- Não testar endurance. Um protótipo que funciona por 10 minutos não é um produto. Você precisa de horas de operação cíclica para descobrir fadiga de componentes, aquecimento, degradação de eletrodos.
- Achar que "solar" significa "infinito". Painel fotovoltaico com cobertura parcial de nuvem cai para 10% da produção. Bateria subdimensionada = sistema inoperante em semana nublada. Sempre dimensione para o pior cenário sazonal, não para o dia ensolarado de teste.
Por que esse caso deveria ir pro currículo de Engenharia de Software
Se eu fosse reestruturar a grade de uma faculdade de computação, incluíria esse tipo de projeto como trabalho de conclusão de disciplina em Sistemas Embarcados. Por quê? Porque une camadas: eletrônica de potência, firmware, eficiência energética, ciência dos materiais, e um problema real onde a falha de software mata gente. Diferente de mais um CRUD em React.
Para devs querendo entrar no mercado de IoT, agro, telemetria veicular ou saúde, esse é o tipo de pensamento que diferencia estagiário de profissional sênior: entender o sistema inteiro, da célula solar ao bit mais significativo do seu analogRead().
FAQ — Perguntas que um dev faria sobre o purificador a plasma
1. Qual o patógeno mais resistente que o plasma consegue matar?
Cryptosporidium e Giardia (protozoários com cistos resistentes a cloro) são eliminados. Vírus como rotavírus e hepatite A também. Mycobacterium tuberculosis em água é mais desafiador, mas estudos publicados mostram eficácia acima de 99.9% em condições controladas.
2. Isso é seguro para uso doméstico? O ozônio residual é perigoso?
O ozônio gerado se decompõe em O₂ em poucos minutos. Sistemas bem projetados incluem câmara de retenção com tempo de residência suficiente para que, na saída, a concentração de O₃ residual esteja abaixo do limite da OMS (0.1 mg/L). Para o protótipo do Zabeer, em escala doméstica, é seguro — mas replica que vá virar produto precisa de sensor de O₃ no efluente.
3. Posso montar algo parecido com uma fonte ATX velha de PC?
Não exatamente. Fontes ATX entregam 12V e 5V estáveis. Você precisa de pulso de alta tensão (kV) com corrente controlada. O caminho seria usar a bobina de um flyback de TV antiga (o tal "peça de TV antiga" do projeto) ou um módulo de ignição automotiva. Cuidado: alta tensão é letal. Não brinque se não tiver formação em eletrônica de potência.
4. Qual microcontrolador faz sentido para esse tipo de projeto?
Para a camada de controle, um ESP32 dá conta e ainda adiciona Wi-Fi para monitoramento remoto (se houver rede). Um Arduino Nano/Mega serve para versões mais simples. Para a leitura de tensão HV com segurança, prefira ADC externo (ADS1115) ao ADC do AVR — é mais preciso e tem entrada diferencial.
5. Existe risco de explosão da célula Li-ion recarregada em ambiente úmido?
Sim. Baterias de Li-ion com inchaço, dano físico ou já degradadas podem entrar em thermal runaway. Se for usar baterias reaproveitadas, teste cada célula individualmente: medir tensão interna em repouso (deve ser ~3.6–3.7V), medir resistência interna (acima de 100mΩ descarta), inspecionar abaulamento. E, claro, isolar eletricamente e mecanicamente o compartimento de baterias do contato com água.
Esse projeto é a prova de que engenharia de impacto não exige PhD nem laboratório de ponta — exige curiosidade, restrição e coragem pra mexer no que ninguém quer mexer. Se você, como dev, já passou horas debugando um sistema legado numa sexta à noite, sabe: o butiá é o mesmo.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.