¿Digital qué…?

Audio digital, video digital, telefonía digital, televisión digital, juegos digitales, ¡mundos digitales! Pero, ¿qué significa «digital»?
Para empezar, digamos que «digital» viene de «dígito» o «número». En tal sentido, «digitalizar» significa «pasar a números», de modo que algo digital es algo que representa números, sea de por sí o sea porque es algo que se ha digitalizado previamente.
Por ejemplo, se puede tomar una página de un libro de papel y «digitalizarla», y por lo tanto tener una representación digital, es decir numérica, de esa hoja.
Una forma de hacer esto conceptualmente, podría ser dividir la hoja en un cuadriculado, donde cada cuadradito sea lo más pequeño posible. Luego, por cada uno de esos cuadraditos (o pixeles), tomaremos nota de tres valores: coordenada en y, coordenada en x, y la «profundidad de color» que para simplificar, valdrá 0 si el cuadradito es mayoritariamente blanco o 1, si es mayoritariamente negro. Hecho esto tendremos una tabla de tres columnas de números que será la versión «digitalizada» de nuestra hoja.
A partir de ahora, enviando sólo los números y las indicaciones para interpretarlos, podríamos enviar una copia digitalizada de la hoja a cualquier destinatario.
Como hemos visto, la digitalización implica necesariamente, una selección de ciertos valores para digitalizar, por lo tanto, siempre la copia digital de cualquier cosa es más pobre que el original. En nuestro ejemplo, para perfeccionar la copia digital, habría que hacer cada vez más pequeños los cuadraditos; en el caso límite, recién cuando la cantidad de cuadraditos sea infinita la copia será perfecta. Obviamente, es un extremo que la tecnología no puede alcanzar.
¿Por qué ocurre eso? Por la sencilla razón que entre dos puntos cualquiera de la imagen, por próximos que se encuentren, puede haber infinitas variaciones de gris. Lo mismo ocurre con otras magnitudes físicas: entre dos valores cualesquiera, puede haber una variación infinita. Eso justamente, es lo que define la naturaleza de las magnitudes «analógicas» del mundo real.
Debe resultar evidente en este punto, que para interpretar cierta información digitalizada, debemos convertirla nuevamente en analógica, porque son estas las magnitudes que interpretan nuestros sentidos. Es decir, si queremos ver la imagen de la página del libro, no nos alcanzará con mirar la tabla con los números producidos en la digitalización, sino que tendremos que usar esos valores y reconstruir la imagen a partir de ellos.
Entonces, el «mundo digital», primero debe convertirse en «analógico» para que podamos interactuar con él. Justamente esa tarea tienen los monitores, impresoras, dispositivos de sonido, gafas de realidad virtual, guantes táctiles, y otros transductores menos comunes.
De hecho, todo el avance que se ha producido en la digitalización en las últimas décadas tiene que ver con que ha sido posible tomar el mundo analógico (sonidos, imágenes, etc), transformarlo en digital, manipularlo mediante ciertos procedimientos (algoritmos) y volverlo a convertir en analógico con el detalle y la rapidez suficiente para que nuestros sentidos no pudieran advertir la diferencia.
El hecho de que nuestros sentidos sean analógicos, implica que lo digital siempre debe convertirse para que podamos interpretarlo, del mismo modo que nuestros datos deben digitalizarse para que podamos manipularlos digitalmente. Así las cosas, analógico y digital, han llegado a ser dos caras de una misma moneda, dos conceptos que se complementan, omnipresentes en toda la tecnología actual.
Aún así, en algunos campos, notablemente el audio de alta fidelidad, hay quienes rechazan el procesamiento digital y prefieren que desde la grabación hasta la reproducción de la música sea analógica en virtud de no perder nada de los datos originales en ninguna digitalización, cosa que podría redundar, en alguna pérdida de la calidad original del sonido. Sin embargo, esto es más atribuible a cuestiones estéticas que técnicas.
Hasta acá la explicación de hoy. Sin embargo, son bienvenidas las preguntas y sugerencias. Saludos!

Netbook del gobierno en 2021

