Que fatores a considerar ao selecionar um MCU wifi integrado para um dispositivo de borda de baixa potência?

A motivação para esta pergunta vem do fato de que, há algum tempo atrás, criei um dispositivo de ponta da IoT para prova de conceito simples (PoC) usando um microcontrolador e um processador de rede Wifi CC3100 . Um dos problemas desse protótipo era que a configuração exigia uma quantidade considerável de energia. Assim, não conseguiu superar os benefícios do dispositivo de baixa potência existente, que poderia durar mais de 2 a 10 anos, dependendo da escolha da bateria e da frequência de uso.

Dependendo da aplicação, o produto atual usa uma bateria de 6V DC com capacidade entre 1400 mAh e 2400 mAh. O dispositivo possui um elemento sensor de baixa potência e um mecanismo de atuação. A carga útil provavelmente será de cerca de 100 bytes. A frequência da comunicação será de dois em dois minutos durante o pico da atividade. Com os avanços na IoT e nas demandas do mercado, esse PoC ganhou alguma atenção.

Por sugestão de alguns fornecedores de plataforma IOT, estou olhando para o MCU sem fio CC3200 da Texas Instrument principalmente porque é o sucessor do CC3100. No nível do sistema, quando não estiver em uso, a energia do CC3100 pode ser completamente desligada. Essa é uma vantagem significativa para a baixa energia no nível do sistema. Quando a atividade é detectada, o elemento sensor ativa o microcontrolador através de uma interrupção. Existem outros MCUs wifi integrados, como ESP8266 , BCM43362 , ATWINC1500B , 88MC200 e muitos mais. Eu uso ULPBench Pontuações para fazer uma primeira análise a fim de microcontroladores de baixa potência, seguido de análise tal como descrito emComo selecionar um micro controlador para uma aplicação de baixa potência? para ajudar a selecionar um microcontrolador de baixa potência. Utilizei parâmetros como consumo de corrente no modo ativo por frequência e consumo de corrente em diferentes modos de baixa potência para fazer uma seleção informada. Portanto, para manter a opção de baixa energia e adicionar capacidade de IoT, quais são os parâmetros críticos (podem estar relacionados à comunicação sem fio) aos quais devo prestar muita atenção ao selecionar um MCU wifi integrado?

Referências:

• SimpleLink ™ CC3100 / CC3200 Gerenciamento de energia do subsistema de rede Internet no chip Wi-Fi
• Como selecionar o seu módulo Wi-Fi?

Como sua restrição mais importante é ter um baixo consumo de energia, acho que você já está prestando atenção nos 2 parâmetros mais importantes: consumo de corrente no modo ativo por frequência e consumo de corrente nos diferentes modos de baixo consumo de energia.

Mantendo a comunicação como constante (ou seja, mesmo protocolo de comunicação e frequência EM), a escolha do melhor MCU é apenas uma questão de agregar esses dois parâmetros corretamente. E aqui está como eu criaria um único valor numérico que eu poderia comparar em todas as opções:

1. Crie um perfil de atividade projetado para o dispositivo (com que frequência ele se comunica e por quanto tempo) durante um período - digamos, durante uma semana.
2. Calcule o consumo de corrente na frequência EM usada nos períodos do período selecionado em que a comunicação estiver ativa - ou seja, 10 uA (frequência de 900 MHz) por 2 s de duração a 1000 x atividade em uma semana significaria 20.000 uA-s / semana.
3. Calcule o consumo de corrente nos períodos selecionados no período em que o dispositivo estiver no modo de baixa energia padrão - ou seja, 10 nA de consumo em [7 dias x 24 horas x 60 minutos x 60 s - atividade de 1000 x 2 s] significaria 6.028 uA -s / semana.
4. A soma dos 2 produz 26.028 uA-s / semana de consumo atual para este hipotético MCU.
5. Esse consumo de corrente semanal calculado pode ser comparado para todas as MCUs.

