blogElectronica.com

Hoy en día ya parece claro qué es PoE y la ventajas que significa. PoE, acrónimo de Power Over Ethernet es la posibilidad de llevar alimentación a través del cable Ethernet, facilitando la instalación de múltiples sistemas electrónicos que tienen como interfaz una conexión de Ethernet.  Esta tecnología está estandarizada a través del IEEE 802.3af y IEEE802.3at y hoy en día podemos encontrar electrónica y equipos tanto inyectores o  extractores donde el fabricante ha optado por montar un módulo tipo SilverTel.  Estos módulos son fáciles de integrar requiriendo un mínimo de componentes externos cumpliendo normas y seguridad, y lo más importante hoy en día, a bajo coste.

Esta semana me ha llegado la noticia de SilverTel de unos nuevos módulos que permiten llevar alimentación, hasta 100W a través de un cable CAT5/6 Ethernet,  para la tecnología HDBaseT

¿Y qué es HDBaseT?

Lo primero a saber es que es una alianza formada por los grandes fabricantes de electrónica de consumo:  LG, Samsung, Sony  y Valens.  La idea es promocionar y comercializar el llamado HDBaseT. Esto permite eliminar múltiples cables y conexiones en el hogar y oficinas para que con un calble CAT5/6 podamos conectar ordenadores, televisores, consolas, reproductores multimedia … entre sí, garantizando un ancho de banda de 10.2 Gbps.

No entiendo que ventaja me ofrece esto.

Un ejemplo. Supón que tienes un disco duro multimedia de 1080 Full HD y el televisor a una distancia de 100 metros. ¿Cómo los conectas?

Con un cable CAT5e y ambos equipos habilitados con HDBaseT.

Mola… pero no tengo enchufe donde quiero instalar la tele.

No haría falta buscar un enchufe para ese televisor situado a 100 metros del reproductor multimedia si usamos la tecnología PowerOverBaseT, llamada  POH.

No me creo que la tele se alimente con esto.

Ahora mismo una TV LED de 40” consumo unos 70W, y está el propósito (consorcio Energy Star 6.0) de que todas las dimensiones de pantallas y televisores LCD y LED no lleguen a los 85W.

Estupendo … Y encima ahorro energía. Explícame un poco más que es esto de POH

Basada en la tecnología PoE, la idea es llevar por el mismo cable (CAT5/6) , los datos y la alimentación  a una distancia de máximo 100m. Al igual que en PoE tenemos el equipo que inyecta la alimentación o potencia, PSE y el equipo que es alimentado PD (en nuestro ejemplo, la tele).

Y … ¿no puedo usar PoE? Ya tengo funcionando en casa y en la oficina teléfonos, puntos de acceso con PoE. ¿los tengo que tirar?

No, aquí no se tira nada,  hay compatibilidad. Si conectas un telefono PoE a la red POH, el inyector PSE lo reconocerá y le dará menos tension/corriente para  cumplir con las especificaciones, osea no tienes que tirar ningún dispositivo existente.

¿Lo reconoce? ¿Cómo?

Al conectarse un equipo POE o POH antes de que la fuente PSE de toda la potencia, alimenta con un par de voltios y hay una comunicación entre ellos ya que el equipo habiitado para POE-POH tiene una firma electrónica interna. Si es válida, el inyector aplica después toda la potencia. Si no, evidentemente el equipo no es POE-POH y no aplica tensión.

Vale. Soy fabricante de equipos y quiero ponerle POH. ¿Qué electronica necesito? ¿Por dónde empiezo?

No nos compliquemos. La compañía SilverTel tiene una larga experiencia en módulos inyectores PSE y extractores PoE, PoE+ y PoE Ultra, y acaba de lanzar unos nuevos módulos Ag6600 y Ag5600 compatibles con la norma POH para HDBaseT. Lleva ya 7 años preparándose para POH. Con estos modulos no necesitarás conocer la norma, con un mínimo de componentes tu electrónica estará lista.

Esto parece dirigido al fabricante de televisores….

No es así. Existen otras aplicaciones donde POH tiene un gran potencial y que se necesite alta potencia. Unos ejemplos son etapas de potencia de sonido (a veces integrada en el altavoz), terminales punto de venta con pantalla, aplicaciones de señalización y paneles.  También donde la seguridad de alimentar en CC sea imprescindible.

