¿Qué factores a tener en cuenta al seleccionar una MCU wifi integrada para un dispositivo de borde de baja potencia?

La motivación para esta pregunta proviene del hecho de que hace algún tiempo creé un dispositivo IoT edge de prueba de concepto (PoC) simple usando un microcontrolador y un procesador de red CC3100 Wifi . Uno de los problemas con este prototipo era que la configuración requería una cantidad considerable de energía. Por lo tanto, no podría superar los beneficios del dispositivo de baja potencia existente que podría durar más de 2 a 10 años, dependiendo de la elección de la batería y la frecuencia de uso.

Dependiendo de la aplicación, el producto actual usa una batería de 6V CC con una capacidad entre 1400 mAh y 2400 mAh. El dispositivo tiene un elemento sensor de baja potencia y un mecanismo de accionamiento. La carga útil probablemente será de alrededor de 100 bytes. La frecuencia de comunicación será aproximadamente cada dos minutos durante la actividad pico. Con los avances en IoT y las demandas del mercado, este PoC ha ganado algo de atención.

Por sugerencia de algunos proveedores de la plataforma IOT, estoy mirando la MCU inalámbrica CC3200 de Texas Instrument principalmente porque es la sucesora de la CC3100. A nivel del sistema, cuando no está en uso, la alimentación del CC3100 puede desconectarse por completo. Esta es una ventaja significativa para la baja potencia a nivel de sistemas. Cuando se detecta actividad, el elemento sensor activa el microcontrolador mediante una interrupción. Hay otros MCU wifi integrados como ESP8266 , BCM43362 , ATWINC1500B , 88MC200 y muchos más. Utilizo ULPBench Scores para hacer un análisis de primer orden de microcontroladores de baja potencia seguido de análisis como se describe en¿Cómo seleccionar un microcontrolador para una aplicación de baja potencia? para ayudar a seleccionar un microcontrolador de baja potencia. He utilizado parámetros como el consumo de corriente en modo activo por frecuencia y el consumo de corriente en diferentes modos de baja potencia para hacer una selección informada. Entonces, para mantener la opción de baja potencia y agregar la capacidad de IoT, ¿cuáles son los parámetros críticos (pueden estar relacionados con la comunicación inalámbrica) a los que debo prestar mucha atención al seleccionar una MCU wifi integrada?

Referencias

• SimpleLink ™ CC3100 / CC3200 Wi-Fi Internet en un chip Subsistema de red Administración de energía
• ¿Cómo seleccionar su módulo de Wi-Fi?

Como su restricción más importante es tener un bajo consumo de energía, creo que ya está prestando atención a los 2 parámetros más importantes: consumo de corriente en modo activo por frecuencia y consumo de corriente en los diferentes modos de bajo consumo.

Mantener la comunicación como una constante (es decir, el mismo protocolo de comunicación y frecuencia EM), luego elegir la mejor MCU es solo cuestión de agregar esos dos parámetros correctamente. Y así es como crearía un único valor numérico que podría comparar en todas las opciones:

1. Cree un perfil de actividad proyectado para el dispositivo (con qué frecuencia se comunica y durante cuánto tiempo) durante un período, por ejemplo, más de una semana.
2. Calcule el consumo actual a la frecuencia EM utilizada para los tiempos durante el período seleccionado cuando la comunicación está activa, es decir, un consumo de 10 uA (frecuencia @ 900 MHz) durante una duración de 2 s con una actividad de 1000 x en una semana significaría 20,000 uA-s / semana.
3. Calcule el consumo actual para los tiempos durante el período seleccionado cuando el dispositivo está en su modo de bajo consumo predeterminado, es decir, un consumo de 10 nA a [7 días x 24 horas x 60 minutos x 60 s - actividad de 1000 x 2 s] significaría 6.028 uA -s / semana.
4. Agregar los 2 rendimientos 26,028 uA-s / semana actual sorteo para esta hipotética MCU.
5. Este consumo actual semanal calculado se puede comparar para todas las MCU.

