Mejorar la vida de las baterías de Litio

¿Eres de los que espera a que se termina la batería del móvil para cargarlo? ¿Temes el efecto memoria? El efecto memoria y similares se esfumó cuando los dispositivos pasaron a usar baterías de Litio. La mejor forma de conservarlas no es haciendo ciclos de carga completos. Os explico en este post cómo funcionan las baterías de Litio y cómo se deben tratar.

Las baterías de Litio usan un voltaje medio de 3.7 voltios y varía generalmente entre 2.8v y 4.2v. Con este tipo de baterías se pueden realizar cargas y descargas parciales sin problema; es decir, no tenemos el porqué preocuparnos de poner el móvil a cargar cuando aún le queda el 60%; ni tampoco por desconectarlo del cargador si aún está al 70%. Los porcentajes son un ejemplo; cualquier porcentaje sería válido.

Estas baterías sufren más por dejarlas o forzarlas en estados extremos de la carga. Esto es, por encima del 85% y por debajo del 20%. Su mejor rango de trabajo va del 30% al 80%. Por ejemplo, para almacenar las baterías un largo período hay que dejarlas con un 60% de carga aproximadamente. Si están demasiado cargadas se hinchan. Si no tienen suficiente, con los años la pierden y se vuelven irrecuperables.

No es bueno tener los dispositivos permanentemente en el cargador. Eso reduce su vida útil. Con los móviles es menos acusado, pues llevan sistemas para automatizar la carga. Cuando llega al 100%, el cargador deja de funcionar hasta que la batería cae al 95%. Según el móvil y ROM esto puede ser perceptible o puede que lo esconda al usuario. Si una ROM realiza ciclos de carga demasiado a menudo (por ejemplo del 98 a 100%), tener el móvil cargando por la noche puede ser perjudicial. Afortunadamente casi ninguna hace esto. De todos modos, si quieres maximizar la vida útil de la batería, desconecta el cargador al llegar al 90%.

Para jugar y otros usos del móvil que piden mucha energía, es mejor que el móvil tenga una buena carga, siempre por encima del 60%. Las baterías se desgastan por el uso que le hacemos, pero internamente hablaríamos de oxidación por el movimiento de electrones. A nivel eléctrico, el electrón transfiere más energía a mayor sea el voltaje; por lo que se concluye que si tiene más tensión (está más cargada) conseguiremos menor desgaste de batería para las mismas horas de juego.

Tanto las cargas rápidas como las descargas rápidas desgastan la batería algo más de lo normal. Hoy en día las de los móviles suelen estar preparadas y la diferencia es poca, pero hay gente que prefiere cargar por USB al ordenador que es mucho más lento, ya que la carga es mejor y alargan un poco su vida útil.

En el caso de los portátiles, al permanecer conectados a la red parece que degradan la batería fácilmente. Da la sensación de que no llevan un regulador de la carga. Si es posible, el portátil hay que conectarlo y desconectarlo intermitentemente. Es un coñazo, pero parece hecho a propósito por los fabricantes para aumentar la venta de los equipos nuevos.

Volviendo a los móviles, se da el caso a veces que el indicador de batería no refleja la batería real. Por ejemplo que veamos un 60% y de golpe baje a un 30%, o que se apague el terminal sin motivo. También puede pasar hacia arriba, que indique un 80% y al cargar de golpe indique 100%. Si pasa, no es que la batería esté estropeada, aunque es señal de desgaste, lo que indica es que necesitamos calibrarla de nuevo. La carga de una batería no se puede determinar mientras está conectada a un dispositivo o cargador, por lo que se recurre a otros métodos para poder determinar el porcentaje de carga. Lo que hacen los móviles es estimar la carga a partir del uso que se le ha dado al móvil; por eso, si la batería ya no se comporta como antes, la estimación es incorrecta. Esto se arregla realizando una calibración completa de la batería.

Para calibrar una batería por completo el procedimiento es sencillo. Primero descargamos la batería por completo hasta que el terminal se apague. Luego, una vez el terminal está apagado un tiempo (por ejemplo una hora), se conecta el cargador, pero no encendemos el terminal. Se deja en el cargador hasta que llegue al 100%, desconectamos el cargador, dejamos que repose un tiempo y encendemos el móvil. Con esto el sistema realiza un nuevo perfil de carga, que normalmente corregirá los problemas de estimación. No es estrictamente necesario dejar reposar el terminal, ni dejar que se apague, ni que llegue al 100%. Lo que sí es preciso es realizar la carga con el terminal apagado. Si no realiza una carga completa sólo tendrás un perfil parcial de la batería. Los tiempos de reposo mejoran las mediciones reales mínimas y máximas.

Si al conectar el cargador el móvil no se enciende: paciencia. Los móviles cuentan con un sistema de protección de la batería: si la batería baja de 3.2V el móvil no se enciende. Eso no quiere decir que no cargue la batería. Las baterías si bajan de 2.5V pueden bloquearse y no cargar jamás; por eso mismo los móviles con un margen de seguridad muy grande bloquean todas las funciones excepto la carga.