Espero que os haya gustado. Es un interesante artículo de mi compañero Jesús Santos. Gracias.

Aprovechando que he tenido que probar el interfaz PCM de los módulos Cinterion y de los módulos bluetooth de Bluegiga voy a poner un post sobre ello que será de gran ayuda para quienes quieran desarrollar algún equipo GSM con voz manos libres (vía bluetooth). Lo voy a poner un poco en modo esquemático, de manera totalmente práctico para que no se complique más de lo necesario, que lo es un poco.

Bueno, vamos allá rápido que las manecillas del reloj vuelan y ya es tarde …

1.- Cogemos una placa de evaluación DSB75 donde insertaremos el módulo GSM de Cinterion que queramos usar (un TC63i, un TC65i, un PH8, …). En mi caso tengo aquí montado un TC65i.

2.- Localizamos los pines en la placa de evaluación DSB75 que corresponden a los PINES de audio PCM. Concretamente corresponden al conector x703 de la placa. En ese conector veremos 7 pines: TXDAI, RXDAI, FS, BITClk, FSIN, BCLKIN y GND.

3.- De esos 7 pines necesitaremos sólo 5, que son los que usa PCM. La elección dependerá de si usamos el módulo de Cinterion en modo PCM MASTER o en PCM SLAVE. Si usamos el módulo Cinterion en modo PCM MASTER usaremos los pines TXDAI, RXDAI, FS, BITCLK y GND.  Si usamos el módulo Cinterion en modo PCM SLAVE usaremos los pines TXDAI, RXDAI, FSIN, BCLKIN y GND. La siguiente foto indica como lo he usado yo, en modo SLAVE, conectando unos cablecillos a dichos 5 pines.

4.- Cogemos un kit de desarrollo de Bluegiga, concretamente el más sencillo de usar es el del módulo bluetooth WT32, la razón es que ese kit tiene los pines de PCM disponibles en el PCB del kit de desarrollo. En el PCB de Bluegiga se ve perfectamente donde están los PINES del PCM debido a la buena serigrafía.

5.- Conectamos los pines PCM del módulo GSM Cinterion con los pines PCM del módulo bluetooth WT32 de Bluegiga. Básicamente hay que conectar los pines así:

TC65i  (Slave)    WT32 (Master)

RXDAI             OUT
TXDAI             IN
FSIN                SYNC
BCLK               CLK
GND                GND

¿Cómo? ¿Qué lo quieres al revés?  Venga, te lo pongo, sería algo así: en el caso de que quisiéramos usar el módulo GSM como Master:

TC65i  (Master)   WT32  (Slave)

RXDAI              OUT
TXDAI              IN
FS                       SYNC
BITCLK            CLK
GND                  GND

Bueno, una vez hecho esto ya tenemos todo el hardware conectado. Ahora tenemos que conseguir un pinganillo Bluetooth manos libres. Yo tengo uno de Plantronics, con MAC bluetooth: 00:03:89:a5:a6:72 (la indico porque la usaré después).

6.- El siguiente paso es configurar el módulo bluetooth WT32 para enrutar el audio hacia/desde el interfaz PCM. Para ello lo hacemos enviando al módulo WT32, vía un hyperterminal a 115200,8,N,1 el comando:

SET CONTROL AUDIO PCM PCM

7.- Establecemos la configuración PCM al módulo bluetooth. Debido a la complejidad de las distintas configuraciones de PCM usamos un Excel que proporciona bluegiga. Con este Excel indicamos la configuración que queremos y de esa manera obtenemos de manera sencilla el valor de la PSKEY_PCM_CONFIG32 que necesitamos para configurar el PCM. EN este caso la PSKEY_PCM_CONFIG32 tiene un valor de 0×08400000.

Igual que en el punto anterior podemos configurar la PSKEY mediante un comando desde hyperterminal:

SET CONTROL PCM 08400000 006C

8.- Ahora vamos a configurar el módulo GSM de Cinterion para usar el interfaz digital del audio. Ojo que estos comandos pueden ser distintos en función del modelo que se vaya a usar. Yo lo voy a hacer con un TC65i. Por lo tanto, desde un hyperterminal enviamos:

AT^SAIC=1,1,1,1,1,1

Así configuramos el módulo para usar el audio digital PCM en modo Slave, a 512MHz y Long Frame.

