HTML5 + Box2D = Quick’N’Dirty Dakar Rally Sim

I very rarely mess with web development these days, but the power of current JavaScript engines and latest HTML5 features were just too juicy to pass on.

So sometime around early 2011, I took two afternoons and played with these technologies. Just now I remembered the project I had in hands, and decided I could give it a name and publish it on the net for your personal amusement.

Consider it pre-alpha, and expect bugs! ūüôā



  • Infinite landscape, using procedural generation (how else could I squeeze infinity into a few KBs?), and adaptive terrain features based on play style (namely, how fast you like to drive).
  • Somewhat realistic physics (based on Box2dJS library).
  • Incredibly detailed graphics engine based on WebGL. Nah just kidding, it’s the default HTML5¬†canvas-based rendering provided by Box2D itself…
  • Physically-modelled rolling stones on the driving surface. Framerate suffers too much so they’re disabled by default. To re-enable, dive in the source code and hack away.
  • Tested on major PC browsers, and on Dolphin Browser Mini on Android.


  • right-arrow -> gas
  • left-arrow <- brake

Right now I’m in the middle of a physical home migration so the code is not githubbed yet, but you can access it by clicking the following link:

Quick’N’Dirty Darkar Rally Sim 2011

There’s no purpose as of yet, but you can try to race against the terrain and see how far you last before ending up on your roof or suffering a physics explosion.

License is GPLv3.


Software steadicam – Or how to fix bad cameramen

So you’ve just come back from vacations (wohoo), having filled 10 gigs of photos and video, only to discover you’re a (let’s be honest here) shitty cameraman without your tripod?


Fret not, for this article will show you the secret to solve your problems!


In an ideal world, your hands are as steady as a rock, and you get Hollywood quality takes. In the real world, however, your clumsy hands could use a hand (hah!).

So here’s your two main options:


Hardware solution (for use while filming)

This is the proper solution: a system that will compensate for the vibration of your shaky hands and the movement of your body while walking – not unlike the springs on your car allow for a pretty comfortable ride through all sorts of bumps.

Ideally, it will compensate for all the 6 axis (3D traslation + 3D rotation), but in practice you may be limited to less than that. Unfortunately (for most), this depends on how deep your pockets are (buying a ready-to-use steadicam, ranging from 100 bucks to several thousand), or on how handy you are with your toolbox (building a home-built equivalent).

The result could (in theory) be similar to this:

(ah, yeah… a segway, minor detail)

Software solution (for use after filming):

If you can’t spare a segway + a steadycam backpack, there are affordable alternatives. And if you already have many shaking, blurry videos lying on your hard disk, then this is your only option!

We’ll rely on PC software to fix those videos. This, you can do for free at home. There are some payware software packages that may produce slightly better results: but what I’m going to show you is freeware, very quick to use, and good enough quality for most purposes.

The software method may not be that good when compared to an actual steadicam, but hey, it’s better than nothing!


The steps:

I’m not going to go much into details, so here’s the basics.

  1. Download VirtualDUB, an open source and free video editing software.
    (Make sure you can open your videos. E.g. you may need to install the ffdshow-tryout codecs and set them up, or whatever; Google is your friend! ūüôā )
  2. Once you can open your videos, you have to download the magic piece of the puzzle: Deshaker.
    (This free tool – though unfortunately not open source – will do all the important work)
  3. Now open your video, add the Deshaker video filter, choosing “Pass 1“.
    (If you have a rolling shutter camera (most likely), and know its speed (unlikely), you can also correct it by entering the necessary values in there)
  4. Click OK, and play the video through.
    (This will gather information about motion vectors and similar stuff, in order to find out how to correct the shaking, if present)
  5. Now edit the Deshaker video filter settings again, and choose “Pass 2“. Tweak settings at will, and click OK.
    (A progress window will be visible for just a few moments)
  6. Finally, export the resulting video, and you’re good to go!

For a more detailed guide (including rolling shutter values for some cameras), just read the official Deshaker page, or browse Youtube; there’re some tutorials there too.

The settings basically tune the detection of camera movement, as well as what method will deal with the parts of the image that are left empty after deshaking.

The results:

The video below is an example I’ve cooked for you. Each of the 3 processed videos uses a different combination of settings, and was created in no more than 20 minutes each.

I sticked them all together for your viewing pleasure. The improvement can be easily appreciated!


That’s it. Happy filming! 8)


Bonus track