Recomiendo mucho mantener en el móvil funcionando una aplicación que registre porcentaje y voltaje de la batería durante al menos los últimos 7 días. Cuando algo ocurre, éstas aplicaciones dan una información muy valiosa de qué ha pasado y cómo se ha estado comportando la batería. Con que realicen una muestra cada 15 minutos es suficiente, y esta actividad apenas consume batería. En mi caso, la aplicación que uso es el 3C Battery Monitor.

El 4g y la banda de 800mhz

No sé si habéis escuchado hablar alguna vez de la banda de 800Mhz para el 4G. Sino, seguro que os sonará resintonización de la televisión que tuvo lugar a principios de 2016. Con ésto pretendían liberar la banda de 800Mhz para que lo puedan usar los móviles con el 4G. Éste tiene muchas más bandas aparte de la de 800Mhz, y en el caso de España hay al menos otras dos bandas en funcionamiento que no entran en conflicto con el televisor. ¿Porqué entonces tomarse tanta molestia para algo que ya funciona?

Resulta que la banda de 800Mhz es importante para un buen funcionamiento del 4G. A pesar de que es de todas la que menos ancho de banda tiene (a menor frecuencia, menor ancho de banda), resulta que es la que más alcance y penetración tiene. A las zonas rurales o dentro de los locales no llegan las bandas altas (de 2100Mhz por ejemplo). Se necesitan muchos postes o repetidores, cosa que es interesante en ciudades (y necesario por la cantidad de gente que hay), pero en otras zonas menos pobladas esto no sale a cuenta. La banda de 800Mhz casi que puede reaprovechar los antiguos repetidores de 2G.

Respecto al móvil, algunos recordaréis que cuando la cobertura es pobre en el móvil en lugar de “H+” se veía “E” … y iba como el culo. Esta letra “E” indicaba lo que se llama el 2.9G y es la banda de 900Mhz del 3G. Cuando la cobertura era aún peor, se veía “G” y entonces si que te podías olvidar hasta de enviar whatsapp. Bien, pues este “G” era la banda de 800Mhz del 2G, que ahora sirve para el 4G.

¿En qué nos afecta a la gente normal todo esto? No todos los móviles tienen la banda de 800Mhz, especialmente los de procedencia china, o cualquiera que no sea específico para el mercado español. Comprar un iPhone americano y traerlo aquí puede ser un error por esto mismo. Es como aquello del PAL y el NTSC, hay sistemas distintos en distintos países, y aunque los fabricantes intentan poner muchas frecuencias en el teléfono para que funcione en todo el mundo, parece que para poner unas tienen que descartar otras (o sino, no lo entiendo). Así que, el teléfono de América seguramente funcione en España, pero la cobertura no será la mejor posible.

El dilema que yo tenía a este respecto era el siguiente: El 4G promete velocidades altísimas, pero a mí me sobra con 10Mbps con el teléfono. La pregunta es, cuando esa velocidad pasa a la banda de 800Mhz, con cuanto nos quedamos? cuan cutre es la conexión con la banda de 800Mhz, realmente vale la pena? Estuve rebuscando mucho por internet y parecía que sí, pero nadie lo decía claramente.

Estuve esperando a comprarme nuevo teléfono (El sucesor de mi Xiaomi Redmi Note 4G, Codename Dior) a ver algo que al menos incorpore 4G de 800Mhz. Sorprendentemente Xiaomi está siendo de las últimas compañías chinas en colocar esta banda en sus teléfonos. Es que no la llevaba ni uno, y para uno que salió, llevaba el MTK Helio, que no sé qué tal irá, pero el GPS de los MTK hasta la fecha ha sido terrible. Así que seguí esperando. Hasta que encontré, de casualidad, una tienda en Aliexpress que es distribuidor oficial de Xiaomi y tiene versiones preparadas para España. Esos teléfonos sí anunciaban 4G de 800Mhz, y como el resto de características cumplían, no dudé en comprarme el Xiaomi Redmi Pro Prime 3gb+32Gb.

Cuando lo tuve y empecé a probarlo, primera sorpresa: Tengo 4G … ¡en Bocairent!. Llega mal y sólo a ciertos sitios, pero la verdad es bastante mejor que el 3G que tenía. Incluso dentro de un local, con 4G llegando mal, va mejor que el 3G. Así que, sí, no sé cuanto ancho de banda tengo en estos casos, pero deben ser más de 3Mbps. Ahora veo el símbolo “G” del teléfono y sé que es 4G, pero del malo, que es algo más lento que el “H+”, pero similar. Eso sí, donde sólo llega “G”, obviamente no llega nada de 3G.

Así que, la mejora es mucha. En casa de mi novia me llegan 15mbps de bajada y unos 3mbps de subida (antes no recibía ni cobertura para llamar). En carretera, empiezo a tener 4G mucho antes de llegar a la ciudad. No he tenido demasiadas oportunidades de probarlo por carretera pero tiene buena pinta.