Llegados a este punto ya tenemos configurados tanto el módulo de bluetooth como el módulo GSM. Ahora vamos a probar el audio.

Venga, que ya queda poco !!!!

9.- Desde el pinganillo manoslibres bluetooth (que supongo ya pareado con el módulo bluetooth de Bluegiga) nos conectamos al módulo bluetooth de Bluegiga (pulsando el único botón que tiene para ello).

10.- Seguidamente conectamos físicamente (con un cable serie cruzado) el puerto serie ASC0 RS232 del módulo TC65i con el puerto serie del módulo bluetooth WT32.

11.- Hacemos una llamada GSM de audio desde un teléfono móvil al módulo GSM TC65. Al recibir la llamada el módulo sacará un “RING” por su puerto serie que será recibido por el módulo bluetooth que a su vez informará al pinganillo bluetooth de la llamada entrante (oiremos el típico beep beep de llamada entrante). Aceptamos la llamada con el botón del pinganillo bluetooth.

12.- Una vez hecho eso aceptamos la llamada de voz en el módulo GSM con el comando típico ATA. Si todo ha ido bien en este instante estaremos hablando con nuestro pinganillo manos libres bluetooth, conectado vía bluetooth al módulo WT32 de bluegiga y este a su vez conectado al módulo GSM de Cinterion mediante la interfaz PCM.

Bueno, esto es todo por hoy. Es un post quizás algo complejo de entender si no se tienen los equipos delante, pero ya veréis que si alguna vez necesitáis hacer algo parecido este post os irá de perlas pues os ahorraréis muchas horas de trabajo. A mi mismo me irá bien si alguna vez me tengo que volver a poner con ello, ya que he tenido que hacer el montaje 3 veces a lo largo del tiempo y siempre pienso que no se me va a olvidar el montaje y siempre se me escapa algo. A partir de ahora ya no

Salu2!!!

.

Etiquetas: bluegiga, bluetooth, cinterion, gsm

Si en alguna ocasión has desarrollado equipos dentro de la categoría que podríamos denominar embarcados (equipos para automóviles, autobuses, trenes …) sabrás que uno de los mayores problemas (y los más habituales) son los relacionados con las vibraciones.

El problema se acentúa sobre todo si el dispositivo que estamos diseñando va a utilizar periféricos USB, por ejemplo porque se va a conectar un pendrive de memoria, una cámara de vídeo USB, un módem GPRS-3G, …   A corto y medio plazo, si las vibraciones son intensas, es fácil ver como los dispositivos USB fallan debido a que físicamente se sueltan del conector. No son pocos los desarrolladores que utilizan incluso silicona para fijar los conectores USB y evitar este problema.

Ya sabéis que yo no suelo hablar de conectores pero sí que me gusta comentar de tanto en tanto algunos que destacan por alguna razón especial. Por este motivo hoy os pongo aquí uno de esos conectores que facilitan la vida del ingeniero. Se trata del nuevo conector de la casa Amphenol LUSB-A111-00. Aquí tenéis una foto:

Si os fijáis veréis que el conector USB cuenta con una pestaña en la zona superior. Esa pestaña es basculante tal y como indico con la flecha dibujada, es decir, podemos subirla haciendo presión con un dedo.

Cuando la pestaña está bajada, dos pivotes se anclan en los 2 agujeros de anclaje que tiene el conector de cualquier dispositivo USB. De esta manera ninguna vibración, por fuerte que sea, va a conseguir desconectar el dispositivo USB de nuestro conector. Se necesita una fuerza de 10Kg para soltarlo por lo que la única manera de soltarlo es de forma intencionada.

Pues eso, otro conector interesante para tener en cuenta y evitar así los problemas y disgustos típicos de equipos instalados en escenarios de fuertes vibraciones.

Espero os resulte de interés para algún proyecto. Salu2.

 

Etiquetas: conectores

Hoy voy a poner un artículo que seguro que resulta interesante y curiosos a muchos, sobre todo a quienes estamos trabajando de forma habitual con equipos GSM. Y es que ayer Jueves por fin me llegó a casa un aparatito que compré hace unas semanas únicamente, y que nadie piense mal, para poder probar esta capacidad con la que cuentan los módems de Cinterion y que hasta ahora no había podido probar y me la tenía que creer: el Jamming detection.

