Consumo em Sono Profundo
Como um modo de espera extrema, o sono profundo reduz o circuito ativo ao domínio necessário para manter memória, relógio ou fontes de despertar. Microcontroladores podem consumir de poucos microampères a dezenas de microampères, enquanto o produto completo frequentemente gasta mais por regulador, sensor e fuga da placa. Integra-se a Zigbee, Thread, BLE e dispositivos a bateria, mas o erro comum é usar apenas o valor do chip para estimar autonomia do equipamento.
Consumo em sono profundo é a corrente ou potência demandada pelo dispositivo quando a maior parte de seus blocos eletrônicos está desligada e apenas os elementos necessários para preservar estado ou detectar um evento permanecem ativos. A analogia técnica é a de uma instalação com quase todos os circuitos seccionados, mantendo apenas o relógio, a memória essencial e o mecanismo que reconhece a hora de religar. Em microcontroladores, o modo pode desligar CPU, caches, rádios, ADCs e periféricos. Permanecem RTC, memória de retenção, GPIO de wake-up, comparadores ou temporizadores, conforme a arquitetura. O valor costuma ser expresso em microampères, µA, ou microwatts. Em produtos a bateria, ele é um dos componentes do orçamento energético. Não é o único. O consumo médio depende da corrente em sono, do tempo em cada estado, da frequência de despertar, da duração do rádio, do processamento, dos sensores e da eficiência da alimentação. Um sensor que dorme a 5 µA, desperta a cada minuto e transmite por 50 ms pode consumir menos que outro que dorme a 2 µA, mas mantém o rádio ativo por 2 s a cada ciclo. A média é a soma ponderada. Para um ciclo com estados i, corrente média é aproximadamente Σ(Ii × ti)/T. A autonomia ideal é capacidade da bateria dividida pela corrente média, com ajustes para tensão, eficiência, temperatura, envelhecimento e autodescarga. O erro comum é multiplicar a corrente de deep sleep do microcontrolador pela capacidade nominal e anunciar anos de autonomia. O produto completo inclui regulador, sensor, memória, LED, resistores, divisores de tensão, proteção, pull-ups e correntes de fuga. Um regulador com corrente quiescente de 20 µA já supera um MCU de 3 µA. Um divisor permanente pode consumir dezenas de microampères. Um sensor ambiental pode ter aquecedor ou circuito de medição. A placa pode sofrer fuga por umidade. A bateria também se autodescarrega. A escolha de componentes precisa ser sistêmica. Protocolos influenciam o ciclo. Dispositivos Zigbee, Thread e BLE podem dormir e acordar periodicamente. Um end device Zigbee dorme e consulta o parent para receber mensagens. O poll interval altera latência e energia. Thread Sleepy End Devices também dependem do parent e do período de polling. BLE usa advertising e connection intervals. Wi‑Fi tradicional tende a exigir picos maiores e associação mais custosa, embora mecanismos de power save existam. A interoperabilidade entre o dispositivo e o ecossistema precisa respeitar esses tempos. Se o controlador espera resposta imediata de um sensor adormecido, haverá atraso ou falha. Protocolos definem filas e janelas para dispositivos sonolentos. O firmware precisa implementá-las corretamente. O sono profundo também afeta tempo de reconexão. Se o rádio perde contexto, cada despertar pode exigir oscilador, calibração, associação, autenticação e obtenção de endereço. Manter parte da memória reduz energia e latência, mas aumenta corrente de retenção. O projeto escolhe entre cold boot e wake-up com contexto. Alguns microcontroladores mantêm RTC e uma pequena RAM. Outros preservam mais domínios. O consumo publicado precisa indicar tensão, temperatura, pinos, memória retida e fonte de wake. Um número de 2 µA em 3,0 V pode tornar-se 10 µA com RTC, watchdog e GPIO ativos. A placa de desenvolvimento consome muito mais devido a conversor USB, LED e regulador. Medir uma dev board e extrapolar para produto final também é inadequado. A medição exige instrumento com ampla faixa dinâmica. O dispositivo alterna entre microampères em sono e dezenas ou centenas de miliampères no rádio. Multímetros comuns podem ter burden voltage, faixa lenta e resolução insuficiente. Analisadores de potência, shunts com amplificador ou instrumentos como Nordic Power Profiler, Joulescope e Otii permitem capturar corrente ao longo do tempo. A taxa de amostragem precisa registrar picos curtos. A resistência de medição não pode derrubar a tensão e alterar o comportamento. Capacitores locais fornecem parte dos picos, por isso a posição do shunt muda a forma observada. Para autonomia, interessa energia retirada da bateria, incluindo perdas do regulador. A tensão da bateria varia. Células CR2032 possuem capacidade nominal medida em descarga pequena. Picos altos causam queda de tensão e reduzem capacidade utilizável. Temperatura baixa aumenta resistência interna. Uma bateria de 220 mAh não entrega necessariamente 220 mAh no perfil real. Células alcalinas, lítio primário, Li-ion e LiFePO4 têm características distintas. Corrente de sono muito baixa pode tornar a autodescarga dominante. Se o circuito consome 1 µA, uma bateria com 2% de autodescarga anual pode limitar a vida antes da carga calculada. A vida de prateleira e a vedação do produto importam. Sensores também têm requisitos de estabilização. Um sensor de gás não pode ser desligado por longos períodos sem perder prontidão. Sensores de umidade e pressão podem acordar, medir e desligar rapidamente. PIRs exigem alimentação e estabilização. Radares mmWave costumam consumir muito mais e raramente entram em sono profundo mantendo presença contínua. A função do produto define o que pode ser desligado. Um sensor de porta usa interruptor magnético como wake-up e pode dormir quase todo o tempo. Uma fechadura precisa ouvir comandos ou usar rádio com janela periódica. Uma câmera não consegue manter gravação em deep sleep. Comparar consumo entre categorias sem considerar disponibilidade é enganoso. A qualidade do firmware é decisiva. Periféricos esquecidos ligados, GPIO flutuante, debug ativo, memória não colocada em modo de baixo consumo e interrupções frequentes elevam corrente. Eventos espúrios podem causar wake-ups invisíveis. Logs durante desenvolvimento ajudam a contar causas e duração. Em produção, telemetria pode registrar resets, transmissões e bateria. Atualizações de firmware podem alterar consumo. Um novo intervalo de polling ou bug de reconexão reduz autonomia. Testes de regressão energética são necessários. O sono profundo interage com segurança. Chaves e contadores precisam ser preservados ou restaurados. O dispositivo deve evitar reutilizar nonces após perda de energia. Secure boot aumenta tempo e energia de inicialização, mas protege firmware. Armazenar estado em flash a cada ciclo desgasta memória e consome energia. Retenção em RAM ou batching de gravações pode ser melhor. O desenho precisa equilibrar segurança, durabilidade e consumo. Para o morador, a consequência é frequência de troca de bateria e confiabilidade. Um sensor prometido para cinco anos pode durar meses se estiver longe do hub e retransmitir, se a temperatura for baixa ou se o firmware acordar demais. A instalação deve observar qualidade de enlace e usar baterias recomendadas. Relatórios muito frequentes precisam ser justificados. Limites e variação mínima evitam transmitir ruído. Em dispositivos de segurança, autonomia não deve ser obtida sacrificando supervisão. O controlador precisa detectar bateria baixa e ausência de comunicação. Para escolher produto, é útil procurar consumo médio real, perfil de uso, intervalo de relatório, protocolo, tipo de bateria e condições do ensaio. O valor de deep sleep é relevante em desenvolvimento e comparação de arquitetura, mas não substitui autonomia medida. Um produto bem projetado alinha corrente de sono, duração ativa, rádio, sensor, bateria e comportamento de rede. O menor número do chip é apenas uma peça.
- AO valor do microcontrolador não é o consumo do produtoRegulador, sensor, memória, LED, divisor, proteção e placa somam corrente. A corrente quiescente do regulador pode superar a do MCU. Dev boards incluem circuitos que inviabilizam medições de microampères. O ensaio deve ser feito no hardware final e em todos os modos. Datasheets precisam ser lidos com condições de tensão, temperatura e retenção. A autonomia deve ser validada com bateria real e perfil de uso.
- BFrequência e duração dos despertares podem dominar a energiaReduzir deep sleep de 10 para 2 µA ajuda pouco se o rádio fica ativo por segundos a cada minuto. Intervalo de relatório, polling, retries e reconexões precisam ser otimizados. Variação mínima reportável evita transmitir ruído. Batching agrupa dados. Boa margem de enlace reduz repetição. O firmware deve registrar causas de wake e tempo em cada estado. Energia é resultado do ciclo completo.
- CBaixo consumo precisa preservar disponibilidade e segurançaDormir mais aumenta latência de comandos e pode reduzir frequência de supervisão. Uma fechadura, alarme ou detector não deve economizar energia a ponto de perder eventos críticos. Protocolos oferecem filas para dispositivos sonolentos, mas exigem configuração. Chaves, contadores e estado precisam ser preservados com segurança. O projeto deve definir tempo máximo de resposta, janela de detecção e intervalo de check-in antes de otimizar corrente.
- DAutonomia precisa ser testada sob temperatura e rede reaisBaterias entregam menos em frio e sob picos. Interferência e sinal fraco aumentam retransmissões. Firmware pode mudar consumo. Ensaios acelerados, perfis de corrente e testes de campo são complementares. A instalação deve observar qualidade do enlace. Um sensor atrás de metal pode gastar mais que outro idêntico em posição aberta. A promessa de anos depende de cenário; o valor de sono profundo é apenas o piso eletrônico.