ios - tecnologia - Bluetooth Low Energy-actualizar un valor característico repetidamente

swift bluetooth tutorial

Question

Pregunta de seguimiento en Ingeniería Eléctrica Stackexchange

Quiero escribir el valor de una característica de Bluetooth de baja energía repetidamente en un corto período de tiempo (como un posible caso de uso, imagine un mouse).

• La característica con un UUID de 128 bits tiene 20 bytes de longitud. Por lo tanto, se puede escribir en una sola transacción de baja energía.
• Las escrituras se producen a una velocidad de 50 Hz, que es igual a una escritura cada 20 ms .
• Por lo tanto, se escriben 20 * 50 * 8 = 8 kbit / s .
• Estoy usando el modo Comando / Escritura sin respuesta para escribir la característica. Por lo tanto, no se producen acuses de recibo en la capa de atributo.
• No hay otros dispositivos Bluetooth o Bluetooth de baja energía conectados. Nada se realiza a través de WLAN. No se leen ni escriben otras características durante las pruebas.

Pruebo el programa enviando paquetes que contienen números de secuencia de un iPhone 4S. El número de secuencia se incrementa en uno después de cada paquete enviado.

En el lado receptor, se utiliza una placa de desarrollo programable, que incorpora un chip BLE CSR1000 , que recibe los paquetes e imprime los números de secuencia recibidos en la conexión en serie.

Mis problemas son los siguientes:

• Después de algún tiempo, los paquetes comienzan a caer. Los primeros ~ 100 paquetes funcionan bien a 50 Hz. A partir de entonces, los paquetes empiezan a caer.

             0x00 - 0x46   received
              0x47, 0x48   missing
  0x49, 0x4a, 0x4b, 0x4c   received
                    0x4d   missing
  0x4e, 0x4f, 0x50, 0x51   received
                    0x52   missing
  0x53, 0x54, 0x55, 0x56   received
                    0x57   missing
  ...

  Muy a menudo, un paquete de cuatro paquetes se transmite bien (rara vez, solo 2 paquetes). Entonces, faltan 1-7 paquetes.

  Cuando reduzco el tamaño del valor característico, el problema aún persiste.

  Cuando escribo a 100Hz en lugar de a 50Hz, la imagen es la misma, solo que las caídas comienzan a ocurrir después de alrededor de 35 paquetes y que se caen de 5 a 7 paquetes entre la transmisión correcta de cuatro paquetes.

  Con los paquetes perdidos, la velocidad de transmisión resultante es de alrededor de 5 kbit / s, independientemente de la frecuencia de escrituras. Esto está claramente por debajo de los ~ 305 kbit / s que deberían ser técnicamente posibles a través de Bluetooth Low Energy.

• El problema también se produce en la dirección opuesta, cuando envío paquetes desde la placa de desarrollo al iPhone 4S. Nuevamente, 5 kbit / s es el máximo que estoy obteniendo. El mecanismo de notificación se utiliza para este escenario. De nuevo, no se producen acuses de recibo en la capa de atributo.

• Cuando trato de enviar ambas direcciones simultáneamente, las cosas empiezan a estallar hasta el punto en que tengo que restablecer tanto la placa de desarrollo como el iPhone 4S.

Preguntas:

• ¿Puede ser este un problema del chip Bluetooth Low Energy, que se usa en la placa de desarrollo?

  En caso afirmativo, ¿por qué el problema también se produce en la dirección opuesta, donde el iPhone actúa como receptor?

  ¿Existen paneles de desarrollo en el mercado que admitan el acceso de alta frecuencia a las características?

• ¿Cuál podría ser el origen del problema?

  Intente también hacer referencia a partes de las Especificaciones de Bluetooth / diapositivas / artículos de presentación además de suposiciones.

Existen ratones Bluetooth de baja energía en el mercado. Los ratones tienen tasas de sondeo típicas de 125 Hz y deben enviar al menos dos valores de 16 bytes más la sobrecarga HID adicional por tic. Por lo tanto, una solución para mi problema debería estar disponible.

Actualizar

El Evento de Conexión Completa LE se describe en la Especificación de Bluetooth, Versión 4.0, Vol. 2, Parte E, Sección 7.7.65.1 . Recibo los siguientes valores para los diferentes parámetros de conexión:

Parameter               Value      Description
--------------------------------------------------
Conn_Interval           0x0054     Time =  105 ms
Conn_Latency            0x0000     Time =    0 ms
Supervision_Timeout     0x00fc     Time = 2520 ms
Master_Clock_Accuracy     0x05              50 ppm

Answer 1

El problema principal parece ser que se trata de un problema de búfer en el chip que está utilizando. De la especificación básica, Volumen 3, Parte F, 3.3.2:

Para las notificaciones, que no tienen una PDU de respuesta, no hay control de flujo y se puede enviar una notificación en cualquier momento.

Los comandos que no requieren una respuesta no tienen ningún control de flujo. Nota: un servidor puede estar inundado de comandos, y una especificación de capa superior puede definir cómo evitar que esto ocurra.

Los comandos y notificaciones que se reciban pero no puedan procesarse, debido a desbordamientos de búfer u otros motivos, se descartarán. Por lo tanto, esas PDUs deben ser consideradas como no confiables.

Answer 2

La emisión de una Actualización de Parámetros de Conexión resolvió el problema y aumentó el rendimiento de 5 kbit / s hasta ~ 33 kbit / s . Sin embargo, esto todavía está por debajo de los ~ 305 kbit / s esperados.

Conn_Interval = 0x000f = 18.75 ms
Conn_Latency  = 0x0000
Supervision_Timeout = 0x00fc

¿Hay algún método para alcanzar los 305 kbit / s completos?

Pregunta de seguimiento en Ingeniería Eléctrica Stackexchange

Podría obtener una respuesta de Apple al grabar un TSI y esperar un mes.

Básicamente, dicen que el comportamiento está pensado en iOS 5.1. De alguna manera tiene sentido, porque no quieren que el rendimiento de su aplicación dependa de si otra aplicación usa Bluetooth o WiFi.

Según los comentarios de los ingenieros: bajo iOS 5.1, debería haber 6 pares de notificaciones durante un intervalo de conexión, lo que significa 6 * packetSize * 1000 / interval. Esto debería traducirse a un máximo de ~ 55 kbps (el intervalo mínimo es de 20 ms, el tamaño del paquete es de 23 bytes). Tomamos la decisión de limitar el número de pares por intervalo y tener un intervalo mínimo debido al hecho de que el iPhone y el iPad tienen una antena compartida entre BT classic, BT LE y WiFi.

iOS LE está diseñado para ser un transporte de baja potencia. Para un mayor rendimiento, BT classic es un mejor método de transporte.

De vuelta a mí: en base a los comentarios de los ingenieros anteriores, si el deseo es lograr un rendimiento de 200 kbs, el bluetooth clásico es la respuesta. Sin embargo, si el deseo es trabajar con una aplicación en el iPhone, puedo entender que esto no es un cambio simple: Classic BT requiere una licencia de IMF.

Answer 3

Lo que se ve cuando se eliminan los paquetes se debe a un desbordamiento del búfer en el lado del iPhone (probablemente, creo) o en el lado del host. Comenzando con iOS 11.2, Apple proporciona un mecanismo que le permite verificar si el búfer está listo antes de escribir el siguiente paquete; canSendWriteWithoutResponse:

Si espera hasta que canSendWriteWithoutResponse sea verdadero antes de escribir un paquete, se garantiza que la entrega se colocó en el búfer receptor, pero no se garantiza que haya sido procesado (no reconocido). La otra cosa que podría ayudar es negociar un tamaño de MTU mayor que 20. Apple admite MTU en 185B y hasta 251 (longitud de datos extendida, también conocida como EDL). Al dividir sus paquetes de datos en tamaños MTU-3, su paquete == (MTU-3) x 1 por intervalo de conexión. @ 185B MTU, intervalo de conexión de 24 ms Tengo un rendimiento de alrededor de 48 kbps sin paquetes descartados. Al enviar datos al iPhone desde el dispositivo, el SDK en ese extremo necesitará el equivalente a ''canSendWriteWithoutResponse'', que en mi caso utiliza hardware / SDK de SiLabs, por ejemplo.

`` `

 do {
     result = gecko_cmd_gatt_server_send_characteristic_notification(
              0xFF,
              evt->data.evt_gatt_server_attribute_value.attribute,
              chunk.length,
     [chunk bytes])->result;
 } while(result == bg_err_out_of_memory); 
  //retry until buffer is empty and ready for more 
 //then update the offset
 offset += thisChunkSize;

`` `

Aquí hay un video y un archivo .pdf de Apple que explica las diferentes técnicas BLE y las velocidades esperadas. MTU + Connection Interval es lo que se usa para determinar el rendimiento máximo. 48kps deben ser fácilmente alcanzables, 96kbps y tal vez un poco más alto es posible.

Novedades en Core Bluetooth

video: https://devstreaming-cdn.apple.com/videos/wwdc/2017/712jqzhsxoww3zn/712/712_hd_whats_new_in_core_bluetooth.mp4?dl=1
pdf: https://devstreaming-cdn.apple.com/videos/wwdc/2017/712jqzhsxoww3zn/712/712_whats_new_in_core_bluetooth.pdf