Sé que esta es una forma muy simplista de ver la actividad de MCU, es decir, solo consideró 2 estados: inactivo y en comunicación ... pero creo que cualquier otro estado tendrá contribuciones proporcionales y menores a uno de estos 2. Por ejemplo, el poder agotado para los cálculos (ciclos de instrucción) pueden agruparse junto con el estado de comunicación y lo más probable es que tengan una contribución muy pequeña en términos de potencia en comparación con el subsistema de comunicación. El punto es que mirar estos 2 estados es suficiente para el proceso de selección.

No hay una bala mágica, así que creo que el consejo será dolorosamente obvio. Comience a eliminar a los mayores consumidores de energía primero.

¿Estás realmente apagando todos los chips y circuitos cuando está inactivo? Sé que algunas de las placas y escudos para aficionados no siempre apagan por completo todo lo que esperas.

Si es el actuador, ¿puede usar un motor más ligero o reducir la fricción en el tren de transmisión? En general, ¿puede rediseñar la carga impulsada para tener menos masa o para estar mejor equilibrada?

Si es la comunicación, comience mirando la frecuencia de las comunicaciones. ¿Qué factores impulsaron la decisión existente de "dos minutos"? ¿Puedes hacer sacrificios para comunicarte con menos frecuencia? ¿Puedes cambiar a un modelo pub-sub y responder con menos bytes cuando las condiciones lo permitan?

Reevaluar el protocolo. Cada byte que afeita representa un ahorro del 1% de su presupuesto actual de energía de RF. ¿Envío de valores booleanos? Use banderas de bits, no una ASCII 'Y' o 'N'. Asegúrese de estar utilizando el contenedor más pequeño posible: no transmita un número entero de 16 bits si el número tiene un rango permitido de solo 0-99. La mayoría de los protocolos alimentados por batería intentan exprimirlo lo más posible; por ejemplo, si informa sobre una matriz de elementos 5x5, la dirección solo necesita ser un campo de 5 bits, no un byte de 8 bits. El uso de ciclos de CPU para la lógica relacionada con la compresión da como resultado un consumo de energía general mucho menor que la transmisión de bits innecesarios.

Si el gran consumo de energía es la CPU (dudoso, pero posible), ¿puede hacer trucos como tablas de búsqueda precalculadas, o incluso descargar parte del trabajo a un servicio remoto?

No existe un conjunto único de parámetros definitivos que pueda usar para seleccionar un dispositivo integrado como este, pero creo que, como primera aproximación, los dispositivos de nuevo diseño podrían ser significativamente mejores que algo de hace un par de años. Aunque el concepto no es nuevo, este nivel de integración y los objetivos de poder agresivos hacen de este un mercado en evolución.

Preste mucha atención a los estados de potencia que se ofrecen, vistos desde la perspectiva de todo su sistema (reguladores, osciladores, acondicionamiento de la señal del sensor). Es posible (poco probable) que su estado activo de 2 minutos se beneficie de un sueño menos profundo que el estado operativo normal.

El estado útil de energía más bajo debería representar la mayor parte de su consumo de energía. La forma exacta en que esto se desarrolle depende de cosas como si puede operar directamente sin corriente eléctrica sin un regulador, voltaje de funcionamiento mínimo, etc.

Para el estado activo, considere sus operaciones más intensivas de RAM o cómputo y compárelas con las partes disponibles equivalentes más cercanas que pueda encontrar (basadas en la arquitectura de CPU, velocidad y memoria). En su aplicación, parece que preparar la carga útil y el cifrado puede ser bastante trivial, pero en general esto no es una suposición obvia. Los estados de retención pueden permitir la integración del sensor sin guardar / restaurar estados, por ejemplo.

Haga coincidir la velocidad del reloj y la arquitectura con las demandas de su aplicación. En estado de suspensión, ahorra energía de fuga. Las velocidades de reloj objetivo más bajas para un dispositivo pueden significar que necesita permanecer en un estado activo durante más tiempo, pero también dar como resultado un diseño que logre un mejor rendimiento de fuga (así como tal vez un voltaje de funcionamiento más bajo).

No conocerá el mejor diseño absoluto hasta que haya iterado más de un diseño: hay demasiados parámetros (y en este momento, su producto comenzará a envejecer), por lo que los aspectos de mayor nivel del flujo de diseño aún importante. Si puede optimizar su arquitectura para reducir los eventos de activación en un 5%, esto debería ser notable en la duración de la batería.