¿Cómo desactivar la WIFI y/o el Bluetooth internos de una Raspberry PI 3?

Cambiar mi red WIFI al canal 13, como se describe en Usar los canales WIFI 12 y 13 en una Raspberry PI, ayudó un poco, pero la calidad seguía siendo insuficiente. En la práctica no se podía confiar en el funcionamiento WIFI de la Raspberry PI 3, lo que resulta la mar de frustrante.

Antes de la Raspberry PI 3 usaba modelos anteriores con un USB WIFI externo. Funcionaba a la perfección. ¿Y si pruebo ese dispositivo en la Raspberry PI 3?.

Esa Raspberry PI 3 usa OSMC como media center. Esta distribución solo permite una tarjeta WIFI así que tenemos que desactivar la capacidad WIFI interna para que utilice el WIFI USB.

Leer más…

Usar los canales WIFI 12 y 13 en una Raspberry PI

Compré una Raspberry PI 3 cuando salió y llevo usando su WIFI integrada desde entonces. La velocidad y estabilidad de esa conexión, no obstante, se ha reducido a medida que más y más vecinos han ido instalando conexiones de alta velocidad en casa. A ciertas horas del día la WIFI de la pobre Raspberry PI 3, sencillamente, dejaba de funcionar.

Estudiando la distribución de uso del ancho de banda WIFI me resultaba claro que todos los canales estaban ocupados. Existía, sin embargo, un pequeño hueco al final de la banda, correspondiente a los canales 12 y 13. Esa zona recibe solapamientos de los canales adyacentes, pero no había nadie emitiendo centrado en esa zona. ¿Una oportunidad?.

Leer más…

Borrado seguro de datos en discos duros y SSDs (con FreeBSD)

Hace unas semanas tuve que devolver un servidor hospedado en un centro de datos remoto y me surgió la necesidad de borrar cuidadosamente sus dispositivos de almacenamiento. Normalmente usaría unas cuantas pasadas con el comando dd if=/dev/zero of=.... No obstante, este caso tiene algunos factores interesantes: la máquina tiene tanto discos duros como dispositivos SSD lo que me permite poder comparar ambos tipos de dispositivos, es lo bastante moderna como para soportar versiones recientes del estándar ATA y la máquina tiene instalado OpenSolaris. El último punto es importante, porque el entorno de recuperación que me ofrece el centro de datos no incluye Linux; tan solo una versión prehistórica (2009) de OpenSolaris y una versión aún calentita de FreeBSD.

Mi borrado habitual con varias pasadas de dd if=/dev/zero of=... es muy seguro, pero a) no borra absolutamente todo el disco duro. Por ejemplo, no se borran los sectores remapeados o sectores considerados como dañados o sectores de reserva. Y b) el tiempo de borrado es proporcional al tamaño del disco duro y, en cualquier caso, es bastante lento y monopoliza el ordenador durante el proceso.

Los discos ATA modernos implementan una extensión para el borrado seguro de datos. Su uso es mucho más rápido que el borrado "a mano" y teóricamente más exhaustivo. La entrega de este servidor fue la ocasión perfecta para probar la extensión.

Leer más…

Añadir un fichero a un repositorio Mercurial respetando su fecha de modificación

Mercurial es un excelente sistema de control de versiones comparable a Git, pero, en mi opinión, mejor por una gran variedad de razones. En febrero de 2013 di una charla en Python Madrid sobre este tema. Fue muy polémica. Ese es un tema para otro día :-).

Cuando se introduce una nueva versión de un fichero en el sistema de control de versiones, la fecha que se almacena es la fecha del commit. Esto no es problema porque, en general, hacemos el commit segundos o minutos después de hacer las modificaciones en el fichero.

El problema surge cuando queremos añadir un fichero antiguo a un sistema de control de versiones respetando la fecha de última modificación del fichero, no la hora del commit. Esto puede ser importante para respetar la historia del proyecto, preservar la integridad legal del mismo, etc.

Mercurial es versátil. A la hora de hacer un commit podemos especificar la fecha y hora que queremos reflejar mediante el parámetro -d o --date. Por ejemplo:

$ hg commit -d "$(date -u -r FICHERO +'%s') 0" -m "TEXTO"

El comando anterior hará un commit reflejando la fecha y hora del fichero especificado.

Migración de una base de datos LMDB a otra plataforma

