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.

Posts relacionados:

1. Foro de electronica No lo he comentado hasta ahora por falta de tiempo...

La primera es que ya no depende de mi servidor www.otap.es.   Ahora el software incluye un pequeño servidor TCP/IP para gestionar las respuestas OTAP. Es decir, como sabéis, cuando un proceso de OTAP finaliza (bien o mal) si la conectividad GPRS es correcta envía una notificación (petición POST) a un servidor web indicando el resultado de la operación. En la versión 1.0 esta notificación era enviada por el módem siempre a www.otap.es mientras que en esta versión 2.0 podéis especificar vuestro servidor de confirmación OTAP o bien utilizar esta misma aplicación (v2.0) como servidor de confirmación. También la he preparado para ello.
 
Si os fijáis en la siguiente captura de pantalla:

veréis el parámetro URL notify.  Esa es la URL que el módem llamará una vez finalizado el proceso de OTAP. Como decía anteriormente, podéis especificar vuestro propio servidor de confirmación OTAP (mediante una IP o DNS) o bien utilizar esta misma aplicación como servidor de confirmación. Para esto último lo más sencillo es pulsar en el botón “Mi IP”. Al pulsar en ese botón se crea una URL automáticamente con la dirección IP pública de vuestro router (por si no la sabéis). Es decir, por ejemplo, al pulsar el botón “Mi IP” el parámetro URL notify mostrará algo como (en mi caso):

http://83.56.194.122:20010/?ID=<phone>

Esto indica que para el servidor de confirmación el módem debe utilizar la IP: 83.56.192.122,  el puerto 20010 y se pasará como parámetro ID el número de teléfono. El software automáticamente cambiará el texto <phone> por el número correspondiente de la SIM a la que se va a realizar el OTAP, para que el servidor de confirmación OTAP, cuando reciba la confirmación, sepa de qué número de teléfono se trata. 
  
Dos cosas muy importantes. Una es que obviamente hay que hacer un NAT en el router ADSL de nuestra empresa para redirigir el puerto 20010 (o el puerto que uséis) hacia el PC donde corre el software de confirmación OTAP y la otra es que no hay que olvidar la “/” entre el número de puerto (en el ejemplo 20010) y el ?
 
Una vez completados todos los datos necesarios ya estamos en disposición para hacer el OTAP.  Para ello tenemos que tener un módem GSM conectado a un puerto serie de nuestro PC  (configurado a 115200,8,N1 y con control de flujo HW), que será el encargado de enviar los SMS de OTAP.  Una vez todo conectado ya podemos pulsar el botón “Inicar Proceso de OTAP”. 

 
Aquí viene otra de las diferencias de esta versión 2.0 con respecto a la v1.0.  En la figura anterior, abajo, si os fijáis, veréis que si finalmente hemos decidido usar esta misma aplicación como servidor de confirmación de OTAP habrá que habilitar la casilla de “Servidor OTAP activo” y especificar el puerto TCP que indicamos en la pantalla anterior, en “URL Notify”. Repito que no hay que olvidar hacer el NAT en el router como tampoco olvidar desactivar el firewall de windows y/o antivirus para que no bloqueen el puerto TCP escogido.
 
Una vez hecho esto ya estamos en disposición de pulsar “Iniciar proceso OTAP” y empezará el proceso. En esta versión 2.0 el control de errores el OTAP lo he mejorado considerablemente. Si os fijáis veréis que la tabla superior tiene 3 columnas. Las dos primeras son las mismas que la versión 1.0, pero la tercera muestra un LOG con lo ocurrido. Basta hacer doble clic con el ratón en un determinado LOG para abrir una pantalla con el LOG completo. De esa manera resulta mucho más sencillo averiguar, en caso de error de OTAP, el motivo de ello. Por ejemplo, si el proceso de OTAP finalizó OK y abrimos el LOG veremos algo como:
 

 Si en cambio nos hubiéramos equivocado al especificar dentro del archivo JAD la ruta (URL) correcta al fichero JAR en el parámetro <MIDlet-Jar-UR>, tendríamos un error como:
 

Si nos nos hubiéramos equivocado al especificar dentro del archivo JAD el tamaño correcto de fichero JAR en el parámetro <MIDlet-Jar-Size>, tendríamos un error como:
 

Por cierto que si queréis probar el programa lo podéis hacer con el ejemplo HelloWorld que tengo en blogElectronica. Podéis ver el JAD correcto en:
 
http://www.blogelectronica.com/TEMP/HelloWorld.jad

 
Pues nada, espero que quienes usáis OTAP lo consideréis interesante.  Aquí tenéis el LINK para la descarga del software OTAP v2.0, que lo he puesto en un ZIP con todas las DLLs necesarias para que no requiera instalación. Si alguno tiene algún problema de DLLs, por favor, comentármelo. Esta versión es completamente gratuita y jamás caduca, pero como hay un trabajo importante detrás por mi parte “hay un pero” y es que está limitada. Es posible introducir en el sistema hasta 5 módems y por tanto hacer otap como máximo a 5 módems de forma simultánea (por una constante en el código fuente). Pero para la mayoría de usuarios será más que suficiente esta versión.
 
Para aquellos que no quieran la limitación de 5 módems (y poder introducir todos los módems que sean necesario) y sobre todo para los que además quieran EL CÓDIGO FUENTE COMPLETO de la aplicación OTAP v2.0 existe la posibilidad de adquirirlo por PayPal (ya que es algo personal mío y lo envío por correo electrónico a las 24h).   A ver si me da para permitirme un servidor más rápido para blogElectronica y para otros proyectos futuros que tengo en mente …

 
Tener el código fuente puede resultar muy útil a quien tenga planeado hacer su propia aplicación OTAP para no partir de cero y ahorrarse así bastantes horas de trabajo.  Al tener el código fuente de la aplicación es posible modificarla, ampliarla, añadir parámetros, logos … lo que se quiera. No la he hecho en java, la he hecho en Visual Basic 6 y con muchos comentarios para que todo el mundo la entienda, sin clases ni nada, sólo frm y bas.
 

Espero que sea de interés. Otro día más. Feliz Domingo.  ;)

Posts relacionados:

1. Plataforma OTAP para módems gprs Siemens - Cinterion Hace tiempo que no escribo en el blog. Han  sido...
2. Utilización de OTAP en los módems Siemens TC65, XT65 y MTX65 No todos los modems del mercado disponen de la funcionalidad...
3. Versión 1.1 de la plataforma OTAP Aquí cuelgo para quien lo necesite la versión 1.1 (beta por...

 
 
Los operadores que se adhieran a UMTS900 podrán ofrecer servicios HSPA de forma eficiente. Podrán reutilizar su red existente GSM900MHz, incluyendo las antenas y sistemas de manejo de la red. En esta banda UMTS900MHz se pueden llegar a manejar las mismas velocidades que con UMTS2100, con menos de la mitad de celdas. Los operadores incrementarán su tráfico de datos con su mayor oferta en 3G, dando cabida a más aplicaciones en 3G en más regiones….
 

 
 
En octubre 2009, ya hay más de 11 operadores/redes UMTS900MHz trabajando actualmente en otros tantos países y se han comercializado más de 190 dispositivos UMTS900-HSPA  por 34 fabricantes, pensados para los emergentes mercados de Europa, Europa del este/Africa y Asia-Pacifico, donde la esta nueva banda UMTS900MHz se está estableciendo con mayor velocidad, combinando 900/2100MHz para WCDMA-HSPA.
Los operadores que adopten UMTS900 deben aprovisionarse de dispositivos compatibles e introducirlos en su red comercial lo antes posible para una mejor y mayor penetración de servicios y cobertura en esta banda.
 
Los fabricantes deben asegurarse de que sus dispositivos 3G/HSPA puedan funcionar en esta banda, especialmente en aplicaciones para conexión a internet, módems, routers, dongles PC, y como en el caso que nos atañe, también para el mercado de M2M. Cinterion WM lanza por ello su modulo EU3,  que puede operar tanto en la banda UMTS900 como UMTS2100 para HSDPA (3.6Mbps DownLoad y 784Kbps Upload).  Este modulo también puede conmutar automáticamente a redes EGDE  y GSM dependiendo de la disponibilidad de la red.
 
Fuentes documentación: Cinterion WM, GSA Global mobile Suppy Association y Nokia-Siemens Networks

Posts relacionados:

1. De la telefonía movil analógica a UMTS ¿Alguien recuerda alquellos tiempos del Moviline de Telefónica? Aquellos móviles...
2. Comunicaciones RF en la banda de 868 y 869 MHz Si alguna vez habéis tenido la necesidad de desarrollar un...

 
 Ventajas SIM on Chip:

 • Tamaño menor ejemplo encapsulado SMT (VQFN-8) 4.8 mm x 4.8 mm
• Rango temperatura extendida (-40°C a +105°C)
• Mayor expectativas vida de producto y retención de datos (10 años). Importante en aplicaciones M2M en automoción, contadores…
• Reducción de costos: No se necesita conector portaSIM, menos defectos y retornos de SIM defectuosas, menos desplazamientos servicio reparación. 
• Mejor conexión y estabilidad de montaje. Evita corrosión.
• Protección antirrobo, antifraude.
• Fabricación automatizada: Pick & Place.
• Más robusta en severas condiciones (humedad, corrosión, vibraciones, temperaturas). Posibilidad de tropicalizado, resinado del equipo.

 
Los módulos de CINTERION pueden aceptar las 3 formas: SIM tradicional, External Component SIM y Component SIM Integrado. A continuación se indican las ventajas e inconvenientes de cada tecnología:
 

1.- Sim Tradicional

 
 Ventajas:
 
• Ni el fabricante del dispositivo, ni el integrador tienen porque seleccionar el operador
• Se pueden usar todos los operadores
• Es el cliente final el que contrata la SIM y sus servicios
• Se puede cambiar de SIM en cualquier momento de la vida del equipo.
 
Inconvenientes:
 
• Las SIMs tradicionales suelen tener una garantía de 2 años
• Proceso manual de insertado.
• No es adecuada en múltiples aplicaciones M2M, donde están presentes vibraciones, cambios de temperatura. En algunos casos se han detectados problemas de falsos contactos ya que la SIM se comba debido a dilataciones en sus materiales por cambios de temperatura.

 2.- M2M SIM Soldada en la  PCB

 
 Ventajas:
 
• Adecuada para todas las aplicaciones M2M
• El fabricante o montador del equipo dará un valor añadido si la deja conectada por defecto

Inconvenientes:
 
• Fabricantes de chips M2M SIM limitado
• Los módulos GSM M2M deben estar preparados para ello.
• No se puede cambiar de operador, a no ser que se deje previsto otra huella para M2M SIM

En este caso, a continuación podéis ver un ejemplo del interfaz de a SIM del módulo a 2 SIMs externas, sean del tipo que sean. El concepto de esta aplicación es que para conmutar entre otra solo es necesario controlar la línea de reset (SIM-RST), resetando la SIM que no se “usa”. El resto de cables están simplemente conectados en paralelo.

3. M2M SIM interna en el Modulo

Ventajas:
 
• Perfecto para grandes volúmenes de producción. Ahorra costes de componentes, montajes.
• Modulo listo para comunicarse.
• Modulo es testeado con la SIM
• No hay que comprar chips
 
Inconvenientes:
 
• El modulo está restringido a usarse con el operador seleccionado
• Si hay que cambiar el modulo por otro hay que reconfigurarlo a la antigua información de la SIM.

 
 
En cualquier Caso, los módulos WM de Cinterion para GSM/GPRS/EDGE y UMTS están preparados para la tecnología actual y la nueva tarjeta SIM en forma de componente. A ello le llaman  Multi-SIM Interface —“ Flexible SIM interface enables regular SIM cards to M2M component SIM’s”.
 
Un ejemplo de módulo es el nuevo EU3. Es un módulo UMTS-HSDPA-EDGE-GPRS, compatible con los módulos TC63i, TC65i y MC75i para una fácil migración de GSM-GPRS-EDGE a UMTS-HSDPA. Este módulo tiene unas interesantes funciones: USB, puerto serie UART a 460Kpbs, stack TCP-IP, 10 GPIO, 2 ADCs, y  que permite estas 3 posibilidades de integración de SIM.
 

No hay posts relacionados.

  
Muy bien ¿y qué es lo que hace este ejemplo?

Si descargas y abres el proyecto verás 3 archivos. Para probar el ejemplo sólo tienes que editar el main.java y cambiar los parámetros de conexión en función de tu operador. Si usas Movistar en España puedes dejar el código como está y compilar y ejecutar el proyecto.
 
Cuando lo ejecutes verás que el módem se conecta a GPRS y, por la salida estandard (normalmente ASC0), te sacará la IP que ha obtenido. Yo si lo ejecuto obtengo:
 

 
Después de eso abre el explorador (yo sólo lo he probado en Microsoft Explorer, en ninguno más) y escribe algo en la barra de direcciones como:

http://80.29.209.172/suma.html?a=10&b=20

Y obtendrás una respuesta tal que así:
 

 
Es decir, el módem ha recibido la petición HTTP GET, a tomado los valores de los parámetros pasados en la URL “a” y “b” los ha sumado y ha devuelto una página HTTP con la suma. Evidentemente que lo que hace el presente ejemplo (una calculadora GPRS) sirve de bien poco y no tiene mucho sentido, pero seguro que se os ocurren muchas ideas a partir del ejemplo.
 
Una cosita más, en el código tengo puesta una variable de nombre “numMaxClientesX”. En esta podéis especificar el número de peticiones concurrentes que puede haber. Por defecto está a “1″ y podéis subirla, pero recordad que los módems Siemens / Cinterion soportan máximo 6 sockets y uno ya lo toma el socket listener que escucha en el puerto TCP80 (Http). También pensad que se lanza un Thread por cada conexión establecida.
 
El ejemplo está hecho utilizando los sockets mediante clases java. A quien me pregunte que qué es mejor, si gestionar los sockets con clases java o con comandos AT como he hecho otras veces por este blog, pues no se qué decirle. Más o menos es lo mismo. La ventaja de usar clases java es que quizás la aplicación (un socket server) resulte algo más sencilla de implementar y con comandos AT es que se tiene algo más de control del estado de cada uno de los sockets. Son apreciaciones subjetivas, realmente ambos métodos funcionan muy bien, en ocasiones uso uno y en otras otro.
 

Espero que os resulte de interés, otro día más.

 
www.blogElectronica.com

Posts relacionados:

1. Cómo obtener la hora con los terminales MTX y módems Siemens / Cinterion Llevo casi un mes sin escribir en blogElectronica. Y es...
2. Nuevo módem GPRS teminal MTX65 basado en el módem Siemens TC65 Matrix Electrónica ha lanzado la distribución de un nuevo modelo...
3. MTX65-ULP. Módem GRPS Ultra Low Power basado en Siemens/Cinterion   Hoy voy a hablar de un nuevo terminal, del...

 
Fijaros en una cosa muy importante, algo por lo que yo daría una colleja al que definió la nomenclatura. En los equipos DCE (p.e. módems) el pin RX es de transmisión y el pin TX es de recepción, justo al contrario de lo que indica la lógica. Ésto para mi está hecho para los tontos, para que unan RX con RX, TX con TX, RTS con RTS etc etc sin confusión. Pero para los que sabemos un poco es una auténtica guarrería. He visto montones de gente y empresas con confusiones en este aspecto, por ejemplo uniendo el TX de un micro con el pin RX de un módulo TC65, algo que por lógica debería ser así, pero no, pues hay que unir el pin TX del micro con el pin TX del módulo. Al final todo se resume en saber si un equipo es DTE o DCE.
 
Bueno, otro día más, que ahora me voy de excursión motorizada con la familia a la montaña, a desayunar en el Santuario del Corredor. A ver  si no se tuerce el día y no nos llueve demasiado.  ;) .

 
www.blogElectronica.com

Posts relacionados:

1. Conversor serie RS232 Bluetooth   Para variar un poquillo, hoy me salgo del tema...
2. MTX-Tunnel - Gateway GPRS-RS232 Como dije ayer, hoy voy a presentar un nuevo producto...

 
A quien le interese este módulo puede dar un vistazo a su datasheet aquí . También si dáis un vistazo a las guías de montaje (página 15 del datashee) veréis que también son menos restrictivas que las del WT11.
 

www.blogElectronica.com

Posts relacionados:

1. Nuevo módulo bluetooth de bluegiga WT32 Hoy día 19 de Septiembre Bluegiga, fabricante finlandés de módulos...
2. Módulos bluetooth WT11 y WT12 de bluegiga Hoy os presento unos modulos bluetooth que seguramente a muchos os podrán...
3. Gateway Bluetooth-GPRS Desde hace ya un tiempo quería escribir un post acerca...

Me ha parecido bastante interesante así que, como todavía falta un rato para ver a Horatio (CSI Miami para los despistaos ) os lo comento rápidamente.

Como decía, el Digi Connect Me 9215 está preparado para PoE. Ojito, PoE Pass-Through.  Es decir, que nadie piense que como en las especificaciones del módulo pone PoE ya puede uno conectarlo a una red ETH con PoE habilitado y sin más funcionar. Eso no es así, se necesita de unos componentes electrónicos adicionales para ello. Es decir, básicamente lo que hace el pass-through del DigiConnect ME 9215  es llevar las líneas necesarias PoE hacia algunos de sus pines para ser tratadas.

Y hablando de esos componentes electrónicos adicionales, si dais un vistazo a la documentación de Digi (http://ftp1.digi.com/support/documentation/90000940_A.pdf) veréis que plantean como opción usar un LM5070 de National para la gestión del PoE. Este LM5070 no un módulo sino un chip y hay que usar muchos componentes externos junto a ese chip, con lo que se complica bastante la aplicación.

Más fácil es usar un módulo Ag9020 de Silver Telecom ya que este módulo lo incluye todo y además es muy económico. De hecho es tan fácil de usar que basta con soldar directamente 6 de sus pines para tener activo el POE del Digi Connect Me 9215, tal y como muestra la siguiente fotografía.
 

Y bueno, una vez todo montado ya solo falta probarlo. Los Digi Connect Me 9215 son tanto endspan como midspan. Antaño, los módulos que había probado eran sólo midspan y no endspan, es decir, funcionaban bien con dispositivos PoE injectors (dispositivos que se usan para dotar de PoE a redes ethernet no son PoE) pero no funcionaban si se conectaban a dispositivos endspan (típico ejemplo de un dispositivo endspan es un switch con POE). Por suerte, los módulos Digi Connect ME 9215 funcionan con ambos tipos.
 
Pese a funcionar tanto con midspan como endspan, para este caso de test se ha usado una fuente POE de SL-Power (un PoE Injector) midspan. Como era de esperar una vez conectado ha funcionado todo (Digi Connect ME 9215 + ag9020 +  fuente POE) perfectamente. Por supuesto estos 3 componentes los distribuye Matrix en España.
 
Espero que los que tengáis que desarrollar algún equipo POE en el futuro encontréis de interés el artículo. 
 
Otro día más

 
www.blogElectronica.com
 

Posts relacionados:

1. Cómo usar ficheros con módems de Siemens desde Java. Como seguro ya sabéis, varios de los modelos de módems...
2. Digi Show-box - Sistemas de publicidad Hace ya tiempo puse unos post relativos al dispositivo Access...
3. Alcance módulo RF Xbee-868MHZ   Hace ya bastante tiempo puse algunos artículos sobre modulitos...

Vamos allá. El módem MTX65+G, como muchos recordaréis, tiene un único puerto serie. Ese puerto serie ya estaba ocupado con otro dispositivo, así que la única alternativa era utilizar una pantalla controlable por SPI. La pantalla escogida fue una de Electronic Assembly, concretamente el modelo EA DIP204-4HNLED.

Lo primero que hay que hacer con esta pantalla es configurarla para que trabaje por SPI ya que por defecto utiliza un bus paralelo. Para ello basta con darle la vuelta, desoldar el jumper marcado con 4/8 y soldar el jumper marcado con SPI. Ambos están muy juntos y uno debe asegurarse con un polímetro que el jumper 4/8 está realmente desoldado.

Las conexiones de la pantalla son muy simples, así que rápidamente decir que yo sólo he conectado el pin 17 y 18 a 4V, para el backlight, la alimentación (pin 1 y 2) a 3.3V, el contraste (pin 3) a un potenciómetro de 10K y los cuatro pines propios del bus SPI (pin 4,5,6 y 7) a los correspondientes del bus SPI del módem (obviamente el DI de la pantalla al DO del módem y viceversa). Para mis pruebas, por comodidad de bornas, he utilizado un módem MTX65-IND, pero con un MTX65 o un MTX65+G sería exactamente lo mismo.
Bueno, pues ya está casi todo, tan solo falta enviar los comandos AT apropiados al módem para que éste envíe datos vía SPI a la pantalla y así poder escribir sobre ella. Evidentemente todo esto se puede hacer desde una aplicación java embebida dentro del módem, pero por comodidad, lo voy a poner mediante comandos AT enviados desde una aplicación de PC por el puerto serie. Bien, pues estos son exactamente los comandos que hay que enviar para escribir un HOLA en la pantalla.
 
 

 ’Activamos el bus SPI y lo ponemos en modo 0 (de los cuatro modos posibles)
 respuesta = enviarAT(”at^sspi=1000,0000,0000,0000,0000″)

 ’8bits y activamos las funciones extendidas
 respuesta = enviarSerie(”<2000000F820C0>”)

 ’Modo 4 líneas
 respuesta = enviarSerie(”<2000000F89000>”)

 ’8bits y desactivamos las funciones extendidas
 respuesta = enviarSerie(”<2000000F800C0>”)
 
 ’Display on, cursor on y cursor parpadeando
 respuesta = enviarSerie(”<2000000F8F000>”)
 
 ’Limpiamos display y cursor en columna 1 y fila 1
 respuesta = enviarSerie(”<2000000F88000>”)
 
 ’Para que el cursor avance con cada escritura
 respuesta = enviarSerie(”<2000000F86000>”)

 ’Escribimos un HOLA   
 respuesta = enviarSerie(”<2000000FA1020>”) ‘H
 respuesta = enviarSerie(”<2000000FAF020>”) ‘O
 respuesta = enviarSerie(”<2000000FA3020>”) ‘L
 respuesta = enviarSerie(”<2000000FA8020>”) ‘A

 
 
No me invento nada, es básicamente el ejemplo que hay en el manual de la pantalla, página 3. Lo único que hay que tener presente es que hay que enviar el bit de menor peso el primero y el de mayor peso el último. Es decir, en el ejemplo del manual se envía primero un comando 0×34, que en binario es el 0011 0100, por lo que con nuestro módem tendremos que enviar, si le damos la vuelta el 0010 1100, es decir, un 2C.  Otra cosa importante es que la pantalla requiere que en cada byte se envíe dividido en 2 bytes, como XXXX0000 XXXX0000, por eso, en lugar de enviar un 2C se envía un 20C0. El porqué del F8 inicial de cada trama (o el FA inicial de cuando escribimos un caracter) lo tenéis explicado aquí  en la página 51, es básicamente la cabecera que necesita la pantalla en cada trama SPI.

Únicamente con esto ya es suficiente para escribir datos en la pantalla como podéis ver en la imagen anterior.

Espero que resulte de interés o ayuda para quien necesite usar alguna pantalla con un módem Siemens/Cinterion en algún proyecto.

Y ya que hablo de Siemens/Cinterion comentar una buena noticia que me afecta a nivel personal y que en los tiempos que corren, son siempre bienvenidas. Y es que resulta que esta semana se ha celebrado el congreso que Cinterion organiza a nivel mundial con todos sus distribuidores. Como ya he comentado muchas veces en mi blog yo trabajo en Matrix Electrónica (distribuidor de Cinterion en España) como ingeniero de aplicaciones. Pues bien, este año se nos ha concedido el premio al distribuidor con el mejor soporte técnico de módems Cinterion del mundo, cosa que tanto a mi compañero Jesús Santos como a un servidor que os escribe, que somos principalmente quienes nos encargamos, entre otras muchas cosas, del soporte técnico de Cinterion y terminales MTX en Matrix, nos ha alegrado mucho.
 

 
Sienta bien. Y es que después de tantas horas de trabajo empleadas con estos productos, de estar siempre echando una mano a mucha gente (que se traduce en cientos de consultas de cientos de empresas con todo tipo de proyectos gsm), de estar siempre ahí dispuesto a buscar soluciones cuando aparecen problemas, sin esconder jamás la cabeza como una avestruz. En definitiva, después de tanto tanto trabajo que al menos se reconozca por parte de Cinterion …  pues la verdad es que nos ha sentado muy bien y nos anima a seguir y a mejorar.

Decía mucho mi abuelo, que en paz descanse, que es de bien nacidos ser agradecidos. Así que mi agradecimiento también a Antonio López (de Cinterion España), que siempre está ahí dispuesto a echar una mano cuando lo necesitamos y cuya ayuda ha sido muy valiosa y fundamental para poder desempeñar bien nuestro trabajo durante todo este tiempo.

 
Esto es todo por hoy, otro día más. Feliz Domingo.

www.blogElectronica.com

Posts relacionados:

1. Nuevo módem GPRS teminal MTX65 basado en el módem Siemens TC65 Matrix Electrónica ha lanzado la distribución de un nuevo modelo...
2. Cómo utilizar el Watchdog del módem GPRS Siemens TC65 Hace muy poquito salió la versión firmware 3.0 del módem...
3. MTX65-ULP. Módem GRPS Ultra Low Power basado en Siemens/Cinterion   Hoy voy a hablar de un nuevo terminal, del...

• Software embarcable sobre un MTX65, TC65T, MTX65+G, MTX-IND y los módulos TC65, TC65i y XT65. En breve también sobre el MTX65-ULP (módem de ultrabajo consumo).
• Funcionamiento en modo socket cliente o socket servidor (es decir, el módem puede iniciar una conexión o esperar una conexión remota).
• Conexión GPRS siempre permanente o activable mediante SMS o llamada perdida
• Posibilidad de reset automático cada 24h.
• DynDNS (para no pagar por una IP fija al operador)
• GPRS y GSM (se puede acceder tanto vía GPRS a un puerto serie RS232 remoto como mediante una llamada GSM, esto último obligatorio para los operadores de energía en aplicaciones de metering. La llamada GSM tiene prioridad sobre GPRS).
• Firewall GSM (puede escogerse si el acceso vía GSM puede hacerse desde cualquier número de teléfono o sólo desde los autorizados).
• Firewall GPRS (puede escogerse si el acceso vía GPRS puede hacerse desde cualquier IP o sólo desde las autorizadas).
• Envío automático de SMS ante cambio de entrada digital
• Cambio de estado de salida digital (o relé en el caso del MTX-IND) mediante SMS.
• Ejecución de comandos AT remotos (lectura remota de la cobertura, lectura de entradas digitales, lectura remota de conversores A/D …)
• Posición GPS remota del módem (aunque no tenga GPS el módem se puede obtenerse una posición GPS aproximada en función de la estación de telefonía más próxima)
• Cambio de configuración remota (permite cambiar de forma remota la configuración del puerto serie deñ módem, dyndns, …)
• Pasarela quasi-transparente Coronis para aplicaciones de metering y telemetría (MTX-IND con tarjeta wavecard embarcada). Próximamente.
   

 
Hoy voy a exponer brevemente una pequeña utilidad de nombre Remote AT Command. Sirve básicamente para poder ejecutar sobre el MTX-Tunnel-Advanced comandos AT remotos, pero también para poder cambiar la configuración del módem de forma remota, también para poder obtener la posición GPS del módem (aunque no tenga GPS) de forma aproximada (¿os acordáis?) y en breve, para aplicaciones de metering. Esta utilidad ha gustado mucho a empresas con proyectos de telegestión de contadores de energía (lo cual, como creador, me ha alegrado mucho en todos los sentidos).

Por un lado el MTX-Tunnel-Advanced ha interesado mucho sobre todo por la posibilidad de acceso remoto tanto vía GPRS como GSM (como curiosidad decir que actualmente, en proyectos reales ya en la calle, Iberdrola puede acceder vía GSM a los contadores mientras que desde otro punto, vía GPRS, se está accediendo para obtener lecturas en tiempo real de los contadores cada 15 segundos). 

Por otro lado la utilidad Remote AT Command ha gustado bastante por la posibilidad de la monitorización de la cobertura de forma remota así como por la posibilidad de cambiar ciertos parámetros del módem también de forma remota. Por lo visto, en ocasiones, puede haber confusiones con la velocidad del puerto serie del contador que se va a monitorizar en el momento de la instalación o porque un contador es substituido por otro con una configuración del puerto serie RS232 diferente. El hecho de poder cambiar la configuración del puerto serie del módem de forma remota adaptándola a la del contador y evitando así desplazamientos (que en algunos casos pueden ser cientos de Km) ha gustado mucho.

Pues bien, la utilidad Remote AT Command se compone básicamente de 3 secciones (realmente 4, con una de metering que estoy finalizando). Para conectarse con el MTX-Tunnel-Advanced remoto basta con poner su IP remota (o DNS, si usamos DynDNS) y puerto TCP. Una vez estamos conectados al módem, mediante la sección “Comandos AT” se puede lanzar cómodamente un comado remoto al módem. Fíjate en el ejemplo siguiente, he lanzado un AT+CSQ, para comprobar la cobertura de forma remota .
 

Como decía en párrafos anteriores, también es posible cambiar los parámetros de configuración del módem de forma remota e incluso enviar un Reset al módem.  Para eso sirve la segunda sección:
 

 
También he incluido lo de la posición GPS (de la estación de telefonía más próxima) que comenté hace un tiempo, no me he podido resistir . Para aplicaciones de metering tan vez no tenga sentido pero sí puede tenerlas en otras aplicaciones móviles, que las hay, y como me costaba bien poco, he incluido la prestación.
 

 
Y por último, algo que casi tengo terminado, una sección de metering. ¿Os acordáis cuando hablamos del MTX-IND y vimos al final del vídeo que podía montarse una tarjeta Wavecard? Pues esto está muy relacionado. Veréis como es posible hacer un sistema de metering muy completo, a la vez que muy sencillo de mantener, con el MTX-Tunnel-Advanced, pero eso ya será otro artículo. Antes de eso hablaré, seguramente en mi próximo artículo, de los WaveFlow de Coronis (módulo RF para lectura de contadores). Después ya contaré como utilizar un MTX-Tunnel-Advanced como concentrador de comunicaciones radio para aplicaciones de metering.

Espero que quieres estéis relacionados con aplicaciones de metering lo consideréis interesante. Feliz Domingo.
 

www.blogElectronica.com

Posts relacionados:

1. MTX-Tunnel-Advanced. Gateway GPRS-RS232 avanzado. Hoy me gustaría presentar un nuevo producto GSM/GPRS orientado a...
2. MTX-Tunnel - Gateway GPRS-RS232 Como dije ayer, hoy voy a presentar un nuevo producto...
3. Plataforma OTAP para módems gprs Siemens - Cinterion Hace tiempo que no escribo en el blog. Han  sido...

Hoy os cuelgo un pequeño ejemplo en Java para hacer la segunda parte, el envío de los datos por FTP a un servidor central.

Hace ya mucho tiempo puse unos posts con muchos ejemplos java, entre ellos ( http://www.blogelectronica.com/ejemplos-java-j2me-modem-gprs-siemens/ ó http://www.blogelectronica.com/j2me-ftp-cinterion-tc65-xt65-mtx65-tc65t/ ).

En este último también había un ejemplo de FTP. Este de hoy es más elaborado, pues permite subir directamente un archivo almacenado en la memoria flash de nuestro módem a un servidor vía FTP. El proyecto y código fuente del ejemplo lo puedes descargar de aquí­.
 

 
Para probarlo sin complicaciones haz lo siguiente paso a paso. Crea un fichero de nombre “datos.txt” con los datos que quieras en su interior y grábalo en la memoria FLASH de tu módem TC65 / XT65 (en el directorio raí­z). Después importa el proyecto de ejemplo desde Eclipse. Abre el fichero FtpHandle.java, en él verás que se leen algunas variables del fichero EjemploFTP.jad

Si abres el fichero EjemploFTP.jad verás que tienes que establecer las siguientes propiedades:

gprs-timeout: 20
remote-file: fichero.txt
server: 100.100.100.100
user: MiUserDeFTP
pass: MiPasswordDeFTP
remote-dir: TEST
gprs-apn: movistar.es
gprs-user: MOVISTAR
gprs-dns: 80.58.0.33
gprs-pass: MOVISTAR

ajústalas a tus necesidades, indicando el nombre del fichero remoto (el nombre con el que se guardará en tu servidor FTP, la IP de tu servidor FTP, el user y password de tu servidor FTP, la carpeta donde se almacenará el fichero (asegúrate de tener la carpeta creada antes de ejecutar la aplicación) y el resto de parámetros ya os los conocéis de sobras.

Una vez cambiadas a tu gusto las propiedades del jad compila el programa y ejecútalo, verás como sube el fichero datos.txt almacenado dentro de la FFS de tu módem a tu servidor FTP. Seguro que te será de utilidad en alguna ocasión.

Y bueno, para finalizar, aunque un poco tarde (he estado unos dí­as un poco fuera de combate por una pequeña operación en los párpados), al ser este el primer post del año, simplemente desear de corazón a todo el mundo lo mejor para este año 2010 que empieza.

Otro dí­a vuelvo con más

Posts relacionados:

1. Ejemplo envío Email Java para módems Siemens / Cinterion Esta mañana he estado un buen rato realizando pruebas de envío...
2. Ejemplo FTP Java para módems Siemens Hoy pongo un brevísimo post con un nuevo ejemplo Java...
3. Localizando fallos difíciles de reproducir en los módems Cinterion TC65, XT65 Si desarrollas aplicaciones en Java para los módems gprs TC65,...

¿Qué es Orbcomm? ¿Por qué me vas a hablar de este sistema y no de otro?

La razón es que como sabéis yo trabajo en Matrix, que entre otras cosas es el distribuidor oficinal en España de los productos de Digi. Digi es una empresa muy similar a mi chica, pues le encanta salir de compras . En este caso Digi obviamente no sale a comprar ropa, sino empresas tecnológicamente muy avanzadas. Compras recientes han sido Maxstream, Rabbit, Sarian y ahora Mobiapps. Mobiapps es una empresa que fabrica módulos para comunicaciones vía satélite. A su vez, estos módulos de Mobiapps utilizan la red de satélites de Orbcomm. Y eso es la razón por la que yo estoy aprendiendo sobre esta nueva tecnología y como siempre iré compartiendo lo que sé por aquí para quien le interese.

Muy bien ¿pero para qué quiero comunicaciones vía satélite?

Pues obviamente para comunicar con equipos con los que no es posible comunicarse de otra manera. No en todos los sitios del territorio nacional ni mucho menos en todos los lugares del planeta tenemos cobertura GSM/GPRS/UMTS (desiertos, montañas, selvas, campos de cultivo en medio de la nada, …). Incluso también en lugares con cobertura GSM puede ser necesario un sistema de comunicaciones de backup, por si GSM cae.

Alguien puede pensar “qué caro debe ser”. Pero no, no es excesivamente caro. Pero como lo de caro/barato es muy subjetivo después hablo de precios. Este tipo de comunicaciones tiene algunas ventajas muy interesantes, como por ejemplo que no nos tenemos que preocupar de qué tipo de equipo tenemos que usar en un país u otro, aquí no hay cosas análogas a GSM850,900,1800,1900, … Tampoco hay que pagar tarifas de roaming, evidentemente. En este aspecto es todo mucho más simple.

¿Puedo usar en todos mis equipos comunicaciones vía satélite?

No. Por precio o por la propia esencia de este tipo de comunicaciones no es posible usar siempre este tipo de comunicaciones.

Si tu sistema requiere un gran ancho de banda ($), si necesitas comunicarte con tus equipos constantemente (más de una vez por hora), si necesitas comunicación 100% del tiempo y además en tiempo real, son ejemplos típicos donde este tipo de comunicaciones vía satélite no es lo que te conviene.

Características de la red de satélites Orbcomm.

La red de satélites Orbcomm consta de 29 satélites orbitando a unos 815Km de altura (obviamente con esta altura no son satélites geoestacionarios). Las frecuencias de las señales son de 148-150MHz para el radioenlace de subida y de 137-138MHz para el de bajada, con 12 canales. Estos 29 satélites orbitan agrupados en planos, planos diseñados de forma óptima para obtener la mejor cobertura. Para entender esto de los planos nada como una foto:

Estos satélites se comunican con estaciones terrestes repartidas alrededor del mundo, llamadas “Gateways Eath Stations”. Realmente estos satélites actúan como meros routers, es decir, por ejemplo, un módulo de mobiapps quiere enviar datos al servidor de nuestra oficina (ya veremos en otro post esto en detalle) pues lo que hace es enviar los datos a un satélite de orbcomm. Éste a su vez envía los datos a un gateway terrestre que a su vez lo enviará (vía internet, por email) a nuestra oficina.

Muy interesante. ¿Y siempre voy a tener cobertura satelital 100% del tiempo?

No. No la vas a tener. Digamos que en la latitud de España puede haber una latencia de hasta 5 minutos (es decir 5 minutos sin cobertura satelital) y en el ecuador y en los polos de hasta 90 minutos. Tengo una imagen muy ilustrativa con las latencias en todo el globo terreste, pero lamentablemente la tengo marcada como confidencial por el fabricante, así que para evitarme líos no la voy a publicar. Pero bueno, para compensar os pongo un enlace muy pero que muy interesante:

En él podréis ver la cobertura de la red de satélites Orbcomm en tiempo real y en todo el globo terráqueo.

Y bueno, en cuanto a precios. Por decir algo muy aproximado, si tienes pensado emitir datos (muy pocos bytes) una vez al día te puede costar unos 5$/mes y si necesitas algo más, transmitir por ejemplo cada hora, se te puede ir a una cuota mensual de unos 15$ aproximadamente. Como digo tómate esto como una idea. Son sólo ideas de precios que me comentaron en un webminar hace un mes.

Volveré otro día posteando las características de los módulos de Mobiapps (Digi) y también, en cuanto reciba el kit de desarrollo que ya tengo pedido, comentaré los resultados de las primeras pruebas que haga, cómo funciona etc etc.

Bueno, espero que os haya resultado de interés.

www.blogelectronica.com

Posts relacionados:

1. Redes Zigbee (I). Introducción. Voy a iniciar una serie de capítulos breves introductorios a...
2. Comunicaciones RF en la banda de 868 y 869 MHz Si alguna vez habéis tenido la necesidad de desarrollar un...
3. Capítulo I - Sistemas Embebidos Linux - Introducción y conceptos. Se acaban las vacaciones para todos. Muchos decimos, “ufff, vuelta...

Así que voy a comentar este interesantísimo módulo EU3 (presentado recientemente en la feria del Metering en barcelona hace ahora justo 2 meses) pero sólo en base a la poca información disponible.


¿Qué es el EU3?

El EU3 es un módulo UMTS que permite trabajar tanto en las bandas de GSM (GPRS/EDGE) como en 3G. Una característica a destacar es que también está preparado para su uso en la nueva banda UMTS900.

¿Y que es esto del UMTS 900, no es UMT2100?

Desde hace ya un tiempo se está trabajando en el nuevo UMTS900. Y es que trabajar en esta banda implica numerosas ventajas tanto desde el punto de vista técnico como económico.

Desde el punto de visto técnico es mejor porque ofrece una mayor cobertura y penetración que el actual UMTS2100, lo cual es ideal para dar cobertura en zonas rurales e incluso en ciudades, donde al tener una capacidad de penetración mayor la cobertura en edificios es mejor.

Y desde el punto de vista económico pues es evidente. Una razón es que, al disponer de mayor alcance, para dar cobertura a una determinada área es necesario instalar menos estaciones base con UMTS900 que con UMTS2100. Otra razón es que las actuales estaciones GSM siguen siendo válidas y sólo son necesarias pequeñas y económicas adaptaciones, no como ocurre con UMT2100.


Volviendo al tema del EU3 ¿qué otras características destacables tenemos?

Pues que dispone de un puerto USB y de puerto serie. El puerto USB al ser 2.0 ofrece una velocidad de hasta 480Mbps y el puerto serie hasta 460kbps (acordáos que el HC25 está limitado a 115Kbps por su puerto serie, este no). En este caso y a diferencia también del HC25 incorpora también 10 GPIOs de propósito general (el mismo número que tiene también el TC65 … ).

Y bueno, sé que no es mucho, pero hasta aquí es hasta donde puedo decir por el momento sobre el EU3.

Sólo un consejo más para quienes a día de hoy vayáis a empezar un nuevo proyecto con módulos GSM/GPRS con visión de futuro y estéis evaluando los módulos de distintos fabricantes. El consejo es que leáis la noticia del anuncio del nuevo módulo EU3 publicada en la web de Cinterion. Con especial  atención al título, “Cinterion Announces First UMTS Module to Support Seamless 3G Transition for Existing GPRS/EDGE Designs“.


Volveré a hablar sobre esto último en cuanto pueda.


www.blogElectronica.com

Posts relacionados:

1. Nuevo firmware v2.0 para los módems Siemens / Cinterion XT65 y MTX65+G Desde la semana pasada está disponible el nuevo firmware del...
2. Cómo obtener la hora con los terminales MTX y módems Siemens / Cinterion Llevo casi un mes sin escribir en blogElectronica. Y es...
3. Cinterion. Nuevos módulos GSM/GPRS LGA Hoy voy a hablar de unos nuevos módulos de Cinterion...

Como seguro sabéis Google tiene un servicio (que está pontenciando con Android, su nuevo Sistema Operativo para móviles) para la locaclización por celdas GSM. Es decir, por ejemplo, te va a permitir, mediante una aplicación en el móvil, saber qué amigos tienes a tus alrededores. ¿Y cómo hace eso? Pues detectando si algún amigo tuyo está dentro de la misma celda GSM (o próxima) a la que estás tú.
  
 
¿Y cómo sabe Google si una celda está próxima a otra?
 
Pues porque es Google y ya sabes que Google todo lo sabe. :)  Realmente es porque tiene una gran base de datos con las coordenadas GPS de todas las antenas de telefonía.

Si dáis un vistazo a la web:
http://www.codeproject.com/KB/mobile/DeepCast.aspx

veréis que esos chicos explican muy bien cómo funciona este servicio de Google y ya se han dedicado a investigar qué datos hay que pasar a esta API de Google (concretamente a http://www.google.com/glm/mmap) y lo más importante, cómo hay que hacerlo pára que ésta devuelva las coordenadas (latitud / longitud) de una determinada antena de telefonía.
 
Si leéis con atención el artículo veréis que son necesarios obtener los siguientes datos de una antena GSM para obtener dicha posición:

Cell Tower ID
Location Area Code (LAC)
Mobile Network Code (MNC)
Mobile Country Code (MCC)

 
¿Y cómo obtener esos datos con nuestros módems? En el artículo habla de RIL Windows Mobile, …
 
Eso es porque el artículo piensa en teléfonos móviles. Nosotros vamos a pensar en nuestros módems Cinterion. Afortunadamente estos estupendos módems cuentan con comandos que nos permiten obtener tales datos. Por ejemplo uno de ellos es:

AT^MONI

 
¿Ya has ejecutado el comando? Venga …

Si lo has ejecutado verás que obtienes unos datos, en mi caso:

chann rs  dBm MCC MNC  LAC cell NCC BCC PWR RXLev  C1 I chann TS timAdv PWR  dBm Q ChMod
18 21  -89 214  07 0335 5A0C   1   0  33  -103  13 I    No connection

 
Pues bien, de aquí podemos extraer que:

Cell Tower ID = 5A0C
Location Area Code (LAC) = 0335
Mobile Network Code (MNC) = 07
Mobile Country Code (MCC) = 214

 
Muy bien, con estos datos ya podemos llamar a la página siguiente y ver el resultado. Hacer click en el enlace de Test y luego, en los valores de los parámetros de la URL (mcc, mnc, lac,cid) substituir los que yo os pongo (que son los que obtengo desde mi casa ) por los vuestros y volver a cargar la página:

Test de localización GSM
  

 
¿Chulo verdad?

Obviamente la posición es aproximada, esto no es un GPS, pero sí da una aproximación bastante decente dentro de la inmensidad del territorio de dónde se encuentra nuestro módem. ¿Aplicaciones?  Eso ya queda en la imaginación de cada uno …

Y hablando de aplicaciones decir que dentro de un tiempo volveré a hablar largo y tendido del MTX-Tunnel-Advanced, pues tiene añadidas un montón de nuevas prestaciones, entre ellas, ésta que acabamos de ver.

 
¿Se puede mejorar la posición de localización GSM?
 
Sí, pero eso ya es otro post para el año que viene o para cuando tenga tiempo. Los módems Cinterion disponen de otro comando AT^SMONC que puede llegar a devolver información de hasta 7 celdas que éstén próximas al módem GSM. En esta información se devuelve el RSSI, por lo que con la posición (longitud/latitud) de estas antenas de telefonía triangulándolas en función del RSSI deberíamos poder obtener una información más precisa. Como digo esto por ahora se sale de lo que yo puedo aportaros.
 
Ya por útimo os dejo el enlace al código fuente del PHP en el que me he basado (para la consulta a la API de Google y el PHP final de blogElectronica donde he añadido al código anterior el código necesario para usar Google Maps y hacer la demostración más visual. Os lo dejo todo en una caja con lazo, no os quejaréis …

 
Espero que os haya gustado el post, yo al menos me lo he pasado muy bien.

Bueno, ahora me voy a arreglar el buggy, que he de cambiar todo el eje delantero derecho y tengo para rato … ciao

www.blogElectronica.com

Posts relacionados:

1. Modem terminal para aplicaciones de localización GPS Ultimamente he leído bastantes posts (y recibido emails) de lectores...
2. Entrenador de Módems GPRS Siemens Seguramente si lees mi blog de tanto en tanto has...

 
Hoy me voy a centrar en esta característica, en concreto en un “white paper” que han publicado los de Digi respecto a las pruebas de alcance que han hecho con estos modulitos. Y es que algo que a todos nos gusta tener como referencia cuando empezamos un diseño con equipos de comunicaciones de radiofrecuencia es  ¿cuánto alcance tiene realmente? ¿alguien ha comprobado la máxima distancia de un enlace? ¿cómo lo ha hecho exactamente y qué elementos (antenas, …) ha utilizado?
 
Pues bien, aquí pongo las pruebas de alcance que han hecho los chicos de Digi con los XBee PRO 868 y que yo os pongo aquí gustoso para vuestro uso y disfrute.
 
 

Veamos el escenario.
 
Las pruebas la hicieron hace poco más de un año en Utah, al oeste de los EEUU. Consistía en comunicar 2 modulitos Xbee PRO 868 a larga distancia. Aquí tenéis un mapa y las coordenadas GPS de ambos puntos:
 
A: 40.348582,-111.904831
B: 40.069544,-111.600838 
 

Y ya que nos dan las coordenadas del experimento y a mi me gusta hacer turismo con el Google Earth sentado en mi sillón, me he dado una vueltecita por “el escenario” para comprobar si realmente estaban encima del tejado de una casa, y sí, es verdad, doy fe
 
Aquí pongo “una foto” aproximada del escenario en 3D capturada con Google Earth:
 

 
Pues bien, uno de los extremos, (A), estaba en el tejado de una casa a 7m de altura respecto al suelo. El otro extremo, (B), a 40Km con visión directa (es decir sin obstáculos) respecto a (A). Entre (A) y (B) había una diferencia de alturas de unos 300m (recordad lo que hablamos de las zonas de fresnel).
 
Se hicieron 2 tipos de pruebas de envío y este es el esquema de montaje de los equipos:

En el extremo (A) se probó tanto con una antena dipolo de ganancia 2.1dBi como una antena Yagi de 15dBi a 900MHz. En el extermo (B) sólo una antena dipolo de 2.1dBi. En (A) se introdujo también un módulo de atenuación variable. De esta manera se puede inducir una atenuación controlada para simular posibles escenarios.
 
Las pruebas consistían en el envío de un paquete de 32bytes. En el extremo (B) se puso un loopback en el puerto serie (es decir para que cuando se reciba la trama enviada por (A) esta sea reenviada de nuevo a (A)). Se configuraron los módulos para que no hubiese reintentos y si una trama enviada no era recibida en un segundo sería considerado fallo.
 
Pues bien, estos fueron los resultados de las pruebas de comunicación a una distancia de 40Km:

Como podéis ver, para la prueba con antenas dipolo en ambos extremos, hasta introducir una atenuación de 11dB prácticamente el 100% de los paquetes llegan bien. A partir de ahí la cosa empieza a torcerse. Para la prueba con la antena Yagi en el extremo (A) vemos que hasta los 25dB de atenuación inducida casi todos los paquetes se transmiten correctamente. Podríamos decir que en las condiciones ideales el alcance con antenas dipolo es de 40Km y con un alcance (ahora sí, teórico) de unos 100Km en el caso de usar antenas Yagi de alta ganancia. Siempre todo en condiciones ideales (visión directa, zonas de fresnel, condiciones metereológicas favorables, …).
 
En resumen, aquí tenéis un material cuyo objetivo no es tanto demostrar el alcance máximo de los módulos sino el de disponer de un documento, de un experimento real en el que basarnos o del que partir cuando tengamos que usarlos en escenarios similares.
 
Espero que haya sido de interés.
 
www.blogElectronica.com

Posts relacionados:

1. Alcance de los dispositivos RF El lector de este blog que use habitualmente dispositivos RF...
2. Nuevo módulo bluetooth WT41 de Bluegiga. Hace ya tiempo hablé de los módulos WT11 y WT12 de...

 
Que bien, ¿y qué es eso de LGA?

Pues LGA significa Land Grid Array y es un tipo de encapsulado para montaje superficial, parecido a BGA. Para quien quiera saber más click aquí.

 
¿Y por qué LGA y no BGA?

Bueno, la elección no ha sido fruto de un capricho. Los ingenieros de Cinterion antes de decantarse por una u otra tecnología para su nueva gama de módulos de montaje superficial realizó cientos de pruebas y tests con las diferentes tecnologías existentes. De entre las analizadas la que mejor resultados aportó (para minimizar el tamaño del módulo, para tener el mejor contacto posible en los pads, por cuestiones térmicas, etc ) fue la LGA y por ello fue la escogida.

Si queréis saber más sobre LGA y por qué se escogió frente a BGA podéis ir a:

http://www.lga-modules.com

y hacer click en el menú “COMPARATION LGA VS BGA“. Veréis que los chicos de Cinterion se lo han currado bien. Una página además muy atractiva visualmente.

 
Por cierto, otro enlace muy interesante también es:

http://www.cinterion.com/lga-mounting.html

donde podéis ver un ejemplo de proceso de montaje LGA. Una visión bastante interesante y práctica.

 

¿Y por qué LGA, no es más cómodo y sencillo utilizar los módulos con los conectores de siempre?

Bueno, digamos que los escenarios de uso son distintos. Estos equipos LGA no substituyen a ningún modelo de los que ya hay, es una familia de módulos completamente nueva. Están pensados para producciones de grandes volúmenes donde un pequeño ahorro por placa significa un gran ahorro en el conjunto.

 
Hablas de ahorro ¿y en qué ahorro?

Pues además de ser unos módulos económicos los ahorros adicionales son el conector de placa (pues ahora va soldado), el conector de antena, los tornillos de anclaje del  módulo + separadores, o clips de montaje y la mano de obra asociada al montaje manual de cualquier tipo de tornillería.

Todo esto puede suponer unos pocos euros de ahorro por equipo, pero si las cantidades son muy grandes, como comentaba antes, el ahorro también es grande.

Para que os hagáis una idea de volúmenes, las unidades que vienen por cada reel (carrete) son 300, aunque se pueden solicitar muestras .

   
Pues es interesante  ¿y qué modelos hay en LGA?

Pues actualmente hay 4 módulos, de nombre:  EES3, EGS5, EGS3 y BGS3

Las características no las voy a poner de nuevo en el blog. Podéis darle un vistazo rápido a este documento , donde encontraréis una tabla con todas las características.

como orientación os pongo unas equivalencias:

El EES3 sería el equivalente al MC75i
El EGS5 sería el equivalente al TC65i  (recordad, con posibilidad de java embebido)
El EGS3 sería el equivalente al TC63i
Y el BGS3 sería el equivalente (en funcionalidad) al MC55i

 
Otro día comentaré para quien le interese los accesorios que proporcionar Cinterion para ayudar con este tipo de tecnilogía, que son el módulo Daisy Chain, los sockets y los módulos de evaluación.

www.blogElectronica.com

Posts relacionados:

1. Nuevos módulos Siemens / Cinterion TC65i, TC63i y MC75i Tenemos nueva familia de módems. Y es que Siemens /...
2. Controlar una pantalla SPI con un módem gprs Cinterion Hace poco tuve que echar una mano en un proyecto...
3. Clases java InPort y OutPort para los módems gprs Cinterion y terminales MTX Como vimos hace ya un tiempo, con las nuevas versiones...

www.blogElectronica.com

Posts relacionados:

1. Nuevo módem GPRS teminal MTX65 basado en el módem Siemens TC65 Matrix Electrónica ha lanzado la distribución de un nuevo modelo...
2. MTX-Tunnel-Advanced. Gateway GPRS-RS232 avanzado. Hoy me gustaría presentar un nuevo producto GSM/GPRS orientado a...
3. MTX-Tunnel - Gateway GPRS-RS232 Como dije ayer, hoy voy a presentar un nuevo producto...

Como sabéis el módulo TC65 tiene un total de 400KB de memoria RAM y 1.7MB de memoria FLASH. Es evidente que la memoria flash, FFS (File Flash System, el sistema de archivos) estará en parte ocupada por nuestra aplicación java (es decir, por los ficheros .jad y .jar) y por todos aquellos archivos extra que necesitemos para nuestra aplicación así como los propios archivos generados por nuestra aplicación java, es decir, ficheros con logs, históricos, etc etc …
 

Bueno … con 1.7MB puedo hacer un programa inmenso y me sobra ¿para qué me voy a perder el tiempo leyendo esto?
 
Es cierto que puedes hacer programas bastante grandes pero va a depender mucho de cómo los hagas y de las herramientas que estés utilizando. Si no estructuras bien tu programa puedes llegar a tener problemas serios de memoria.
 

Vaya, no lo entiendo, cuando ejecuto mi aplicación java me sale un “out of memory” y antes me funcionaba, lo único que he hecho es añadir un poco más de código. Mi fichero .jar ocupa unos 150KB y veo que cuanto más grande es mi fichero .jar menos memoria RAM libre me queda libre … ¿Cómo es esto posible? ¿Pero el programa no está en la memoria flash y los 400KB de RAM no son exclusivamente para las variables y datos de mi aplicación?
 
 
Evidentemente no. Por supuesto tus ficheros .jar y .jad están tranquilamente en la memoria Flash, sino cuando apagases el módem se borrarían. Pero piensa que el fichero .jar es un fichero comprimido (puedes abrirlo si quieres con el winrar) y dentro están los bytescode, los ficheros .class, los ficheros con código java compilado. El módem va a descomprimir esos archivos y va a cargar los necesarios en memoria RAM. De ahí que cuanto mayor sea tu programa java menos espacio libre te va a quedar en memoria RAM (o no, depende de tu programación).

Si por ejemplo eres de la vieja escuela y pese a permitir el lenguaje java una programación orientada a objetos haces una programación completamente lineal, tipo programación C, es decir, si tu aplicación consiste en un único fichero .java inmenso lleno de métodos (que tú verás como funciones de C) puedes tener serios problemas a medida que tu aplicación crezca. Si trabajas de esa manera, cuando arranques tu aplicación java, todo el código de programa lo vas a tener cargado de forma permanente en memoria RAM y podrás tener problemas serios de memoria a la larga.

La mejor manera de ahorrarse esos problemas consiste en una programación más estructurada, es decir, una programación realmente orientada objetos. Antes de ponerte a escribir código planifica tu aplicación, estructúrala en objetos creando un archivo .java (y por tanto un archivo .class) por cada objeto de tu aplicación. De esta manera cargarás en memoria pequeños archivos .class sólo cuando sean necesarios por tu aplicación, es decir, cuando necesites crear  un determinado objeto para realizar algo y destruyéndolo cuando no lo necesites, o lo que es lo mismo,  liberando memoria cuando ya no lo necesites. Si haces un programa un único fichero .java inmenso (.class inmenso) tendrás en memoria todo el código de todos los métodos te sean necesarios o no en un momento determinado.
 
 
Es demasiado tarde … ya tengo hecha mi aplicación y tengo problemas de memoria. No puedo volver a hacerla toda, tardaría semanas y mi jefe me mataría … ¿Puedo hacer algo?
 
Estás de suerte, sí (de todas maneras cuando hagas otra aplicación estructúrala mejor).  Puedes utilizar un ofuscador java. Un ofuscador, al realizar su misión, es decir, al ofuscar el código compilado, comprime todavía más los archivos .class. De hecho si creas un package mediante un ofuscador verás como el fichero .jar ocupa bastante menos, incluso la mitad. Esto te va a dar cancha para no tener que rehacer la aplicación entera pero te aconsejo una programación más estructurada en un futuro.
 
 
¿Y qué ofuscador utilizas?
 
Personalmente utilizo el de Proguard integrado en el Eclipse. Otro día ya hablaré más de él en otro artículo, por hoy ya está.
 
 
 
Hoy Sábado a ver si acabo un proyecto que tengo pendiente y al que no acabo nunca de darle el remate final, pues últimamente estoy saturado de trabajo. Un pequeño proyecto on-line que he lanzado hace pocos días en el dominio www.PisosDeAlquiler.com, un portal de cruce de ofertas de pisos de alquiler, como su propio nombre indica.

La verdad es que es uno de los mejores nombres de dominio que tengo (y tengo más de un cententar). Un dominio, como digo yo, “gran reserva del 2002″, ya que lo adquirí en aquel año. Realmente durante estos años he estado a punto de venderlo en varias ocasiones, pues he recibido algunas ofertas de compra por él. La última oferta fue de 3.000€ que me hizo dudar bastante, aunque finalmente, y más viendo cómo está el patio de la vivienda en España en el que creo el alquiler va a crecer, me lo quedé. El tiempo dirá si hice bien.
 
 
Que paséis un estupendo fin de semana

Posts relacionados:

1. Uso correcto de la Flash de los módems Cinterion TC65 y XT65 En muchas ocasiones podemos tener la necesidad de utilizar el...
2. Ejemplo de FTP Java para módems gprs Cinterion TC65 y XT65 Posiblemente en alguna ocasión tengas que hacer un programita en...
3. Localizando fallos difíciles de reproducir en los módems Cinterion TC65, XT65 Si desarrollas aplicaciones en Java para los módems gprs TC65,...

Y es que se anuncia que, después de muchos años de pruebas e historias, el sistema EGNOS está por fin operativo.
 
 
Muy bien, ¿y qué es esto del EGNOS?
 
Pues son 3 satélites geoestacionarios (dícese de aquellos que giran a la misma vez que la tierra, es decir, que siempre están en el mismo punto) colocados entre el Océano Atlántico y Europa. Son satélites añadidos a los ya existentes del sistema GPS, es decir, no los substituyen, los complementan.

Estos satélites son controlados por 40 estaciones terrestres con las que hablan. Actualmente estos satélites son gestionados por la Agencia Espacial Europea (ESA)
 
 
¿Y de qué hablan, del tiempo, de salud?
 
Pues sí, más o menos. Las estaciones terrestres envian a estos 3 satélites, información del resto de constelación de satélites GPS y sobre la salud de los mismos, desviaciones de su ruta y sobre todo, los cálculos de correcciones de estas órbitas, de timing, correcciones debidas a la atmósfera (más concretamente la ionosfera), etc.  Estos tres satélites geoestacionarios después, con todos los datos, hacen sus cálculos y nos envían una información más fiable sobre el sistema GPS.
 

 
Seguro que esto ha costado un dineral…  ¿y para qué vale?  ¿en qué me va a beneficiar?
 
Pues a todos aquellos que tengamos nuestros receptores GPS preparado para ello, colocados en navegadores, localizadores vehículos, personas, móviles, etc, en que se mejora la  precisión de la localización, pasando de unos 20 metros, a incluso 2 metros.
 
 
¿Todos los GPS valen o pueden usar el EGNOS?
 
Bastantes. De los distribuidos por Matrix todos o casi todos. Por ejemplo, para los basados en SIRF basta con enviar o usar el mensaje SIRF número 133 y habilitar la fuente DGPS con el sistema SBAS.
 
 
Me acabo de hacer un lío. ¿Qué es esto de DGPS y SBAS?
 
Estamos hablando de lo mismo. DGPS significa GPS diferencial. Es la posibilidad de que en un receptor GPS se le puedan introducir datos de entrada para correcciones y así mejorar su precisión. SBAS significa sistemas de augmentación, es lo mismo, pero engloba también otros países. Es decir, si en Europa existe el EGNOS, en Estados Unidos existe un sistema parecido,  que se le llama WAAS. En Japón también tienen sus satélites, a su sistema correctivo se le llama MSAS.
 
 
Vamos, que si me llevo mi receptor basado en SIRF a Las Vegas, USA,  ¿me va a funcionar?
 
Sí.
 
 
Me mola, pero no me he enterado de nada.
 
En la Wikipedia puedes encontrar más información: http://es.wikipedia.org/wiki/SBAS
 
 
Por cierto, ¿esto del EGNOS también se puede utilizar con el módulo GPRS+GPS de Cinterion XT65 y en el terminal MTX-65+G?
 
Pues claro. Tan solo hay que mandar el siguiente comando AT.

AT^SGPSC=”SBAS”,1,0,7,1,00000000
 
Algunas noticias relacionadas aquí.
 
 
Bueno, espero que os haya resultado de interés, desde luego a mi me lo parece y mucho. En los próximos días voy a hacer cambios en blogElectronica y puede que haya algún problema, cosas que no se vean bien, etc. El motivo es la actualización de wordpress, el core de este blog, por motivos de seguridad.
 
Otro día más

Posts relacionados:

1. Historia del Sistema Operativo Windows CE Vamos a hablar un poquito del sistema operativo Windows CE,  un...
2. El GPS - Sistema de Posicionamiento Global ¿Qué es el sistema GPS? El sistema GPS (Sistema de...

Pero como sabemos todos los que nos dedicamos a la electrónica en ocasiones aparece Murphy … y seguro que justo donde tenemos que poner el nuevo taladro ya tenemos un molesto componente . En este caso, bueno, pues obviamente la primera posibilidad es modificar el diseño del PCB y ruteado de la placa para despejar la zona del taladro. Otra solución es la que presento ahora aquí y es utilizar un clip especial de sujección (distribuido por Matrix) que fija completamente el módulo TC63i/TC65i al anterior taladro del TC63/TC65. Es muy fácil de usar y queda pero que muy bien sujeto.

Como una imágen vale más que mil palabras aquí os pongo un gráfico aclaratorio:
 

Espero que este post ayude o aclare a los que estáis en proceso de transición, que sé que soys muchos. Y es que realmente cada vez son más y más gente los que se animan a usar módems y terminales basados en Cinterion. Como se suele decir, la familia crece (y muy rápido) También se refleja en las estadísticas de este blog, en el que, como todo el lo lee sabe, el 85% de los contenidos hacen referencia a módems Siemens / Cinterion y por tanto la gente que lo visita son  en su inmensa mayoría usuarios de éstos. Para quien le interese pongo unas estadísticas de la evolución del tráfico de blogElectronica.com de los últimos 2 años y medio y del último mes que ya por fin roza las 10.000 visitas mensuales (este mes probablemente las alcance).
 

 
 
Ciao, me voy a cenar, otro día más

Posts relacionados:

1. Módulo GPRS tc65 vs tc65i Esta mañana he hecho un test muy básico comparando la...
2. Nuevos módulos Siemens / Cinterion TC65i, TC63i y MC75i Tenemos nueva familia de módems. Y es que Siemens /...
3. Compresión de archivos con J2ME en módems GPRS Siemens TC65 En muchas aplicaciones con módems GPRS es necesario almacenar datos...