Sei que essa é uma maneira muito simplista de visualizar a atividade do MCU - ou seja, apenas consideramos 2 estados: ocioso e comunicando ... mas acredito que quaisquer outros estados terão contribuições proporcionais e menores para um desses 2. Por exemplo, energia consumida pois os cálculos (ciclos de instruções) podem ser agrupados juntamente com o estado de comunicação e provavelmente terão uma contribuição muito pequena em termos de potência em comparação com o subsistema de comunicação. O ponto é que, analisar esses dois estados é suficiente para o processo de seleção.

Não há bala mágica, então acho que o conselho será dolorosamente óbvio. Comece escolhendo os maiores consumidores de energia primeiro.

Você está realmente desligando todos os chips e circuitos quando está ocioso? Eu sei que algumas das placas e escudos amadores nem sempre desligam completamente tudo o que você esperaria.

Se for o atuador, você pode usar um motor mais leve ou reduzir o atrito no trem de força? Imagem maior, você pode reprojetar a carga acionada para ter menos massa ou ser mais equilibrado?

Se for a comunicação, comece observando a frequência das comunicações. Quais fatores impulsionaram a decisão "de dois minutos" existente? Você pode fazer sacrifícios para se comunicar com menos frequência? Você pode mudar para um modelo pub-sub e responder com menos bytes quando as condições permitirem?

Reavalie o protocolo. Cada byte que você barbeia representa uma economia de 1% do seu orçamento atual de energia de RF. Enviando algum valor booleano? Use sinalizadores de bit, não um ASCII 'Y' ou 'N'. Verifique se você está usando o menor contêiner possível - não transmita um número inteiro de 16 bits se o número tiver um intervalo permitido de apenas 0-99. A maioria dos protocolos alimentados por bateria tenta compactá-lo o máximo possível; por exemplo, se você estiver reportando uma matriz de elementos 5x5, o endereço precisa ser apenas um campo de 5 bits, não um byte de 8 bits. O uso de ciclos de CPU para lógica relacionada à compactação resulta em um consumo geral de energia muito menor do que na transmissão de bits desnecessários.

Se o grande consumo de energia é a CPU (duvidosa, mas possível), você pode fazer truques como tabelas de pesquisa pré-computadas ou até mesmo descarregar parte do trabalho em um serviço remoto?

Não há um único conjunto definitivo de parâmetros que você possa usar para selecionar um dispositivo integrado como este, mas acho que, como primeira aproximação, os dispositivos recém-projetados podem ser significativamente melhores do que alguns anos atrás. Embora o conceito não seja novo, esse nível de integração e os objetivos agressivos de energia fazem deste um mercado em evolução.

Preste muita atenção aos estados de energia oferecidos, vistos da perspectiva de todo o seu sistema (reguladores, osciladores, condicionamento do sinal do sensor). É possível (improvável) que seu estado ativo de 2 min se beneficie de um sono menos profundo do que o estado operacional normal.

O estado útil de menor potência deve responder pela maior parte do seu consumo de energia. Exatamente como isso ocorre para você depende de coisas como se você pode operar diretamente com a energia sem um regulador, tensão operacional mínima, etc.

Para o estado ativo, considere a maior quantidade de RAM ou operações intensivas de computação e compare-as usando as peças disponíveis equivalentes mais próximas que você puder encontrar (com base na CPU, velocidade e arquitetura de memória). Em seu aplicativo, parece que preparar a carga útil e a criptografia pode ser bastante trivial, mas em geral isso não é uma suposição óbvia. Os estados de retenção podem permitir a integração do sensor sem salvar / restaurar o estado, por exemplo.

Combine a velocidade e a arquitetura do relógio com as demandas do seu aplicativo. No estado de suspensão, você economiza energia de vazamento. Velocidades de clock alvo mais baixas para um dispositivo podem significar que ele precisa permanecer em um estado ativo por mais tempo, mas também resultam em um projeto que alcança melhor desempenho de vazamento (bem como talvez menor voltagem operacional).

Você não conhecerá o melhor design absoluto até ter iterado mais de um design - existem muitos parâmetros (e, a essa altura, seu produto estará começando a envelhecer), portanto, aspectos de nível mais alto do fluxo do design ainda serão importante. Se você pode otimizar sua arquitetura para reduzir os eventos de ativação em 5%, isso deve ser notado na duração da bateria.