Estoy trabajando en un BluetoothLE dispositivo sensor, por lo que necesito para formar un uno-a-muchos de difusión de datos. Según la especificación, periféricos pueden tener un solo maestro, y debido a las limitaciones del chip y de la pila que estoy diseñando, un maestro sólo puede tener tres esclavos. Por lo que yo entiendo, Android no puede convertirse en un BLE esclavo de todos modos, así que tener mi dispositivo como maestro no es una opción.

Tanto el BT4 y especificaciones de la documentación del fabricante hablar de otro modo de operación, que se conoce como modo de transmisión. En el modo broadcast, una conexión nunca se hizo, y la aplicación de los datos se transmiten como parte de la publicidad de paquetes. Esto es exactamente lo que se adapta a mis necesidades, ya que muchos de Android/iOS teléfonos al mismo tiempo puede escanear cada paquete. Una publicidad paquete se transmite varias veces en ráfagas, por lo que sospecho que la recepción de datos a ser sobre todo confiable. Si un paquete se pierde, aquí y allá, puede ser tolerado.

Cuando esto se pone interesante, es que quiero que estos paquetes para llevar en vivo los datos del sensor, que se actualiza a una velocidad de 10-20 hz. De los ejemplos que he encontrado en la web, BLE en este modo es en su mayor parte se utiliza para la «iBeacon» tipo de implementaciones, donde se están transmitiendo datos estáticos. No puedo encontrar ninguna información sobre la forma de publicidad de los paquetes son filtrados en el Android de la pila. Podría ser que devuelven un resultado por Bluetooth dirección de hardware, o podría ser la combinación única de la dirección y de datos. La segunda opción sería trabajar para esta aplicación. Si iniciar y detener el escaneo restablece el filtro, puedo hacer algo así.

El Android documentación menciona nada acerca de cómo el dispositivo de filtrado en el método de análisis de las obras. He sido capaz de encontrar un post en la red intentando resolver este mismo problema, que tiene pendiente de respuesta: BLE: Múltiples descubrimiento de la misma periférica durante la exploración. En iOS, mi colega me informa de que hay un parámetro que se puede pasar a la función de escaneo que hace que esto sea posible.

He intentado rastrear el código de la startLeScan() la llamada en el Android de origen, pero el código es bastante complejo, y el uso de la abstracción, ha hecho difícil la identificación de la aplicación del objeto que lo contiene. El más lejano que he llegado es a un IBluetoothGatt objeto devuelto desde el BluetoothManagerService método de clase getBluetoothGatt(). Este objeto recibe la solicitud para iniciar el escaneo. Es que se creen instancias de alrededor de línea 790 de BluetoothManagerService.java en la actual revisión vivir en github. El objeto se proyecta desde el resultado de un mensaje, por lo que sospecho que tal vez el resultado es teléfono/controlador específico. Es más allá de mi experiencia para ser capaz de rastrear cualquier aún más.

Otra pregunta que me gustaría resolver es cómo rápidamente el escaneo puede ser encendido y apagado. La digitalización es una potencia intensivo de la operación, sin embargo, la transmisión de datos se producen periódicamente en una forma bastante precisa, en tiempo real temporizador. Como resultado, sería una gran optimización, si el escaneo puede ser encendido y apagado, de tal manera que la emisión y análisis son sincronizados, con el escáner de apagar el otro 90%+ de la época. Esto probablemente tendrá que ser probada experimentalmente.

Todavía estoy haciendo la viabilidad de la investigación para ver si esto es posible para nuestro accesorio para Android. Mi actual teléfono aún no se puede ejecutar la versión 4.3, así que no tengo manera de poner a prueba/hacking experimentalmente.

  • No está seguro de cuál es su pregunta aquí es.
  • ¿Cómo funciona el BLE escáner en Android filtrar los resultados? El resto del post es justo contexto.
InformationsquelleAutor mattthebaker | 2013-10-21