Otro tema que es interesante es Voz sobre LTE. Esto también es un punto importante para un teléfono de hoy. El mío lo lleva. Si no lo tienes, el teléfono cuando recibe una llamada tiene que pasar a modo “3G” para poder responder a la llamada. Además de que baje el ancho de banda, con el 3G la cobertura de voz también es inferior al 4G de 800Mhz.

No sé si lo implementaron ya, pero existe una funcionalidad prevista para juntar varias antenas de 4G en una única comunicación, para aumentar el ancho de banda. De cualquier modo, no creo que tarden muchos años en hacerlo. (Creo que lo llaman 4G+) Lo interesante de esto es que, cuando tienes mala cobertura, si tu móvil es capaz de contactar a duras penas con 4 torres de comunicación, podrá hacerlo con las 4 a la vez. Y 4 comunicaciones malas pueden hacer una medio buena. El otro punto es que si a esto le sumas la voz sobre LTE, tienes que puedes hacer llamadas en carretera de horas, mientras te mueves. Esto ahora no es posible que yo sepa, porque al menos con 3G el teléfono durante una llamada no puede cambiar de antena, por lo que cuando sales del radio de acción de la antena, se corta.

La conclusión es que si pensáis comprar un móvil chino o incluso uno nacional, revisad por triple que lleve 4G de 800Mhz. Va a marcar la diferencia. Y si ahora lo tenéis, y compráis otro móvil que no lo tenga, vais a notar una pérdida notable en cobertura.

Por otra parte, ya ha empezado la previsión a largo plazo del 5G. Ni idea de lo que traerá, pero parece que quieren asignarle la banda de 700Mhz. Y a ver si lo adivináis que va a pasar…. ¿no? …. que vamos a tener que resintonizar la televisión ¡otra vez!. Pero no sólo eso, es que no cambiará ni un canal ni dos, están diciendo que van a mover TODOS los canales. En fin. El caso es que la televisión cada vez va a necesitar más ancho de banda y supongo que en algún punto querrán aumentar la frecuencia de la señal, y dejar así las frecuencias bajas libres para los dispositivos móviles de los que dependemos cada día más. Al ser frecuencia aún más baja, debería tener aún más cobertura. Ya veremos, porque aún queda hasta el 2022 para que el 5G sea algo tangible. [1]

NoSQL, ¿explotó la burbuja?

Han pasado cuatro años y pico desde la última vez que hablé de las NoSQL, prometiendo segunda parte [1] y prácticamente no ha cambiado nada. Quizá ese sea el problema, empezaron muy fuerte, prometieron mucho, y luego se estancaron.

Supongo que, como Facebook usaba Cassandra y lo publicaron, tuvo mucho “hype” y ganó muchísima visibilidad. Tanto CassandraDB en sí misma como el NoSQL en general. Con todo el tiempo que ha pasado, y el sector de gente que usa y promueve NoSQL sigue siendo el mismo de hace cuatro años. Algo falla.

En su momento estuve comparando PostgreSQL (mi base de datos preferida) contra diversas NoSQL: Cassandra, CouchDB, MongoDB. Se solía decir que las SQL estaban pensadas para leer múltiples veces el mismo dato y las NoSQL para escribir muchos datos. Por lo tanto cabía pensar que para ver dónde se podrían lucir lo suyo era comprobando cuánto podrían escribir.

Mis tests de aquel momento mostraron que Cassandra y CouchDB eran muy muy lentos escribiendo. Creo que conseguía unos 200-1000 registros por segundo. Hace tiempo y ya no tengo las comparativas a mano. MongoDB estaba en el orden de los 10.000 registros por segundo. A algunos os parecerá mucho, pero no lo es tanto cuando sabes que PostgreSQL se acerca al millón de registros por segundo en igualdad de condiciones (COPY, fsync=off, sin índices, etc). ¿Entonces?

Estuve preguntando en aquellos tiempos a los chicos del IRC de CassandraDB. Me dijeron que “claro, con sólo una máquina no tiene sentido”. Por norma general, al poner otra unidad de cómputo en un cluster, la potencia sube un 80% (es decir, un 20% de penalización). Para igualar a PostgreSQL, que necesitaba, ¿2000 equipos? ¿en serio?.

Después de varios intentos con distintas NoSQL abandoné el intento de escribir más rápido que PostgreSQL. En muchos casos PostgreSQL era más rápido incluso con índices, fsync=on y usando inserts. En fin.

Me puse a comparar el rendimiento de lectura. En determinados casos es mejor, y tenemos tecnologías de Map & Reduce que facilitan la integración de datos entre diferentes nodos. Lo que me encontré es que, el diseño de las tablas en NoSQL necesita ser mucho mucho más cuidadoso que en SQL, y hay que tener en cuenta de qué modo se va a leer una tabla habitualmente. Es un problema gordo ya que, a no ser que quieras escribir un log (y para eso escribes un fichero de texto), la mayoría de tablas necesitan leerse en 3-4 ordenes distintos. También había mucha duplicación de dato, y yo que me quejo de SQL, pero en NoSQL hay mucho, mucho más.

