Archivo de la etiqueta: 3g

Liberar modem 3G Huawei E220 de Vodafone

Facilísimo. Y de paso, al actualizar el firmware, lo dejamos preparado para soportar 7,2Mbps. Este es un proceso delicado ya que si se corta a mitad la instalación del firmware se pierde el modem para siempre, hazlo bajo tu responsabilidad. Hay muchos sitios por ahí donde lo cuentan, yo os lo resumo :).

Desinstalamos completamente el software de Vodafone (o de cualquier otra operadora) y descargamos dos paquetes de actualización, el del firmware en sí mismo y el del software del del modem, ya que no queremos que siga cargando los de Vodafone.

  • El firmware te lo doy yo :P.
  • Para el software vas aquí y escoges el que prefieras:
    • El primero, HOSTB107D05SP00C03…, instala el Mobile Connect.
    • El último, UTPSB002D03SP16C03…, el Mobile Partner.

Yo me quedo con el Partner, me parece más sencillo e intuitivo.

Además necesitarás el Qmat (QC Mobile Analysis Tool) y esto otro.

El procedimiento es muy simple. Conectas el modem y cancelas la instalación de los drivers. A continuación ejecutas los dos archivos de actualización, firmware y software. Entre uno y otro (y al terminar el segundo también) conviene desconectarlo y volver a conectarlo (cancelando nuevamente la instalación de los drivers de Vodafone). Ya casi hemos terminado :P.

Instala ahora el Qmat y ejecútalo. En el menú superior ve a Hardware Forensics y Use Mobile Ports.

forensics

En la ventana que aparece seleccionas, en el primer combo, el puerto donde está tu modem, no tiene pérdida, pondrá algo parecido a COMxx – HUAWEI Mobile Connect – 3G PC UI Interface (COMxx). Pulsas en «Send» y deberían salir unos números en la caja de texto de abajo, eso quiere decir que se comunica correctamente con el modem.

En el combo que muestro desplegado en la imagen de abajo seleccionas «Display NVItem» y a la izquierda, en «Item» introduces 1156 y pinchas en «Let’s go«. Si todo va bien en la ventana de texto aparecerán unos números y, al final de todo, un código de 6 a 8 cifras, ése es tu código de desbloqueo. Cópialo. Si tienes algún problema prueba a desconectar el modem y volver a conectarlo o, incluso, a instalar los drivers nuevos cerrando el programa cuando arranque.

qcAhora vamos a la última utilidad, al CardLock_UnLock. Lo abres y te identificará el IMEI de tu teléfono. Pegas en la caja de texto el código que obtuviste en el paso anterior y voilà, el modem está liberado.

unlockLo he probado hoy mismo con SIM’s de Orange y Movistar, aunque la idea es utilizarlo con la de Simyo :). La configuración que hay que utilizar en este último caso es la siguiente:

partner

APN: gprs-service.com
Usuario: (vacío)
Clave: (vacío)
Número: *99***1#

Ya podemos utilizar el modem con la operadora que nos venga en gana.

Como última curiosidad veremos cómo dejar el software en castellano ya que la actualización lo deja en inglés y no podemos modificar los archivos de la memoria del modem. Editamos el archivo C:Program FilesMobile PartnerRunInfo.ini de manera que donde pone:

[language]
active=_en-us

ponga

[language]
active=_es-es

Listo!

Convierte tu móvil 3G en un punto de acceso wifi con JoikuSpot

Hace unos días tuve un problema, necesitaba conectar dos portátiles a Internet simultáneamente pero sólo disponía de un teléfono 3G, así que, o conectaba uno o conectaba el otro. Buscando por Google llegué a JoikuSpot, una aplicación para Symbian que convierte tu teléfono 3G en un router inalámbrico. Sí, como lo has oído, lo mismo que hacen esos routers pero con un sencillo teléfono S60.

Además de la ventaja de compartir la red, me pareció interesante disponer de  un método de conexión portátil/teléfono alternativo y estándar al Bluetooth y al cable USB.

Obviamente este método sólamente sirve para terminales que dispongan de conexión wifi 😛 . En mi caso tengo un Nokia E51 que la tiene, así que es un dispositivo con dos interfaces de red, la wifi por un lado y la conexión dinámica 3G/HSDPA por el otro, lo mismo que un router normal y corriente.

