Kleidos
EN ES
Menú

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.

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.

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.

El reloj Plus SE (mA) Core2 v1.3 (mA)
80 MHz A lo que corren todas las pantallas 22,025,3
160 MHz A lo que se compone y se envía un repintado de pantalla completa 26,130,2
240 MHz A lo que corre el desbloqueo de dos segundos, y nada más 34,243,1

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

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.

Placa Partes por millón Segundos por hora dormido
M5StickC Plus S3 -1768 a -99 0,4 a 6,4
M5Cardputer ADV -2022 a -538 1,9 a 7,3
LilyGO T-Deck Plus -6033 a -4719 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.