En muchos casos, si soportan índices, soportan uno. (O así era cuando lo probé). Terminé bastante frustrado porque lo que parecía una buena idea, al final se quedó en algo de utilidad muy específica.

¿Dónde es útil NoSQL?

Básicamente en dos aspectos: el caché de datos en memoria y el Big Data.

Para almacenar datos, consultas o cualquier dato transitorio en memoria existen MemCache, Redis y otros. Se pueden considerar NoSQL aunque concretamente son de clave valor. Al estar pensadas para memoria sí que son extremadamente rápidas. Normalmente en éstas no se usa clustering.

El Big Data, primero nos hemos de preguntar “qué es Big Data” o cuando lo necesitamos de verdad. Es bastante subjetivo, pero para mí estaríamos hablando de conjuntos de datos que requieren varios equipos para su almacenamiento. Esto no son 8Tb . En realidad primero en un equipo deberías hacer uso de RAID o JBOD (o los dos) para unir varios discos antes de pensar en el BigData. Eso normalmente nos hacer un equipo de 8Tb * 6 discos en RAID6, con unos 256Gb de RAM. Eso son 4*8Tb=32Tb. Cuando nos acercamos a este valor, estaríamos pensando ya en BigData.

En estos casos, el NoSQL puede ser la única solución. La consulta típica suele ser un Map&Reduce, algo así como un SUM() colaborativo entre varios nodos donde cada uno suma su parte y la van compartiendo. Por supuesto es bastante más complejo, pero es la base de este tipo de peticiones.

Ventajas del NoSQL

  • Clustering y sharding automático: Las NoSQL por lo general tienen mucha facilidad para hacer réplicas horizontales y verticales. No obstante en las normales también se puede, aunque siempre hay que hacerse las cosas a mano. El sharding en SQL por el contrario es muy manual y artesanal. En algunos casos es contraproducente, pero tanto en SQL como en NoSQL.
  • Sin Bloqueos: Está preparado para que todos los usuarios escriban a la vez. El problema es que la consistencia puede ser pobre y tener alguna sorpresa.
  • Sin esquemas de datos: Al usar generalmente JSON, los registros pueden tener casi cualquier dato, y para agregar nuevos datos no necesitamos bloquear y rehacer la tabla.

SQL se pone a la altura

Muchas de las cosas que venían diciendo las NoSQL las han ido trayendo las SQL. Por ejemplo PostgreSQL agregó un tipo de dato JSON, por lo que en él es muy fácil hacer tablas como las de las NoSQL y trabajar del mismo modo. Además permite modos “mixtos” que no son posibles en una NoSQL. En la replicación también se han puesto mucho las pilas en los últimos años. La replicación “lógica” de postgresql, o las de MySQL, son muy útiles para hacer réplicas distantes que no son consistentes. Permitiendo que un gran volumen de usuarios escriba en cada nodo sin que los bloqueos de un sitio afecten al otro. El problema que nos resta es el “Write Amplification”, que también lo sufren en menor medida las NoSQL. Se soluciona con el Sharding, que he visto que mucha gente ha resuelto en MySQL. De cualquier modo el sharding es muy complejo de realizar correctamente, independientemente de qué base de datos sea.

Conclusión

No recomendaría pasar a NoSQL absolutamente nada que no sea estrictamente necesario. Como sistema de caché en memoria, funciona bien. Como base de datos, las SQL ofrecen muchas más ventajas que su contraparte. Además están mucho más probadas y por lo tanto los datos están más seguros en una SQL tradicional. Usando un disco duro de estado sólido se puede conseguir minimizar los tiempos de lectura, y configurando correctamente PostgreSQL se pueden reducir los de escritura.

Y el clustering, hay que recordar que su uso primario es la redundancia de datos, no la mejora de velocidad. El clustering como mejora de velocidad es un tema complicado que se tiene que revisar por gente experta. Como apunte, está el caso de Uber, que migró de PostgreSQL a MySQL, pero curiosamente no se plantearon el cambio a ninguna NoSQL a pesar de contar con un servidor con más de 700Gb de RAM y su base de datos parece caber allí dentro.

Ojalá hubiese sido el fin de la WiFi

Hace ya muchos años empecé la mudanza de mi ordenador a mi propio cuarto. Antes de eso compartía el ordenador la habitación de mi hermano que siempre fue la sala de estar de la casa. Pero como mi hermano siempre fue un poco dormilón, supongo que me harté de entrar a hurtadillas en su cuarto y encender mi ordenador para hacer cosas.

En aquella habitación tiene internet con ONO desde principios de 2005. Internet llegó a mi casa un poco tarde. Así que por 2006 me puse a cambiar el ordenador a mi cuarto, pero esa habitación está en el otro extremo de la casa, y no es una casa pequeña. Cablear no era una opción, así que pensé: lo pongo por WiFi.