Existen dos versiones de JoikuSpot,  Light (gratis) y Premium (en oferta por 15$). La diferencia fundamental es la cantidad de protocolos soportados. Mientras que con la primera sólamente tienes HTTP/HTTPS, con la segunda tienes prácticamente todos los necesarios para una navegación completa (smtp, pop3, vpn, messenger, skype…). Para el uso que le voy a dar yo me es suficiente con la versión Light, al menos por el momento.

Una vez descargada habrá que configurar el punto de acceso inalámbrico con los parámetros típicos de cualquier router: nombre de la red, canal, tipo de autentificación, clave…

screenshot0003.jpg

Una vez tenemos nuestro punto de acceso wifi bien configurado no tenemos más que iniciarlo, para lo cual nos pedirá qué punto de acceso de datos queremos utilizar para salir a Internet. Seleccionamos nuestra conexión 3G/HSDPA y nuestro móvil ya será un router inalámbrico.

screenshot0001.jpg

En todo momento tenemos información del tráfico y el tiempo de conexión.

screenshot0002.jpg

Ahora podemos buscar la red inalámbrica desde los portátiles. Veremos que en la lista de redes aparece una nueva con el nombre que le hemos puesto al configurar JoikuSpot. Nos conectamos indicando la clave y por arte de magia tenemos conexión a Internet en todos los equipos que se conecten a nuestro móvil.

screenshot0009.jpg

Todo muy sencillo de configurar.

Una alternativa más que útil para emergencias (Noooooo, no funciona Internet) o viajes.

Screenshot

Para los que se estén preguntando cómo hago las capturas de pantalla directamente desde el móvil, os recomiendo Screenshot, una aplicación Symbian libre para realizar capturas de pantalla y que te permite definir la combinación de teclas que dispararán la captura. Llevo utilizándolo mucho tiempo y siempre me ha dado muy buenos resultados.

Conversión de vídeos a 3gpp bajo demanda en un entorno web

Hoy veremos como aplicar conversiones de vídeo en un entorno web donde los usuarios suben sus vídeos en cualquier formato. Sí, tienes razón, ni más ni menos que lo que hace YouTube, de hecho utilizaban un sistema muy similar a lo que veremos ahora y basado en el mismo software. En realidad el artículo se podría aplicar a prácticamente cualquier tipo de conversiones, incluso para iPod o PSP, sólo hay que utilizar los parámetros adecuados. Nosotros nos centraremos en la conversión a 3gp para después poder hacer streaming con ellos además de permitir su descarga.

Nuestro entorno se basará en un servidor con Linux (Centos5 en mi caso). Como software sólamente necesitaremos ffmpeg, herramienta imprescindible para cualquier aplicación (tanto web como de escritorio) bajo Linux.

¿Qué es ffmpeg?

Hace unas semanas veíamos cómo utilizar ffserver para convertir flujos de vídeo y hacer streaming. ffmpeg es la utilidad en la que se apoya ffserver para realizar las conversiones.

ffmpeg es una herramienta de software libre que permite realizar conversión entre la mayoría de formatos de vídeo más utilizados. Una inmensa mayoría de programas de conversión bajo Windows no son más que frontends gráficos para ffmpeg.

Normalmente los paquetes precompilados de ffmpeg no vienen con las extensiones adecuadas para las conversiones que necesitamos, así que deberemos compilar nuestra propia versión.

Necesitas instalar los siguientes paquetes, son más de los imprescindibles, pero así nos ahorraremos problemas futuros:

libmp4v2
libvorbis
libvorbis-devel
lame
lame-devel
faac
faac-devel
faad2
x264
x264-devel
xvidcore
xvidcore-devel

Debo decir que para mi Centos no están todos disponibles como rpm con lo cual habrá que compilar manualmente algunos de ellos. No deberías tener ningún problema para localizar cada librería.

Finalmente habrá instalar los siguientes paquetes:

http://ftp.penguin.cz/pub/users/utx/amr/amrnb-7.0.0.2.tar.bz2

http://ftp.penguin.cz/pub/users/utx/amr/amrwb-7.0.0.3.tar.bz2

