Con Bluetooth Low Energy, especifica una ventana de escaneo (cuánto tiempo escanear) y un intervalo (cuánto tiempo esperar entre escaneos).
¿Habría alguna diferencia entre escanear 10 ms cada 100 ms o escanear 1 segundo cada 10 segundos? ¿Parece que la posibilidad de que dos dispositivos se encuentren (que sus radios estén encendidas simultáneamente) debería ser igual en ese caso?
¿Existe una fórmula simple para calcular la ventana/intervalo correcto en función del tiempo máximo permitido para conectarse?
De acuerdo con la especificación básica de Bluetooth 4.0, el período de tiempo de los "eventos publicitarios" se muestra a continuación para los diferentes tipos de paquetes publicitarios:
ADV_IND: el período de tiempo de los paquetes de publicidad conectables y escaneables generales varía de 20 ms a 10,24 s en pasos de 0,625 ms.
ADV_DIRECT_IND: el período de tiempo de los paquetes de anuncios dirigidos es inferior o igual a 3,75 ms. Este tipo de eventos publicitarios pueden ocurrir consecutivamente solo durante 1,28 s. Esto es para establecer una conexión rápida (si hay un dispositivo escuchando).
ADV_NONCONN_IND: el período de tiempo de los paquetes de anuncios no conectables y no escaneables varía de 100 ms a 10,24 s en pasos de 0,625 ms.
ADV_SCAN_IND: el período de tiempo de los paquetes de anuncios escaneables varía de 100 ms a 10,24 s en pasos de 0,625 ms.
Por lo tanto, a menos que sepa el tipo de dispositivo que está escaneando, un buen enfoque sería escanear continuamente durante alrededor de 11 (máximo) segundos para ver si hay algún dispositivo publicitario alrededor. La frecuencia con que haga esto dependerá de la cantidad de batería o energía disponible.
Espero que esto ayude.
Hay otro aspecto de esto que se está perdiendo en las otras respuestas. Según la especificación Core BLE, solo se mira un canal de publicidad durante cada scanInterval y se rota al siguiente de los 3 canales con cada intervalo. Entonces, si hay interferencia de RF en ese canal, es posible que no vea el dispositivo incluso si tiene scanWindow igual a scanInterval para realizar un escaneo continuo.
El dispositivo periférico BLE que hace publicidad normalmente rotaría a través de los tres canales publicitarios en secuencia muy rápidamente durante cada parpadeo publicitario. Por lo tanto, el mejor algoritmo de escaneo del dispositivo central tendría ventanas e intervalos más cortos para verificar secuencialmente cada canal de publicidad. Aparentemente, Apple usa una ventana de escaneo de 30 ms con un intervalo de escaneo de 40 ms en iOS con aplicaciones en modo de primer plano. Eso significa que cada canal de publicidad será revisado cada 40 ms. Según la especificación del núcleo BLE:
Cada evento publicitario se compone de una o más PDU publicitarias enviadas sobre índices de canales publicitarios utilizados. El evento publicitario se cerrará después de que se haya enviado una PDU publicitaria en cada uno de los índices de canales publicitarios utilizados (consulte la Sección 4.4.2.1) o el anunciante puede cerrar un evento publicitario antes para acomodar otra funcionalidad.
Otro aspecto muy importante es que el dispositivo Periférico establezca un intervalo de publicidad que sea relativamente principal en comparación con el scanInterval en el dispositivo Central . Es por eso que Apple especifica intervalos publicitarios específicos. Si tuviera que elegir un scanInterval de 100 ms con una scanWindow que fuera más pequeña, digamos 80 ms y tuviera un intervalo de publicidad de 1000 ms (1 segundo), entonces podría tener mala suerte y estar siempre publicitando durante los 20 ms cuando el dispositivo Central no estaba escaneando durante cada scanInterval. En realidad, la especificación del núcleo BLE agrega un intervalo aleatorio de 0 a 10 ms al intervalo de publicidad, lo que ayuda a evitar un punto muerto completo, pero realmente hace más para evitar que la publicidad de varios dispositivos casi exactamente al mismo tiempo interfiera entre sí para siempre.
Para todos los eventos publicitarios no dirigidos o eventos publicitarios dirigidos conectables que se usan en un modo de ciclo de trabajo bajo, el tiempo entre el inicio de dos eventos publicitarios consecutivos (T_advEvent) se calcula de la siguiente manera para cada evento publicitario:
T_advEvent = advInterval + advDelayEl advInterval será un múltiplo entero de 0,625 ms en el rango de 20 ms a 10,24 s. Si el tipo de evento publicitario es un tipo de evento no dirigido escaneable o un tipo de evento no dirigido no conectable, el advInterval no será inferior a 100 ms. Si el tipo de evento publicitario es un tipo de evento no dirigido conectable o un tipo de evento dirigido conectable utilizado en un modo de ciclo de trabajo bajo, el advInterval puede ser de 20 ms o más. El advDelay es un valor pseudoaleatorio con un rango de 0 ms a 10 ms generado por la capa de enlace para cada evento publicitario.
Piensa en tener dos frecuencias cerca una de la otra y cómo obtienes una frecuencia de pulsación de su diferencia. Eso es esencialmente lo que puede suceder entre scanInterval y el intervalo de publicidad. Apple hizo un trabajo decente con su configuración para esto, por lo que seguir sus estándares no solo funcionaría bien para iOS sino también para Android. El modo de primer plano de Apple de 30 ms scanWindow con 40 ms scanInterval significa que, para un intervalo publicitario base de 1022,5 ms, verá el dispositivo en 1 segundo, aproximadamente 3/4 partes del tiempo y siempre en 2 segundos, suponiendo que no haya interferencias de radiofrecuencia que oscurezcan el paquete publicitario. . En el modo de fondo con una ventana de exploración de 30 ms y un intervalo de exploración de 300 ms, el tiempo medio se convierte en 5 segundos y el máximo habitual se convierte en 19 segundos, aunque con muy mala suerte de los cambios aleatorios, podría ser un poco más largo.
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
Los intervalos de publicidad periféricos recomendados por Apple son 152,5, 211,25, 318,75, 417,5, 546,25, 760, 852,5, 1022,5, 1285 ms.
La respuesta de @EarthLord me parece engañosa y, por lo tanto, quiero compartir mi respuesta:
Creo que no comprende qué es un intervalo y una ventana en ese escenario específico. Una ventana especifica un tiempo en el que un dispositivo escucha anuncios y, opcionalmente, solicita registros de escaneo. El intervalo define el tiempo entre dos ventanas consecutivas.
En el Bluetooth Core Spec 4.0 dice
Los parámetros scanWindow y scanInterval serán menores o iguales a 10,24 s . scanWindow será menor o igual que scanInterval . Si el host establece los parámetros scanWindow y scanInterval en el mismo valor, la capa de enlace debe escanear continuamente .
Lo que significa que establezca ambos en 5 fotogramas y tendrá un escaneo continuo. Sin embargo, si realiza un escaneo activo (lo que significa que solicita una respuesta de escaneo), no debe hacerlo. Cualquier periférico alimentado por batería será succionado muy rápido.
En su lugar, defina un intervalo que funcione para su aplicación y establezca una ventana de exploración que sea más pequeña que ella.
Sin embargo, no creo que haya algún valor predeterminado para esto.
HL-SDK