Hoy les dejo un video donde muestro una máquina de Conectar Igualdad que me dieron en 2011 funcionando con la última versión de Debian 11 el sistema operativo más nuevo de la serie Debian GNU/Linux. Por supuesto, en una máquina de este tipo no es posible usar las versiones actuales de otros sistemas operativos. Sin embargo, puede seguir usándose perfectamente con Linux, aún con el más nuevo. Espero animarlos a no desechar sus equipos y usarlos por largo tiempo ! Cualquier comentario o sugerencia es bienvenido.

Cámara web con soporte

Como un complemento del artículo sobre como hacer una cámara con smartphone para GNU/Linux, dejo este pequeño aporte que le agrega un soporte hecho con el exhibidor de un reloj pulsera. Este soporte nos permitirá ubicar nuestra cámara con comodidad sobre el monitor, y lo mejor del caso, sin gastar nada y usando cosas que de otro modo terminarían en la basura.

El soporte se muestra en el video que aparece a continuación. Les dejo un gran saludo y espero que sirva.

¿Cuándo dejan de ser útiles las computadoras?

Desde la irrupción de las computadoras personales allá en la década de 1970 todo ha sido vértigo, y una generación computadoras ha sido sustituida por la siguiente casi sin respiro desde entonces, generando una pila de deshechos proporcional a la velocidad de la evolución tecnológica y a la necesidad de ventas de los fabricantes.

Por lo tanto, llegados a este punto, debemos preguntarnos si tenemos que deshacernos tan rápidamente de nuestros aparatos, o podemos darle uso por un tiempo más prolongado del que dicta la moda.

En este sentido hoy les dejo un video que hice ayer (22 de julio de 2021) donde muestro mi viejo Celeron 2.66 GHz y 1GByte de Ram funcionando como en los mejores tiempos, a pesar de que tiene unos 15 años de antigüedad.

Les dejo un gran saludo, espero animarlos a poner en práctica aquella máxima de las tres «R»: Reducir, reciclar, reutilizar. Por supuesto, los comentarios son bienvenidos 😉

¿Qué software matemático puedo usar?

Cualquier persona que de una u otra manera realice tareas relacionadas con ciencia o técnica necesita, más temprano que tarde usar un software matemático como una herramienta más de uso cotidiano. Las opciones son muchas, que sin embargo se reducen significativamente al considerar tres tres necesidades importantes:

1. Costo
2. Calidad
3. Portabilidad

Por supuesto, dados los requisitos, la elección cae dentro del software libre, donde hay grandes clásicos del rubro: Octave (clon de MatLab), Scilab (gran paquete de origen francés) y Maxima (software de álgebra simbólica).

Los tres satisfacen con creces los tres puntos anteriores. Sin embargo, elegimos Maxima porque es el único que tiene, además de la versión nativa de GNU/Linux y la versión para Windows, una excelente versión para Android que funciona muy pero muy bien y que se instala fácil y sin inconvenientes. Y por si fuera poco, existe la posibilidad de ejecutar una versión on line desde cualquier navegador, llevando al extremo la portabilidad y la austeridad de recursos.

A continuación les dejo unos videos relacionados que muestran los primeros pasos y algunos usos interesantes del software. Por supuesto, son bienvenidos los comentarios y sugerencias ;-).

Primeros pasos con Maxima

Ecuaciones de nodos resueltas con Maxima

Uso de Maxima para encontrar funciones de transferencia

Resolución de circuitos con Maxima comparando datos con un simulador (LTSpice)

Como extender el alcance de un control remoto de garage tipo llavero

El problema

Hace poco compré un llavero emisor de 433MHz basado en el codificador EV1527 con la idea de usarlo con un módulo MX-RM-5V (receptor de 433MHZ) y así leerlo con un Arduino Uno. La tarea resultó sencilla usando la librería rc-switch: sólo hay que instalarla con el manejador de librerías de la IDE de Arduino, luego buscar el programa ReceiveDemo_Simple (en la IDE Archivo->Ejemplos->rc-switch->ReceiveDemo_Simple) y grabarlo en la placa. Luego, cada vez que oprimimos el botón del llavero veremos una lectura como esta

Aquí, cada línea corresponde a una vez que se oprimió el botón.

