Archivo por meses: noviembre 2010

Manifiesto por una Red Neutral

Los ciudadanos y las empresas usuarias de Internet adheridas a este texto manifestamos:

  1. Que Internet es una Red Neutral por diseño, desde su creación hasta su actual implementación, en la que la información fluye de manera libre, sin discriminación alguna en función de origen, destino, protocolo o contenido.
  2. Que las empresas, emprendedores y usuarios de Internet han podido crear servicios y productos en esa Red Neutral sin necesidad de autorizaciones ni acuerdos previos, dando lugar a una barrera de entrada prácticamente inexistente que ha permitido la explosión creativa, de innovación y de servicios que define el estado de la red actual.
  3. Que todos los usuarios, emprendedores y empresas de Internet han podido definir y ofrecer sus servicios en condiciones de igualdad llevando el concepto de la libre competencia hasta extremos nunca antes conocidos.
  4. Que Internet es el vehículo de libre expresión, libre información y desarrollo social más importante con el que cuentan ciudadanos y empresas. Su naturaleza no debe ser puesta en riesgo bajo ningún concepto.
  5. Que para posibilitar esa Red Neutral las operadoras deben transportar paquetes de datos de manera neutral sin erigirse en «aduaneros» del tráfico y sin favorecer o perjudicar a unos contenidos por encima de otros.
  6. Que la gestión del tráfico en situaciones puntuales y excepcionales de saturación de las redes debe acometerse de forma transparente, de acuerdo a criterios homogéneos de interés público y no discriminatorios ni comerciales.
  7. Que dicha restricción excepcional del tráfico por parte de las operadoras no puede convertirse en una alternativa sostenida a la inversión en redes.
  8. Que dicha Red Neutral se ve amenazada por operadoras interesadas en llegar a acuerdos comerciales por los que se privilegie o degrade el contenido según su relación comercial con la operadora.
  9. Que algunos operadores del mercado quieren “redefinir” la Red Neutral para manejarla de acuerdo con sus intereses, y esa pretensión debe ser evitada; la definición de las reglas fundamentales del funcionamiento de Internet debe basarse en el interés de quienes la usan, no de quienes la proveen.
  10. Que la respuesta ante esta amenaza para la red no puede ser la inacción: no hacer nada equivale a permitir que intereses privados puedan de facto llevar a cabo prácticas que afectan a las libertades fundamentales de los ciudadanos y la capacidad de las empresas para competir en igualdad de condiciones.
  11. Que es preciso y urgente instar al Gobierno a proteger de manera clara e inequívoca la Red Neutral, con el fin de proteger el valor de Internet de cara al desarrollo de una economía más productiva, moderna, eficiente y libre de injerencias e intromisiones indebidas. Para ello es preciso que cualquier moción que se apruebe vincule de manera indisoluble la definición de Red Neutral en el contenido de la futura ley que se promueve, y no condicione su aplicación a cuestiones que poco tienen que ver con ésta.

La Red Neutral es un concepto claro y definido en el ámbito académico, donde no suscita debate: los ciudadanos y las empresas tienen derecho a que el tráfico de datos recibido o generado no sea manipulado, tergiversado, impedido, desviado, priorizado o retrasado en función del tipo de contenido, del protocolo o aplicación utilizado, del origen o destino de la comunicación ni de cualquier otra consideración ajena a la de su propia voluntad. Ese tráfico se tratará como una comunicación privada y exclusivamente bajo mandato judicial podrá ser espiado, trazado, archivado o analizado en su contenido, como correspondencia privada que es en realidad.

Europa, y España en particular, se encuentran en medio de una crisis económica tan importante que obligará al cambio radical de su modelo productivo, y a un mejor aprovechamiento de la creatividad de sus ciudadanos. La Red Neutral es crucial a la hora de preservar un ecosistema que favorezca la competencia e innovación para la creación de los innumerables productos y servicios que quedan por inventar y descubrir. La capacidad de trabajar en red, de manera colaborativa, y en mercados conectados, afectará a todos los sectores y todas las empresas de nuestro país, lo que convierte a Internet en un factor clave actual y futuro en nuestro desarrollo económico y social, determinando en gran medida el nivel de competitividad del país. De ahí nuestra profunda preocupación por la preservación de la Red Neutral. Por eso instamos con urgencia al Gobierno español a ser proactivo en el contexto europeo y a legislar de manera clara e inequívoca en ese sentido.

(Si te sientes cómodo y representado por este texto, dale toda la difusión que puedas y quieras: reprodúcelo, enlázalo, tradúcelo, compártelo, vótalo… todas esas cosas que puedes hacer con total tranquilidad y libertad gracias, precisamente, al hecho de que tenemos todavía una red neutral. Hagamos posible el seguir teniéndola)

Clon de videocámara MD80