Para las pruebas me he basado en la nota de aplicación oficial de Cinterion de nombre “AN_45_Jamming_Detection.pdf”. Ahí tenéis detallada toda la documentación al respecto, yo me voy a centrar en la parte práctica. En cuanto al módem he utilizado un MTX65i de Matrix, que tiene un TC65i en su interior, pero podría haber utilizado otro modelo de MTX o Cinterion, sería lo mismo.

Bueno, sí, vale, ¿pero qué es el Jamming detection?

Pues en pocas palabras es la capacidad que tiene el módem para detectar una interferencia intencionada en los canales de comunicaciones para bloquearlos.

Quizás pienses que no tiene importancia, y seguramente en la inmensa mayoría de aplicaciones GSM así sea, pero en las aplicaciones relacionadas con seguridad, alarmas … sí es bastante importante (o lo debería ser).

Pongamos algún ejemplo. Una casa o un coche que cuente con una alarma típica GSM, una alarma que si salta debe comunicarlo a una oficina central receptora de alarmas GSM.  Pero, ¿qué ocurre si unos maleantes perpetran su acción con un inhibidor GSM? ¿Podrá la alarma GSM comunicarse con la central? ¿Será la alarma al menos capaz de detectar que está siendo interferida con un inhibidor GSM para actuar en consecuencia?

Obviamente ante la acción de un inhibidor GSM suficiente potente ningún equipo (ningún teléfono móvil, módulo GSM/3G, …) será capaz de realizar una comunicación GSM. Pero sí que algunos dispositivos tienen, al menos, la capacidad de detectar que están siendo interferidos por un inhibidor GSM: los módulos de Cinterion. Esta capacidad permite actuar en consecuencia, es decir, si un equipo sospecha que empieza a ser interferido pues puede intentar una comunicación cuando la interferencia es todavía débil, puede pre-activar avisos acústicos etc etc etc. En definitiva, siempre será mejor que un equipo de alarma sepa lo que está ocurriendo a que no lo sepa, el cómo se actúe en esas situaciones ya dependerá de la capacidad e imaginación de quien desarrolle la alarma.

Funcionamiento del Jamming Detection en los módulos Cinterion.

Como decía anteriormente toda la documentación está en la nota de aplicaciones 45 de Cinterion. Básicamente, y muy resumido, consiste en activar el indicador de estabilidad del link de comunicaciones “lsta”, por ejemplo con:

 AT^SIND=”lsta”,1,5

y activar los URCs con:

 AT+CMER=2,,,2

Una vez activamos el jamming (la interferencia) veremos como el módem va indicando la situación  mediante URCs (enviando mensajes por su puerto serie). Primeramente enviará mensajes del tipo:

+CIEV: “lsta”, , ,

indicando que están ocurriendo errores en el link de comunicaciones. “lstaEdv” (que es un contador cuanta atrás) irá decrementando rápidamente hasta llegar a “0″. Mmmm … empieza la sospecha …

Tras este URC el módem nos devolverá otro del tipo:

+CIEV: “lsta”, , , , , ,

Este URC ya indica pérdida de cobertura de Red. Según detalla la documentación de Cinterion, cuando se obtiene un URC con un “lstaNo” = 40, un “lstavar” bajo (inferior a 10) y un “lstaMean” > 40 es indicación clara de Jamming.

Como siempre todo se entiende mejor con imágenes y si es un vídeo pues mejor todavía, por lo que aquí lo tenéis. (Si has recibido el artículo por email es probable que tengas que verlo desde www.blogelectronica.com).

 

Espero que os haya parecido interesante. Otro día más.

Etiquetas: cinterion

Como todos los que trabajáis con los terminales MTX65i ó MTX65+G (o los módulos TC65i ó XT65) sabéis, para grabar / modificar / renombrar / borrar archivos y aplicaciones dentro de los equipos usamos una herramienta de nombre MES que se instala cuando instalamos el entorno de desarrollo eclipse.

Este MES (ojo, no todas las versiones) incluye una serie de utilidades de línea de comandos, es decir, utilidades de consola. Estas utilidades pueden resultar muy útiles para automatizar los procesos de producción, ya que es sencillo automatizar la carga de aplicaciones dentro del módem.

Las aplicaciones de consola que incluye MES son las siguientes:

MESClose.exe
MESCopy.exe
MESDel.exe
MESDir.exe
MESFormat.exe
MESMKDir.exe
MESFormat.exe
MESPort.exe
MESRmdir.exe
MESSearchApp.exe
MESServer.exe
MESXCopy.exe