Con esto tenemos ya todo preparado para compilar nuestro propio ffmpeg. Descarga el paquete desde la web oficial, descomprímelo y:

./configure --enable-libmp3lame --enable-libvorbis --enable-libogg --enable-libamr-nb --enable-libamr-wb --enable-libfaac --enable-gpl --enable-libxvid --enable-libx264 --enable-libfaad --enable-shared
make
make install

Si has seguido bien todos los pasos tendrás el software de conversión preparado.

Convirtiendo a 3gp

Para realizar las conversiones algo tan sencillo como:

ffmpeg -y  -i original.avi -s qcif -r 12 -b 30 -ac 1 -ar 8000 -ab 12200 video.3gp
/usr/local/bin/MP4Box -3gp -mtu 1450 -hint video.3gp

Cuando vimos cómo hacer streaming a móviles veíamos como utilizar la utilidad MP4Box para que nuestros vídeos 3gp se puediesen utilizar para emitir en vivo.

Para nuestro proyecto es probable que necesitemos algo más. Si queremos que también se puedan visualizar los vídeos desde una web necesitaremos convertirlos a flv:

ffmpeg -y -i original.avi -acodec libmp3lame -ac 2 -ar 22050 -r 12 -b 196 -s 176x144 video.flv
/usr/bin/flvtool2 u video.flv

Flvtool es una herramienta que inserta en los flv los metadata necesarios para que funcione bien en el reproductor flash.

Y necesitaremos capturar algún fotograma del vídeo para mostrar como demo:

ffmpeg -i original.avi -y -ss 00:00:01 -vframes 1 -an -sameq -s 160x120 -f image2 thumbnail.jpg

Ahora ya sabemos:

  • cómo crear nuestro vídeo 3gp que nos sirva tanto para descarga como para streaming.
  • cómo crear el vídeo flv que nos sirva para ver vía web.
  • cómo generar thumbnails de escenas del vídeo.

Creando el entorno web

Supongamos que queremos desarrollar una web al estilo Youtube donde el usuario sube vídeos desde un formulario y posteriormente se desea mostrarlos categorizados, con un buscador, una preview (flv), descarga para móviles, etc.

La parte de la web propiamente dicha resulta obvia, no vamos a entrar en detalles. Lo que nos ocupa aquí es como realizar la conversión según las instrucciones que hemos visto. Obviamente no podemos ejecutar la conversión cada vez que un usuario sube un vídeo, sería un proceso lento y pesado. La mejor manera es crear una cola de conversión. Cuando se sube un nuevo vídeo no esta disponible públicamente (no se ha convertido todavía). Podríamos definir tres estados diferentes para un video:

  1. Sin procesar (convertir).
  2. Procesando.
  3. Procesado.

Según esto sería sencillo tener en una tabla el estado de los vídeos. Sólo los procesados se listarían públicamente.

Por otro lado tendríamos una tarea encargada de buscar vídeos en estado «sin procesar» y realizar su conversión. Esta tarea podría ser o bien un demonio residente que está permanentemente buscando vídeos o bien, si el tráfico de nuevos vídeos no va a ser elevado, podría ejecutarse periódicamente para realizar las conversiones.

Si el tráfico fuese muy elevado podría incluso haber varias tareas en paralelo ya que una vez una de ellas encuentra un vídeo «no procesado» actualiza su estado a «procesando» de manera que la siguiente tarea ya no escogerá ese mismo vídeo.

La teoría es mucho más sencilla de lo que parece. La tarea que realiza la conversión creará los formatos que estimemos oportunos según ya hemos visto antes.

Convirtiendo a otros formatos

Con ffmpeg se pueden generar los vídeos para casi cualquier formato existente incluyendo PSP, iPod/iPhone/iTouch… Googleando un poco encontrarás los parámetros adecuados para cada formato.

Conclusiones

En este artículo he explicado cómo realizar conversiones de vídeos a distintos formatos y cómo aplicarlo a un entorno web dónde los usuarios suben sus propios vídeos. He dado los pasos básicos para entender el sistema, vosotros tendríais que adaptarlo a vuestras necesidades.

Las operadoras móviles y el control de Internet

