Mensajes

Hola,

Depende mas bien del fabricante del Modulo Bleutooth. Eso no lo calcula el Stack de Bluetooth si no lo hace el propio modulo en la capa de seguridad.

Hombre, normalmente la gestion de numeros "seudo-aleatorios" en un sistema embebido (como es un modulo de Bluetooth) se basan en el timer o clock del propio dispositivo. Si que tendran cierta pauta, pero complicado me parece que puedas determinarla de foma clara y ademas para todas las marcas de modulos (un fabricante como Nokia (ejm) usa varias marcas de modulos bluetooth: Murata, Nokia, Texas instruments).

Puede ser una idea, pero es complicada de mirar....

Saludos,
Sir Graham.

Hola,

Depende de como se haga el tratamiento del USB, si se virtualiza a un COM.

No obstante tienes otra solucion. Si lo haces en Bluetooth y con el Stack de Microsoft, te va a vitualizar los puertos COM en el perfil del modem y lo vas hacer como si fuera un puerto serie en USB e inalambrico. ¿¿¿???

Saludos,
Sir Graham.

[XBlue Points]

Hola,

Os felicito por el gran trabajo del XBlue Point Lite

 Gracias. Pues es el Txiki de la familia. Una version economica de nuestros XBlue Points.

En que lenguaje esta hecha la interfaz?

C++ (que no es C)  mas  mucho amor y cariño.  

Y otra cosa... lo de "Un hombre posible propietario del dispositivo" como lo haceis?  Comparais el nombre con una lista inmensa?

Algo asi... pero mas elaborado. Es muy efectivo.
Entre la deteccion de tipo de movil y cosas parecidas (como el sexo del destinatario), los que reciben el mensaje suelen "fliplar" de la informacion que tenemos de ellos.

Eso es "Marketing"....     ... mas que el puro envio por Bluetooth.

Saludos,
Sir Graham.

[XBlue Point Lite]

Hola,

Que "complicao" es esto del Marketing de proximidad ...

No puedes comparar el HCITOOL con el BlueZSpammer dado que ese ultimo tambien hace una conexion con el SDP para obtener lo perfiles y ver si  tiene posibilides de envio por Obex.
Esto ultimo es costoso y realmente hara que ciertos dispositivos salgan de covertura antes de que la aplicacion termine el "scaneo".

¿Has tenido eso en cuenta?



Por cierto aqui te dejo un screenshot de nuestro nuevo producto XBlue Point Lite:



Es una version funcional para Windows de nuestros XBlue Point, con todo, pero usando un PC y a un precio mucho mas reducido. Esta disponible, con DEMO para su descarga, a finales de este mes...

Como veras tiene cosas curiosas. Es por si se te complica mucho el tema y decides probar cosas ya echas...  

Saludos,
Sir Graham.

Hola,

Para que lo entiendas es asi. Tu con un modulo, por protocolo de Bluetooth, puedes abrir 7 conexiones hacia 7 modulos de Bluetooth (diferentes o no). Pero eso es en teoria. En la practica no es asi.

¿Por que ? por que el modulo balancea el ancho de banda que tiene disponible y si no queda no abre conexion. Esto mas que en el OBex se ve con un canal de Voz (que "chupa" mucho ancho de banda). Si tu abres un canal voz en un Bluetooth 2.0 (3MBits de ancho de banda) poco mas vas abrir. Pero si lo haces en Bluetooth 1.2 olvidate de abrir nada mas ... ni incluso una simple conexion con el SDP.

Por otra parte:

"Los Threads poderosos son, pero mucho cuidado con ellos debes tener...."
Maestro Zoda.
Star Bytes.

No hay nada como los threads para tener unos enormes dolores de cabeza.... que lo sepas. En muchas ocasiones hay que usarlos (mejor solucion). Pero a la hora de desarrollar debes pensar en multiproceso... no linealmente...  si no te va salir un churro...


Saludos,
Sir Graham.

["No es lo mismo enviar por bluetooth... que hacer Marketing de proximidad..."]

Hola,

Siempre lo decimos...

"No es lo mismo enviar por bluetooth... que hacer Marketing de proximidad..."

Me da que Bluga lo acaba de comprobar cual es la diferencia del tema. Es facil realizar un envio por bluetooth, pero cuando vas a realizar una aplicacion "efectiva" de marketing de proximidad (con las necesidades que ello con lleva) veras que el margen de diseño y gestion se vuelve "mas complicado".

El tiempo que tarda en escanear y enviar a 4 moviles por ejemplo es de unos 40 segs y esto es las mejores condiciones (moviles a los que le he pillado bien el canal y todos al lado de los bluetooth usb), y claro yo lo que quiero captar es a gente que esta andando por la calle y esta solución no me sirve mucho puesto que pierdo a muchos moviles por el tiempo que se tarda.

Evidentemente es necesario realizar unas optimizaciones para que esa gestion "sea mas adecuada". Hay cosas que desgraciadamente no te puedo comentar (dado que es una pieza competitiva de nuestro software) pero te dire que SI ES factible mejorar esos procesos.

Estas son basicamente las sentencias que utilizo, uso un doble for,uno para recorrer cada uno de las 7 conexiones concurrentes que teoricamente soporta el bluetooth y otro para recorrer el hci 1 y el hci2.

