Pregunta de seguimiento de Stackoverflow
Estoy tratando de escribir un valor característico repetidamente durante un corto período de tiempo. Diferentes fuentes dicen que deberían ser posibles velocidades entre 200 y 305 kbit/s . Sin embargo, solo alcanzo ~36 kbit/s .
Estoy usando un iPhone 4S para escribir la característica repetidamente. Una placa de desarrollo con un chip CSR1000 BLE sirve como periférico que acepta las escrituras. Estoy usando escrituras sin respuesta para evitar reconocimientos en la capa de atributos. Consulte mi pregunta sobre Stackoverflow para obtener más detalles.
Una escritura en el valor característico de 20 bytes de longitud se produce después de cada milisegundo. Por lo tanto, estoy enviando 160 kbit/s . En realidad , solo se reciben ~36 kbit/s . Lo extraño de esto es que, al comienzo de la sesión, todo funciona bien por una fracción de segundo. Luego, los paquetes comienzan a caer. Sin embargo, la mayoría de las veces, los paquetes de cuatro solicitudes de escritura continuas funcionan bien antes de que se vuelva a descartar una cantidad variable de paquetes.
He encontrado una correlación significativa entre el rendimiento y el valor de Conn_Interval. Sin embargo, el iPhone 4S no aceptará valores de Conn_Interval inferiores a 0x0f. Esto ya es más bajo de lo que propone Apple dentro de sus pautas de hardware. Cuando cumplo con sus valores y uso un intervalo mínimo de 20 ms y un intervalo máximo de 40 ms, el rendimiento disminuye a ~15 kbit/s.
Conn_Interval = 0x000f = 18.75 ms
Conn_Latency = 0x0000
Supervision_Timeout = 0x00fc
El documento "Modelado del rendimiento máximo de Bluetooth Low Energy en un enlace propenso a errores" de Gomez et al. describe la influencia de Conn_Interval y los errores de bit en el rendimiento. Sin embargo, según su análisis, habría una cantidad relativamente alta de errores de bit, si esta fuera la fuente limitante del problema. La placa de desarrollo se encuentra muy cerca del iPhone 4S. Por lo tanto, supongo que existen otros factores limitantes.
¿Estás seguro de que todos esos paquetes están saliendo del iPhone? Tal vez Apple impone restricciones de ancho de banda en las aplicaciones, como le dije en stackoverflow, realmente debería hacer esta pregunta en la lista de correo de Bluetooth de Apple, donde hay varios ingenieros útiles de Apple que podrían ayudarlo.
De lo contrario, realmente necesita especificar qué conjuntos de chips está utilizando si desea obtener algo de estas preguntas.
EDITAR: está bien, está utilizando el conjunto de chips CSR, entonces le sugiero que se comunique con CSR directamente y publique su pregunta aquí:
https://lists.apple.com/mailman/listinfo/bluetooth-dev
EDIT2: un sniffer ciertamente podría ayudarlo a ver si esos paquetes realmente están siendo enviados por el iPhone y no son recibidos por el conjunto de chips CSR, o si es solo que el iPhone nunca los envía por aire
Podría obtener una respuesta de Apple quemando un TSI y esperando un mes.
Básicamente, dicen que el comportamiento está previsto 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: en iOS 5.1, debe haber 6 pares de notificaciones durante un intervalo de conexión, lo que significa 6*packetSize*1000/interval . Esto debería traducirse en 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 la cantidad de pares por intervalo y tener un intervalo mínimo debido a que tanto el iPhone como el iPad tienen antena compartida entre BT classic, BT LE y WiFi.
iOS LE está diseñado para ser un transporte de bajo consumo. Para un mayor rendimiento, BT classic es un mejor método de transporte.
Volviendo a mí: según 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 este no es un cambio simple: Classic BT requiere una licencia MFI.
¿Qué placa de desarrollo estás usando? Ha habido algunos problemas con Bluegiga y el BLE-112A. Las especificaciones originales que enumeraron no eran del todo correctas con respecto a la capacidad de memoria y las opciones de perfil de firmware disponibles. Tengo entendido que se supone que deben actualizar las especificaciones de su software en función de los comentarios que han recibido.
Dependiendo de lo que intente hacer, otra opción puede estar presente en tod Smart Beacon para obtener más información, consulte todhq.com
Lo que está viendo cuando se descartan paquetes se debe a un desbordamiento del búfer en el lado del iPhone (lo más probable, creo) o en el lado del host. A partir de iOS 11.2, Apple proporciona un mecanismo que le permite verificar si el búfer está listo antes de escribir el siguiente paquete; puedeEnviarEscribirSinRespuesta:
Si espera hasta que canSendWriteWithoutResponse sea verdadero antes de escribir un paquete, se garantiza que la entrega se haya colocado en el búfer de recepción, pero no se garantiza que se haya procesado (no reconocido). La otra cosa que podría ayudar es negociar un tamaño de MTU superior a 20. Apple admite MTU en 185B y hasta 251 (longitud de datos extendida, también conocida como EDL). Al fragmentar 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 caídos. Al enviar datos al iPhone desde el dispositivo, el SDK en ese extremo necesitará el equivalente a 'canSendWriteWithoutResponse', que en mi caso, usando el hardware/SDK de SiLabs, tiene, 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 .pdf de Apple que explica las diferentes técnicas de BLE y las velocidades esperadas. MTU + Intervalo de conexión es lo que usa para determinar el rendimiento máximo. 48 kbps deberían ser fácilmente alcanzables, 96 kbps y tal vez un poco más son posibles.
Novedades de 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