Hace algún tiempo me compré un clon de la videocámara MD80. Esta cámara, que se puede comprar por unos 11 € ( http://www.dealextreme.com/details.dx/sku.32022 ) tiene una relación calidad/precio inmejorable. Graba imagenes a 720×480 pixeles / 30 fps en formato AVI con el codec Motion JPEG y sonido PCM en mono a 22050 hz. Los videos se almacenan en una tarjeta microSD (recomendable class 4 o incluso class 6) de hasta 16 GB. La batería es recargable por el puerto USB y dura para una grabación de 80 minutos. Puede grabar automáticamente cuando detecta un sonido por encima de los 60 db. Además puede funcionar como webcam. Trae consigo varios soportes para que se puedan colocar el distintos sitios. Es sensible a la luz y se ajusta automáticamente.

La verdad es que es muy completa y la gente la suele usar mucho cuando quiere salir al campo en bicicleta y grabar un vídeo. Su tamaño tan reducido y su peso de 20 gramos hace que sea ideal para colocarla en cualquier sitio.

No todo son maravillas, por ejemplo la cámara no tiene estabilizador, por lo que se notarán los movimientos abruptos. También la grabación no es del todo fluida, pero eso ya depende de las condiciones de luz. Importante lo de la clase de la memoria microSD, ya que si no es lo suficientemente rápida veremos saltos en los videos. Por otro lado muestra la fecha y la hora en la grabación, pero esto tiene arreglo.

Finalmente dejo un video que he grabado por el centro de Madrid y en el parking de un conocido centro comercial:

Processing y el puerto serie

Processing es un software de programación de representaciónes gráficas y animaciones. Está basado en java y debido a ello es multiplataforma. Es software libre y tiene una comunidad muy extensa de desarrolladores y de usuarios.

El objetivo de este artículo es tratar de dar una idea de cómo hacer que Processing pueda interactuar con un puerto serie: cómo recibir y enviar datos, cómo mostrarlos en un gráfico y/o guardarlos en un fichero.

Como Processing puede usar librerías al estilo de java, hay una que necesitaremos para la programación del puerto serie, esta es processing.serial y se puede importar desde un sketch de la siguiente manera:

A continuación se debe crear una variable global del tipo Serial (o varias si vamos a tratar con más de un puerto serie).

Después hay que instanciarlo en el método Setup.

Lo que estamos haciendo es crear un objeto Serial. El constructor de la clase Serial tiene varias sobrecargas:

Serial(padre)
Serial(padre, velocidad)
Serial(padre, puerto)
Serial(padre, puerto, velocidad)
Serial(padre, puerto, velocidad, paridad, palabra, parada)

Los parámetros son:

padre: Se suele usar this siempre.
velocidad: La velocidad en b.p.s. a la que se quiere enviar y recibir datos: 9600 es la que toma por defecto si no se le indica otra cosa.
puerto: Nombre del puerto de comunicaciones. «COM1» es el que toma por defecto, pero puede ser otro de windows. En linux o mac suele ser /dev/tty*
paridad: ‘N’ para ninguna, ‘E’ para paridad par, ‘O’ para paridad impar. ‘N’ es la que se toma por defecto.
palabra: Número de bits que conforman una unidad de datos. 8 es el que se toma por defecto.
parada: Número de bits de parada (stop). Puede ser 1.0, 1.5, or 2.0, siempre en formato float. 1.0 es el que se toma por defecto.

Si no sabemos a priori qué puertos serie tenemos en nuestro ordenador, podemos imprimir un listado de los disponibles.

Como se trata simplemente de un array de cadenas, podemos acceder al valor de cualquier de ellas y pasárselo como argumento al constructor de Serial, tal y como he expuesto lineas atrás en la creación del objeto.

A partir de aquí, y si el puerto se ha podido abrir sin problemas, podemos enviar y recibir los datos.

Para enviar datos desde Processing al puerto serie hay que usar el método write del objeto que hayamos creado.

Se puede enviar tipos byte, char, int, array de bytes o cadenas.

Para recibir los datos tenemos dos posibilidades.

1) Comprobar dentro del método Draw si hay datos disponibles para su lectura, leerlos y procesarlos:

El método available nos devuelve el número de bytes que hay pendientes por leer en el buffer. El método read nos devuelve un valor de 0 a 255 del primer byte de la cola FIFO del buffer, o -1 si no hay dato disponible. Además de read hay otros métodos para recuperar los datos: readChar, readBytes, readBytesUntil, readString, readStringUntil.

2) Definir en el método Setup cuantos bytes queremos leer cada vez, esperar a que se active el evento serialEvent, y dentro de este leer los bytes.

En Setup:

En el cuerpo principal del sketch:

Esta técnica es mucho más optima que la primera. El rendimiento del método Draw para leer los datos del puerto serie y dibujarlos será menor que si el método Draw sólo se centra en leer las variables y dibujar en consecuencia, dejando al evento serialEvent que se encargue de poblar las variables con los datos recibidos por el puerto serie. Para que funcione esta técnica, se debe informar al objeto Serial de cuantos bytes se deben leer antes de que se dispare el evento serialEvent, esto se hace usando el método buffer indicando los bytes a leer. Dentro del evento serialEvent se deben leer tantos bytes como se especificaron con el método buffer. Si se está trabajando con más de un puerto serie se puede usar el único parámetro del evento serialEvent para distinguir desde qué puerto serie se han recibido los bytes.

Si se desea escribir los datos que se reciben a un fichero se debe crear una variable global del tipo PrintWriter.

Luego en el método Setup debemos crear el objeto PrintWriter indicando en qué fichero guardar los datos.

Finalmente, ya sea dentro del método Draw o del evento serialEvent (recomendado) se escriben los datos al fichero:

Es importante ejecutar el método flush para garantizar que se están guardando los datos y no se quedan en buffers intermedios, ya que cuando cerremos la ejecución de nuestro sketch todo lo que no haya sido físicamente escrito al disco se pierde.