Parecía sencillo, pero no lo fue. Y de aquello salió este post de 2006 que lo atestigua:

WIFI, LINUX, WIFI, PORTÁTILES Y MÁS WIFI

Y es que si el WiFi de por sí es problemático, el soporte de drivers de Wireless en Linux lo es más. Hoy en día parte de estos problemas se han esfumado, por suerte. Pero otra parte permanecen y es bastante probable encontrar problemas con los drivers de la tarjeta.

Después de pelear bastante más al final creí haberlo arreglado y escribí este post al respecto:

EL FIN DEL ENIGMA DE LA WIFI

Pero ja, qué más hubiese querido. Hubiese sido mejor un cable por el suelo o yo que sé. El caso es que no fue el fin del enigma. Continuó fallando, aunque menos. La cobertura era pobre.

Al final sí decidí comprar ese punto de acceso, un conceptronic. Pronto comprobé al cabo de las semanas que la compra del punto de acceso fue la mejor decisión que tomé jamás.

Al eliminar el problema de la WiFi de mi equipo, eliminé el problema de los drivers. Pero hubo otra mejora inesperada.

Como persona que trastea con Linux, habitualmente termino sin GUI. Bien sea por reinstalación de los drivers de NVIDIA, porque estoy instalando otra distro o yo que sé. Y cuando eso pasa, te das cuenta que no tienes internet: dependes de la GUI (El entorno gráfico y el escritorio) para que se configure la WiFi. Tuve que aprender en aquel momento sobre iwconfig y otros comandos para configurarla en consola, pero es que una WiFi no se configura de forma sencilla. Tiene más parámetros de los que quiero recordar, mucho comando y mucho tiempo de espera intentendo realizar la conexión al router.

Con el punto de acceso todo ese “hell-of-wifi” desapareció. De golpe es una conexión por cable, que perderá más o menos paquetes, quien sabe. Pero funciona y tiene una configuración simple. Así que a partir de ese momento cuando empezaba a cacharrear estaba mucho más tranquilo, porque si necesitaba internet a mitad del proceso, lo tenía sin problemas y al momento.

Aún con router y antena direccional, por mucho que apuntaba seguía perdiendo señal. Tardé meses y hablé de soluciones con mi padre. El problema es que la señal tiene que atravesar la pared del cuarto de mi hermano, hacer todo el pasillo hasta el fondo, girar a la derecha, atravesar la puerta de mi cuarto y acertar en la antena WiFi. Aquello, pensándolo bien, era todo un malabarismo. Por mucha antena que tuviera la cantidad de rebotes mínimos necesarios hacían la conexión muy enclenque.

Estuvimos viendo formas y decidimos sacar un cable de la habitación hasta el pasillo. Fue bastante sencillo, el cable llegaba hasta el principio del pasillo ubicando allí el punto de acceso en un lugar estratégico. Tenía visión directa hasta la pared donde detrás está ubicado el router (o casi, estaba un poco más atrás y a la derecha). Ahora sí, pensé. Y la calidad de la señal estuvo entre el 60-70% que eran unos números nunca vistos, comparado con el 30% que tenía inicialmente era una gran mejora.

Pero la WiFi continuó quedándose frita cada cierto tiempo. Las conexiones de ONO mejoraron y llegó un momento que era más rápido ir al cuarto de mi hermano y enviar algo vía email, que copiar vía FTP por la WiFi de una habitación a otra. Increíble: Internet más rápido que mi WiFi, pero no un poco, sino 3 veces más rápido.

Otro problema al que se le añadió es que la antena estaba demasiado a la vista y cada dos por tres me la encontraba torcida.

Así pasé bastante tiempo. No sé si un par de años, hasta que consulté y un amigo en APP me comentó, después de encoger los hombros y admitir que aquello que yo contaba no tenía explicación alguna, que a lo mejor usando un punto de acceso más potente se arreglaba. Y se lo compré. Con una potencia de emisión de unos 100mW y una antena omnidireccional de unos +6dB, lo monté exactamente detrás de la pared donde apuntaba mi antena direccional.

Y entonces por fin, se solucionó el problema de la WiFi.

Como nota curiosa, ese mismo “trasto” de 100mW tiene tanta potencia que mi teléfono se conecta a mi casa desde la otra punta de la calle, desde dentro del bar. Supongo que con semejante WiFi es normal que funcionase.

¡Ah! pero no terminó aquí! Qué va… luego llegaron los smartphones, y claro, en mi cuarto no hay WiFi. Que el trasto llega hasta el bar que hay al fondo, pero atravesar la casa ni de coña. (A saber de qué están hechas las paredes)

Tuve que usar el cable que tenía dentro, reutilizar un router linksys y emitir una segunda WiFi dentro. Y entonces ya sí que fue el fin de los problemas con la WiFi de marras.

Un día, conversando con mi padre me dice:

Eso? pues si por el techo se puede pasar un cable de punta a punta. ¿La distancia? eso no es problema hombre. Que se hace un agujero aquí, otro allá y en un momento está y el cable llega hasta la otra punta.