Antes de usar ninguna de ellas por primera vez, es necesario registrar en el PC la DLL activeX de nombre MESShellExt.dll, por lo que ejecutaremos el archivo del nombre “register.bat” que se encarga de tal misión. Una vez registrada la DLL ya podremos usar las utilidades.

La primera que debemos usar es la de nombre MESPort. Con ella se especifica el puerto COM del PC que quieremos usar. Para ello haremos:

Lee el resto de esta entrada »

Hace unos días hablé del nuevo MTXTunnelv5.0.   Como comenté entonces, este software que pueden montar opcionalmente los módems MTX, permite llevar a cabo multitud de aplicaciones, no sólo una pasarela GPRS-RS232. Hoy voy a comentar cómo utilizar el MTXTunnel v5.0 para controlar relés mediante SMS (es decir, por ejemplo se puede activar/desactivar luces, calderas, … mediante un mensaje SMS).

Como queremos conmutar relés, vamos a suponer que el MTXTunnel5.0 se está utilizando con un módem MTXIND (de Matrix), pues es el único módem de la familia MTX que incorpora relés. Realmente el MTXTunnel5.0 no es que esté concebido para conmutar relés, sino que va mucho más allá, el MTXTunnelv5.0 tiene la posibilidad de ejecutar comandos AT mediante SMS.

¿Y que quieres decir?

Pues quiere decir que ahora vamos a ver cómo conmutar unos relés por SMS, pero que podría usarse el mismo concepto para conmutar una salida digital, leer una entrada analógica o digital, leer la cobertura GSM del equipo, …

¿Entonces quieres decir que para conmutar un relé del módem gsm MTXIND basta con enviar un SMS con un comando AT?

Eso es. El MTXIND dispone de 4 relés llamados RL1,RL2,RL3 y RL7. Estos relés están asociados, respectivamente, a los GPIOs 1,2,3 y 7 del core del módulo, es decir, del módulo TC65i interno que gobierna el MTXIND.

Por ejemplo, si queremos actuar sobre el relé RL1 (relé asociado a GPIO1) bastaría con enviar el comando AT:   AT^SSIO=0,0  para activar el relé  y el comando:   AT^SSIO=0,1   para desactivar el relé. Cuando digo “bastaría con enviar el comando” me refiero a enviar un SMS con el texto “AT^SSIO=0,0″ ó “AT^SSIO=0,1″. Es decir, el fichero de configuración el MTXTunnelv5.0 que nos permitiría gobernar los relés del equipo por SMS podría ser así:

MTX_PIN: 0000    Si la tarjeta SIM no tiene PIN, dejar en 0000
MTX_model: MTX65IND   El modelo MTX escogido es el MTX65IND por los relés
MTX_mode: none    No necesitamos túneles serie-gprs

SMS_allPhones: off   Sólo queremos que puedan actuar teléfonos autorizados
SMS_validPhone1: 666123456  Teléfono autirizado nº 1
SMS_ATEnabled: on   Se aceptan comandos AT por SMS

Lee el resto de esta entrada »

Etiquetas: sms

Muy buenas a todos. Hoy voy a poner un breve post de un nuevo producto que ha llegado a mis manos hace unos pocos días y sobre el cual he empleado un tiempecito en hacer algunas pruebas. Ya sabéis que siempre que puedo comparto aquí en mi blog las cosas (que a mi parecer) pueden ser interesantes.

El producto que voy a comentar es el llamado CDP (ó Cellular Development Platform para quien como a mi no le gusten demasiado las frías siglas). Es un equipo de la empresa Multitech.

 
 ¿Y qué es el CDP?
 
Pues básicamente es una plataforma ARM9 en caja (de metal, muy robusta) con un linux embedded (kernel 2.6.28.x) que cuenta con un módem GPRS ó 3G interno y con portasim integrado, GPS interno, ranura para tarjetas de memoria SD, puerto USB Host, Puerto RS232 y puerto ETH. Como siempre nada mejor que unas fotos clarificadoras.

 

 

 

 
¿Y no tiene GPIOs?
 
Sí, también tiene GPIOs, aunque están en pines compartidos con el conector DB9 del puerto serie, dicho de otra manera, es posible usar las señales DCD, RI, DSR o DTR como E/S.  También dispone de leds (5 en total) en el frontal para ser controlados por parte del usuario.
 
