Hola,

El uso de inhibidores para la banda de GSM/GPRS/UMTS es ilegal. El tema es muy sencillo: las operadoras pagan al estado un buen dinero para el uso de la licencia de utilizacion de esas frecuencias, por lo que alguien ajeno no puede "emitir" el las mismas (operacion fundamental de un inhibidor).

Puedes percatarte del uso de un inhibidor con un analizador de espectro. Son caros (de echo el mas barato para esa banda esta entorno a los 300€). Con eso puedes ver si realmente existe un inhibidor.

Tambien las operadoras tienen un sistema de seguridad en sus BTS (antenas) que comprueban la cadencia de error de conexion en sus comunicaciones. Esto ya lo comprobamos nosotros con telefonica y unas pruebas que hicimos con un inhibidor  .
Si la antena de telefonia esta cerca puede detectar la "perturbacion" y entonces mandan un tipo a rastrear con una analizador de espectro por el entorno.

Yo pienso, igual me equivoco, que al margen de las historias que tengas con tu vecino, no creo que tenga un inhibidor. Es mas probable que la operadora haya restringido el area de covertura de 3G que tenias (o que simplemente se haya estropeado temporalmente esa instalacion).

Saludos,
Sir Graham.

Hola,

Has posteado el tema en los foros de EndoraSoft tambien, creo que alli, ya te han contestado.

Saludos,
Sir Graham.

El tema ha sido movido a Telefonía Móvil.

https://foro.elhacker.net/index.php?topic=270189.0

Hola,

Con modulos de clase 2 (los dispnibles en los terminales telefonicos actuales) la tringulacion es bastante complicada. El calculo de distancia a partir de los dB de potencia obtenidos es muy "pseudo-aletorio".

Resumiendo: No tendrias una precision buena, mas bien pobre.

Hola,

El problema es que Java (j2me) en Windows Mobile es muy complicado. Microsoft no quiere que se ejecute en pos de C# y SUN no saca maquina virtual.

Con lo cual las unicas positibilidades son maquinas virtuales de 3º que funcionan como funcionan....

Tecnicamente seria factible (habria que ver la compatibilidad) pero se ve que comercialmente no se hace. ¿¿¿???

Nosotros programamos todo en C++ en entornos multiplataforma. Por ello podemos portar la misma aplicacion en WM y Symbian. Al ser C++ no de pendemos de la maquina virtual y aprovechamos todo el rendimiento del dispositivo.

Con esto te quiero comentar que las aplicaciones en Java, supuestamente tienen mas compatibilidad, pero su rendimiento y capacidad de acceso a hardware esta mas limitado. Asi que casi es mejor tener una aplicacion especifica o como en nuestro caso portable facilmente.

Me temo es lo que hay....

Saludos,
Sir Graham.

Hola,

Posiblemente nosotros saquemos nuestra herramienta XBlue Point Mobile (que es gratuita) a versiones de Mobile.
(Actualmente la tenemos en Symbian Serie 60 2º edition)



Con eso no es necesario el API JSR 82.  

Saludos,
Sir Graham.

Hola,

Wifi a diferencia de Bluetooth, no tiene un Stack de protocolos integrado en el S.O. Eso con lleva a que para que exista un intercambio de informacion DEBE existir una aplicacion es profeso en ambos puntos de comunicacion: en el terminal y en el PC.

A parte que Bluetooth esta diseñado y ha sido creado justamente para eso: Sustituir el antiguo cable de comunicacion serie/USB de los terminales para hacer lo inalambricamente y con compatibilidad descenciente (amen de consumo de energia etc...). Wifi fue diseñando para convertir de forma inalambrica una conexion ethernet.

Aunque desde fuera esto pueda parecer lo mismo. No lo es. Por eso es mas practico que te compres un "misero" modulo dongle de bluetooth, se lo conectes a tu portatil e intercambies los datos por bluetooth. Por mucho que tu laptop tenga Wifi.

Saludos,
Sir Graham.

Hola,

La programacion de modulos de Bluetooth "normalmente" se realiza a traves de un Stack de Bluetooth. Esto viene integrado con el S.O.  El Stack de bluetooth cumple dos misiones:

- 1º Tener un API (Application Program interface). Una serie de funciones a las que puedes llamar para hacer cosas.

- 2º Tener una pila de protocolos y unos "servers" por defecto disponibles para cada perfil. Ejm en el caso del Obex es el que recibe el fichero de forma remota y lo graba.

Este concepto de Stack de Bluetooth es valido para Windows, Linux, Symbian o donde haya un S.O tanto propietario como libre para aplicaciones de terceros.

En Linux el Stack mas usado (por no decir el unico) es el BlueZ.

http://www.bluez.org/

Dependiendo de la distribucion que uses puede venir o no. Pero siempre esta disponible para su descarga tanto a nivel de usuario de S.O. o con las librerias de desarrollo para el mismo.

Puedes ver los recursos de desarrollo en su pagina.

http://www.bluez.org/development/

Primero No obstante, independientemente del stack y consecuentemente el S.O que elijas para hacer cosas, es muy importante tener nociones basicas de como funciona el Bluetooth.  Los procesos de Inquiry, conexiones, etc...
Si no los conceptos del Stack te sonaran a chino.

¿Que lenguaje utilizar?  
En Linux por razones obias e historicas: C o C++. Es el lenguaje nativo de este S.O. (De echo C se desarrollo para hacer el UNIX, del que a su vez parte LINUX).

Yo personalmente, por las limitaciones que tiene Java en el uso de perifericos de hardware (que si no tienes el API JSR adecuado olvidate), me decanto siempre por C o C++ (preferible este ultimo si el proyecto pasa de 3000 lineas).

Java solo lo usamos en algunos moviles en los que no tienes S.O libre (sin uno propietario del fabricante: ejm serie 40 de Nokia) y no tienes otra opcion que programar en Java. Pero tanto en Windows, Linux o Symbian (y por supuesto Windows Mobile) nosotros siempre usamos C++.

Espero que esto te valga para situarte...

Saludos,
Sir Graham.

Hola,

Si lo que quieres es eficacia en las operaciones de Bluetooth, vete olvidando, repito olvidando de:

- Usar procesos con scripts.
- Usar aplicaciones externas con el HCItool o ObexFTP.

Todo lo antes mencionado, es presuponiendo que sabes desarrollar aplicaciones en C y que has manejado "algo" el stack de Bluetooth BlueZ.

No tengo muy claro lo que quieres hacer. Si lo que estas tratando es de realizar una herramienta de marketing de proximidad te habras dado cuenta que no es una cosa sencilla. Nosotros como sabras somos expertos en ese campo y para elaborar una buena herramienta como XBlue llevamos años.

Siempre digo que:
"Mandar por Bluetooth no tiene nada que ver con marketing de proximidad por Bluetooth".

Cuando intentas el tema entiendes las diferencias.

Saludos,
Sir Graham.

Hola,

El planteamiento de controlar un modulo de Bluetooth desde un microcontrolador en vez de una plataforma mas completa con microprocesador cambia radicalmente desde que no "existe" un Stack de Bluetooth.

Aqui tienes dos posibilidades. Siempre partiendo que los modulos de Bluetooth tenga chipset de CSR (Cambrige Silicon Radio). Hay muchos fabricantes que lo utilizan para sus modulos.

A este chipset se le puede (con la flash apropiada) mandar comandos serie (como los comandos AT) para hacer cosas, o programar internamente una maquina Virtual que lleva (en C) para que el propio modulo ejecute una aplicacion tuya, aparte de las tareas de Bluetooth.

Usar desde un microcontrolador el interface HCI es muy complicado y elaborado. Mas de lo que la memoria del micro puede hacer.

Deberias tomar alguno de los caminos antes mencionados.

Saludos,
Sir Graham.