Y un poco más y me caigo de culo. Años, varios años peleando para que llegue la WiFi y resulta que cablear de punta a punta era una opción. Supongo que subestimé lo que mi padre podría hacer, no pregunté lo que debía haber preguntado, y además subestimé y mucho los problemas que daría la WiFi.

 


Diez años más tarde, la antena direccional y el punto de acceso me dan servicio en Bocairent, para transformar a cable la conexión al router, que en este caso está pocos metros detrás de la pared en la habitación conjunta.

La lección está aprendida: usa cosas fiables, que funcionen y que no te dejen tirado. La ridícula inversión que hice 10 años atrás sigue rindiendo para tener hoy un internet fluido y no tener que hacer magia con el iwconfig. Y pregunta, coño, pregunta.

Ahorrar batería con móviles Android

Recientemente alguien preguntaba en Quora.com: “¿Harán pronto baterías suficientemente grandes para que los smart-phones duren una semana?” y la respuesta generalizada es, no, no en el futuro cercano. Lo que esta persona no estaba considerando es, ¿puede un móvil moderno consumir menos y estirar más la batería? La respuesta es sí, el problema es que no estamos dispuestos a dejar de usar el móvil de cierta forma.

Las baterías por desgracia están casi al límite de lo que se puede fabricar, y de haber mejoras, posiblemente sea algo radical ya que estamos agotando lo que se puede hacer con Litio. Algunos planteaban Litio-Grafeno, y algún estudio se publicó, pero del laboratorio parece que no ha salido.

Así que, lo primero que debemos hacer es gastar menos, ahorrar la batería todo lo posible para depender menos del cargador. La mayoría de aplicaciones del Play Store que aseguran poder ahorrar batería no hacen nada, el efecto es más placebo que otra cosa. Así que tampoco son una opción.

Lo más fácil es que desinstales lo que no uses y que cierres la conexión de datos (3G/4G) cuando no la necesites. Quita (desconfigura) todas las notificaciones de todas las aplicaciones que tengas, una por una, hasta dejar sólo aquellas notificaciones que consideres de vida o muerte. No es que se ahorre mucho, pero es la solución más sencilla de las que presento.

Para ahorrar batería, primero hay que saber qué consume la batería. Primero hay que distinguir entre primer plano (horas de pantalla) y segundo plano (horas en idle). Las horas de pantalla son complicadas de mejorar, aparte de bajando el brillo y evitando aplicaciones con mucha demanda de CPU (3D, Juegos, etc). Mientras los teléfonos no incorporen pantallas y GPU’s más eficientes poco margen de mejora va a tener esto.

Aquí viene el primer sacrificio: menos consumo significa menos horas de pantalla activa. Si un teléfono tiene batería para 8 horas de pantalla, es normal que si hacemos 4 al día tengamos que cargar el teléfono todos los días.

Eso nos lleva a otra pregunta, ¿cuántas horas de batería puede hacer un teléfono en idle?. La mayoría de teléfonos debería poder al menos con 50 horas en idle. Eso son 2 días de batería sin tocar el teléfono. Con un uso normal fácilmente es un día y pico. Pero son sólo 50 horas porque el teléfono está gastando a un ritmo de un 2%/hora. Puede parecer poco consumo, pero en realidad es bastante. Mis terminales realizan entre 0.2%/h y 0.5%/h (anotado durante la noche). Eso significa que tengo entre 200 y 500 horas de batería en idle, que serían entre 8 y 20 días de batería. Al leer esto seguro que piensas “¡imposible!, además aunque lo fuese, no puedes recibir ni llamadas y entonces ¿de qué te sirve un teléfono?”… pues lo cierto es que esas mediciones se realizan con WiFi, 3G y GPS habilitados. Sí, puedo recibir llamadas y whatsapps durante ese período y el teléfono responde sin problema. Y no, el teléfono no me dura 8 días de batería, porque el uso que hago es bastante intensivo. Me dura 2-3 días con mi uso, aunque hay quien lo ha estirado 5 días.

¿Dónde está el truco? El GPS, el 3G y la WiFi se encienden y se apagan automáticamente según la necesidad. De todos el que más batería consume a la práctica es el 3G, por lo que tener el teléfono con WiFi durante la mayor parte del día ayuda bastante. La WiFi en cambio tiene modos de “dormir” que permiten al teléfono usar muy poca energía y seguir al tanto de los eventos que lleguen. No es necesario apagar manualmente el 3G, basta con que el teléfono tenga una WiFi que le funcione.

Lógicamente la historia no termina aquí. Si fuese tan sencillo a la gente le duraría una batería bastante más de 24 horas. El propio teléfono (la CPU) también se enciende y se apaga según la necesidad. Y esto es la clave. Android es un sistema operativo pensado para que la mayor parte del tiempo esté apagado. Digamos que despierta por un evento, realiza el trabajo pendiente y se vuelve a hibernar. Eso es lo que debería pasar, y lo que ocurre es que se despierta y nunca termina. Las aplicaciones y el propio sistema provocan que por una cosa u otra al final siempre haya algo que hacer cada poco tiempo. Nuestro objetivo es que, al apagar la pantalla, no haya nada que hacer.

