Programación y gestión de redes de notas via Internet I

Programación y Gestión de Redes de Motas Via Internet I J. Jiménez A. Priegue F. Guzmán E. Oñate Publicación CIMNE Nº-279, Diciembre 2005 CENTRO INTERNACIONAL DE MÉTODOS NUMÉRICOS EN INGENIERÍA Programación y Gestión de Redes de Motas Via Internet I J. Jiménez A. Priegue F. Guzmán E. Oñate Publicación CIMNE Nº-279, Diciembre 2005 Centro Internacional de Métodos Numéricos en Ingeniería Gran Capitán s/n, 08034 Barcelona, España ÍNDICE 0. Introducción 0 1. Desarrollo de una aplicación de programación sobre el aire 1 1.1 Conceptos de la programación sobre el aire 1 1.2 Adaptación de una aplicación 3 1.3 Validación de la aplicación Blink 3 2. Desarrollo de una Aplicación de Sensor de Luz 7 2.1 Arquitectura del Sensor 7 2.2 Desarrollo del driver de Sensor 8 2.2.1. Determinar las interfaces del hardware con el sensor 8 2.2.2. Definir las líneas de entrada / salida con Tinyos 9 2.2.3. Crear la componente de Tinyos para controlar el sensor 9 2.2.4. Crear una aplicación simple 10 2.3 Interfaz de comunicación UART 13 2.3.1 Nueva componente GenericComm 13 2.3.2 Estructura de mensajes en Tinyos 14 2.3.3 Código para el puerto UART 15 2.4 Interfaz de comunicación por RF 17 3. Consumo energético en motas 19 4. WSNP – Plataforma web para el monitoreo de redes sensoriales 22 4.1 Administración 22 4.1.1 Administración de usuarios 23 4.1.12 Administración de proyectos de redes 25 4.2 Monitoreo de una red 26 5. Anexo 28 0. Introducción Este trabajo presenta los desarrollos llevados a cabo en CIMNE en la programación y gestión de redes de motas utilizando Internet. El trabajo se enmarca dentro de la línea de I+D de CIMNE en el estudio, desarrollo y aplicación de redes de sensores inteligentes sin hilos en diversos ámbitos de la ingeniería. En las referencias [(1-3)] se describen los resultados de investigaciones anteriores del equipo de CIMNE sobre el tema. El trabajo se ha llevado a cabo en el marco de las actividades del proyecto "Desarrollo de tecnologías para investigación y gestión de procesos constructivos utilizando redes de sensores sin hilos.(PROSENSOR)" financiado por el programa PROFIT del Ministerio de Educación y Ciencia. El proyecto se inició en Noviembre de 2005 y su finalización está prevista en Diciembre, 2007. Los autores agradecen a la empresa Sensoria S.A., el asesoramiento y colaboración en la realización del trabajo. Referencias [(1)] J. Jiménez y E. Oñate, "Plataforma WSN/NIMS - I", Publicación CIMNE PI- 268, 20pp., 2005 [(2)] J. Jiménez, A. Priegue, J. Piazzese y E. Oñate, "Plataforma WSN/NIMS II. Primeras experiencias en CIMNE", Publicación CIMNE PI-272, 28pp., 2005 [(3)] J. Jiménez, A. Priegue, J. Piazzese y E. Oñate, "Plataforma WSN/NIMS III. Programación básica de motas", Publicación CIMNE PI-277, 20 pp., 2005 Plataforma WSN/NIMS IV 1 1. Desarrollo de una aplicación de programación sobre el aire En este apartado se explicará el procedimiento para realizar la programación de las motas a través del envío de los paquetes por el aire. Dicha aplicación tiene la ventaja de poder reprogramar las motas sin la necesidad de traer a éstas a la tarjeta de programación Mib510. A lo largo de esta sección se describirán los siguientes pasos:  Conceptos de la programación sobre el aire.  Adaptación de una aplicación.  Validación de la aplicación Blink. 1.1 Conceptos de la programación sobre el aire Para la programación sobre el aire, las motas utilizan un servicio llamado “Deluge”, el cual se rige por un modelo epidémico para contagiar a todas las motas de una red. Este programa es muy compacto y utiliza 159 bytes de la memoria RAM, y 3.5 kB extra para el programa. El programa “Deluge” sigue una estrategia de trabajo la cual considera una serie de pre-condicionantes.  Los nodos están habilitados con el servicio Deluge.  La librería Deluge está conectada  “Bootloader” instalado. Existen dos pasos en la aplicación del servicio “Deluge”.  Infección - Descarga y propagación.  Reprogramación y reinicio del nodo. El programa a enviar por el aire a las motas recibe el nombre de “imagen de programa”, y dicho programa es dividido en páginas cada una conteniendo N paquetes. Las ventajas que ofrece la estructura de páginas es que se puede trabajar con memoria RAM limitada, para sólo mantener el estado sobre cuales son los paquetes que se requieren. Así también, la estructura de páginas permite trabajar con multiplexado espacial. Cada imagen de programa está representada por un número de versión único. Plataforma WSN/NIMS IV 2 La operación de un nodo bajo los efectos de programación sobre el aire se representa en la figura siguiente. Al principio, el nodo es infectado con una nueva versión de programa y posteriormente éste se encarga de infectar al vecino. Cada nodo tiene la capacidad de comunicar al nuevo paquete sobre el aire el número de versión de programa con el que cuenta. Si el nodo requiere actualización solicita la descarga del paquete al vecino más próximo que cuente con la información, una vez realizado esto, el nodo actualizado se comunica con sus nodos vecinos que están a su alcance para repetir el proceso en caso de ser necesario. El Bootloader, es un programa especial para las motas que les permite realizar las siguientes operaciones:  Toma la imagen de programa de la memoria externa flash.  Escribe la imagen de programa directamente en la memoria del procesador.  Se repite hasta que una nueva imagen de código ha sido cargada completamente.  Reinicia el procesador y el nuevo programa comienza su operación. Plataforma WSN/NIMS IV 3 1.2 Adaptación de una aplicación En este apartado utilizaremos la aplicación “Blink”, la cual adaptaremos al servicio “Deluge” con la finalidad de poder enviar este programa a las motas de la red vía aire. El primer paso será realizar la conexión de la componente “DelugeC” a la aplicación Blink, de manera que se pueda acceder a las interfaces ofrecidas por dicha componente. configuration Blink { } implementation { components Main, BlinkM, SingleTimer, LedsC, DelugeC; Main.StdControl ->DelugeC; Main.StdControl -> SingleTimer.StdControl; Main.StdControl -> BlinkM.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC; } La componente DelugeC, utiliza la interfaz StdControl para inicializarse, comenzar y parar su funcionamiento. El segundo paso es incluir la librería Deluge en el archivo Makefile de la aplicación. COMPONENT=Blink TINYOS_NP=BNP XBOWROOT=%T/../contrib/xbow/tos PFLAGS= -I$(XBOWROOT)/platform/mica2 include ../MakeXbowlocal include $(TOSROOT)/tools/make/Makerules Una vez realizados los dos pasos mencionados anteriormente, la aplicación Blink está lista para ser compilada para posteriormente ser enviada a las motas de una red vía aire. 1.3 Validación de la aplicación Blink El objetivo será programar las motas de una red a través del envío de la información vía aire.  Realizaremos la compilación y descarga en cada una de las motas del programa “GoldenImage” (El cual representa nuestro servicio Deluge). Dicho programa se encuentra en el directorio: contrib/xbow/apps/TestDeluge/GoldenImage/ Plataforma WSN/NIMS IV 4 Una vez compilado e instalado en cada una de las motas, contamos con el servicio Deluge en cada una de éstas.  A continuación se definirá el puerto COM para hacer uso de las herramientas de Java que ofrece Tinyos. Para la tarjeta Mib510, desde la ventana de Cygwin se ejecutará el siguiente comando: export MOTECOM=serial@COM1:57600 Para este caso suponemos que el puerto de comunicación es el 1 y que el número de bits por segundo es de 57600.  Estado de las motas. Para verificar el ID del nodo y que el programa GoldenImage ha sido correctamente instalado, se ejecuta el siguiente comando en el directorio Java de Tinyos: tinyos-1.x/tools/java java net.tinyos.tools.deluge - -ping El resultado de dicha instrucción se representa en el recuadro que se muestra a continuación. El recuadro muestra que se está utilizando el puesto COM1 a una velocidad de datos de 57600 bits por segundo. Así también se muestra el ID del nodo y la ejecución del programa “GoldenImage” en este. Para este caso, el recuadro también indica que la mota no tiene ninguna aplicación sobre el aire descargada. Esto se puede interpretar por medio del parámetro “No Image” en la columna de Páginas. Plataforma WSN/NIMS IV 5 Cada una de las motas deberá contar con el programa GoldenImage instalado, tanto la mota que se encontrará en la mib510 como base, así como las motas que se encontrarán desplegadas como miembros de la red de motas. Una vez instalado GoldenImage, centraremos la atención en la aplicación “Blink”, la cual será inyectada a la red de motas, de forma que cada mota integrante de la red pueda descargar la “imagen de programa” en su memoria del procesador. Una vez compilada la aplicación “Blink”, el archivo main.ihex, creado en la carpeta buid de la aplicación, tendrá que ser copiado y pegado en la carpeta tinyos/tools/java. El siguiente paso será inyectar el programa en la red de motas. Para dicho objetivo, se ejecutará un comando especial en el siguiente directorio: opt/tinyos-1.x/tools/java java net.tinyos.tools.Deluge - -inject - -ihexfile main.ihex - -imgnum 0 Una vez ejecutada dicha instrucción, aparece el siguiente recuadro que nos indica el progreso de la descarga. El red rojo parpadeando significa que la mota está recibiendo páginas de código. Conforme la instrucción se ejecuta, se puede observar el comportamiento de los Leds en las motas:  Led verde, cuando la mota busca por la versión de la información.  Led rojo parpadeando, cuando la mota recibe páginas de información. Si una nueva mota es encendida o puesta dentro del rango de recepción, ésta se actualizará automáticamente, siempre y cuando contenga la aplicación GoldenImage, previamente en su memoria. Si vemos el estado de la mota, por medio del comando: java net.tinyos.tools.Deluge - -ping Plataforma WSN/NIMS IV 12 El programa TestSensor se encarga de hacer las conexiones entre las componentes primitivas y complejas de la aplicación. configuration TestSensor { // this module does not provide any interface } implementation { components Main, TestSensorM, LedsC,TimerC, PhotoDriver as Sensor; Main.StdControl -> TestSensorM; Main.StdControl -> TimerC; // Wiring for New Sensor TestSensorM.SensorControl->Sensor; TestSensorM.SensorData -> Sensor; TestSensorM.Leds -> LedsC; TestSensorM.Timer -> TimerC.Timer[unique("Timer")]; } Se definen las componentes a utilizar dentro de nuestra aplicación, y se asigna un alias a PhotoSensor. Se define el uso de la interfaz StdControl en las componentes TestSensorM y TimerC. Se hace la conexión entre el programa TestSensorM y PhotoDriver. Conexión de la componente LedsC y TimerC. La palabra unique, permite identificar nuestro temporizador en las componentes de la aplicación. Finalmente, destacamos que en la carpeta de trabajo de nuestra aplicación, se contendrán los siguientes archivos: Makefile. Define las direcciones de archivos complementarios para la compilación de la aplicación. Sensorboard.h. Archivo definido por el usuario. Contiene enumeraciones, registros o tipos de datos creados por el usuario. PhotoDriver. Es el archivo de conexiones entre las componentes del sistema y el programa PhotoDriverM. PhotoDriverM. Es el archivo que implementa el código que inicia, arranca y detiene el sensor de luz. Plataforma WSN/NIMS IV 13 TestSensor. Es el archivo de conexiones entre las componentes del driver del sensor de luz y el programa TestSensorM. TestSensorM. Contiene el código para iniciar el sensor, el temporizador y tomar los datos. Así también contiene el código para el control de los leds. 2.3 Interfaz de comunicación UART A través de este apartado, se analizará como hacer uso de la información obtenida por medio del sensor de luz, basándonos en el la comunicación a través del puerto UART del sistema y el comando Xlisten. Empezaremos definiendo dos conceptos fundamentales:  UART. Es un circuito que utiliza la mica2, para convertir los datos en paralelo, que manda la UCP, en serie, con el fin de comunicarse con otro sistema externo.  Xlisten. Es una herramienta diseñada para desplegar las lecturas tomadas por las tarjetas de sensores, a través del puerto serie o por RF. Los datos medidos por el sensor de luz, pueden ser enviados a un ordenador por medio del puerto serie del mismo. La velocidad a la cual se envían estos datos, entre la mica2 y el ordenador, es de 57600 bits por segundo. En el apartado 2, se han creado los programas para el driver del sensor (PhotoDriver) y los programas de validación del mismo (TestSensor). Para realizar las pruebas del apartado 3 -enviar los datos medidos por el puerto serie y desplegarlos en el ordenadorañadiremos algunas líneas de código al programa TestSensorM y a las conexiones de TestSensor. 2.3.1 Nueva componente GenericComm La componente GenericComm será integrada a las conexiones definidas en el archivo TestSensor.nc, posteriormente el programa TestSensor.M.nc, hará uso de las interfaces que proporciona dicha componente. GenericComm es una componente que dirige toda la información de los Mensajes Activos (AM) en las motas hacia el UART o el medio de Radio Frecuencia (RF). Plataforma WSN/NIMS IV 14 Organización de Tinyos GenericComm Los diferentes tipos de Mensajes Activos se identifican por medio de los Canales de Datos, de tal manera que la información irá directamente a los componentes que la necesitan. 2.3.2 Estructura de mensajes en Tinyos Los mensajes que Tinyos envía por el puerto serie o el medio de RF siguen la estructura que se presenta a continuación.  Header: Esta parte está integrada por 5 bytes, los cuales se utilizan de la siguiente manera. o Dirección de destino: 2 bytes. o Tipo de Mensaje Activo (AM): 1 byte. o ID del grupo: 1 byte. o Longitud de datos (Payload): 1 byte.  Payload: Se pueden enviar hasta 29 bytes de datos de los resultados de las actividades de la aplicación.  CRC: Se utilizan 2 bytes, y pueden ser empleados para monitorizar la media de error de bit. Existen un par de protocolos que permiten aumentar la fiabilidad de transmisión de los datos dentro del sistema Tinyos.  Serial Framer Protocol. Apoya en asegurar la fiabilidad del grupo de bytes transmitido sobre el puerto UART. Plataforma WSN/NIMS IV 15  Serial Forwarder Protocol. Apoya en el re-envío de comunicación del puerto serie sobre un puerto de Internet. 2.3.3 Código para el puerto UART Bajo esta sección, se agregará el código necesario para habilitar el envío de datos por el puerto UART.  Conexiones de la componente GenericComm en TestSensor.nc. En este apartado se definen las interfaces para el envío de mensajes, así como la estructura de los mensajes. #define AM_TYPE 50 Components GenericComm as Comm; TestSensorM.CommControl -> Comm; TestSensorM.SendMsg -> Comm.SendMsg[AM_TYPE]; Se define el tipo de Mensaje Activo. Se agrega la componente asignándole un alias. Se hacen las conexiones para facilitar las interfaces CommControl y SendMessage.  A continuación se estructura la salida del paquete XSensor de la aplicación. En las especificaciones del archivo TestSensorM.nc agregamos las interfaces de mensajes: interface StdControl as CommControl; interface SendMsg; En la sección de implementación del archivo TestSensorM.nc declaramos las variables del mensaje TOS: Plataforma WSN/NIMS IV 16 typedef struct DataMsg { uint8_t board_type; uint8_t packet_id; uint8_t node_id; uint8_t parent; uint16_t batt; uint16_t temp; uint16_t light; } __attribute__ ((packed)) DataMsg; Finalmente se define el espacio de memoria y variables globales. TOS_Msg msg_buff; TOS_MsgPtr msg_ptr; norace uint16_t sens;  Envío del TOSmsg sobre el puerto UART. #define MSG_LEN 29 task void send_msg(){ DataMsg* data = (DataMsg*)msg_ptr->data; call Leds.yellowToggle(); data->batt = bat; data->light = sens; data->board_type = SENSOR_BOARD_ID; data->packet_id = 1; data->node_id = TOS_LOCAL_ADDRESS; data->parent = 0; call SendMsg.send(TOS_UART_ADDR, MSG_LEN, msg_ptr); } Longitud del mensaje en bytes. Función send_msg de la componente GenericComm. Asignación de los parámetros de identificación y de medición del sensor. Definición del puerto UART como destino de la información. Con el uso de la interfaz StdControl, se inicializa la componente GenericComm. command result_t StdControl.init() { atomic msg_ptr = &msg_buff; call Leds.init(); call SensorControl.init(); call CommControl.init(); call BatteryControl.init(); return SUCCESS; } command result_t StdControl.start() { call Leds.redOn(); call SensorControl.start(); call CommControl.start(); call BatteryControl.start(); call Timer.start(TIMER_REPEAT, 1000); return SUCCESS; } Plataforma WSN/NIMS IV 17 La información del sensor se coloca en un TOSMsg una vez llegado el evento dataReady. Posteriormente se llama una tarea para enviar el paquete. async event result_t SensorData.dataReady (uint16_t data) { call Leds.greenToggle(); sens = data; post send_msg(); return SUCCESS; } Finalmente se define la interfaz SendDone. event result_t SendMsg.sendDone(TOS_MsgPtr msg, result_t success) { call Leds.yellowToggle(); return SUCCESS; }  Validación del código implementado. Para comprobar que el código funciona correctamente, es necesario realizar los siguientes pasos: o Conectar la Mib510 al puerto serie del ordenador. o Instalar un Mica2 sobre la Mib510. o Desde el Cygwin, ir a la carpeta donde se encuentra la aplicación. o Compilar la aplicación “make mica2” o Descargar la aplicación “make mica2 reinstall.0” Para poder ver la lectura del sensor de luz, es necesario que se llame al comando Xlisten desde la interfaz Cygwin. 2.4 Interfaz de comunicación por RF En este apartado se realizarán los cambios necesarios al código de comunicación por el puerto UART, de tal manera que éste pueda transmitir por Radio Frecuencia. El objetivo es tener comunicación inalámbrica entre una mota y la estación base. El programa TOSBase es una aplicación que permite identificar mensajes de las motas enviados por radio frecuencia. Por tal motivo, este programa será instalado en la mota base para que ésta pueda actuar como un rastreador de señales. Cualquier paquete en el medio, que sea identificado por la mota base, será enviado por el puerto UART al ordenador.  Envío de mensaje por radio a través de la componente GenericComm. Es necesario realizar una pequeña modificación para activar la comunicación vía radio frecuencia. Se cambia el parámetro TOS_UART_ADDR por TOS_BCAST_ADDR. Plataforma WSN/NIMS IV 18 task void send_msg() { DataMsg* data = (DataMsg*)msg_ptr->data; call Leds.yellowToggle(); data->batt = bat; data->light = sens; data->board_type = SENSOR_BOARD_ID; data->packet_id = 1; data->node_id = TOS_LOCAL_ADDRESS; data->parent = 0; call SendMsg.send(TOS_BCAST_ADDR, MSG_LEN, msg_ptr); }  Consideraciones del rango de radio frecuencia. Es necesario definir la radio frecuencia en la cual trabajan las motas, 433Mhz, 916Mhz o 2400Mhz. Para hacer esto, se edita el archivo Makexbowlocal.  Validación del código implementado. Para comprobar que el código funciona correctamente, es necesario realizar los siguientes pasos: o Conectar la Mib510 al puerto serie del ordenador. o Colocar un Mica2 sobre la Mib510 e instalar la aplicación del sensor de luz. o Colocar un Mica2 sobre la Mib510 e instalar la aplicación TOSBase. Para poder ver la lectura del sensor de luz, es necesario que se llame al comando Xlisten desde la interfaz Cygwin. Plataforma WSN/NIMS IV 19 3. Consumo energético en motas Todas las motas están diseñadas para ser alimentadas por baterías. Las formas del MICA2 y del MICAz están diseñados para funcionar con dos baterías AA, aún así cualquier combinación de baterías (AAA, C, D, etc.) puede ser utilizada, siempre considerando que la alimentación debe ser de 2.7 VDC a 3.6 VDC. El MICA2DOT cuenta con un diseño para funcionar con una pequeña batería de forma de moneda, aunque cualquier combinación de baterías (AAA, C, D, etc.) puede ser utilizada bajo la condición de voltaje de 2.7VDC a 3.6VDC. A continuación se presenta una tabla con las especificaciones de baterías para cada uno de los tipos de motas. Mota Batería Capacidad (mA-hr) Voltage MICAz 2 AA 2000, alcalina 2.7 a 3.6 MICA2 2 AA 2000, alcalina 2.7 a 3.6 MICA2DOT De moneda 560, Li-ion 2.7 a 3.6 Se debe tener especial cuidado al seleccionar la batería y su capacidad para poder cubrir los requerimientos de energía de las motas y los períodos requeridos de su funcionamiento. También se debe considerar que el rango de temperatura de trabajo y la degradación de capacidad sean adecuadas para los ciclos de trabajo de la mota. La siguiente tabla proporciona información sobre los consumos de corriente de los diferentes componentes del sistema. Corriente de operación MICAz MICA2 MICA2DOT ATMega 128L, operando 8 mA 8 mA 6 mA ATMega 128L, durmiendo 8 uA 8 uA 8 uA Radio, reciviendo 19.7 mA 8 mA 8 mA Radio, transmitiendo (1mW) 17 mA 12 mA 12 mA Radio, durmiendo 2 uA 2 uA 2 uA Memoria, escritura 15 mA Memoria, lectura 4 mA Memoria, durmiendo 2 uA Plataforma WSN/NIMS IV 20 Los MICA2 y MICA2DOT también pueden ser alimentados externamente por medio de: 1. El conector de 51 pines se puede alimentar la corriente y el neutro a la unidad. 2. El conector de 2 pines “Molex”. (Mostrado a continuación) En la siguiente tabla se muestra un ejemplo para predecir la vida útil de una batería en las motas. La hoja de cálculo utilizada para realizar el cálculo puede ser encontrada en el ‘Anexo’ de este documento. ESPECIFICACIONES DEL SISTEMA DISPOSITIVO CONSUMO CICLO DE TRABAJO • Procesador A toda operación 8 mA 1 Durmiendo 8 uA 99 • Radio Recibo 8 mA 0.75 Transmisión 12 mA 0.25 Durmiendo 2 uA 99 • Memoria Escritura 15 mA 0 Lectura 4 mA 0 Durmiendo 2 uA 100 • Sensor Operación 5 mA 1 Durmiendo 5 uA 99 mA-hr usados cada hora Procesador 0.0879 Radio 0.0920 Memoria 0.0020 Sensor 0.0550 Total (mA-hr) usado 0.2369 Vida de batería vs. Tamaño de batería Meses 2000 11.73 560 3.28 Plataforma WSN/NIMS IV 21 La tabla anterior muestra el consumo de corriente para una mota en una hora de trabajo. Cabe considerar que los ciclos de trabajo de la mota a toda operación pueden parecer muy cortos, sin embargo hay que recordar que las tareas que se ejecutan son del orden de micro - mili segundos. En la mayoría de las aplicaciones de las motas, el procesador y la radio funcionan por un período muy breve de tiempo, seguidos por un ciclo de dormir. Mientras la mota duerme, el consumo de corriente es del orden de micro amperes, distinto al de mili amperes cuando la mota está operando. El ciclo de dormir ayuda a minimizar el consumo de corriente la mayor parte del tiempo, y cuando la mota despierta para procesar, transmitir o recibir información, sólo aparecen picos de consumo de corta duración. Este método de optimización de energía prolonga la vida de la batería, aún así, debido a las fluctuaciones de corriente en la batería, se reduce un mínimo la capacidad de la misma. Para los detalles de la tabla anterior, se puede consultar el ‘Anexo’ de este documento. Plataforma WSN/NIMS IV 28 5. Anexo Estimate of baterry life operation for a MOTE mA-hr % trabajo-hr mA-hr used each hr Total Time (min) Time (Seg) Processor Current full operation 8 1 0.08 0.6 36 Current sleep 0.008 99 0.00792 0.0879 59.4 3564 Radio Current to receive 8 0.75 0.06 0.45 27 Current to transmit 12 0.25 0.03 0.15 9 Current to sleep 0.002 99 0.00198 0.0920 59.4 3564 Logger Memory Current to write 15 0 0 0 0 Current to read 4 0 0 0 0 Current to sleep 0.002 100 0.002 0.0020 60 3600 Sensor Board Current full operation 5 1 0.05 0.6 36 Current sleep 0.005 99 0.00495 0.0550 59.4 3564 Total Current Used (mAmp-hr), each hour 0.2369 Daily consumption (24 hrs) mA-hr / day 5.684 Typical Battery Capacity mA-hr Voltage Range AA (2) - Alkaline 2000 2.7 to 3.6 Coin, Li-ion 560 2.7 to 3.6 Battery life Years Months (30 days) Weeks Days Hours AA (2) - Alkaline 0.98 11.73 50.26 351.84 8444.16 Coin, Li-ion 0.27 3.28 14.07 98.5 2364.37