Sin embargo, el alcance dejó mucho que desear: usando el módulo receptor MK-RM-5V con la antena indicada (un alambre de 17 cm), la señal del llavero se perdía luego de dos o tres metros sin obstáculos, lo cual puede hacerlo inútil para muchas aplicaciones prácticas.

Solución

Antenas

La solución más simple y obvia fue trabajar sobre las antenas. A este respecto, luego de unas pruebas, se vio que una antena de media onda en el módulo receptor MK-RM-5V (alambre de cobre sin enrollar de unos 34cm) y una antena de un cuarto de onda en el llavero dieron resultados bastante buenos: el alcance aumentó hasta unos 8 o 10 metros a través de varias habitaciones.

Luego de abrir el llavero, es evidente por la extensión de la pista del borde que es la antena, así que después de limpiar un poquito del barniz que cubre la placa, soldamos el alambre de 17 cm.

Para poder volver a cerrar el llavero, marcamos y hacemos una muesca para dejar pasar la antena. Es muy práctico usar el disco de amolar del minitorno.

Cerramos de nuevo, y ya está.

Sólo a modo de referencia, se muestra el módulo receptor con su antena, conectado al Arduino Uno, todo alimentado por el cable USB de la computadora.

Alimentación

El otro punto a considerar es la fuente de alimentación: mayor tensión es más potencia y por lo tanto mayor alcance. Este llavero viene con dos baterías tipo CR2016 en serie, así que usa 3V. El EV1527 tiene una máxima tensión de alimentación posible de 13V, así que se puede aumentar la alimentación del llavero con cierta seguridad.

Una forma de hacer esto podría ser insertar otra pila CR2016, soldar unos cables y usar una batería convencional de 9V o incluso una de de 12V. Por supuesto, si se usan baterías externas, no se podrá cerrar la carcasa.

Yo soldé unos cables, conecté una batería de 9V e hice algunas pruebas que mostraron que el alcance aumentó aún más: esta vez hubo recepción hasta unos 20 metros, a través de varias habitaciones.

Conclusión

Es muy sencillo y económico usar un control remoto tipo llavero con Arduino, pero su alcance puede ser muy limitado. Se vio que tiene un fuerte impacto el agregado de una antena tanto en el emisor como en receptor y el aumento de la tensión de fuente en el emisor. Si se va utilizar para algo serio, convendría probar con un llavero que ya tenga antena incorporada y una alimentación alta, que para el EV1527 es de unos 12V.

Trabajo futuro

Estudiar mejor el tema antenas y ver que impacto en el alcance tiene un ajuste más preciso de las sus longitudes y posibles alternativas constructivas, tanto en el emisor como en el receptor. Además, habría que ver como adaptar la antena y una alimentación más grande del lado del emisor.

Por supuesto, cualquier comentario o sugerencia s bienvenida. Saludos a todos!

Método de nodos

El método de nodos tiene una enorme aplicación en el análisis de circuitos eléctricos y en redes de naturaleza física no eléctrica pero con una representación matemática similar.

Hoy dejo un pequeño trabajo que hice para mis alumnos sobre el método de nodos, y la manera de aplicar mecánicamente las ecuaciones, lo cual tiene una serie de ventajas sobre la forma usual que parte de la aplicación de las Leyes de Kirchhoff. En especial permite encarar rápidamente el análisis de circuitos complejos y reduce errores al permitir plantear las ecuaciones directamente.

El material consiste de un apunte (que se puede bajar desde acá ) y un video que explica el método utilizando el apunte anterior.

Espero que sirva. Y por supuesto, son bienvenidos los comentarios, sugerencias y correcciones.

Zoom arranca solo en GNU/Linux

• 

Con la pandemia tuve que instalar zoom en mi máquina con Debian 10. Funcionó bien, pero apareció un comportamiento errático: cada tanto, se iniciaba solo. Y esto aún cuando no había puesto ninguna opción de auto arranque.

