21 jun 17 Emulador software de teclado mecánico IBM Model M
Un compañero de trabajo me ha pasado un enlace a un proyecto Github que promete ser una verdadera herramienta del mal: un emulador por software del sonido de un teclado mecánico IBM Model M.
Su instalación es extremadamente sencilla: está incluido en los repositorios de Debian y Ubuntu, no da mucha guerra para instalarlo en otras distribuciones, además de estar disponible para Mac y Windows. Puedo atestiguar que el efecto es tremendamente realista:
Y sé que es algo completemante psicosomático, pero me da la impresión de que escribo más cómodo en mi portátil desde que lo he instalado. Eso sí, ni Ana ni mis compañeros de trabajo -aparte del enajenado fanático de los teclados mecánicos que me lo ha pasado- creo que aprecien este descubrimiento en demasía. 
Etiquetas: ibm, modelo m, teclado mecánico
15 jun 17 Mitigación de los problemas de sobrecalentamiento de la Orange Pi Zero
En fechas recientes he adquirido un par de Orange Pi Zeros para algunos proyectos personales. Para quien no las conozca, las Orange Pi Zero son una interesante copia china de las Raspberry Pi, con un precio casi imbatible de 15$ contando el modelo de 512 MB de RAM y cuatro cores, junto con un módulo de expansión de puertos y una carcasa bastante maja.
Placa Orange Pi Zero
El problema es que montan un procesador ARM que funciona a 1200 MHz, que tiene una irritante tendencia a sobrecalentarse más que una plancha de acero a pleno sol en Córdoba un 15 de agosto. En Irlanda, con una temperatura ambiente que rara vez sube de los 22 grados ya es problemático, así que cuanto más en Córdoba, donde tengo una de las Zero:
83ºC… ¡y sin hacer nada, por la mañana, y a la sombra en interior!
Así que para no acabar con una bonita fogata quad-core, toca tomar medidas. La solución más básica es empezar por procedimientos mecánicos. Un disipador, vaya. El problema es que la Zero es pequeña, muy pequeña. El procesador central tiene este tamano:
OPi Zero y su tamaño relativo
En efecto, el procesador es del tamaño de una moneda de 1 céntimo de Euro. Genial para construir sistemas pequeños, no tanto si tienes que encontrar un disipador de su tamaño. Puedes encontrarlos en Amazon o en Aliexpress, pero tardan un tiempo en llegar. En mi caso, al final, acabé canibalizando un viejo router, de donde pude sacar un disipador adecuado. Eso sí, de añadir un ventilador, más vale irse olvidando. Ya sólo el disipador me dio guerra para encajarlo en la caja:
OPi Zero con disipador
De todas maneras, es una solución bastante razonable. En mi Orange Pi de Irlanda conseguí bajar la temperatura de unos 72ºC a unos 62ºC. El problema vino con la de Córdoba. A las 11 de la noche alcanzaba una temperatura de unos 85ºC. Vale que había unos 32ºC de temperatura ambiente (¡sí, a las 11 de la noche!), pero aun así, con disipador y todo, seguía resultando demasiado. Así que tocaba tomar medidas adicionales. En este caso, medidas software. Por suerte, el procesador que monta (SunXi H2+, una versión capada del H3) dispone de una utilidad para controlar diversos aspectos del procesador, como velocidad de proceso, número de cores activos, posibilidad de desactivar la tarjeta gráfica o la WiFi. En mi caso, y siguiendo las recomendaciones del enlace anterior, he optado por desactivar un par de cores, dejando sólo 2 activos, así como la GPU y la WiFi. La mejora ha sido considerable. En el caso del equipo de Córdoba, he conseguido moderar la temperatura (en plena mañana en Córdoba) desde más de 85ºC a menos de 75ºC. No es que sea la panacea, pero es una mejora notable.
Etiquetas: armbian, orange pi zero
22 may 17 Hello World IPv6!
Hoy he publicado mi primer sitio en IPv6:
Mi primer sitio en IPv6
…y no sólo se trata del sitio, que ya mola de por sí, sino lo que estoy utilizando para ello: un servidor NGINX, una Asus TinkerBoard… y las IPs v6 que me da mi proveedor irlandés. Aunque los malditos me hacen CG-NAT en IPv4. :@
Etiquetas: asus tinker board, ipv6, nginx, servidor web
20 feb 17 Mejoras en el sistema de telemetría
Este fin de semana he estado con Ana y unos amigos en Waterford. Ha sido la oportunidad perfecta para probar el sistema de telemetría. Y la verdad es que se ha portado de fábula. Como muestra, un botón:
Como se puede apreciar, la recogida de datos funcionó a la perfección durante las dos hora de viaje desde Dublín a Waterford. Por ello, me he decidido a realizar algunas modificaciones en el sistema de telemetría:
- Recogida de parámetros adicionales: Hasta ahora recogía 3 valores de la centralita del coche: velocidad, revoluciones por minuto y flujo de aire entrante en el motor, este último, junto con la velocidad, para realizar el cálculo del consumo de combustible. Ahora voy a pasar a recoger 14 parámetros en total, que son los que proporciona la centralita del coche. En otros vehículos más modernos se pueden recoger muchos más parámetros, pero por el momento tengo información más que suficiente de múltiples valores: temperaturas, sensores de depósito, % de potencia utilizada, % de recorrido del acelerador… El detalle de los parámetros recogidos es el siguiente:
PIDs OBD II Mercedes W203
- Modificación en la frecuencia de recogida de valores: Dado que paso a recoger más parámetros, y anteriormente he tenido problemas de uso del canal de comunicación Bluetooth, voy a reducir la frecuencia de recogida de valores desde los 2 segundos a los 5. Si el sistema se sigue mostrando estable, consideraré volver a recoger valores cada 2 segundos.
- Cálculo de distancia recorrida: Uno de los valores que la centralita no proporciona es la distancia recorrida. Así que he introducido el cálculo de la misma, basado en los datos proporcionados por el sensor GPS.
- (En desarrollo) Incorporación de acelerómetros: De nuevo, un valor no proporcionado por la centralita. En este caso, se trata de medir la aceleración del vehículo en los ejes X, Y y Z. La centralita no los proporciona, y la Raspberry Pi tampoco. Así que he encargado un acelerómetro con giróscopos incorporados, que proporcionará información a través del los puertos GPIO de la RPi.
Etiquetas: gps, raspberry pi, telemetría
29 ene 17 Sistema de telemetría y geoposicionamiento para vehículos
Escribía en mi entrada anterior que estaba trabajando en un sistema de telemetría para el Mercedes. Durante estas últimas semanas he estado realizando algunas mejoras en el sistema, y si bien aún es posible incorporar algunas más, en este momento ya empieza a tener un desarrollo bastante definido. En pocas palabras, se trata de un sistema de telemetría que recoge datos de dos fuentes, la centralita del coche y un módulo GPS, para transmitirlo a un servidor donde se almacenan los datos para su posterior tratamiento. En este momento, el tratamiento consiste en dos actividades: representación gráfica de velocidad, revoluciones por minuto y consumo del coche, y geoposicionamiento en mapas en tiempo real. Este es un esquema básico de la plataforma:
Esquema del sistema de telemetría
El sistema está compuesto por los siguientes elementos:
- Sonda de captura de datos: La sonda de captura de datos consiste en una Raspberry Pi que se conecta con la centralita del coche mediante un módulo bluetooth. La centralita del coche se ha equipado, a su vez, con un módulo OBD-II con bluetooth. Esta sonda, de igual manera, dispone de un módulo GPS para proporcionar datos relativos a la posición del vehículo.
- Programa de telemetría: En la sonda de posicionamiento he desplegado un programa que recopila información de las fuentes anteriores, que he desarrollado en Python. Este programa, en líneas generales, comprueba el estado de las fuentes de datos antes mencionados, recopila la información y la prepara para su transmisión. Para ello, se apoya en un broker MQTT instalado en la propia sonda. Por último, se hace un almacenado local en ficheros csv de la información recopilada, junto con una marca de tiempo.
- Broker MQTT local: Para realizar la transmisión de datos al servidor de almacenamiento y procesado de datos se hace uso de un broker MQTT local. MQTT es un protocolo ligero de mensajería para pequeños sensores y dispositivos móviles ideado por IBM. Está optimizado para realizar la transmisión de datos incluso en redes no confiables y en entornos de alta latencia, por lo que es ideal para delegar en él la capa de transmisión de datos del programa anterior, ya que es presumible que el vehículo pueda encontrarse en situaciones de escasa cobertura o incluso pérdida total de la misma, además de en situaciones en las que la transmisión de datos haya de efectuarse haciendo uso de redes GSM de escasa capacidad. Además, tiene la ventaja de que produce menos sobrecarga que otros protocolos como HTTP, y (en teoría) hace un menor consumo de datos. La idea es la siguiente: el programa anterior delega en el broker MQTT el establecer el envío de paquetes al servidor. El broker MQTT actúa además como buffer local de los paquetes transmitidos, en caso de pérdida o inestabilidad de las comunicaciones. Este buffer local, gracias a una pequeña base de datos interna, es persistente incluso ante reinicios inesperados de la sonda. El broker MQTT local está sincronizado con otro broker MQTT desplegado en el servidor de recepción de datos, y es capaz de garantizar la correcta sincronización, como se ha comentado, incluso en situaciones de pérdida total de conectividad y reinicios en la sonda de datos.
- Envío de datos mediante tethering bluetooth: El broker local MQTT es dotado de conectividad a Internet mediante tethering bluetooth con un teléfono móvil. Si bien a priori sería más interesante hacer uso de tethering wifi para esto mismo, hay tres buenas razones para optar por bluetooth: La primera es que al hacer uso de MQTT el volumen de información a intercambiar es bastante reducido, por lo que es posible hacer uso de bluetooth para ello, con el consiguiente impacto positivo en el consumo de energía necesario para establecer el canal de datos. La segunda es una limitación física en la sonda. La Raspberry Pi 2 que utilizo tiene sólo dos puertos USB, uno usado con el módulo GPS y otro con el módulo bluetooth para conectar con la centralita, por lo que no queda sitio para un módulo WiFi. Y la tercera, es que todo es mejor con bluetooth.
- Servidor de recepción de datos: El segundo bloque del sistema es el servidor de recepción y análisis de datos. Consiste en líneas generales en un servidor Graphite donde se almacenan los datos proporcionados por la sonda de captura de datos, y que permite su posterior utilización, bien para la representación de gráficas de dichos datos mediante Grafana, bien para la el geoposicionamiento del vehículo en tiempo real, con información añadida del resto de parámetros proporcionados por la sonda.
- Broker MQTT: La comunicación, como se ha comentado, se realiza mediante un broker MQTT que sincroniza con el broker MQTT de la sonda. Este broker recibe los datos proporcionados por la sonda, y los inyecta, mediante una pasarela desarrollada en Python, en el servidor Graphite. Dado que es posible que la información proporcionada por el broker MQTT de la sonda no se reciba en tiempo real debido a posibles cortes en las comunicaciones, se hace uso de la marca de tiempo incluida en cada transmisión de la sonda remota para inyectar los datos en el servidor Graphite con información de tiempo de creación correcta.
- Servidor Graphite: El servidor Graphite consolida la información proporcionada por la sonda de captura de datos, la almacena en una sistema de base de datos buffer de corta duración (Carbon) y posteriormente la consolida en una base de datos da larga duración (whisper).
- Servidor Grafana: Los datos consolidados en el servidor Graphite son consumidos por Grafana, software para visualización de métricas. Se han creado una serie de gráficas que permiten acceder a la información relativa a la velocidad, revoluciones por minuto, entrada de aire en el motor, consumo de combustible y altitud con respecto al mar, así como a sus valores medios en un rango de tiempo establecido. Grafana proporciona, además, la capacidad de integrar estas gráficas en una plataforma de terceros.
- Sistema de geoposicionamiento: El broker MQTT permite, además, el procesamiento de la información proporcionada por la sonda para representar en tiempo real la ubicación geográfica del vehículo, así como la traza de las posiciones anteriores mediante una línea de posición. Además, se proporciona información en tiempo real de los parámetros proporcionados por la sonda. Este sistema está basado en Node-RED, una herramienta desarrollada por IBM para permitir una interconexión sencilla de diversas aplicaciones y dispositivos IoT. También hace uso de OpenStreetMap, mediante la librería WorldMap.
Captura de posicionamiento de vehículo con datos en tiempo real
Todo este sistema lo he compilado en la siguente web para su visualización: Telemetría (www.eniac2000.com/telemetria)
Dado que la información mostrada en esa URL proporciona datos en tiempo real, he realizado una captura de datos obtenidos en vivo:
Captura del sistema de telemetría
…así como un vídeo en el que se aprecia la información, si bien realizando la captura de la información desde las dos fuentes de datos separadas, y no desde el mismo portal:
Como comentaba, el sistema está aún en una fase muy temprana, pero el potencial de mejora es grande. Los principales puntos en los que estoy trabajando son los siguientes:
- Mejora en la seguridad de comunicaciones entre brokers MQTT
- Mejora en la fiabilidad de la comunicación OBD-II
- Reemplazo del sistema de base datos de larga duración de Graphite por un sistema NoSQL, presumiblemente un InfluxDB
- Dotar de redundancia a los elementos de la plataforma
- Proporcionar un sistema de persistencia de la información
- Creación de un portal multiusuario con soporte de múltiples dispositivos
- Otros…
Si bien este proyecto empezó como algo personal, con la idea de comprobar cuánto consumía mi coche en los desplazamientos, tengo el convencimiento de que puede convertirse en algo más que en un mero pasatiempo. Esperemos que así sea.
Etiquetas: bluetooth, gps, grafana, graphite, ibm, iot, mqtt, node-red, obd-ii, python, raspberry pi, telemetría, tethering
Últimos vídeos en Dailymotion
- Ha ocurrido un error; probablemente el feed está caído. Inténtalo de nuevo más tarde.
Medidor de entropía
Validación de estándares