En las estadísticas de Android veréis alguna barra que dice “Awake”, o en castellano “Activo”. Esta barra indica las veces que el teléfono estaba realizando algo. Abajo está la de pantalla activa, y como veréis en el ejemplo, coincide aproximadamente con la de “Awake”. Esto es bueno, quiere decir que si no usamos el teléfono, éste duerme.

Pero en la mayoría de los terminales veréis que “Activo” está casi siempre en azul, y casi nunca duerme el teléfono. Por eso se os agota la batería. El teléfono sigue consumiendo aún con la pantalla parada. Ésto lo producen aplicaciones como Facebook, Whatsapp, etc. Al quitar las notificaciones del Facebook por ejemplo, éste también desactiva el servicio de segundo plano que las monitoriza, liberando al teléfono del trabajo de tener que estar revisando cada poco si hay algo.

Hay aplicaciones que sirven para “hibernar” otras aplicaciones mientras el teléfono está parado o no las usas. Es perfecto para poder tener instaladas 150 aplicaciones y algunas de ellas mal hechas, sin que te condene a ir buscando cargador todo el rato. La que yo usaba era Greenify, que la recomiendo mucho.
El paquete de donativo creo que son 0,70€ y además de valer la pena, contribuyes al trabajo de una persona que se lo ha currado mucho para mejorar la duración de nuestras baterías. Eso sí, si el teléfono no esta rooteado no es práctica y el paquete de donación entonces no sirve para nada. Hay que ir con cuidado con greenificar whatsapp, telegram y otros del estilo, ya que mientras están hibernados las notificaciones no llegan. Hay arreglos para esto, pero casi que no vale la pena.

Para reconocer las aplicaciones problemáticas está el BetterBateryStatus y el WakeLockDetector (WLD). Yo uso normalmente el segundo. Creo que si no está el teléfono rooteado no pueden funcionar, aunque creo que WLD tiene algún modo si se usa la depuración USB. Además el WLD se integra bien con el Greenify.

Desde que uso MIUI 8 no he necesitado rooteo, ya que estas funcionalidades y otras las tengo integradas de base, y bastante bien configuradas al principio. No sé si conocéis la ROM, pero la recomiendo mucho. Está muy cuidada y trae un montón de cosas de serie que son muy útiles.

Aún con todo esto, desde hace un tiempo estoy viendo un problema recurrente. Desde cierta actualización del Google Play (creo que del 2015), Google Play y Google Play Services conspiran para consumir la batería. Lanzan unos eventos de posicionamiento que se conocen como CoarseLocation y cuesta muchísimo de localizar, ya que a menudo el WLD y otros programas del estilo no son capaces de cazar a Google Play.

En mi caso, lo que hago es configurar el GPS como “Solo dispositivo” y eliminar el histórico de posiciones de Google. Además, la MIUI 8 me deja bloquear el acceso al GPS al google play cuando la pantalla está parada. Con esto, me deja la batería finalmente en paz.

Para terminar esta entrada, comentar que cuando se sale fuera de casa como no tenemos WiFi y empieza con el 3G la batería lo nota. Aplicaciones como Juice Defender pueden activar el 3G intermientemente para que consuma menos, pero no dejemos de recibir emails y mensajes; aunque lleguen un poco más tarde. Si vamos a viajar en coche, es útil el modo avión, ya que el cambio constante de antenas hace trabajar al móvil. Pasando al modo avión evitamos esto. De todos modos, las llamadas en carretera con el coche en marcha no es que funcionen muy bien hoy en día.

Probando Steam en Linux / Jugando a Portal 1 & 2

Hace unas semanas instalé el Steam en el ordenador de sobremesa, que lleva Debian. Por pasar el rato un poco, ya que sé que desde hace años Valve está dando bastante soporte a Linux, me animé a probarlo a ver qué tal. Si bien la instalación no la conseguí a la primera, al final la guía de Debian para Steam [1] me funcionó muy bien.

Estuve mirando y probando varios juegos. Hay que tener en cuenta que no soy un jugón; la verdad en los últimos ¿10 años? he jugado muy poco. Mayormente en el móvil para pasar el rato. Así que todos estos juegos actuales me pillan un poco descolocado. Cuando yo jugaba los juegos eran diferentes y parece que no, pero las cosas han cambiado un poco. La calidad gráfica es innegable, la jugabilidad está bien, pero estoy encontrando que son demasiado lineales. O demasiado para lo que estoy acostumbrado, yo que sé.

Hay bastantes juegos disponibles para Linux, más de los que mucha gente quiere pensar. Entre un 30 y un 50% funcionan en la plataforma. Supongo que tiene que ver con que Steam tiene una plataforma para Linux (Una especie de consola) y claro, si quieres venderlo tendrán que funcionar los juegos, ¿verdad?

