Um fornecedor vai dizer que o sensor LoRaWAN dura dez anos com uma única célula. Isso pode ser verdade. Também pode estar errado por um fator de cinco com o mesmíssimo hardware, porque a duração da bateria em LoRaWAN é resultado de configuração, não uma especificação de hardware. A resposta honesta para “quanto tempo essas baterias duram” fica entre cerca de um ano e mais ou menos uma década, e onde você cai dentro dessa faixa depende de com que frequência o dispositivo fala, de quão longe ele está de um gateway e de se a rede tem permissão para ajustar o rádio para você.
Então a pergunta de planejamento não é “quanto tempo a bateria dura”. É “o que estou pedindo para este dispositivo fazer, e quanto isso custa em energia”. Erre nisso e você ou superdimensiona com baterias maiores que não precisava, ou coloca em campo sensores que apagam um ano antes do esperado. Veja o que de fato determina o número, o que o Adaptive Data Rate muda e como enxergar uma bateria morrendo antes que ela deixe um dispositivo isolado.
O que realmente drena uma bateria LoRaWAN
A maior parte da vida de um sensor de baixo consumo é passada dormindo, puxando quase nada. A energia vai embora durante a transmissão. Então tudo que aumenta por quanto tempo ou com que frequência o rádio fica ligado é o que custa caro.
A frequência de uplink é a maior alavanca que você controla diretamente. Um sensor que reporta uma vez por hora vai durar mais que o mesmo sensor reportando a cada minuto, muitas vezes por anos, porque gasta sessenta vezes menos esforço falando. O tamanho do payload importa pelo mesmo motivo: uma mensagem mais longa demora mais para ser enviada, e mais tempo no ar é mais energia.
A distância até o gateway define o spreading factor, e o spreading factor define o tempo no ar. Um dispositivo perto de um gateway pode operar em SF7, terminar a mensagem rápido e voltar a dormir. Empurre-o para a borda da cobertura e ele sobe para SF12, onde a mesma mensagem fica no ar muito mais tempo e queima muito mais energia, algo como vinte vezes mais por transmissão. Um sensor que “ainda conecta” na borda do alcance costuma ser o primeiro a morrer.
Mensagens confirmadas somam um segundo custo. Quando um dispositivo pede que a rede confirme cada uplink, ele precisa manter o receptor aberto para escutar o downlink, e os downlinks forçam gateway e dispositivo a trocas extras. As janelas de recepção são mais baratas que a transmissão, mas não são gratuitas, e tráfego confirmado em toda mensagem acumula rápido. A maioria dos sensores de campo não precisa de confirmação em cada leitura.
A temperatura é a vilã silenciosa. As células de lítio perdem capacidade útil no frio, e uma química que parece bem numa bancada à temperatura ambiente se comporta de outro jeito num telhado no inverno ou dentro de um gabinete fervendo ao sol. Os extremos nas duas pontas encurtam a vida real para abaixo do número da ficha técnica.
O que é o ADR e por que ele importa
O Adaptive Data Rate é a rede decidindo, em seu nome, as configurações de rádio de menor energia que um dispositivo consegue usar e ainda ser ouvido. O network server observa a qualidade do sinal dos uplinks recentes do dispositivo. Se ele chega forte, o servidor manda baixar o spreading factor e a potência de transmissão. Spreading factor menor significa menos tempo no ar. Potência menor significa menos energia por transmissão. Os dois economizam bateria, e o dispositivo continua fazendo o trabalho dele.
Isso funciona porque muitos dispositivos operam de forma bem mais conservadora do que precisam. Um sensor parafusado numa parede a cem metros de um gateway de telhado pode estar transmitindo em SF10 por cautela quando SF7 chegaria de boa. O ADR encontra essa folga e a aproveita. Para um dispositivo parado com cobertura estável, ligar o ADR é praticamente bateria de graça, e é a configuração que mais vale a pena acertar.
O ADR foi feito para dispositivos que não se movem e cujas condições de rádio permanecem estáveis. É aí que ele brilha e onde você deve deixá-lo ligado por padrão.
Quando o ADR ajuda e quando ele não consegue
O ADR funciona aprendendo com o histórico, então parte do princípio de que o passado recente prevê o futuro próximo. Essa premissa vale para um sensor fixo e quebra para um em movimento.
Um dispositivo num ativo em movimento, um caminhão, um pallet, uma pessoa, vê suas condições de rádio mudarem mais rápido do que o ADR consegue acompanhar. O servidor ajusta o dispositivo para baixo em um local forte, o ativo entra em uma região fraca, e agora o dispositivo transmite baixo demais para ser ouvido. Para dispositivos móveis, a especificação LoRaWAN manda deixar o ADR desligado e deixar o próprio dispositivo gerenciar a taxa de dados, geralmente de forma conservadora.
O ADR também não conserta cobertura ruim. Se um dispositivo está de fato na borda, atrás de concreto ou longe de qualquer gateway, não há configuração mais baixa para dar a ele. O servidor vai mantê-lo no spreading factor alto de que ele precisa, e a bateria paga a conta. O ADR otimiza dentro da cobertura que você tem. Ele não cria cobertura. Um dispositivo travado em SF12 porque está num ponto cego é um problema de cobertura, e a solução é um gateway melhor posicionado ou adicional, não uma configuração de rádio.
Passos práticos para esticar a bateria
A energia mais barata é a mensagem que você nunca envia. Comece por aí.
Reduza o intervalo de reporte para o ritmo mais lento que o seu caso de uso tolera. Uma leitura de temperatura a cada quinze minutos em vez de a cada minuto é uma grande economia para uma medição que raramente muda nessa velocidade. Envie por mudança ou por limiar onde os dados permitirem, para o dispositivo ficar quieto quando nada está acontecendo.
Mantenha os payloads pequenos e desligue as mensagens confirmadas a menos que a leitura realmente precise ser confirmada. Reserve a confirmação para o punhado de eventos que importam, não para a telemetria de rotina. Ligue o ADR em todo dispositivo parado e deixe-o desligado em qualquer coisa que se mova. Posicione os gateways bem para que os dispositivos consigam manter um spreading factor baixo, já que a altura e o posicionamento do gateway fazem mais pela bateria da frota do que qualquer ajuste por dispositivo. E dimensione a bateria para a ponta fria da faixa de temperatura que o dispositivo vai de fato enfrentar, não para a bancada.
Acompanhe a bateria antes que ela morra
Tudo isso define quanto uma bateria deveria durar. Nada disso diz quando um dispositivo específico em campo está prestes a parar, e essa é a falha que custa uma visita ao local e um buraco nos seus dados.
A maioria dos dispositivos LoRaWAN reporta o estado da bateria no seu status, seja como nível ou como tensão, junto com as leituras. A TagoIO ingere essa telemetria de bateria do mesmo jeito que ingere qualquer outra variável, pelo seu network server LoRaWAN e pelas integrações MQTT, e a armazena por dispositivo. A partir daí você a coloca em um dashboard, de modo que uma frota de sensores mostra a bateria atual num relance e uma linha de tendência mostra quais estão escorregando. A parte que realmente evita a ida a campo é o alerta: defina um limiar e a TagoIO avisa quando um dispositivo o cruza, bem antes de a célula zerar. Você troca uma bateria numa visita planejada em vez de descobrir um sensor morto depois que os dados já sumiram.
A TagoIO é agnóstica de conectividade e fica do lado da plataforma, então uma frota mista de dispositivos LoRaWAN e celulares reporta a bateria em um só lugar com uma única configuração de alertas. Ela é certificada ISO 27001 e alinhada ao GDPR para equipes que precisam dessa postura. O rádio decide quanto a bateria dura. A plataforma garante que você veja a queda chegando.