En las pruebas que he hecho he usado algunas  GPIOs sin mayor problema, pues con el SDK se suministran los drivers adecuados para controlar todos los periféricos (GPIOs, RTC (reloj en tiempo real), sensor de temperatura, …)

  Lee el resto de esta entrada »

Etiquetas: ethernet, gateway, gprs, gps, Linux, modem, rs232

Ya está disponible el nuevo MTXTunnel v5.0.

Tras un periodo de trabajo bastante largo por fin está finalizado.    La nueva versión 5.0 trae muchísimos cambios con respecto a la versión anterior MTXTunnel v4.0  (para que os hagáis una idea el manual pasa de unas 20 páginas a unas 210)   Muchas de las prestaciones que han ido sugiriendo los propios usuarios actuales de la versión v4.0 y anteriores las he incluído en esta nueva versión. Cosas como poder controlar 2 equipos con un único módem MTX65i (uno por cada puerto serie), como poder usarlo en escenarios de ultra bajo consumo, comunicaciones UDP (además de TCP), seguridad SSL, DynDNS, Webserver embebido, Telnet, envío de telemetrías (GPIOs y ADCs …), envío de posición GPS, etc etc … forman parte de esta nueva versión. Creo que ha quedado bastante completo.

El manual como digo es extenso, pero he añadido unos 30 ejemplos de configuración para diferentes escenarios. De esa manera a la mayoría de los usuarios les bastará con buscar el ejemplo que más se parezca a lo que quieren hacer y modificarlo un pelín según sus requerimientos. (Es decir, no hace falta leerse todo el manual )

Como es costumbre en todo lo que hago suelo añadir unas FAQ en los manuales para intentar disipar las dudas que me imagino puedan surgir. Estas FAQs del manual del nuevo MTXTunnel 5.0 son las que os pongo a continuación. Espero que las encontréis interesantes. Y ya sabéis, como siempre, cualquier sugerencia me la podéis comentar que si son interesantes os aseguro que no van a caer en saco roto, si no que serán incluídas en posteriores versiones, tal y como he hecho con sugerencias pasadas en esta nueva versión.

Aquí os pongo las FAQ, son un poquito largas, pero resumen todo lo principal que puede hacer el nuevo equipo. Si tienes 5 minutos y las lees verás que el MTXTunnel 5.0 te puede ser de utilidad para muchas de tus aplicaciones futuras.

¿Qué es el MTXTunnel?

El MTXTunnel 5.0 es un software que puedes solicitar a Matrix instalado dentro los siguientes módems de la familia MTX  (MTX65i, MTX65IND, MTX65ULP y MTX65+G)

  Lee el resto de esta entrada »

Etiquetas: cinterion, dynDNS, gateway, gprs, rs232

Hoy voy a poner un pequeño post sobre Proguard, un ofuscador para Java. Probablemente muchos lo conozcáis y lo utilicéis ya con vuestras aplicaciones j2me, pero para los que no, os aconsejo dar un vistazo a este articulillo, que os irá bien, sinó ahora, más adelante, en alguna ocasión, con algún nuevo proyecto con módems Cinterion (TC65, XT65) o los terminales MTX.

El uso de un ofuscador para nuestras aplicaciones j2me es interesante, más que por su capacidad de “ofuscar el código”, por la reducción del tamaño final del fichero “.jar” generado. Nunca hay que olvidar (aunque alguno a veces parece que lo haga ) que no estamos programando un procesador Core2Duo, sino que estamos programando dispositivos con un tamaño de memoria RAM y FLASH muy limitada. Por ejemplo un módem GPRS MTX65 dispone de una memoria RAM de unos 400KB y de 1.7MB de memoria FLASH. El uso de un ofuscador nos hará aprovechar al máximo la preciada memoria FLASH y sobre todo la memoria RAM de nuestros módems.

Para hacernos una idea, el nuevo firmware del MTXTunnelv5.0 que saldrá en breve (este mes) ocupa, sin ofuscar, unos 130KB, mientras que ofuscándolo unos 80KB. Podéis ver que la reducción es bastante significativa.

¿Y qué hay que hacer para usar un ofuscador?

Pues lo primero de todo bajárselo.

¿Con el emule?

No, que es gratis.