If you insist on using hardware solutions (good!), here’s a neat little trick that’ll allow some smooth panning (provided you’re not walking):


Zonas horarias, DST, Desplazamientos y otras zarandajas

[¬†Ir a la parte 1 de 2: “Sobre la Hora Universal y los relojes at√≥micos (o qu√© tienen en com√ļn el TomTom y unos trigales)”¬†]

Continuamos desentra√Īando el misterio de las horas, orientando la explicaci√≥n principalmente a programadores.

Hemos establecido qué sistemas de medición de la hora existen. También hemos visto que el estandard de facto es UTC, y por buenas razones.

Y ahora vamos a ver como se pueden representar esas horas en una aplicación.

A efectos pr√°cticos, en este art√≠culo voy a llamar “hora” al conjunto de “fecha+hora“.


Conceptos b√°sicos

Repaso de UTC

Quedabamos en que UTC es una hora universal, que trata de indicar la hora del planeta¬†Tierra en general. No est√° ligado a ning√ļn pa√≠s en concreto, ni a ning√ļn continente, sino al planeta entero: Espa√Īa no tiene horas UTC. Argentina no tiene horas UTC. El planeta Tierra s√≠ que tiene horas UTC.

Si en una hora UTC particular es pleno d√≠a en Espa√Īa, entonces en esa misma hora UTC ser√° noche cerrada en sus ant√≠podas; y ser√° el amanecer o el anochecer si nos quedamos a medio camino entre ambos puntos.

UTC no sufre saltos [*], sino que avanza siempre a una velocidad constante. Porque el planeta Tierra tampoco sufre saltos ni rotaciones bruscas en ning√ļn momento (menos mal :-D).
[*] Técnicamente sí (tiene saltos por debajo del segundo), pero se puede ignorar perfectamente para este artículo.


Hora Local (Local Time)

Los habitantes de este planeta estamos acostumbrados a hablar en t√©rminos locales. Yo, como habitante de Madrid, puedo decir “Me levanto a trabajar a las 07:00”. Un japon√©s, a su vez, puede decir “Yo tambi√©n me levanto a trabajar a las 07:00”. Pero obviamente no hablamos de la misma hora UTC, sino de una hora “local”.

Trabajar con horas locales puede ser complicado, por ejemplo cuando el locutor se desplaza de sitio. Si despegas de Madrid a las 10:00 (hora local madrile√Īa), vuelas 10 horas, y aterrizas en Miami, la hora local de Miami no ser√°n las 20:00, sino otra, que hay que calcular en base a unos cuantos factores.

En cambio, si despegas a las 10:00 UTC, sí que aterrizas a las 20:00 UTC.

Desplazamiento (Offset)

El offset es, literalmente, la siguiente resta matem√°tica: hora localhora UTC.

Por ejemplo: La hora local actual en Madrid es finales de Enero a las 20:00. La hora UTC actual en el planeta es finales de Enero a las 19:00 UTC. Por tanto, 20:00 – 19:00 = 01:00 de offset.

Inciso sobre el Horario de Verano:

El Horario de Verano, como sabeis, tiene como objetivo reducir el consumo eléctrico, tener más luz durante las horas laborales, etc (al margen de que se consigan o no dichos propósitos :-P).

Consiste en mover las manecillas de los relojes locales de un pa√≠s, para atrasar o adelantar la hora local durante unos meses determinados, cada a√Īo.

  • Lo t√≠pico es atrasar o adelantarlo 1h, pero en algunos paises es 30 minutos.
  • Cada pa√≠s lo puede aplicar durante unos meses diferentes: de marzo a octubre, de abril a septiembre… Los d√≠as exactos tambi√©n pueden variar.
  • En muchos pa√≠ses ni siquiera se aplica el Horario de Verano.

En cualquier caso, el offset ya lleva incluído el horario de verano cuando se usa, puesto que el offset se obtiene restando la hora local (que ya lleva aplicado el cambio horario) y la hora UTC.

Otro ejemplo: En Agosto de este a√Īo se habr√° aplicado el horario de verano en Madrid, por lo que el offset no ser√° 01:00h sino 02:00h.