LMDB es una base de datos ACID ligera y de alto rendimiento, especialmente recomendable para entornos con pocas escrituras y poca concurrencia de escritura. Dado el cambio de licencia de la extraordinaria Berkeley DB a partir de su versión 6.0, estoy usando LMDB cuando no necesito utilizar las sobresalientes características de Berkeley DB. Cuando necesito tirar de las funcionalidades de Berkeley DB, pero el proyecto no puede utilizar la licencia AGPL3, utilizo la última versión con una licencia utilizable en la práctica, la 5.3.

Una buena parte del rendimiento de LMDB proviene de mapear la base de datos directamente en memoria. Una consecuencia de eso y del uso de punteros y estructuras nativas es que la base de datos no es portable. Cambios de arquitectura entre 32 y 64 bits o de endianness hacen que la base de datos resulte ilegible.

Leer más…

Sincronización de sonido cuando la tasa de refresco de vídeo es irregular

Los motivos por los que el audio y el vídeo se pueden desincronizar son múltiples y variados. Hay que estudiar cada caso en particular y aplicar las medidas correctivas apropiadas. Un caso muy simple, descrito en Determinar automáticamente el desfase de audio en un fichero MKV, se da cuando las diferentes pistas están bien, pero no empiezan en el mismo instante. Esto puede ocurrir con facilidad si, por ejemplo, estamos añadiendo la pista de sonido en castellano a una película que solo tenía audio en inglés. Como se describe en ese artículo, el proceso es trivial.

Tenemos un caso más complicado cuando estamos separando las diferentes pistas de un fichero multimedia, las procesamos por separado y luego volvemos a unirlas. Normalmente no tendremos problemas, pero cuando surjan -y surgirán- hay que saber cómo diagnosticarlos y solucionarlos.

En este artículo estudiaremos un ejemplo real.

Leer más…

Medir y registrar temperatura, humedad relativa y presión atmosférica con un ESP8266: el componente LUA

Tras instalar un intérprete de LUA en mi placa NodeMCU, como describo en Instalar un intérprete de Lua en el ESP8266, lo siguiente es encontrarle una utilidad.

Mi primer proyecto es un medidor de temperatura, humedad y presión atmosférica, registrando toda esa información en un servidor de mi propiedad. Existen plataformas IoT de uso gratuito, pero no me siento cómodo entregándoles información detallada sobre mis costumbres en casa; prefiero que mi trabajo y mis datos no contribuyan a enriquecer una empresa privada ajena y, claro, yo dispongo de servidores y conocimientos para hacerme cargo personalmente de esta tarea.

Para las pruebas empleo dos sensores diferentes. La idea futura es instalar uno dentro de casa (de hecho, en cada habitación) y otro en la calle. Conectar los dos sensores al mismo equipo para su evaluación me permite comparar su rendimiento y relación calidad/precio. Los sensores son:

  • DHT22. Sensor de temperatura y humedad barato y sensible. Conseguí mi unidad por 3.54 €.
  • BME280: Sensor de temperatura, humedad y presión atmosférica. Es más pequeño y, supuestamente, mucho más preciso que el DHT22. Compré el mío por 7.54 €.

Algunas fotos del invento:

Leer más…

Instalar un intérprete de Lua en el ESP8266

En ESP8266 y el "internet de las cosas" y Ejemplos de uso de los comandos AT del ESP8266 presento el interesante chip ESP8266, un pequeño pero capaz microprocesador que cuesta menos de 2€ y que incluye capacidad WIFI. El fabricante ha ido soltando información con cuentagotas, en chino (literalmente) y orientada hacia la programación en C, pero algunos valientes han implementado cosas como Forth (1 y 2).

Forth es un lenguaje muy interesante del que guardo buenos recuerdos, pero en este artículo veremos cómo instalar Lua en un ESP8266. En concreto la implementación de Lua de NodeMCU.

esp8266.jpg

Leer más…

Dios no hizo todos los cargadores USB iguales

En un mundo en el que casi todos los dispositivos pequeños se alimentan con un cargador USB y en el que hay cargadores con varios puertos USB que dicen ser capaces de entregar tres amperios, uno esperaría que los cargadores modernos sean más eficientes y más capaces. Nada más lejos de la realidad. La mayoría de los cargadores USB son malos, muy malos. Por muchos amperios que digan entregar.

Normalmente yo sigo usando el cargador que me vino con el iPhone 3G en 2008. En este artículo verás por qué.

Para las pruebas usaré un teléfono con la batería descargada capaz de cargar a un amperio o, equivalentemente, 5V*1A = 5W (5 watios).