¿Y dónde está?

Lo encontrarás en este Link: http://sourceforge.net/projects/proguard/files/

Bájalo y descomprímelo dentro de la carpeta del Eclipse, es decir, dentro en:

c:\Eclipse\proguard4.5.1\

Después ves a Window > Preferences > J2ME > Packaging > Obfuscation y selecciona el PATH adecuado tal y como puedes ver en la pantalla siguiente.

Una vez hecho esto ya puedes “compilar” tu aplicación ofuscándola. Para ello en lugar de hacer un “Create Package” hacemos un “Create Obfuscated Package”.

Lee el resto de esta entrada »

Etiquetas: cinterion, j2me, java

Hola de nuevo a todos, espero que hayáis disfrutado de vuestras vacaciones.
 
Supongo que a muchos, como a mi, se os acaban las vacaciones esta semana y toca volver al deber la semana que viene. Animo!!!
 
Yo este año he estado combinando un poco trabajo y vacaciones, pero aún así me lo he pasado bastante bien. De las tres semanas de vacaciones he estado, como cada verano, una semanita en Huesca con la familia de Sonia, 4 días en Peñíscola (ahí si que no he hecho más que descansar )y el resto por casa, en Cardedeu.
 
La verdad es que hace casi tres meses que no escribo nuevos posts (aunque sí que intento siempre encontrar un hueco para contestar a todo el que comenta los posts del blog). La razón fundamental es que he estado obsesionado muy ocupado en estos últimos tiempos en varios proyectos. Especialmente he estado muy ocupado con la nueva versión de firmware del MTXTunnel, la v5.0, que verá la luz durante este Septiembre de 2010. Me ha llevado muchísimo trabajo pero creo que el resultado final merece la pena. Ya os la presentaré cuando tenga 100% finalizada la documentación, que es básicamente lo que estoy terminando.
 
También estas vacaciones he dedicado un tiempo para replantearme un proyecto que he intentado llevar a cabo en un par de ocasiones, pero que por unas cosas o por otras no he conseguido que funcione tal y como tenía en mente: un foro de electrónica. Y es que muchos posts del blog tienen demasiados comentarios ya y creo que lo mejor es un foro. Sí, ya sé que tengo uno integrado en mi blog, pero es que es excesivamente lento y tedioso de usar. Y si a mi me da pereza entrar por lo lento que es (y no digamos ya de administrar) supongo que a los “navegantes” que lleguen a él, pues más.
 

 
Para este nuevo foro he comprado el script del Sistema de foros de VBulletin, algo caro (195$), pero después de lo que he leído (y probado), creo que simplemente es el mejor. Ahora me falta comprar el VBSeo, un mod para VBulletin, pero imprescindible para el buen posicionamiento en buscadores, que es de donde siempre provienen la mayor parte de las visitas. Al menos a mi, que entre todas mis webs suman casi 2 millones de páginas vistas al mes, las visitas provienen en más de un 85% de los motores de búsqueda.
 
Por otro lado, a parte del script para el foro está el tema del nombre del dominio a usar. Quería un dominio distinto de blogElectronica.com, pero como casi todo el mundo sabe, el tema de los nombres de dominio de Internet está a día de hoy muy complicado. Todos los dominios .COM , buenos y malos, están registrados. A mi personalmente me parece totalmente imprescindible tener un buen nombre de dominio (.COM) para cualquier proyecto con presencia en Internet. No es que sea determinante para que un proyecto tenga éxito pero sí es una ayuda muy grande en cuanto a generación de tráfico type-in, en SEO y en branding. Así que, viendo que “por suerte” los antiguos propietarios de los dominios “foroElectronica.com” y “foroDeElectronica.com” los tenían en venta, he negociado con ellos un precio y los he comprado, pues, aunque me han salido algo caros (unos 500€ al cambio), considero que ambos dominios son los más apropiados para un foro de electronica.
 
Como véis, tal y como decía el actor Richard Attenborough en su papel en Jurassic Park “no hemos reparado en gastos” con mi nuevo foro.
 
Por el momento no eliminaré el antiguo foro incluído en blogElectronica, pero por favor, para introducir nuevos comentarios, usar foroElectronica.com 

 
En fin, no me enrollo más. Que tengáis una feliz re-entrada en el trabajo !!!

 
Salu2.

Etiquetas: foro electronica