El offset de una localizaci√≥n geogr√°fica puede variar tanto a lo largo de un mismo a√Īo, como hemos visto, pero tambi√©n a lo largo de varios a√Īos. Por ejemplo:

  • Antes del 1901, cada provincia espa√Īola ten√≠a su propia hora local, en base a su meridiano concreto. Ahora ya no.
  • En el 1918, en Espa√Īa se decide empezar a aplicar el horario de verano, que nunca antes se hab√≠a utilizado. El offset ya no es el mismo todo el a√Īo, sino que aumenta 1h en verano (como en el presente).
  • El 16 de Marzo de 1940, Espa√Īa decide incrementar todos sus relojes en una hora: el offset pasa de 0h a 1h en invierno, y de 1h a 2h en verano. (se ha cambiado la zona horaria, que explico m√°s abajo)
  • Si varios paises con diferentes horas locales eliminan sus fronteras pol√≠ticas para unirse en un solo pa√≠s, seguramente modifiquen sus horas locales para coincidir en todo el territorio (variando por tanto el offset).

Por tanto, es perfectamente posible que dos pa√≠ses tengan el mismo offset durante algunos meses del a√Īo, pero difieran durante otros.

Dicho de otra forma: a partir de un offset, no se puede deducir en qu√© localizaci√≥n te encuentras, ni por tanto qu√© otros offsets existir√°n en otros momentos del a√Īo.

Por ejemplo: Si no sabes si tu +01:00h actual es de Madrid o del Congo, no puedes saber si en Agosto ser√° un +02:00h (caso de Madrid), o se mantendr√° en +01:00h (caso de Congo, sin horario de verano).


Zona horaria (Time Zone, o TZ)

Se dice que varias poblaciones est√°n en una misma Zona Horaria, cuando desde el a√Īo 1970 han compartido siempre¬†la misma hora local. La nomenclatura es “Area/Localizaci√≥n”.

Mapa de todos los TimeZones

No hay que confundir con los husos horarios, meridianos ni offsets. Son conceptos diferentes: “UTC+02:00” no es realmente una Zona Horaria, es un Offset respecto de UTC.

Por ejemplo: En Espa√Īa, desde el 1970 hasta ahora, han existido tres regiones que no siempre han compartido completamente las horas locales en todo momento. Las tres zonas horarias (o TZs) son:

  • Europe/Madrid: para la pen√≠nsula y baleares principalmente.
  • Atlantic/Canary: para el archipi√©lago canario.
  • Africa/Ceuta: para Ceuta y Melilla.

Actualmente, esas 3 timezones usan horario de verano, por lo que actualmente sus offsets respectivos de invierno son 1h, 0h y 1h; y los de verano 2h, 1h y 2h.

Cada TZ ha tenido un pasado diferente: algunos aplicaron el horario de verano durante 20 a√Īos, otros no lo aplicaron; unos tenian un offset de 5h, otros de 10h, etc.

Toda esa información se almacena en lo que se llama tz database (en castellano, base de datos de zonas horarias).

La tz database¬†debe ser actualizada constantemente, reflejando los cambios horarios que se pueden producir a lo largo de los a√Īos.


Empieza el meollo de la cuestión

Una vez que conocemos los conceptos básicos, podemos pasar a la acción:

¬ŅEn qu√© me influye todo eso a la hora de dise√Īar mi software?

¬ŅC√≥mo gestiono las horas correctamente?
¬ŅY si mi usuario vuela de Espa√Īa a la India y cambia el reloj de su portatil?
¬ŅY si mi usuario quiere introducir la hora local de despegue y la hora local de aterrizaje en mi software de calendario?
¬ŅY si mi software tiene varios usuarios simult√°neos en diferentes zonas del mundo?

Una política habitual en el mundo de la programación es:

Almacena y procesa globlamente, muestra localmente“.

Dicho de otra forma: elige un formato neutro¬†para almacenar y operar sobre los datos, y preoc√ļpate de las particularidades culturales cuando debas mostrar o recoger los datos de un usuario final.

Recordemos que en este post se usa la palabra “hora” como abreviaci√≥n de “fecha+hora“.


“Almacena y procesa globalmente”

Empecemos con un ejemplo sencillote:

Tenemos una variable tipo entero, cuyo valor es 7 millones.
  • El ordenador almacena y opera globalmente. Concretamente, usa el binario:¬†00000000011010101100111111000000.
  • En cambio al mostrarlo en una hoja de c√°lculo, nos puede mostrar¬†“7.000.000“, o bien “7,000,000“, o tal vez “7e6“, o incluso “######“, seg√ļn el contexto local (d√≥nde vivimos, tama√Īo de la celda, formato del n√ļmero…).
De igual forma, la práctica apropiada suele ser almacenar y operar en Hora UTC, y mostrar en Hora Local.
Y no es porque sea conveniente, sino que muchas veces adem√°s es necesario. Por ejemplo:

Tenemos una Hora Local, las 15:00 de un d√≠a de Enero. Se le quiere sumar casi medio a√Īo (24h*180d√≠as=4320h) a esa hora. ¬ŅCu√°l ser√° la Hora Local resultante?:

  1. Las 15:00 hora local, como en la hora de partida.
  2. Las 16:00 hora local, porque hay que aplicar el Horario de Verano.
  3. Ninguna de las 2 anteriores.
  4. Cualquiera de las 3 anteriores.

Y la solución es 4) Cualquiera de las tres anteriores, puesto que depende de la zona horaria:

  • En el Mosc√ļ actual o el Madrid del a√Īo 1910, no hay horario de verano, luego ser√≠a 1) Las 15:00.
  • En el Madrid actual hay horario de verano, luego ser√≠a 2) Las 16:00.
  • En la Isla de Lord Howe hay horario de verano de 30m, en vez de la hora t√≠pica, luego ser√≠a 3) Las 15:30.

Queda claro entonces¬†que la √ļnica forma de operar correctamente con horas es pasarlas a UTC, operar sobre ellas y finalmente (si hace falta), convertirlas a la Hora Local de nuestra elecci√≥n para mostr√°rselo al usuario final.


“Muestra localmente”

Hemos establecido que, para la interfaz con el usuario final, necesitamos conversiones de UTC a Hora Local (al renderizar en pantalla) y viceversa (al aceptar datos del usuario)

Si habéis entendido perfectamente todo lo explicado hasta hora, se pueden deducir cuáles son las posibles conversiones inequívocas que podemos hacer:

Para conseguir esto...:...puedes usar esto:
Hora LocalUTC con TZ del usuario
Hora LocalUTC con Offset del usuario en esa hora y lugar
UTCHora Local con Offset del usuario en esa hora/lugar
UTCHora Local con TZ del usuario -- Imposible
Dos aspectos a destacar son:

a) Almacenar el offset no vale para mucho

Un offset solamente es v√°lido para una hora concreta del a√Īo, en un lugar concreto del planeta.
Tal y como se explicó antes, en la sección de Offset: si solamente conocemos el Offset para una Hora Local, no podemos averiguar mágicamente a qué lugar (TimeZone) pertenece esa Hora Local.
Y por tanto, tampoco podemos calcular autom√°gicamente el offset que habr√° en otros momentos del a√Īo (o lo que es lo mismo, la Hora Local en otros momentos del a√Īo). Para ello necesitamos¬†el TZ; no queda otra opci√≥n posible.
As√≠ que en vez de almacenar, Hora Local + Offset, bien podr√≠amos almacenar √ļnicamente el UTC a secas.

b) El usuario debería poder especificar el offset al introducir una hora

Como veis en la tabla, la unica forma inequívoca de que el usuario introduzca una hora, es indicar también el offset de alguna forma.
Por ejemplo: si el usuario introduce la Hora Local “02:30”, necesitamos saber a cu√°l de las dos posibles “02:30” existentes se refiere (en caso de existir horario de verano en ese lugar).
Existen muchas formas de hacerlo:
  • Un checkbox con el que marcar si la fecha va con DST o no.
  • Una dropdown con 25 o 23 elementos (horas), en vez de los 24 habituales.
  • Una mensaje de pregunta que √ļnicamente saltar√° cuando se d√© el caso de una hora ambigua.
  • Etc.
Por ejemplo, esta es una forma que aconseja Microsoft si se utiliza su framework de .NET:  MSDN РHow to let users resolve ambiguous times


Si no se da esa opci√≥n al usuario, el sistema inform√°tico deber√° resolver la ambig√ľedad de forma arbitraria.¬†Que en funci√≥n del caso concreto, puede ser algo perfectamente aceptable (aunque siempre mejorable).


Con esto terminamos la segunda y √ļltima parte del temario.
Espero que hayais conseguido leer y entender hasta este punto, y no est√©is aqu√≠ unicamente porque os haya llamado la atenci√≥n eso de “ult√≠logo” ;-).
Con suerte el artículo ha sido de ayuda y os evitará bugs y quebraderos de cabeza en un futuro.


Happy coding!

[¬†Ir a la parte 1 de 2: “Sobre la Hora Universal y los relojes at√≥micos (o qu√© tienen en com√ļn el TomTom y unos trigales)”¬†]


Sobre la Hora Universal y los relojes at√≥micos (o qu√© tienen en com√ļn el TomTom y unos trigales)

[¬†Ir a la parte 2 de 2: “Zonas horarias, DST, Desplazamientos y otras zarandajas”¬†]

Con este ladrillazo de artículo intento esclarecer unos cuantos detalles sobre esos grandes desconocidos que son UTC, GMT y demás acrónimos indescifrables.


Obligatory disclaimer: Intento dar una explicaci√≥n inteligible, no algo 100% teńánicamente correcto. En parte porque… bueno, tampoco soy aqu√≠ un experto en la materia ;-). Tanto mis fuentes como mi interpretaci√≥n pueden ser err√≥neas. As√≠ que si algo canta, os ruego dej√©is un comentario para corregirlo.



TAI es una medición del tiempo, independiente del planeta Tierra, del sistema solar, y de cualquier astro en general. Está basada en relojes atómicos.
Empezó a medirse en el 1972, y es completamente independiente de cualquier otro sistema de medición.

Si el d√≠a de ma√Īana cae un meteorito que ralentiza el giro del planeta, haciendo que los d√≠as duren 3 minutos extra desde ese momento, al TAI se la trae floja. ūüėÄ

Actualmente el TAI lleva un desfase acumulado de m√°s de medio minuto (porque la Tierra ha ido ralentiz√°ndose desde 1972).



No, no aceptamos la hora de un Casio como UT.

UT es una medición del tiempo, conforme al planeta Tierra. Por tanto, UT varía si el comportamiento de la Tierra varía.

Ejemplos: movimientos de placas tectónicas, terremotos, el susodicho meteorito de los dinosaurios, mareas por la Luna, o por si al Sol, Saturno y Jupiter les toca alinearse, etc.

El UT puede medirse de muchas formas diferentes. Ninguna de ellas se puede dar como Verdadera ™ realmente, porque la Tierra ni siquiera es una esfera, y esto de “la hora del d√≠a” es una invenci√≥n humana al fin y al cabo.

Existen unos cuantos de esos métodos de medición: UT0, UT1, UT1R, UT2, UT2R, y UTC (para más info: UT Versions).




Evolucion del DUT1 a lo largo de los a√Īos

  • UTC, en concreto, usa una especie de media entre varios relojes at√≥micos situados en diferentes puntos del planeta (por efectos relativistas que no vienen al caso)
  • UT1, por su parte, usa fuentes “externas” (como cu√°sares, posiciones de sat√©lites, etc) para intentar medir el UT. Se suele considerar como la¬†mejor¬†t√©cnica¬†de las existentes. Aunque es algo subjetivo, claro est√°, y depender√° de la aplicaci√≥n.
  • Al offset que acumula UTC respecto a UT1, se le denomina¬†DUT1.


Por definición, UTC debe mantener el DUT1 por debajo de 1 segundo.


Este a√Īo 2012, el DUT1 anda muy cerca del segundo, por lo que en Junio el UTC sufrir√° un salto para corregir ese DUT1 excesivo. A eso se le llama leap-second.

Los ordenadores se suelen sincronizar via NTP con un proveeder de UT basado en relojes atómicos (UTC), de ahí que se use tanto el término UTC en computación.

Si quitas todos los leap-seconds que ha habido, UTC se convierte efectivamente en TAI.

Esto es un cuasar, por si te lo estabas preguntando.


GMT es lo que se usaba antes de establecerse los UTs actuales para medir el tiempo del planeta Tierra. En el 1972, se decidi√≥ pasar a llamarlo “UT”, sin m√°s, as√≠ en general. A veces GMT se refiere a UTC, a veces a UT1, y a veces a lo que usaban antes del 1972 (observaciones √ļnicamente desde el meridiano de Greenwhich).

Adem√°s, GMT es una zona horaria usada como referencia para otras. Por ejemplo, GMT (√≥ GMT+0), es usada en ciertas √©pocas del a√Īo por UK.

No solo eso, sino que el viejo GMT tuvo varias definiciones: inicialmente se pon√≠a la “hora cero” al mediod√≠a (muy usada por astr√≥nomos, y ahora llamada GMAT), y m√°s tarde, a la noche. El cambio se produjo al pasar del a√Īo 1924 al 1925. Ese a√Īo Diciembre no tuvo 31 d√≠as, sino 31.5 d√≠as.

Resumiendo, tenemos unas cuantas acepciones de GMT:

  1. Sistema previo al 1924 (basado en mediodía, también llamado GMAT)
  2. Sistema entre 1924 y 1972 (basado en medianoche)
  3. Sistema posterior al 1972 (UT1).
  4. Sistema posterior al 1972 (UT1+DUT1, es decir, UTC).
  5. Zona horaria de algunos países.
  6. Otras posibles acepciones (cualquier otro UT) en fechas posteriores a 1972.

Efectivamente: al explicarlas, las siglas GMT suelen ir acompa√Īadas de las siglas WTF.

Por todo ello, GMT se puede usar en entornos informales (peliculeros, noticiarios, o lo que sea). Pero en entornos computacionales, militares, médicos, aeronáuticos, y cualquier otro que sea crítico, lo mentalmente saludable es usar siempre algo como UTC.


TomTom y los trigales

"En la próxima rotonda, tome la tercera salida hacia el primer trigal que vea"

En realidad esto de los trigales lo hab√≠a puesto por atraer un poco la atenci√≥n (¬Ņ¬Ņha funcionado??), pero ya que estamos, habr√° que explicarlo…

El GPS como sab√©is, utiliza sat√©lites. Concretamente, utilizan much√≠simo las mediciones de tiempo para poder estimar la posici√≥n y altitud. Es imperioso que todos los GPS funcionen en un marco horario com√ļn, o sino los delicados c√°lculos de vuestro TomTom no valdr√≠an para nada.

Usar UTC no es muy serio, por el tema de los leap-seconds. UT1 tampoco es especialmente √ļtil, porque cambia continuamente, seg√ļn cambia el planeta Tierra.

Así que los GPS usan su propio sistema, el GPS-Time. GPS-Time es idéntico al TAI mencionado al principio del post, pero tiene un offset constante de unos 19 segundos. Esto se debe a que el GPS-Time coincidía con UTC en el momento de su creación (en 1980), pero no avanza a la velocidad de UTC, sino a la del TAI.

Si el GPS-Time tuviera una velocidad variable como cualquier UT, entonces sería facil que el navegador del coche acabara situándote 100 metros más allá de donde realmente estás, plantándote en medio de una pradera, o en el fondo de un lago.

As√≠ que, por suerte para los conductores, el TomTom y los trigales tienen pocos puntos en com√ļn.


Zonas horarias, DST

¬ŅCre√≠ais que empezabais a entender el tema?

Pues olvidaos, porque a√ļn falta todo el tema de zonas horarias y DST, que es la verdadera miga del asunto en lo que a programaci√≥n se refiere.

Y eso que no se han tocao apenas temas tangenciales, como pueden ser los meridianos de referencia, las horas m√©tricas, las horas decimales como la Internet Time¬†de Swatch, el protocolo NTP con sus stratums…


Pero lo dejo ahi, porque bastante gordo ha quedado ya el post!


[¬†Ir a la parte 2 de 2: “Zonas horarias, DST, Desplazamientos y otras zarandajas”¬†]


Surfing the electromagnetic waves – Debugging IEEE 802.11 with Wi-Spy

Some months ago, when I moved to this house, I found it was pretty difficult to get any WiFi device to connect to my wireless home network. Recently I tried debugging it, and these are the results…


Finding a proper WiFi channel

Finding an appropriate WiFi channel is part of the usual initial setup. Some routers and APs can choose channels automatically, but that’s not my case, so I had to resort to third party applications.¬†One of my favourites is Wifi Analyzer for Android, which looks like this:

Wi-Fi Analyzer for Android

You can see what channels are used by which networks, and so the less used channels can be easily spotted. In my case, I decided to go for channel 10, which was pretty much free.


I tested Wi-Fi networks with 2 different routers, 1 dedicated AP, 2 Android phones, 1 iOS device, 1 laptop and 2 netbooks. Some specific combinations of them seemed to work, but most of them didn’t, sometimes even if they were in the same room as the access point.

How could this be?


Extending Wi-Fi range with WDS

First of all, I thought that the thin room walls might be thicker than I initially supposed. Therefore, I decided to put an AP in each of the two rooms I wanted to wirelessly link together.

One of the easiest ways is to use a Wireless Distribution System (WDS). You set up each of the two APs with the other’s MAC address, do some reboots, and off you go.

Extending Wi-Fi range with WDS

However, simple ping tests demonstrated I was still having a packet loss as high as 40%. Even if the APs were just a meter and a wall away from each other!

Extending Wi-Fi range with FEC

RJ45So the next option was to get a stronger signal in the other room, not with WDS, but using a Freaking Ethernet Cable. Once I got hold of a 10 meters cable, I plugged an AP at the end of the cable, in the other room.

To my dismay, it was barely possible to get a MacBook Pro to connect to the AP. There was a distance of 50 cm between the two!

So apparently, the wireless signal was being lost inside the room, and not due to the wall (this quickly ruled out the possibility of my walls being built of a thin layer of pure lead….).


Checking for electromagnetic interferences

Next up, and thinking it could be some sort of EMI, I decided to get help at the mailing list where the local computer geek^H^H^Hurus hang around, the e-ghost. A few emails later, and thanks to the kindness of¬†@txipi, I was holding a USB ÔĽŅ2.4GHz spectrum analyzer on my hands.


The Wi-Spy 2.4i is a nice piece¬†of hardware, with a similar functionality to the WiFi Analyzer program mentioned at the beginning of this article. Main difference being, it can detect¬†all kinds of EM signals (not just those identified as wifi networks). For example, it’ll pick up signals coming from bluetooth devices, wireless security cameras, microwave ovens, baby monitors, etc.

There’s some tools for linux, which can be installed with¬†sudo apt-get install spectools, and look like this:

Wi-SPY spectools for Linux

There’s also native software for Windows in the Wi-Spy CD which I sadly had to use, since I couldn’t configure the timescale of the spectrographs on linux spectools.

Once the software was correctly set up, I disabled my 802.11 network completely, and started logging data. Here’s the spectrograph for a period of about 30 non-continuous hours:

2.4GHz spectrograph

(click to zoom)

Vertical axis is time, horizontal axis is the frequency (wifi channel numbers are shown at the bottom for your convenience), and color axis is the maximum signal power.

Analyzing the 2.4GHz spectral graph

Several interesting patterns emerge from the graph:

First of all, there’s these red-yellow dots all over the spectrograph. They seem to represent network scans made by wifi devices every once in a while. The pattern can be consistently repeated by turning the WiFi of any device OFF and then ON; or by simply trying to refresh the list of networks.

Then there’s the prominent vertical patterns hovering around channels 1, 2 and 3. These obviously represent other existing WiFi networks around my house. There are other similar vertical patterns that cannot be easily appreciated with the color coding in this graph, but they’re logically low signal and won’t interfere much anyway.

Finally, there’s the massive¬†horizontal patterns that appear from time to time. They use up varied frequencies, ranging from two channels, to almost all of the 802.11 spectrum. To make matters worse, the signal is very strong when present. The duration can range from a few minutes, to well over an hour straight.



I suspect it is this last type of interferences which makes my WiFi connectivity act so erratic. Sometimes, all my devices will connect just fine, but sometimes it’s impossible to connect even 10cm away from the AP.

It’s possible that a Police station located half a kilometer away (with¬†direct line-of-sight)¬†produces it, or maybe it’s the hardware of some¬†neighbors. Building a huge Faraday cage is unthinkable, and hopping from channel to channel has proven useless, so I guess I’m irrevocably¬†stuck with wired conections until I move to another house.

On the bright side, debugging these WiFi issues surely has been an interesting fun ride ūüôā

Since I am by no means an expert in telecommunications, any further explanations or corrections are more than welcome. Feel free to use the comments box below!


Mad oversteer

Some old vids in which I’m just the wheelman. Thanks to Darth Joules and Geert, the simracers who did the video capturing and editing (my crappy 1k ghz putter couldn’t handle all that stuff, 30 constant FPS was already a great achievement), and of course thanks to Eero Piitulainen for the excelent RBR physics (hope to see another physics engine of yours soon…).

Ahora lo que es en castellano: un par de viejos videos, de cuando sol√≠a quemar rueda (virtual) semanalmente, en este caso con RBR. ¬†Gracias a Darth Joules y Geert por la captura y edici√≥n, y Eero por el brutal motor f√≠sico que program√≥ a contrarreloj para SCi y que a√ļn hace vibrar a la comunidad. Una pena que el c√≥digo se haya perdido en el limbo legal gracias a los 6 a√Īos de abandono, los Ferraris de dudosa legalidad estrellados, la mierda que salpic√≥ a Warthog Studios por sus relaciones con cierta mafia sueca de blanqueo, las detenciones de algunos CEOs y los consiguientes enchironamientos, y weno… mejor no seguir que escribo un libro ūüėÜ

Richard Alexander Burns

January 17, 1971 – November 25, 2005



No, esta vez no es 42

Por fin, tras varias semanas lo he localizado! Se trata de un relato de Asimov, de esos que te hacen pensar en el sentido de la vida. Un relato que deber√≠a de leer m√°s de un pol√≠ticucho, para darse cuenta de lo est√ļpidamente oximor√≥nico que es su famoso palabreo sobre “crecimiento sostenible” (entre otras cosas).

Por si a alguien le molan estas comeduras de tarro, tengo otro relato rondándome la cabeza (relacionado con multiversos, detección de mundos virtuales desde dentro de uno, y chorradas similares), pero hoy estoy un poco paleto con google y no lo encuentro. Quizás en otro post.

Mientras tanto os dejo con…


...y se hizo la luz.

(por Isaac Asimov)

La √ļltima pregunta se formul√≥ por primera vez, medio en broma, el 21 de mayo de 2061, en momentos en que la humanidad (tambi√©n por primera vez) se ba√Ī√≥ en luz. La pregunta lleg√≥ como resultado de una apuesta por cinco d√≥lares hecha entre dos hombres que beb√≠an cerveza, y sucedi√≥ de esta manera:

Read the rest of this entry »


Nope, not 42 this time

At last! After several weeks of search, I’ve finally found it: it’s a short story writen by Asimov. One of those that make you ponder about the meaning of life. A story that should be read by many a politician, in order for them to realize how moronically oxymoronic it is to talk about the so called “sustainable development” (amongst other things).

I have another brain melting story waiting in the chamber, in case someone cares. It explores the idea of multiverses and how to detect nested virtual worlds. Unfortunately, I’m a bit thick with google today, so I’ll leave that for a different post.

Meanwhile, you can discover the answer to…


...y se hizo la luz.

(by Isaac Asimov)

The last question was asked for the first time, half in jest, on May 21, 2061, at a time when humanity first stepped into the light. The question came about as a result of a five dollar bet over highballs, and it happened this way:

Read the rest of this entry »


Now that’s [super]cool!

Estaba yo en mi habitaci√≥n estudiando para el examen de ma√Īana de eso (estructura de sistemas operativos), cuando mi est√≥mago empez√≥ a lanzarme indirectas para que le diera de comer. Me he dirigido a la cocina a por algo de papeo, acompa√Ī√°ndolo con un refresco.

Como hoy es un d√≠a jodiamente caluroso (picos de 35¬ļ o as√≠, segun me informaba mi querido wmweather), he ido a por unos pocos cubitos de hielo.

Mi frigor√≠fico es normalucho. No tiene televisi√≥n integrada, ni cafetera, ni congela agua al vuelo, ni lo tritura, ni me hace los deberes. Amos, que es tradicional: rellenas el template de cubitos con un poco de agua, esperas unas horas y listo. A que mola..? ūüėõ

Pues weno, yo había puesto los hielos hace unas 3 horas, así que he ido a comprobar si estaban ya helados mediante la avanzada técnica consistente en la medición de la fuerza normal ejercida por el fluído-sólido al intentar ser atravesado por mi dedo índice.

Por desgracia la mayoría de los cubitos eran todavía agua. Pero nada más sacar el dedo del template, el cubito de agua en cuestión ha empezado a convertirse en un cubo de hielo en cuestión de segundos, cual T1000 transformándose. Este efecto no es otro que el comunmente denominado superenfriamiento, en inglés supercooling. Algunos os preguntaréis a ver qué carajo es eso. He aquí una demo que he robado impunemente de la web de uno al que le ha pasado lo mismo:

Me ha sorprendido bastante, no por ser algo nuevo (ya había leido sobre el tema hacía unos meses), sino porque creía que las condiciones necesarias para que se diera el supercooling eran muy estrictas, y por tanto dificiles de conseguir por azar. O tal vez lo mío ha sido simplemente potra!

En cualquier caso, os invito a que lo prob√©is. Y a ver si alguien consigue que su dedo se quede congelado dentro tambi√©n :P. Yo lo he intentado, pero solamente se congelaban las esquinas del cubito, quedando mi dedo rodeado por una capa de agua. Una pena. Imagino que har√°n falta algo m√°s grande que cubitos de hielo, as√≠ que ya sab√©is como mejorar el experimento ūüôā

Por cierto, tambi√©n existe el supercalienting, pero en ese caso no recomiendo a nadie que pruebe lo de meter el dedo, que igual sal√≠s escaldaos ūüėČ