Hace algo más de un año saltaba la noticia: Vodafone UK había implantado un proxy-transcoder en su red de datos de manera que todas las conexiones de sus clientes pasaban por este sistema. Con la excusa de hacer accesibles a todos los terminales cualquier página web ya existente, modificaban completamente el aspecto de la misma, añadiendo publicidad, accesos directos a Vodafone Live! y lo que es peor, modificando las hojas de estilos de los portales, con lo que tu trabajo perdía su apariencia original.

El movimiento internacional dentro del sector fué considerable. Gente como Andrea Trasatti o Luca Passani, verdaderos gurús de la adaptación, se revelaron contra la medida. Mucha gente lo criticó.

El problema no era sólo la apariencia de los portales, eso es lo que se veía directamente, el problema serio era (es) que se estaban cargando uno de los conceptos básicos de la adaptación para móviles: el UserAgent. Aunque existe en todos los navegadores web, el UserAgent cobra especial importancia en un dispositivo móvil ya que lo identifica, te aporta información sobre marca y modelo del mismo con lo que, con una buena base de datos de terminales (por ejemplo wurlf), puedes obtener compatibilidades (vídeo, mp3, mms…) y tamaños de pantalla. Al eliminarse el UserAgent se eliminaba la posibilidad de ofrecer contenido compatible con ese terminal. Pensemos en los juegos Java para móvil donde es imprescindible saber qué modelo tiene el cliente puesto que hay que darle un archivo compilado para ese mismo.

Después de algunas protestas, desde Vodafone UK decidieron enviar el UserAgent del teléfono original pero en una cabecera HTTP distinta, con lo cual tendrías que modificar TODOS tus desarrollos por culpa de esta maravillosa idea.

Finalmente se sacaron de la manga dos soluciones al transcoder:

  • Si tu dominio es .mobi no modifican el contenido ya que asumen que YA es contenido optimizado para pequeños dispositivos.
  • Una whitelist donde, si enviabas tus dominios, dejaban de filtrarlos y adaptarlos.

En realidad no sé si el segundo método llegó a funcionar alguna vez. El primero sí.

En octubre del año pasado llegaba la debacle a España. Vodafone ES ponía el famoso transcoder y todos nuestros portales móviles perdían su look&feel además de verse modificados para incluir todos los enlaces directos de Live!. También tuvimos voces de alarma.

Aquí el problema fue peor, nunca llegaron a enviar el UserAgent original. No sé si ahora lo hacen, pero en su momento no lo hicieron. Esta medida de Vodafone hizo mucho daño al sector.

Hoy, casi un año después, he descubierto, por pura casualidad, que Movistar también tiene el famoso proxy-transcoder, aunque por el momento parece que no hacen un uso abusivo de él. No modifican nada visualmente ni esconden el UserAgent, pero adaptan algunas cosas. Os explico la situación que me tuvo loco durante dos días.

Preparando un portal para una importante promoción me encontré con que en un Nokia N95 las imágenes no se veían al tamaño adecuado. Nuestra plataforma adapta automáticamente el tamaño de las imágenes en función del ancho de pantalla del terminal del cliente (obtenido a partir del UserAgent).  Pues resulta que en el servidor estábamos generando las imágenes correctamente, a 240px de ancho, mientras que en el teléfono se estaban recibiendo a 95px de ancho. ¡Imposible!

Probamos con el mismo teléfono pero con tarjetas SIM de otras operadoras y voila, funcionaba a la perfección. Finalmente pruebo con otros terminales y descubro que, en efecto, están adaptando las imágenes, imagino que para reducir el tráfico de red y optimizar el ancho de banda. El problema del N95 es que, por alguna extraña razón, lo tienen mal configurado en su base de datos de terminales  y, en vez de ponerle el tamaño real de pantalla que tiene (240×320), le han puesto 95px de ancho, incluso a lo mejor es el tamaño por defecto que devuelve el transcoder si no existe ese terminal en la base de datos, razón todavía peor, el N95 es uno de los dispositivos más populares a pesar de su coste.

¿Qué hago ahora cuando  el cliente nos diga que el portal se ve mal en su N95? ¿Se creerá que la culpa es de Movistar?