Buscando en internet encontré a qué se debía el problema y la solución (en este link http://zarnovican.github.io/2018/05/20/autostarting-zoom-app/ ). Resulta que el responsable es el viejo y querido xscreensaver, que arranca una aplicación de protección de pantalla que casualmente se llama zoom. Por lo tanto, la solución es deshabilitar el salvapantallas zoom y listo.

Hay varias maneras de hacer esto. Una es ir a los archivos de configuración de xscreensaver y comentar la aplicación. Con LXDE quizá lo más fácil sea hacer Inicio->Preferencias->Salvapantallas y una vez en la utilidad de configuración, sacar el tilde a Zoom

Y colorín colorado, el problema se ha solucionado.

Smartphone como GNU/Linux webcam

Motivación

Luego de usar mi Lenovo N500 por más de diez años, nunca me preocupé de hacer funcionar la cámara web integrada, y ya con la pandemia y la avalancha de video reuniones encima, descubrí que el driver para GNU/Linux (Debian 10 en mi caso) no funcionaba. Y al mismo tiempo, las aplicaciones usuales para reuniones (ZOOM / Google Meet) ya pesan bastante para mi vieja notebook, así que consideré usar una PC de escritorio que tenía disponible, y que es un poco más nueva. Sin embargo, esta PC, no tiene cámara web.

Con esto en mente, las alternativas eran:

1. Trabajar para lograr que funcione la cámara web integrada en la notebook.
2. Comprar una cámara web externa
3. Usar una cámara digital como cámara web,

La primera alternativa, se descartó por dificultosa. La segunda se descartó por el costo: una cámara web acá (Argentina) cuesta unos $5000, que representa más del 25% de la mensualidad de un jubilado, lo que es un precio considerable. Así que se exploró la tercera opción.

Créditos

Los teléfonos inteligentes que quedan en desuso casi nuevos son tan abundantes que nos dejan piezas de tecnología muy versátiles y poderosas a costo casi cero y todos tienen por lo menos una buena cámara digital. Después de una breve búsqueda en internet aparecieron varias soluciones que implementaban cámaras web usando teléfonos celulares. En especial estos dos vínculos

https://www.atareao.es/software/video/utiliza-tu-android-como-webcam-en-ubuntu/

https://github.com/bluezio/ipwebcam-gst/

El primer vínculo realmente refiere al segundo y siguiendo las instrucciones que da, se puede instalar un smartphone como cámara web en un sistema GNU/Linux. En el segundo link aparece el «driver para Linux», que en realidad es un gran trabajo que ha hecho Antonio García Domínguez, el autor, escribiendo dos scripts de shell que instalan y combinan software ya existente para que todo funcione. Esto demuestra la potencia y versatilidad de GNU/Linux como sistema capaz de adaptarse a usos peculiares y la potencia del software libre que además de proveer herramientas poderosas nos deja la información al alcance de la mano para que quién quiera aprender pueda hacerlo. A continuación muestro una implementación simplificada del trabajo de Antonio, hecha con dos cosas en mente

1. Aprender para poder explicar el proceso
2. Poder usar otras aplicaciones de cámara que la que muestra el trabajo original. Ya veremos de qué se trata.

La idea

La idea es tomar el streaming de la cámara, que normalmente saldría por la interfase de red, y redirigirlo al puerto USB para evitar demoras, y enviarlo a la PC. Ya en la computadora, de nuevo se redirecciona a la interfase loopback (que siempre tiene la dirección 127.0.0.1 ó localhost) desde donde se vuelve a tomar el streaming para procesarlo y enviarlo al dispositivo /dev/video0, lugar que lo hará disponible para cualquier aplicación como si se tratara de un dispositivo de captura convencional

El esquema propuesto en el trabajo de Antonio para usar el teléfono cómo cámara es el siguiente

Lo que es cada cosa…

Cámara y streaming en android

Este planteo requiere correr en el dispositivo android una aplicación que tome el video que produce la cámara y que genere el streaming que se quiere transmitir. Hay varias aplicaciones que hacen eso. Antonio propone usar IP-webcam, y de hecho, es obligatorio usarla para utilizar su script, pero no es una aplicación libre. Lamentablemente, buscando en F-droid (que es un repositorio de software libre para android), si bien hay algunas aplicaciones de este tipo, no funcionan adecuadamente o no trabajan completamente sobre http, cuestión aparentemente insalvable en este esquema de trabajo, como veremos después.

Finalmente, se decidió usar #LiveDroid, porque aunque no es software libre, es relativamente pequeña (5,8 MB), funciona completamente sobre http y no contiene ni anuncios ni compras integradas. Se puede instalar desde Google Play, como indica el link mostrado recién. Agradezco a su autor Akshay Chopde por esta amigable y eficaz aplicación.

Normalmente estas aplicaciones hacen el streaming sobre la red en la dirección IP del teléfono, de manera que si nos conectamos a la misma red podemos acceder al video desde un navegador. Por ejemplo, si el teléfono está conectado a un access point con la dirección 192.168.1.20 y nuestra computadora está conectada al mismo access point con la dirección 192.168.1.5, si ponemos http://192.168.1.20:puerto/algo en la computadora, podremos ver la imagen que está tomando la cámara del teléfono por intermedio de la red local.

Por lo general, puerto es 8080, y comunmente se puede configurar desde la aplicación. Una relativa dificultad es conocer qué es algo en la dirección de arriba, porque en general debemos tener la dirección completa para acceder al streaming de la cámara. Para el caso de IP-webcam se puede usar el url http://ip_del_telefono:puerto/videofeed según el trabajo de Antonio.

Para #LiveDroid es http://ip_del_telefono:puerto/?action=stream cosa que se descubrió analizando el flujo de datos con wireshark, que es un excelente analizador de flujos de red libre con una utilidad superlativa. Es probable que descubrir el url completo sea el paso clave que permita adaptar otras aplicaciones de cámaras que hacen streaming para que funcionen con GNU/Linux. Como veremos más adelante, al final se usa la dirección 127.0.0.1 (localhost) para acceder a la cámara, así que se apunta wireshark hacia allí, y con un poco de suerte, se puede verificar el url donde la aplicación sube el streaming.

Software de redirección en Android y en GNU/Linux

Existe un software llamado adb por Android Debug Bridge, que permite hacer cosas asombrosas. Si ya está instalado, se puede consultar información al respecto tecleando man adb desde la consola. Y si no está instalado, es imprescindible instalarlo usando apt o synaptic. Desde la consola podemos instalarlo poniendo

$apt-get install adb

adb tiene tres partes: un servidor que corre en segundo plano en la máquina GNU/Linux y un demonio que se ejecuta también en segundo plano en el dispositivo android. Finalmente, hay un cliente que también se ejecuta en la computadora GNU/Linux.

La idea es que los clientes nos permiten enviar comandos al servidor local para luego enviarlos al demonio remoto en el dispositivo.

Usaremos adb para redirigir el tráfico de la interfase de red del teléfono hacia el puerto USB. Para hacer esto tenemos que hacer dos cosas.

1. En el dispositivo android, habilitar primero el modo de desarrollador y luego habilitar el modo de depuración por USB. Esto permitirá al demonio adb redirigir el tráfico tcp y otras cosas.
2. Luego, desde la consola, tipear

$adb forward tcp:8080 tcp:8080

Con lo cual se hace el reenvío de los paquetes tcp entre el puerto 8080 en la máquina GNU/Linux con el puerto tcp 8080 del dispositivo android. Volveremos sobre esto más adelante con más detalle.

El modo de desarrollador puede estar habilitado en el dispositivo android, o quizá sea necesario habilitarlo. Para hacerlo, por lo general hay que ir a Ajustes -> Acerca del teléfono -> Información de Software -> Número de compilación y golpear 7 veces en esa última opción. Luego de esto, deberá aparecer la opción Ajustes -> Opciones del desarrollador y dentro, deberemos habilitar la opción Depuración de USB.

GStreamer

GStreamer es un software de procesamiento de audio y video que permite separar la complejidad del procesamiento del streaming de la aplicación que finalmente muestra esos datos.

GStreamer se basa en tuberías que es un concepto muy usado en sistemas tipo UN*X y consiste en la idea de que un flujo de datos (stream) puede ser la entrada de un programa que lo procesa, dando una salida que a su vez se puede usar como entrada de otro programa y así sucesivamente. En el caso de GStreamer, el operador que conecta la tubería, es decir, la salida de un programa con la entrada del siguiente, es » ! «.

En la figura de abajo se muestra este concepto, en donde el origen de datos se llama source (fuente) y el destino recibe el nombre de sink (sumidero). (Las dos figuras siguientes se han tomado de https://es.wikipedia.org/wiki/GStreamer, lugar en donde se puede encontrar una muy buena explicación sobre GStreamer)

Para instalar gstreamer en Debian GNU/Linux (según la página oficial de gstreamer) ponemos

$apt-get install libgstreamer1.0-0 gstreamer1.0-plugins-base  gstreamer1.0-plugins-good gstreamer1.0-plugins-bad  gstreamer1.0-plugins-ugly gstreamer1.0-libav gstreamer1.0-doc  gstreamer1.0-tools gstreamer1.0-x gstreamer1.0-alsa gstreamer1.0-gl  gstreamer1.0-gtk3 gstreamer1.0-qt5 gstreamer1.0-pulseaudio

v4l2loopbak

Un dispositivo de video real constituye un punto en dónde se puede tomar una señal de streaming proveniente de un dispositivo de captura real, como por ejemplo, una cámara de video física conectada a la computadora. Por el contrario, un dispositivo de video virtual, toma su streaming de otra fuente, pero la hace disponible a cualquier aplicación de la misma forma que uno real. en nuestro caso, esta característica resulta muy conveniente y se logra utilizando el módulo v4l2loopback.

Bajo Debian, este módulo puede venir para construir en formato dkms como directamente en formato binario y se puede instalar usando tanto apt como synaptic.

Si elegimos usar el que viene para construir con dkms, hay que prestar atención a un asunto muy importante: la versión de este módulo debe coincidir con la versión del kernel que correrá cuando hemos de cargarlo. Es sencillo, pero es algo que hay que resolver a mano, porque ni el script de Antonio ni los programas de instalación lo resuelven de manera automática. Una forma de asegurarse de esto es usar synaptic y mirar la versión de kernel que figura al final del nombre del paquete v4l4loopback, para luego buscar las imágenes (linux-image-*) y verificar que coincida con la versión que también aparece al final del nombre del archivo de la imagen del kernel. Si la imagen no es la activa, sencillamente instalamos la que nos hace falta y la elegimos desde el menú de inicio cuando la computadora arranque la próxima vez.

Por ejemplo, si nuestro paquete es v4l2loopback-modules-4.9.0-13-686-pae, entonces, tendremos que instalarlo junto con la imagen del kernel que viene en linux-image-4.9.0-13-686-pae.

Para este caso, desde la consola habría que teclear, como root

$apt-get install v4l2loopback-modules-4.9.0-13-686-p linux-image-4.9.0-13-686-pae

Ahora tenemos que construir e instalar el módulo con module-assitant, de tal manera que si no está instalado, hay que instalarlo. Siempre como root, desde la terminal ponemos

$apt-get install module-assistant

Una vez instalado el asistente para la construcción de módulos, lo usamos para construir e instalar el módulo que nos interesa

$ module-assistant auto-install v4l2loopback

Esto iniciará un proceso de compilación e instalación que culminará con nuestro módulo disponible. La ventaja de este método sobre el clásico make install es que el sistema lleva la cuenta de que el módulo se instaló y lo considera para futuras dependencias.

Si por el contrario, instalamos el binario, hacemos directamente podremos instalarlo (como root) tecleando en la terminal

$ apt-get install v4l2loopback-dkms

Una vez instalado por cualquiera de los dos métodos, el módulo queda disponible para cargar poniendo, como root

$modprobe -v v4l2loopback

Y si no hay errores, ya tendríamos que tener nuestro /dev/video0 listo para usar.

Ponemos todo junto…

En este punto ya se puede unir todo, con el siguiente esquema

1. Conectamos el teléfono con #LiveDroid instalado a la computadora mediante un cable USB. En mi caso usé un viejo y pequeño LG20. Para verificar que está bien conectado podemos teclear, como root, desde la terminal

$ adb devices -l
 List of devices attached
 * daemon not running; starting now at tcp:5037
 * daemon started successfully
 LF5SP7AIHIRG8DVO       unauthorized usb:2-5 transport_id:1 d:1 
$

Al ingresar este comando, en el teléfono debe aparecer algo como esto

Pantalla del LG 20 al ser conectado mediante adb

Esa es una reacción de seguridad del teléfono, así que debemos contestar «ok» para poder conectar el teléfono. Si vamos a usar siempre la misma computadora, también podemos tildar la casilla y ya no nos va pedir nada la próxima vez que nos conectemos al teléfono.

Si esto no sucede, se puede matar al servidor adb en la computadora y volver a intentarlo. Por ejemplo

$ps -C adb
   PID TTY          TIME CMD
 28244 ?        00:03:15 adb
$kill 28244

Esto mataría al servidor adb para poder volver a intentar.

Retomando, si apretamos «ok» en el teléfono, ya podremos conectarnos

$adb devices -l
 List of devices attached
 LF5SP7AIHIRG8DVO       device usb:2-5 product:luv20ss_global_com model:LG_D100 device:luv20ss transport_id:1

Notar que ha desaparecido la palabra unauthorized de la salida del comando, lo cual significa que podremos conectarnos.

2. Ahora redireccionamos el puerto tcp 8080 del dispositivo android al puerto tcp 8080 de la computadora GNU/Linux. Esto significa que los datos que las aplicaciones del teléfono envíen a ip_telefono:8080 aparecerán en 127.0.0.1:8080, y habrán viajado por el cable USB, no por el WiFi. Usamos el comando adb forward tcp:puerto_local tcp:puerto_remoto, que en realidad permite redireccionar dos puertos cualquiera de los dos lados. El comando es

$ adb forward tcp:8080 tcp:8080

(Si da error, verificar la conexión con el teléfono: si no permitimos siempre la depuración desde esta computadora en la pregunta que nos hizo el dispositivo antes, tendremos que autorizar de nuevo la conexión)

3. Ahora hay que cargar el módulo v4l2loopback para tener disponible nuestro dispositivo de video /dev/video0

$ /sbin/modprobe -v v4l2loopback
 insmod /lib/modules/4.19.0-6-686-pae/kernel/drivers/media/v4l2-core/v4l2-common.ko 
 insmod /lib/modules/4.19.0-6-686-pae/updates/dkms/v4l2loopback.ko 

4. Ahora ejecutamos gstreamer para habilitar el procesamiento y redirección del streaming

$ gst-launch-1.0 souphttpsrc location=http://localhost:8080/?action=stream do-timestamp=true is-live=true ! queue ! multipartdemux ! decodebin ! videoconvert ! video/x-raw,format=YUY2 ! v4l2sink device=/dev/video0 sync=false

5. Si no hubo errores, ya podemos intentar ver lo que está capturando la cámara del teléfono. Una alternativa es teclear lo siguiente en la consola

$ webcamoid /dev/video0

Veremos aparecer webcamoid y si apretamos play tendría que aparecer en vivo la imagen que captura nuestro dispositivo

El teléfono funcionando como webcam

En síntesis…

Una vez que tenemos todo el software instalado, cada vez que queremos habilitar la cámara sólo tenemos que ingresar tres órdenes para habilitar la cámara

$ adb forward tcp:8080 tcp:8080
$ /sbin/modprobe -v v4l2loopback
$ gst-launch-1.0 souphttpsrc location=http://localhost:8080/?action=stream do-timestamp=true is-live=true ! queue ! multipartdemux ! decodebin ! videoconvert ! video/x-raw,format=YUY2 ! v4l2sink device=/dev/video0 sync=false

Luego de esto, la cámara debería estar disponible, como se muestra en el video que sigue

Como una forma de hacerlo más simple, puse esos tres comandos juntos en un pequeño script llamado webcam.sh: se puede bajar, hay que hacerlo ejecutable y correrlo cada vez que se necesite usar la cámara web. El archivo se puede bajar desde acá.

Si no se quiere cambiar los permisos al archivo, se lo puede ejecutar poniendo, como root:

$ bash webcam.sh

Conclusión

Se presentó una manera sencilla y económica de agregar una cámara web a una computadora GNU/Linux: no se gasta un céntimo, se hace todo con lo que hay a mano, y se da nuevo uso a celulares que de otro modo terminarían en la basura. Y por si fuera poco se aprenden cosa nuevas.

Por supuesto, cualquier comentario, corrección o ampliación de este trabajo es bienvenida. En especial sería muy agradable que alguien acerque el dato de una aplicación libre de cámara web para ejecutar en el teléfono, que fue el único software propietario que no se pudo evitar usar.

Compilar el SDK para el ESP8266

El ESP8266 es un microcontrolador fabricado por la compañia china Espressif, con capacidad de WiFi que se ha hecho muy popular integrando «Shields» para arduino y como microntrolador principal en algunas placas como la Wemos D1.
Un SDK es un «Software Development Kit», es decir, un conjunto de herramientas de software que nos permite desarrollar programas para el dispositivo de que se trate.
En el caso particular de la placa Wemos D1, puede usarse como SDK la IDE de Arduino mas una serie de librerias y programas escritos para el ESP8266. Sin embargo, acá intentateremos compilar el SDK específico para el ESP8266 en su versión de software libre que se puede obtener del vínculo

Hay que seguir las instrucciones que aparecen alli. En nuestro caso, como se compilará sobre debian 10, nos aseguramos que estén las dependencias

$ sudo apt-get install make unrar-free autoconf automake libtool gcc g++ gperf \
flex bison texinfo gawk ncurses-dev libexpat-dev python-dev python python-serial \
sed git unzip bash help2man wget bzip2

$ sudo apt-get install libtool-bin

Después hacemos una copia local del repositorio

$ git clone –recursive https://github.com/pfalcon/esp-open-sdk.git

Y luego, compilamos con la opción que nos guste

$ make STANDALONE=y

ó

$ make STANDALONE=n

La primera opción mezcla el software propietario y libre, mientras que la segunda mantiene separada las aguas.

Acá elegimos la segunda y damos ENTER.

Sin embargo, obtenemos un error como

checking for bash >= 3.1… no
configure: error: could not find bash >= 3.1
make[1]: *** [../Makefile:143: _ct-ng] Error 1
make[1]: Leaving directory ‘/home/badbob/esp8266/esp-open-sdk-git/src/esp-open-sdk/crosstool-NG’
make: *** [Makefile:139: crosstool-NG/ct-ng] Error 2
==> ERROR: A failure occurred in build().
Aborting…

En mi caso bash es versión mayor a la 5, así que algo hay de malo en el script.

Cuando buscamos el aviso de error, lo encontramos en el archivo configure.ac bajo el directorio

~/esp-open-sdk/crosstool-NG$

En ese archivo a partir de la línea 190 encontramos las siguientes líneas de código

AC_CACHE_CHECK([for bash >= 3.1], [ac_cv_path__BASH],
[AC_PATH_PROGS_FEATURE_CHECK([_BASH], [bash],
[[_BASH_ver=$($ac_path__BASH –version 2>&1 \
|$EGREP ‘^GNU bash, version (3\.[1-9]|4)’)
test -n «$_BASH_ver» && ac_cv_path__BASH=$ac_path__BASH ac_path__BASH_found=:]],
[AC_MSG_RESULT([no])
AC_MSG_ERROR([could not find bash >= 3.1])])])

El error está en la expresión que comprueba la versión de bash, tanto porque no contempla el 5 como la posibilidad de que en lugar de ‘version’ aparezca ‘versión’ con acento, como ocurre en las versiones en español. Lo único que hay que hacer es modificar la línea dónde aparece $EGREP como sigue

|$EGREP ‘^GNU bash, versi[oó]n (3\.[1-9]|4|5)’)

Luego se graba el archivo y ahora sí se puede compilar sin problemas, aunque el proceso dura varias horas (por lo menos en mi vieja máquina).
Espero que sirva y quedo a la espera de los comentarios.

Referencias:

Una punta para resolver el error al detectar la versión de bash se puede mirar el link https://bbs.archlinux.org/viewtopic.php?id=244333

Para ver sobre bash y las expresiones regulares se puede ver este link https://sospedia.net/el-shell-bash-de-gnulinux-4-expresiones-regulares/