Me recomendaron que me comprara el set de los dos juegos de Portal (1&2). No había jugado a ninguno de ellos más de 15 minutos hará años en casa de algún amigo. Tengo que decir que es un juego que siempre me ha fascinado mucho. El tener que resolver los puzzles con portales, con física bastante particular, es muy muy interesante. Al final no me lo pensé y pillé los dos por algo menos de 5 euros. Al principio me costó, ya no entenderle la lógica, sino más bien el gustillo. La introducción fue un poquito lenta para mí, pero pronto empecé a estar más cómodo. En pocos días he terminado ambos juegos. El primero me duró unas 5 horas y el segundo unas 8 horas de juego. No es mucho, la verdad. Estoy acostumbrado a juegos mucho menos trabajados que tienen bastante más libertad y estos dos Portal parecen una película interactiva. Por eso, no ví más que resolución de puzzles y fui pasando uno tras otro, a toda prisa. Como queriendo saber “qué pasará después”, porque la historia aunque sencilla, te entretiene bastante y es original.

Me gustaron mucho ambos, y si alguien quiere jugarlos recomiendo que juegue los dos, en orden. El precio es de risa y el Portal 1, por mucho que digan, no está a tanta distancia del segundo. Quiero decir que es casi igual de buen juego que el 2, y vale la pena por ver la historia en orden. Y que son más horas de juego para pasarlo bien. En ningún caso del Portal 2 me pareció revivir el Portal 1. De hecho la introducción del portal 2 es bastante más rápida que la del 1, lo que puede hacer que los jugadores nuevos de Portal, si empiezan por el 2, no terminen de entender los puzzles iniciales. Aunque tiene introducción, es tal vez demasiado rápida para un jugador nuevo. Por otra parte, toda la historia del Portal 2 gira alrededor de lo que pasa después del Portal 1, por lo que es mejor haber jugado al 1 para entender la historia al 100%.

 

 

 

Entropy Classifier Network (Part II)

(Continued from “Entropy Classifier Network (Part I)”)

I read a lot about energy based models (EBM), Hopfield networks, Markov Chains and AutoEncoders. Somewhat all of these are related to what I want to do, but none of them exactly fits my purpose.

Inspired by those, I wanted a topology similar to the Hopfield Network, were all nodes are conected to every other node on the network, and every node is input and output at the same time. Like AutoEncoders, I want the network to encode the input and decode it again to the same nodes.

I thought it would be difficult for me to create a network like that from scratch. Mostly because I still don’t understand these kind of networks, I hardly got to understand MLP networks and I’m struggling now with Energy Based Models, which I don’t understand despite the amount of hours studying the field.

It turns this idea is fairly simple, and the network was working and learning after only 1 hour of coding in Theano. Maybe I’m starting to truly understand the basic maths under all of this.

First of all I had to set up a weight matrix for every connection. As this is NxN, I can encode the connection between Input j to Input k inside W_{ik}. The bias is just a matrix of 1xN, so this is exactly like linear regression networks. The cost function can be the squared error, as pointed above.

The output function for neurons is a bit different. As this network isn’t a classifier, its output is not a probability, and thus it doesn’t need to sum to one as it does with linear regression networks. So, we discard the softmax function and we get:

output = dot(input, W) + b

It looks even simpler than the linear regression.

The problem with this setup is that our network learns to output using the same input, and this is not useful for our purpose. This happens because in a NxN matrix, the input 1 is connected to the output 1 in the cell 1,1. So, the diagonal in the W matrix must be forbidden in the learning process.

My solution to this is create a new matrix called L (for Learning Rate matrix) which I use as a filter for learning. First of all I initialize the L matrix with every value as ones excepting the diagonal as zeros:

L = \left| \begin{array}{ccc}  0 & 1 & 1 \\  1 & 0 & 1 \\  1 & 1 & 0 \end{array} \right|

This matrix must have the same size as the W matrix: NxN, where N is the amount of input columns.

With this setup, just append L to the W update function:

W' = W - lrate * g_W * L

And voilà, the network starts learning inputs from every other input excepting from itself.

This is how far I got in 1 hour of coding. But with more time it got better. I’ll explain in a new article. Stay tuned!

Revisitando Viejos Posts

Hace poco que reabrí esto, a ver si le daba algo más de uso. En el camino me encontré el viejo blog de Blogger de 2006, y al pasar los mensajes aquí y releer un poco, veo que han cambiado muchas cosas.

No hay muchos mensajes, pero en cada uno hay una historia pendiente de contar de qué pasó después. O qué opino ahora después de años de los mismos temas.

Por ello he pensado ir publicando una serie de posts, a uno por semana, para contar qué hay de nuevo sobre cada asunto del que hablé años atrás. Así que, cada Jueves, dejaré aquí una nueva entradilla sobre estos temas.

Algunos de los artículos no les pretendo hacer 2ª parte, probablemente porque poco más se puede añadir.

Ya veremos cómo va. Por el momento el roadmap es el siguiente: