hcitool scan tarda mucho

Iniciado por Samy4ever, 25 Agosto 2009, 12:38 PM

0 Miembros y 1 Visitante están viendo este tema.

Samy4ever

Hola,

tengo un bluetooth. Lanzo hcitool scan y me escanea en busca de móviles. SI quiero que me vuelva a escanear, tarda unos segundos en poder hacerlo.

NI siquiera con dos bluetooth desde el mismo PC puedo escanear ka 2a vez justo después de la primera (usando un bluetooth diferente para cada escaneo).

Cómo es eso? Cómo hago para que los escaneos sean seguidos?

Gracias

SirGraham

Hola,

Se puede hacer lo que comentas, siempre que uses Threads diferentes. No obstante me da la sensacion por lo que preguntas que no entiendes muy bien como funciona el inquiry del Bluetooth.

Otra opcion que nosotros hemos probado es hacer el Inquiry no bloqueante.

Saludos,
Sir Graham.
   

Samy4ever

#2
Hola, gracias por responder.

No, la verdad es que no. Sólo tengo dos scripts iguales en csh, los dos lanzan el hcitool pero usando diferentes dispositivos bluetooth (cada uno tiene la MAC correspondiente indicada).

Me puedes orientar acerca de los threads o bien de como lanzarlo en modo no bloqueante?

Por que en scripting diria que no puedo lanzar threads, pero quizá un programa en C que lance threads, el cual cada uno ejecuta el script, funcionaría?

Muchas gracias por tu ayuda,
Samy

Edito: un inquiry y un obex para mandar un mensaje funcionaría, o al ser bloqueante si está sniffando no puedo usar ningun OTRO bluetooth para mandar mensajes o lo que sea?

EDITO2: Ya que estamos... No puedo mandar dos mensajes a la vez desde dos dispositivos bluetooth distintos?

EDITO3: Buscando buscando... Cuando dices de lanzarlo en modo no bloqueante te refieres a usar las librerías bluetooth.h, hci.h y demás, para hacer mi propio inquiry? Por una parte... Cómo puedo usar eso para que no sea bloqueante? Y por otra, como puedo aprender a usar ese código? A base de prueba-error o hay algun sitio o cosa que me pueda ayudar... BUf que perdido voy, gracias por tu ayuda.

EDITO4: He probado a hacer un hcitool scan por un dispositivo y a un obexftp por otro y si me deja... Aunque no me soluciona los problemas de arriba.

SirGraham

#3
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.
   

Samy4ever

#4
Hola,

Sí sé programar en C pero nunca he tocado el stack del bluetooth. Donde se puede aprender a usarlo o a empezar a tener una idea de qué hacer?

Es programando usando las funciones de bluetooth.h, hcid.h y demás? O me confundo?

No estoy intentando hacer nada así. Leí sobre tu XBlue aquí y me resultó interesante y estaba curioseando, me gustaría hacer el trabajo final de carrera de algo así.

Aún no he pensado de qué hacer el PFC exactamente pero me gustaría que fuera algo relacionado con el tema, pero no sé por donde pillar lo del stack... Me puedes orientar?

Samy

Edito: estas cosas mejor en C o en java? Por qué?

SirGraham

#5
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.
   

Samy4ever

Hola SirGraham!

Muchas gracias por tu ayuda, ya tengo un punto de partida. Aunque me he llevado un poco de desilusión porque al estar el obex ya escrito, el hcid.c y demás (claro, es código abierto, no lo había pensado...), no sé yo si me podran aceptar un PFC sobre esto puesto que en principio "ya está hecho".

De todas formas, muchísimas gracias por tu ayuda!! Se agradece. Eso si, he visto el código y no sé como vosotros fuisteis capaces de entenderlo... jejeje

Samy