5 Comentarios

  1. 27

    Con Android 4.3 y 4.4 hasta el momento, parece ser un lío: Algunos dispositivos de llamada
    onLeScan(BluetoothDevice dispositivo, int rssi, byte[] scanRecord) varias veces para un dispositivo en un análisis, algunos no. No hay manera de configurar el filtrado como en iOS (véase la respuesta de
    Arkadiusz Konior). Así que ahora inicio una lista, porque no le puedo pedir a mis usuarios a una pregunta acerca de su dispositivo.

    Sin embargo, el reinicio de scaning, además, no es problema de «no filtrado» de los dispositivos. Así que, yo reinicie analizar en cada dispositivo de ahora.

    No filtrado (Continuamente llamando onLeScan())

    • Samsung Galaxy S4 con 4.2.2 uso de Samsung BLE sdk (yo soy dueño de ese dispositivo)
    • Nexus 5 con 4.4 (añadido por [vegarwe]. El dispositivo dará registros de análisis de forma continua para dispositivos cercanos durante la exploración)
    • Samsung Galaxy S3 con 4.3 (JSS15J.I9300XXUGMK6, se estaba probando en ese dispositivo)
    • Samsung Galaxy S4 con 4.3 y 4.4.2 utilizando el SDK de Android (añadido por arnaud.b, de no construir siempre)
    • HTC One con 4.4.2 (añadido por arnaud.b, de no construir el número proporcionado)

    Los dispositivos de filtrado (se aplica a Estándar)

    • Nexus 4 con 4.3, 4.4 (I propio dispositivo)
    • Nexus 7 2013 4G con 4.4.2 (KOT49H, se estaba probando en ese dispositivo)
    • Samsung Galaxy S4 mini con 4.2.2 (estaba probando en este dispositivo)
    • Motorola Moto X (añadido por user1603602, no hay información acerca de la versión de android siempre)
    • Motorola Moto G con 4.3 (falcon_umts, Mi dispositivo de pruebas)
    • Sony Xperia Tablet Z Wifi con Android 4.3 (Construir 10.4.B.0.577, Modelo SGP311, mi dispositivo de pruebas)
    • OnePlus One con 5.0.1 y 5.1.1 (Cyanogen 12.1)

    Desconocido comportamiento de filtrado (por Favor, ayuda para asociar el dispositivo a un determinado grupo)

    • Nexus 7 2013 (comportamiento Diferente es reportado como aquí. Pero he leído más informes que pertenecen al primer grupo).
    • Otros SAMSUNG, HTC, Motorola, …, dispositivos
    • Parece que la misma versión de android no tienen el mismo comportamiento en todos los dispositivos. Así que supongo que este es el controlador de bluetooth que filtrar los dispositivos ? (Cualquier experto puede confirmar eso ?) También, Nexus 5 utilizar el Snapdragon 800 (8974-AA) chipset, lo mismo que algunas versiones del Samsung Galaxy S4 (GT-I9506). Galaxy S4 tiene otras versiones: GT-I9505 basados en snapdragon 600 (APQ8064T) y GT-I9500 (exynos) Nexus 4, sony xperia tablet Z utilice el mismo chipset (snapdragon s4 pro APQ8064). Moto X y Moto G también está basado en un procesador snapdragon s4, Nexus 7 2013 tiene diferentes chipset (todos ?) basado en el snapdrago
    • Para mi opinión depende de la BLE de aplicación (software) que puede depender del chipset. Por ejemplo, el fabricante de circuitos podría proporcionar la BLE aplicación para el fabricante de teléfonos móviles. También he visto, que continuamente escaneo es más, a menudo en referencia A las implementaciones actuales. Significado SGS4 fue el primer dispositivo que consiguió BLE implementado y por lo tanto todavía está en algún tipo de modo de desarrollador. Después de todo, usted no debe contar con la continua modo de escaneo. Lo más probable es eliminado con más actualizaciones.
    • No filtrado (Continuamente llamando onLeScan()) Galaxy S2 M250s(Probado)
    • Cualquier información acerca de los dispositivos de filtrado usando el nuevo Android 5.0 BluetoothLeScanner? Hacer que dejara de filtrado?
    • Desde mi prueba con el Nexus 4 & 5 sólo, mis experimentos han encontrado que es de hardware-dependiente, no OS dependientes. Mi Nexus 4 filtros en ambos 4.4 y 5.0, mi Nexus 5 no se filtro en ambos 4.4 y 5.0 — ¡qué lío!
    • Comprobar con la nueva API21 también..pero el resultado mismo. Hay API para filtro de escaneo basado en el dispositivo/fabricación/Servicio de información, Pero no hay acceso a más de duplicados de anunciar los datos de la API. Suerte aquí ?
    • Xiaomi redmi note 2 no es filtrado también.

  2. 14

    El texto en las páginas 2535-2536 en la especificación de Bluetooth (Core_v4.1.pdf) acerca de duplicar la publicidad de los informes es poco claro. Sin embargo, el texto en la página 1258 está claro. Especifica un Filter_Duplicates parámetro para la HCI_LE_Set_Scan_Enable comando. En la versión de Android 4.4 (Kitkat) este parámetro 0x00 (Duplicado activado el filtrado).

    Hay una manera sencilla de averiguar si el filtrado se realiza en el chip Bluetooth de versiones de Android 4.4 (Kitkat). Hacer que el teléfono de un desarrollador de teléfono, introduzca las opciones de desarrollador y de verificación «Activar Bluetooth HCI snoop registro». A continuación, APAGUE el Bluetooth y EN vez de hacer la configuración de la mordedura. A partir de ahora todas las HCI de paquetes entre el procesador y el chip Bluetooth serán almacenados en el teléfono en un fichero del que es tirado por adb pull/almacenamiento emulado/legacy/btsnoop_hci.registro . Este no es un archivo de texto y necesitas un programa de http://www.fte.com/products/default.aspx o wireshark para ver btsnoop_hci.registro. Para wireshark necesita una bastante reciente versión, porque las versiones anteriores no admite BLE. Mi experiencia es que nunca hay ningún tipo de filtro en el chip Bluetooth, es decir, la HCI Evento «LE Informe de Publicidad de Evento
    «es enviado por cada ADV_IND
    y ADV_NONCONN_IND
    que el chip Bluetooth que recibe. Esto va para los teléfonos con Bluetooth chips de Qualcomm/Atheros WCN 3680 y Broadcom BCM 4339.

    Corrección: la ruta de acceso a btsnoop_hci.el registro puede ser diferente dependiendo del fabricante del teléfono. Usted puede encontrar la ruta correcta por adb shell cat/etc /bluetooth/bt_stack.conf | grep BtSnoopFileName

  3. 8

    Estoy desarrollando una aplicación para Android 4.3 (Nexus 4&7) el uso de BLE y de mis observaciones de escaneo devuelve el mismo dispositivo varias veces si no había SCAN PETICIÓN de envío de vuelta con el periférico.

    Dispositivo puede anunciar en 2 formas: activa y pasiva. En modo pasivo, el dispositivo periférico es sólo la publicidad de todos los datos y no escuchar después de enviar paquetes periódica. Es sólo envío, de dormir, de envío, de dormir…
    En el modo activo el sensor también se anuncia pero el mensaje es tan corto como sea posible. Después de enviar cambia a escuchar algo de tiempo muy corto. Cuando se escanea, detecta el mensaje corto, se envía inmediatamente ESCANEAR la SOLICITUD de comando para el periférico y obtiene respuesta con más detalles. Tan lejos como puedo ver Android no envió a ESCANEAR SOLICITUD varias veces durante un escaneo.

    Supongamos que tenemos 2 dispositivos en el rango. Uno es f.e. Nórdicos de la nRF sensor de temperatura (pasivo publicidad) y otra connectible dispositivo. He recibido el siguiente análisis de respuesta:

    11-10 21:32:54.281: D/BluetoothAdapter(13468): startLeScan(): null
    11-10 21:32:54.281: D/BluetoothAdapter(13468): onClientRegistered() - status=0 clientIf=4
    11-10 21:32:54.321: D/BluetoothAdapter(13468): onScanResult() - Device=CD:61:1A:A8:BC:BE RSSI=-94
    11-10 21:32:55.122: D/BluetoothAdapter(13468): onScanResult() - Device=CB:32:81:CF:FD:00 RSSI=-61
    11-10 21:32:56.414: D/BluetoothAdapter(13468): onScanResult() - Device=CB:32:81:CF:FD:00 RSSI=-62
    11-10 21:32:57.715: D/BluetoothAdapter(13468): onScanResult() - Device=CB:32:81:CF:FD:00 RSSI=-61
    11-10 21:32:59.016: D/BluetoothAdapter(13468): onScanResult() - Device=CB:32:81:CF:FD:00 RSSI=-63
    11-10 21:33:01.609: D/BluetoothAdapter(13468): onScanResult() - Device=CB:32:81:CF:FD:00 RSSI=-63
    11-10 21:33:02.901: D/BluetoothAdapter(13468): onScanResult() - Device=CB:32:81:CF:FD:00 RSSI=-63
    11-10 21:33:04.212: D/BluetoothAdapter(13468): onScanResult() - Device=CB:32:81:CF:FD:00 RSSI=-62
    11-10 21:33:04.282: D/BluetoothAdapter(13468): stopLeScan()

    Como se puede ver el connectible dispositivo mostró sólo una vez, mientras que el otro 7 veces.

    Otra pregunta que me gustaría resolver es cómo rápidamente el escaneo puede ser encendido y apagado. La digitalización es una potencia intensivo de la operación, sin embargo, la transmisión de datos se producen periódicamente en una forma bastante precisa, en tiempo real temporizador. Como resultado, sería una gran optimización, si el escaneo puede ser encendido y apagado, de tal manera que la emisión y análisis son sincronizados, con el escáner de apagar el otro 90%+ de la época. Esto probablemente tendrá que ser probada experimentalmente.

    De la frecuencia de barrido depende del dispositivo. Además de la publicidad se hace generalmente en 3 canales: 37, 38 y 39 de aumentar la probabilidad de ser encontrado. Sin embargo, esto podría ser muy buena idea para obtener la publicidad de los paquetes de ‘activo’ dispositivos varias veces.

    • He probado el mismo caso en el Samsung S4 con la oficial 4.3 de actualización y recibo las actualizaciones de los dispositivos varias veces. En realidad tengo actualizaciones a partir de 61:1A:A8:BC:SER demasiado a menudo que la posterior. Así que, en conclusión, que depende de qué dispositivo estás utilizando. No es bueno en absoluto para los desarrolladores :/
    • Gracias por comentar, esto es realmente útil la información. Es interesante y útil que el dispositivo devuelve varios resultados de la exploración al uso de la pasiva de la publicidad modo. En esta aplicación, lo ideal sería que me gustaría Android a comportarse como el pasivo del escáner con el anuncio de que … para que yo pueda tener un dispositivo de radiodifusión de datos, así como permitir una conexión para cambiar la configuración.
    • Con respecto a cambiar el Android de Escáner de encendido y apagado: he conseguido en mi prueba de la aplicación para cambiar el startBleScan de encendido y apagado, y recibir activa anuncio de paquetes a una tasa de 20 hz. No es, lamentablemente, algo de latencia en el teléfono cuando se enciende y se apaga, por lo que el proceso de escaneo termina siendo activo de 80% a 90% del tiempo. En el más bajo de paquetes de tarifas de este método puede ser viable como un «Observador» hack.
    • Un caso de uso típico para ejecutar el escáner es capaz de presentar al usuario una lista de dispositivos cercanos, ordenados por la persona con la mejor señal. En este caso usted realmente desea que las actualizaciones para los dispositivos continuamente para poder actualizar y ordenar la lista (basado en el RSSI)
  4. 6

    El real bluetooth especificación dice:

    Duplicar la publicidad de los informes no están obligados a ser enviado al Host.
    Un duplicado de la publicidad informe es un informe de publicidad para el mismo
    dirección del dispositivo, mientras que la Capa de Enlace se queda en la Exploración del Estado. El
    la publicidad de datos puede cambiar; la publicidad de datos o escanear los datos de respuesta es
    no se considera significativo cuando la determinación de duplicar la publicidad
    informes.

    De acuerdo a la especificación esto se aplica dentro de un período de barrido, que sugieren que la correcta forma de evitar esto es para detener y reiniciar la digitalización cada vez que recibe un anuncio.

    Basado en mi experiencia con BLE, parece que el envío de datos de la variable en la publicidad no es sólo una muy buena idea. Casi todo lo que se supone que los datos de los anuncios no cambia. Si desea enviar los datos de la variable (por ejemplo, las lecturas del termómetro), entonces es mucho mejor en realidad se conecta al dispositivo y lo hacen a través de una característica. Es más fiable y utiliza mucha menos energía. El inconveniente es que sólo se pueden conectar hasta 8 dispositivos a la vez.

    Anuncios están diseñados para detectar la presencia de dispositivos y la identificación de ellos.

    • También tenga en cuenta que hay una nueva BLE escáner de la API de Android 5.0. Puedo obtener cada anuncio en mi Nexus 4 con Android 5.0. (Los anuncios son espontáneos, no conectable.)
    • Lo u significa aquí ..» recibe cada anuncio», son u obtener continua(duplicado) de paquetes ?
    • Sí en un Nexus 4 me fue notificado sobre cada anuncio de paquetes, incluso si eran idénticos. Esto está permitido el comportamiento, pero también es permitido para no hacerlo. La especificación es demasiado indulgente.
    • Esto es interesante..¿u cheque cruzado en otro móvil también? También, Como usted sugiere «Esto está permitido el comportamiento, pero también es permitido para no hacerlo» entonces hay manera de conseguir idea de que la publicidad ha sido detenido por Periférico !!
    • No hay manera de detectar cuando la publicidad tiene que se detuvo – usted puede simplemente esperar un poco y ver si usted recibe cualquier tipo de publicidad paquetes o no. Como ya he dicho, si quieres recibir todos los anuncios, a continuación, usted tiene la parte superior detener y reiniciar el escaneo cada vez que recibe uno. Yo no he probado eso.
    • Sí, el mismo que yo estoy haciendo. Pero algunos de ROM-BLE de la implementación de tomar el tiempo para encontrar la publicidad de paquetes, mientras que reiniciar la digitalización(4 Sec I;m uso). Cualquier sugerencia sobre él.
    • Sí me he dado cuenta de esto también. Creo que es una característica de ahorro de energía -, mientras que «escaneo» creo que los dispositivos no están obligados a recibir en los tres canales de publicidad 100% del tiempo, por lo que perder un montón de publicidad paquetes. Creo que no hay ninguna manera alrededor de ella. En Android 5 no es SCAN_MODE_LOW_LATENCY, que puede ayudar.
    • Sí he comprobado eso, pero no encontró ninguna diferencia, en este caso..que todavía se requiere reiniciar la exploración y que tomarnos el tiempo de todos modos. E incluso «CALLBACK_TYPE_ALL_MATCHES» decir «Desencadenar una devolución de llamada para cada Bluetooth anuncio que coincide con los criterios de filtro», pero que también no ayuda.

  5. 0

    En iOS este indicador se denomina CBCentralManagerScanOptionAllowDuplicatesKey. Pasando a la función de análisis de causas de notificación para cada anuncio de paquetes. No pude encontrar productos similares de la bandera en Android.

    • Eso es cierto! Debe haber sido algo similar, al menos en Android 4.4 para evitar esos comportamientos diferentes y ser la predeterminada, el que cumple con el estándar.

Dejar respuesta

Please enter your comment!
Please enter your name here