Los teléfonos modernos tienen una potencia máxima de entrada (en este caso, 5 watios), pero reducen el amperaje si el voltaje cae por debajo de los 5 voltios. En un mundo ideal el teléfono se movería al punto donde el producto entre el voltaje y la intensidad es máximo, pero esa sofisticación es mucho pedir y, en la práctica, lo que hace un teléfono normal es reducir su amperaje de carga si ve que el cargador es incapaz de mantener el voltaje en niveles aceptables [1].

[1]

Aunque el factor limitante acostumbra a ser el cargador, lo cierto es que el cable USB puede ser un problema. Si el cable es muy largo o de baja calidad, puede introducir pérdidas apreciables. El efecto es fácil de medir simplemente cambiando el cable por uno más corto mientras usamos el mismo cargador.

Para evitar este efecto en las pruebas, usaré siempre el mismo cable USB.

Lo más importante que hay que tener presente es que el estándar USB marca que, aunque el voltaje oficial es 5V, se consideran aceptables voltajes desde 4.40V a 5.25V. Esto tiene importancia para lo que sigue.

Leer más…

Reemplazar un disco de arranque ZFS en Solaris 10

En agosto de 2015 me llamó por teléfono un antiguo cliente para pedirme que le ayudase a reemplazar uno de los discos de arranque ZFS de un viejo Solaris 10 que aún tiene en producción. La tarea no es trivial porque a) hay poca documentación al respecto, b) la versión de Solaris 10 que usa está muy anticuada y tiene problemas con el arranque ZFS muy conocidos y arreglados en versiones posteriores y c) en ese momento yo me encontraba a 600 Km de Madrid y tendría que actuar con "manos remotas".

A la hora de trabajar con Solaris hay que entender algunos conceptos diferentes a otros Sistemas Operativos:

  • Aunque lo que se lleva ahora es un sistema de particionado de disco EFI, si tu instalación Solaris es antigua, tendrás los discos formateados con Slices [1]. La diferencia entre las particiones tradicionales y los Slices Solaris es que en Solaris los Slices residen DENTRO de una partición. Es semejante a utilizar una partición primaria de la BIOS de un PC para crear dentro particiones lógicas. La idea es similar.

    En un disco Solaris tradicional es muy típico tener una única partición primaria en el disco que, interiormente, está subdividida en diez Slices de diferentes tamaños.

    [1]

    En el mundo Solaris, este tipo de formato se llama SMI. Más información, por ejemplo, en SMI and EFI disk label on Solaris.

    Nota

    Las versiones antiguas de Solaris 10 no permiten arrancar desde un disco con formato EFI. De hecho, tampoco se pueden usar discos EFI en un zpool ZFS "raíz". No sé si eso sigue siendo un problema en versiones modernas de Solaris y derivados.

  • El soporte ZFS en el gestor de arranque GRUB en Solaris 10 es mínimo y más si se trata de una versión no actualizada del sistema operativo. Esto hace que, por ejemplo, GRUB no pueda encontrar los discos de arranque si se cambian de posición física, aunque técnicamente a ZFS le de igual porque guarda sus UUID dentro del propio disco y le da lo mismo que se hayan movido.

    Por el mismo motivo (soporte mínimo en GRUB), no podemos usar ZFS en los discos de arranque a menos que el zpool [2] de arranque conste de un único VDEV [3] formado por un solo disco o por discos en espejo.

    Por lo mismo también, si estamos usando discos de arranque ZFS en espejo, hay que instalar GRUB en todos y cada uno de ellos.

    [2]

    En ZFS un zpool es la colección de discos que forman una unidad de almacenaje.

    [3]

    En ZFS, un vdev es cada una de las unidades de disco virtuales que forman un zpool. Cada vdev o disco virtual puede estar formado por un solo disco, por varios discos duros en espejo o por configuraciones de redundancia RAID-Z, RAID-Z2 o RAID-Z3.

  • Diferentes subsistemas Solaris 10 identifican los discos duros de forma diferente e inconsistente. Hay que tener mucho cuidado para no meter la pata y reemplazar el disco duro que no es. Este problema me ha mordido el culo varias veces aunque nunca de forma catastrófica. Mide todo tres veces para cortar una y comprueba varias veces lo que parece evidente.

    Por ejemplo, fíjate más abajo en que ZFS habla del disco c1d0s0, mientras que en format el disco que nos interesa es el c2d0.

    Es muy confuso. Ten mucho cuidado.

  • Se pueden ver otras restricciones en ZFS Root Pool Configuration Requirements. Por ejemplo:

    Disks that are designated for booting in a ZFS root pool must be less than 2 TBs in size on both SPARC based and x86 based systems.

En este caso los discos de arranque ZFS están en un zpool formado por dos discos en espejo.

Los pasos a seguir son los siguientes:

Leer más…