# Mediciones Consumo, en miliamperios, leído del controlador de alimentación de la propia placa mientras funcionaba con su propia batería. Al lado de cada cifra está el objetivo que tenía que cumplir, cuando el proyecto se puso uno. Publico también las que no lo cumplen, porque un objetivo de consumo que nadie comprueba es decoración, y porque estas cifras no existen en ningún otro sitio: ninguna hoja de datos te dice cuánto consume un gestor de contraseñas con la pantalla al 85 por ciento y un punto de acceso levantado. En esta página 1. [Despierto](https://kleidos.dev/#awake) 2. [El reloj](https://kleidos.dev/#clock) 3. [Dormido](https://kleidos.dev/#asleep) 4. [Deriva](https://kleidos.dev/#drift) 5. [Método](https://kleidos.dev/#method) ## Lo que consume despierto Una tirada, dos placas, todas las fases con batería y el cable USB fuera, sobre una compilación de desarrollo con el registro, la consola y los diagnósticos en marcha. La retroiluminación va al 100 por cien salvo en las filas que digan otra cosa. ### Pantalla del PIN **Plus SE** 77,5 mA **Core2 v1.3** 81,4 mA **Objetivo** 20 mA por encima del objetivo El dial de desbloqueo, esperando una cifra. ### Lista de la bóveda **Plus SE** 77,4 mA **Core2 v1.3** 80,9 mA La lista de credenciales en pantalla. ### Lista de la bóveda al brillo de fábrica **Plus SE** 69,0 mA **Core2 v1.3** 70,4 mA La misma pantalla al 85 por ciento, que es el brillo con el que sale el firmware. Al 100 por cien consume entre ocho y diez miliamperios más, por una retroiluminación que nadie había pedido más brillante. ### Escribiendo por Bluetooth **Plus SE** 85,4 mA **Core2 v1.3** 91,9 mA **Objetivo** 50 mA por encima del objetivo La pantalla de envío con la radio levantada, esperando a que el equipo recoja las pulsaciones. ### Punto de acceso de administración **Plus SE** 153,5 mA **Core2 v1.3** 153,4 mA **Objetivo** 130 mA por encima del objetivo La red del panel levantada y sin ningún cliente conectado. De esta cifra, el punto de acceso en sí se lleva entre 72 y 76 mA. ### Pantalla dormida **Plus SE** 24,7 mA **Core2 v1.3** 25,6 mA La lista de la bóveda con el panel apagado, al reloj base. Esto es el chip despierto y casi nada más, y ya está por encima de los 20 mA que se le habían asignado a la pantalla del PIN. Tres de estas filas tienen objetivo y las tres están por encima. La pantalla del PIN consume unas cuatro veces lo que se le permitía; escribir, alrededor de una vez y media; el punto de acceso, algo más. La pantalla encendida es la mayor parte: al 100 por cien, la retroiluminación sola se lleva entre 53 y 55 mA de la cifra, que es por lo que la misma placa con la pantalla dormida consume 25. Dos tiradas de la misma fase en la misma placa salieron con hasta 4 mA de diferencia, así que una diferencia menor entre las dos columnas no es un hallazgo. La comparación firme es la que se hace dentro de una misma tirada: una placa, una carga, minutos de separación. La tirada completa, fase por fase, está en docs/research/consumption-self-measurement.md. ## Lo que cuesta el reloj Las mismas dos placas con el panel apagado, a cada uno de los tres relojes que usa el firmware. La pantalla está apagada en los tres, así que la diferencia es el chip y nada más. **80 MHz** A lo que corren todas las pantallas Plus SE: 22,0 mA Core2 v1.3: 25,3 mA **160 MHz** A lo que se compone y se envía un repintado de pantalla completa Plus SE: 26,1 mA Core2 v1.3: 30,2 mA **240 MHz** A lo que corre el desbloqueo de dos segundos, y nada más Plus SE: 34,2 mA Core2 v1.3: 43,1 mA Esta tabla es la razón de que todas las pantallas corran al reloj más bajo que da el multiplicador interno del chip y de que el reloj solo se suba para el trabajo que necesita velocidad: mantener 240 MHz toda una sesión costaría entre 12 y 18 mA para nada. La subida ocurre donde está el trabajo y no en el punto de llamada, así que cualquier llamada nueva la hereda. La tirada completa, fase por fase, está en docs/research/consumption-self-measurement.md. ## Lo que consume dormido: no lo sé Nueve placas, nueve cifras, y ninguna de ellas es una medición. Cada una es la estimación declarada en la configuración de la propia placa, y el objetivo eran 20 microamperios. estimación, no medición ### M5StickC Plus2 **Estimación** 10 µA **Objetivo** 20 µA Suelta su propia retención de alimentación: la placa se corta la corriente. ### M5Stack CoreInk **Estimación** 10 µA **Objetivo** 20 µA Suelta su propia retención de alimentación: la placa se corta la corriente. ### M5StickC Plus 1.1 **Estimación** 30 µA **Objetivo** 20 µA por encima del objetivo Se apaga en su controlador de alimentación, que sigue despierto para volver a encenderla y consume mientras espera. ### M5StickC Plus SE **Estimación** 30 µA **Objetivo** 20 µA por encima del objetivo Se apaga en su controlador de alimentación, que sigue despierto para volver a encenderla y consume mientras espera. ### M5Stack Core2 v1.3 **Estimación** 30 µA **Objetivo** 20 µA por encima del objetivo Se apaga en su controlador de alimentación, que sigue despierto para volver a encenderla y consume mientras espera. ### M5Stack CoreS3 SE **Estimación** 105 µA **Objetivo** 20 µA por encima del objetivo Se apaga en su controlador de alimentación, que sigue despierto para volver a encenderla y consume mientras espera. ### M5StickC Plus S3 **Estimación** 110 µA **Objetivo** 20 µA por encima del objetivo Entra en sueño profundo con una línea alimentada, para que siga corriendo el reloj interno del chip. ### M5Cardputer ADV **Estimación** 150 µA **Objetivo** 20 µA por encima del objetivo Entra en sueño profundo con una línea alimentada, para que siga corriendo el reloj interno del chip. ### LilyGO T-Deck Plus **Estimación** 200 µA **Objetivo** 20 µA por encima del objetivo Entra en sueño profundo con una línea alimentada, para que siga corriendo el reloj interno del chip. No he hecho las mediciones de banco que cambiarían estas estimaciones por lecturas de un polímetro. El dispositivo no puede hacerlo por mí: en un stick con una celda de 120 a 250 mAh, estimar por la caída de tensión solo llega a una precisión de unos diez a veinticinco microamperios tras tres a siete días dormido, y en las placas grandes solo caza fugas del orden del miliamperio. Por eso el firmware da un veredicto de apto, no apto o desconocido con sus márgenes de error, y nunca presenta la cifra de un modelo como una lectura. Las dos estimaciones más bajas son de las placas que se cortan su propia alimentación, y pueden permitírselo porque un chip de reloj aparte mantiene la hora mientras están apagadas. Las tres más altas dejan una línea alimentada para el reloj interno del chip, porque no tienen ningún chip de reloj, que es justo de lo que habla la sección siguiente. Seis de las nueve tampoco tienen sensor de corriente en la línea de batería, así que en esas no hay medición propia que mejorar: un polímetro es la única forma de que estas nueve cifras dejen de ser estimaciones. La tirada completa, fase por fase, está en docs/testing/production-sleep-checklist.md. ## El reloj que deriva Las tres placas sin chip de reloj mantienen la hora durante un sueño con un oscilador interno dividido entre 256. Esta es la deriva de sus relojes en 66 sueños, medida contra el reloj del ordenador, sincronizado con NTP. La tabla recoge los sueños profundos de producción empezados en reposo, y en todos ellos el reloj del dispositivo se quedó atrás. En los sueños empezados en caliente, tras diez minutos de carga, dos placas se adelantaron: el Plus S3 en uno de sus dos sueños en caliente y el Cardputer en los dos. El T-Deck se quedó atrás en todos sus sueños profundos. **M5StickC Plus S3** Partes por millón: -1768 a -99 Segundos por hora dormido: 0,4 a 6,4 **M5Cardputer ADV** Partes por millón: -2022 a -538 Segundos por hora dormido: 1,9 a 7,3 **LilyGO T-Deck Plus** Partes por millón: -6033 a -4719 Segundos por hora dormido: 17 a 22 Los mayores errores de toda la tirada fueron de 6033 partes por millón de retraso y 2300 de adelanto. Cada chip arrastra su propio desvío (el T-Deck unas 5000, los otros dos unas 1000) y alrededor de ese desvío la temperatura del propio chip mueve el error más que nada: un sueño empezado en caliente se desvió entre 1500 y 2700 partes por millón menos. Un sueño ligero con el cristal alimentado tampoco mantiene la hora con la precisión de un cristal. No se aplica ninguna corrección. Ninguna que se ajuste a esa dispersión mantendría un código de un solo uso dentro de su margen de un paso, así que en estas tres placas los códigos vienen desactivados, y al activarlos piden una sincronización nueva (de una red, del navegador que abrió el panel de administración o de una posición por satélite) hecha después del último sueño profundo. La tirada completa, fase por fase, está en docs/research/slow-clock-sleep-matrix.md. ## Cómo se tomaron Los tres grupos de arriba salen de tres métodos distintos, y mezclarlos sería lo más engañoso que podría publicar este proyecto. - Las cifras de estado despierto salen del controlador de alimentación de la propia placa. Tres de las nueve placas tienen un sensor de corriente en la línea de batería, y las dos de la tabla son dos de esas tres; las otras seis solo se pueden modelar. Cada cifra es la media de una ventana de medida tomada después de que la pantalla se hubiera asentado. - La tirada fue con batería y el cable USB fuera, dirigida a través de la consola serie por un script del repositorio y leída con otro. La compilación llevaba la tarea de registro, la consola y los diagnósticos en marcha, así que, en todo caso, estas cifras son algo pesimistas. - Las cifras de sueño no son mediciones y aparecen etiquetadas como estimaciones en todos los sitios donde salen. La lista de comprobación que las sustituiría necesita un polímetro externo y una persona que pulse teclas, y no la he pasado en ninguna placa. - Las cifras de deriva salen de otro método más: el reloj del propio dispositivo contra el reloj del ordenador, comprobado con NTP, antes y después de cada sueño, leyendo la cuenta de pulsos del oscilador en los dos extremos para poder calcular el periodo que realmente mantuvo en vez de suponerlo. - Nada vuelve a leer el firmware para comprobar que estas cifras siguen siendo las que produce. No hay ningún comprobador; las mantengo correctas a mano, y cada sección dice qué documento guarda la tirada de la que salen sus cifras.