Eso no tiene mucho sentido o yo no lo acabo de entender.
¿No es mejor ir ocupando los canales segun los terminales que has encontrado?(obviamente solo los factibles de realizar el envio).

¿Para que "recorrer" las posibles conexiones que dispones?.
Acaso ¿No sabes cuantas estas usando?



Por otra parte que puedas realizar 7 conexiones en bluetooth no quiere decir que te ancho de banda del modulo te de para hacerlo. El Modulo de bluetooth balancea el ancho de banda entre las conexiones abiertas y a poco grande que sea el archivo no vas a llegar a las 7 "ni de coña". Vamos ni tu ni nadie...
En multiples ocasiones hemos explicado aqui que los que usan como "gancho" comercial" para vender su herramienta el de que llegan hasta 21 conexiones concurrentes (con 3 modulos x 7 conexiones = 21) ESTAN MINTIENDO DESCARADAMENTE....
Primero por que no buscarian mientras envian (con lo que ello con lleva). Segundo por que si estas enviando ya por unos canales, el modulo no te abre mas si ve que estas consumiento el ancho de banda disponible...

Por cada envio utilizo un proceso pesado (fork).

Horror!!!!!     ¿Por que? Acaso usas aplicaciones externas para el envio? Para que necesitas usar un Fork?

No se donde indicarle que me haga un envio por la conexión 1 y otro por la 2 asi hasta 7. Y tampoco se si implementarlo mejor con threads en vez de con fork.¿podeis orientarme?

Las conexiones las crea el modulo segun se las vas pidiendo. Evidentemente un Thread es infinitamente menos pesado que un Fork.
Nuestra implementacion del XBlue Point en Linux (que la tenemos) usando 3 modulos bluetooth (el maximo que solemos poner) lleva a consumir de un 0.4 a un 0.7% del proceso de la maquina....

La duda que me trae mas loco es si se puede controlar a nivel de codigo con el obexftp o con otra cosa el tema de las conexiones simultanteas, o eso lo hace automaticamente el hardware del bluetooth.

Lo haces tu... el modulo no tiene conexiones "automaticas" sean simultaneas o no...

Nosotros llevamos "años" (desde 2004) haciendo I+D+i en ese tema...
Bienvenido... pero como estas comprobando te queda un largo camino por recorrer (me temo)...



Saludos,
Sir Graham.

Hola,

En cuanto este disponible para esta plataforma, informaremos del tema.

Saludos,
Sir Graham.

[ws2_32.libirprops.libiphlpapi.lib]

Hola,

Es que una cosa es que le indiques donde estan las librerias y otra que las incluyas.

Vamos, como cualquier otro proyecto de C / C++... 

En este caso concreto, en la zona de linkado, tienes que añadir las librerias correspondientes al tema de Bluetooth, ¿Cuales son? depende de como lo hagas el acceso a Bleutooth (con el API propio o con el Winsock).

Normalmente para tener todo tienes que incluir:

ws2_32.lib
irprops.lib
iphlpapi.lib

Pero esto es un tema muy"basico", no ya de bluetooth ... si no de programacion.... por lo que me da que no estas muy puesto.

¿Estoy equivocado?

Si no es asi, comentarte que:
Acometer un proyecto de Marketing de proximidad sin tener conocimientos extensos de programacion puede que no sea una "buena idea" (y menos en Windows bajo Microsoft Rulez).



Saludos,
Sir Graham.

[Visual Basic]

Hola,

Pues lo que te ha comentado averno.....  Esas funciones son perfectamente validas para los sockets que se usan en linux en BlueZ y en C/C++.

Aunque nosotros usamos las dos formas que comenta.

Con fcntl declaras no bloqueante.... y con el select puedes saber si el socket es esta preparado no para recibir datos... Todo esto metido en un thread....

No existen Callbacks que te "llamen" cuando se producen eventos en los sockets... tienes que estar tu comprobando constantemente el tema. Por eso el uso de threads...

Visual Basic (agggghhggggg!!!! que escalofrio me recorre la espalda)....

El VB te lo da todo echo. Pero el problema de eso es que si no tiene lo que necesitas, no puedes implementarlo "a parte".
En C/C++ lo tienes que hacer tu, pero tienes todo el control...

Aprender con Visual Basic a programar muchas veces puede ser un grave error...  Te encubre todo el funcionamiento natural de las cosas...

La "gente adulta" programa con cosas serias como C, C++, Java... no "Visual Basic" (es una opinion personal  )

Saludos,
Sir Graham.

Hola,

uhmmm... yo no he visto gestión "de Hooks" en las librerías de Socket: Poner una función de callback para eventos del tema.  Puedes en algunos sistemas operativos como el "ventanuco" interceptar el servicio de Winsock con un hook y controlar todos los sockets que se abren...

En el caso de un uso "normal": esto es controlar tus sockects desde tu propia aplicación, lo único que en teoría puedes hacer es un hilo de proceso a parte (un thread) que este testando si ha llegado información al socket. Para eso lo mas practico (que no indispensable) es hacer al socket "no bloqueante" y así puedes realizar las operaciones sin problemas...

¿Eso es lo que preguntas?

Saludos,
Sir Graham.