Free Press

Introducción

En este segundo post de la serie sobre Bluetooth 5, cubrimos la nueva característica de velocidad 2x mejorada junto con una visión general del rendimiento para una aplicación BLE (el post anterior repasaba las nuevas características de Bluetooth 5 en general y cubría más específicamente la característica de mayor capacidad de anuncio).

En primer lugar, tenemos que entender que las velocidades anunciadas (1 Mbps y los nuevos 2 Mbps) son sólo teóricas y se reducen cuando se trata de rendimiento de la aplicación. Esto se debe a múltiples razones que repasaremos en la siguiente sección.

La función de «velocidad 2x» de Bluetooth 5 requiere una actualización de hardware, por lo que los dispositivos/chips/módulos más antiguos no la soportarán. También es importante tener en cuenta que para conseguir este mayor rendimiento necesitarás que los dos dispositivos BLE que se comunican entre sí sean compatibles con el nuevo PHY LE 2M (que hace posible la transferencia de datos a esta mayor velocidad).

La nueva LE 2M PHY, así como la LE 1M PHY original, se denominan PHY sin codificar, ya que utilizan una representación de 1 símbolo por bit de datos (en comparación con la nueva LE Coded PHY, que utiliza una representación de 2 u 8 símbolos por bit de datos).

Otro aspecto importante a tener en cuenta es que, al utilizar la PHY de mayor velocidad, se consigue un menor consumo de energía (dado que se transfiere la misma cantidad de datos). Esto se debe a que se reduce el tiempo de encendido de la radio sin que aumente la potencia de transmisión. Esto, a su vez, también mejora la coexistencia con otras tecnologías inalámbricas dentro del espectro de 2,4 GHz (también debido a la reducción del tiempo de activación de radio).

En este post, cubriremos:

• ¿Cuál es el rendimiento práctico que se puede esperar de BLE?
• El nuevo PHY 2M de Bluetooth 5 para la transferencia de datos
• ¿Cuáles son los factores que impactan/determinan el rendimiento de datos?
• ¿Cómo se calcula el rendimiento de datos de la aplicación?
• ¿Cómo se maximiza el rendimiento de datos?
• Prueba, medición y cálculo del rendimiento de datos utilizando dos kits de desarrollo de la serie nRF52

¿Por qué es imposible alcanzar las velocidades teóricas de BLE?

Las velocidades de datos de 1 Mbps (LE 1M PHY), 2 Mbps (LE 2M PHY), 125 kbps y 500 kbps (ambos utilizando el LE Coded PHY con S=8 y S=2, respectivamente) son las velocidades a las que la radio transmite los datos, pero esto no es alcanzable para el rendimiento de la aplicación debido a las siguientes razones:

• Límite en el número de paquetes por intervalo de conexión
• Retraso del espacio de trama interior (IFS) entre paquetes (150 us)
• Paquetes vacíos requeridos para ser enviados desde un dispositivo incluso si no hay datos disponibles para la transmisión
• Carga de paquetes – no todos los bytes de un paquete se utilizan para la carga útil

Para entender mejor estos factores y comprender qué afecta al rendimiento de la aplicación, tenemos que echar un vistazo más profundo al formato del paquete. La siguiente figura muestra el aspecto de los paquetes de datos LE 1M PHY y 2M PHY:

La parte que nos interesa (y la que realmente define los datos de la aplicación) es la carga útil ATT. Como se puede ver en la figura, hay una serie de bytes de sobrecarga que son utilizados por cada capa en Bluetooth Low Energy.

• En 4.0 y 4.1, la carga útil ATT máxima es de 20 bytes.
• En 4.2 y 5.0, una nueva característica llamada Data Length Extensions (DLE) permite que la carga útil ATT contenga hasta 244 bytes de datos.

Velocidad de Bluetooth 5 : 2 veces la velocidad utilizando el nuevo 2M PHY

Es útil entender las limitaciones de utilizar el nuevo LE 2M PHY en Bluetooth 5:

• No se puede utilizar para transmitir los anuncios primarios (en los canales primarios).
• Se puede utilizar para los «paquetes auxiliares» secundarios que se envían en los mismos canales que los paquetes de datos (37 canales: 0-36).
  Para obtener más información sobre los anuncios primarios y secundarios, consulte mi entrada anterior del blog: Anuncios de Bluetooth 5: Todo lo que necesitas saber.
• LE 1M es obligatorio, mientras que LE 2M es opcional. Por lo tanto, no todos los chips que afirman ser compatibles con Bluetooth 5 pueden manejar necesariamente el mayor rendimiento.
• Los anuncios y el descubrimiento pueden ocurrir en el PHY LE 2M, y luego las conexiones se producen en el canal de anuncios secundario utilizando el PHY LE 2M

La transferencia de datos de aplicaciones de un dispositivo a otro suele ocurrir durante una conexión entre los dos dispositivos. Los dispositivos conectados pueden negociar el uso de un PHY diferente a través del procedimiento de actualización del PHY. Puede ser iniciado por el esclavo o el maestro después de que se establezca una conexión, pero el maestro tomará en última instancia la decisión final sobre qué PHYs se utilizan para cada dirección (en base a la solicitud del esclavo y los PHYs que el maestro soporta).

Factores que impactan/determinan el rendimiento de los datos

Hay algunos factores que impactan el rendimiento de los datos de una aplicación BLE. Los más comunes son:

• PHY que se utiliza (LE 1M vs. LE 2M vs. LE Coded (S=2 o S=8))
• Intervalo de conexión
• Número máximo de paquetes por intervalo de conexión
• Unidad de transmisión máxima ATT (ATT MTU)
• Extensión de longitud de datos (DLE)
• Tipo de operación: Escritura con respuesta frente a escritura sin respuesta, Indicaciones frente a Notificaciones
• Espacio entre tramas (IFS): espacio de tiempo entre paquetes consecutivos (150 us)
• Transmisión de paquetes vacíos
• Carga de paquetes – no todos los bytes, en un paquete, se utilizan para la carga útil de la aplicación

Veamos cada uno de ellos con más detalle.

PHY

Hay básicamente tres PHYs en Bluetooth 5: el original de 1 Mbps, el nuevo de 2 Mbps, y el PHY codificado (con S=2, o S=8). El PHY utilizado tendrá un impacto directo en el máximo rendimiento de datos que puede lograr, ya que determina la velocidad de datos en bruto real en la que los paquetes se envían a través del aire.

Intervalo de conexión & paquetes máximos por evento de conexión

El intervalo de conexión determina efectivamente cuántos paquetes se pueden enviar durante un evento de conexión. Cuanto mayor sea el valor, más paquetes se pueden enviar en un evento de conexión (hasta un cierto límite para algunos dispositivos).

Aprenda más sobre los intervalos de conexión: Intervalos y eventos de conexión BLE

Sin embargo, el número de paquetes por evento de conexión depende del dispositivo y de la pila BLE por lo que es limitado y difiere entre dispositivos y versiones de pila en un dispositivo específico. Este valor también depende del funcionamiento del dispositivo, por lo que la radio puede tener que atender otros eventos y el número de paquetes enviados por eventos de conexión puede no alcanzar el máximo permitido por la pila. Por ejemplo, el número difiere entre iOS y Android y también cambia dependiendo de la versión del SO que se ejecuta en el dispositivo.

A veces es útil actualizar dinámicamente los parámetros de conexión en función del caso de uso. Sin embargo, tenga en cuenta que es hasta el maestro para aceptar estas recomendaciones o actualizar los parámetros para adaptarse a ellos.

Data Length Extensions (DLE)

Esta característica permite que el tamaño del paquete para mantener una mayor cantidad de carga útil (Hasta 251 bytes frente a 27 cuando está desactivado). Esta función se introdujo en la versión 4.2 de la especificación Bluetooth.

Unidad de transmisión máxima de ATT (ATT MTU)

ATT MTU Determina la cantidad máxima de datos que pueden manejar el transmisor y el receptor y que pueden mantener en sus búferes.

El valor de la MTU afecta a la cantidad de datos de sobrecarga (concretamente la cabecera ATT, que es de 3 bytes). La MTU ATT mínima permitida es de 27 bytes. Esto permite un máximo de 20 bytes de carga útil ATT (3 bytes se utilizan para el encabezado ATT, y 4 bytes para el encabezado L2CAP).

No hay límite por la especificación de lo alto que puede ser el valor MTU, pero la pila específica en uso puede tener sus propias limitaciones. Por ejemplo, si activas DLE puedes transferir hasta 251 – 4 = 247 bytes (después de deducir el tamaño de la cabecera L2CAP). Después de tener en cuenta la cabecera ATT (3 bytes), nos quedan 244 bytes para los datos reales de la carga útil ATT. Si la MTU es de al menos 247 bytes, entonces la MTU cabrá en un solo paquete. Si la MTU es mayor de 247 bytes, entonces la MTU abarcará múltiples paquetes causando que el rendimiento baje (debido a la sobrecarga de paquetes y el tiempo entre los paquetes).

La MTU efectiva se determina por el valor mínimo de MTU ATT que el cliente y el servidor soportan. Por ejemplo, si un cliente admite una MTU ATT de 100 bytes y el servidor responde que admite una MTU ATT de 150 bytes, entonces el cliente decidirá que la MTU ATT que se utilizará para la conexión a partir de ese momento es de 100 bytes.

Tipo de operación: Escritura con respuesta vs. escritura sin respuesta, Indicaciones vs. Notificaciones

Si se desea un alto rendimiento, entonces podemos utilizar Escritura sin respuesta o Notificaciones para transferir los datos del cliente al servidor y del servidor al cliente. Estas operaciones eliminan la necesidad de que el otro dispositivo acuse recibo de los datos y responda antes de poder enviar el siguiente bloque de datos.

Inter Frame Space (IFS): retardo de tiempo entre paquetes consecutivos (150 us)

De la especificación Bluetooth:

4.1.1 Inter Frame Space

El intervalo de tiempo entre dos paquetes consecutivos en el mismo índice de canal se llama Inter Frame Space. Se define como el tiempo que transcurre desde el final del último bit del paquete anterior hasta el inicio del primer bit del paquete siguiente.
El espacio entre tramas se designa «T_IFS» y será de 150 μs.

Transmisión de paquetes vacíos

Si el dispositivo que recibe los datos no tiene datos que enviar de vuelta, aún debe enviar un paquete vacío según la especificación Bluetooth.

Carga del paquete

Como vimos en la figura del formato del paquete, éste incluye algunos datos de carga que no cuentan para sus datos de aplicación (datos ATT). Básicamente, estos bytes consumirán parte de su tasa de datos de transferencia mientras que no se contabilizan los bytes que se envían como parte de sus datos de aplicación.

Calcular el rendimiento de los datos de aplicación

La gran pregunta es: ¿cómo calculamos el rendimiento de nuestra aplicación?

Como hemos mencionado antes, hay algunas variables que impactan en el rendimiento de datos:

• Versión de Bluetooth & PHY utilizada
• DLE: Extensiones de longitud de datos – habilitadas o no
• Valor MTU de ATT
• Intervalo de conexión
• Número máximo de paquetes por evento de conexión
• Operación (escribe con respuestas vs. escribe sin respuestas, y notificación vs. indicación)
• Espacio de trama interna (IFS): 150 microsegundos

La versión de Bluetooth y el PHY determinan la tasa de transferencia de datos en bruto. Por ejemplo, si estamos utilizando la versión 4.2 de Bluetooth y el PHY LE 1M, entonces la velocidad de transferencia es de 1 Mbps. Si, por el contrario, utilizamos la PHY codificada de Bluetooth 5 LE con S=8, la velocidad de transferencia de datos se reduce a 125 kbps.

El DLE, la MTU de ATT, el intervalo de conexión, el número máximo de paquetes por intervalo de conexión, la operación y el IFS determinan la parte del tiempo en la radio que se utiliza para la transferencia real de datos.

El formato de los paquetes desempeña un papel importante en la parte de los datos que se transfieren que son los datos reales de la aplicación. La LE 1M PHY y la LE 2M PHY tienen un formato de paquete similar. El LE Coded PHY tiene un formato de paquete significativamente diferente, por lo que veremos estos dos casos por separado.

Cálculo del LE 1M PHY y del LE 2M PHY

Respecto al formato de paquete para los LE Uncoded PHYs:

La cantidad de sobrecarga para cada PHY es ligeramente diferente. El preámbulo es de 1 byte en el caso del PHY 1M y de 2 bytes en el caso del PHY 2M. El campo MIC es un campo opcional que sólo se utiliza para las conexiones cifradas. Para simplificar, sólo consideraremos las conexiones no encriptadas – para el caso encriptado, simplemente añade 4 bytes de sobrecarga.

Para las PHYs codificadas LE, el formato del paquete es el siguiente (de la especificación Bluetooth 5.0 Vol 6, Parte B, Sección 2.2):

Pasos para calcular el rendimiento (en Mbps):

Para simplificar, suponemos lo siguiente:

• El cifrado NO está habilitado (el campo MIC no se incluye en el paquete)
• Estamos interesados en el rendimiento para una dirección (por ejemplo. Maestro a Esclavo), por lo que asumimos que la otra dirección sólo transfiere paquetes vacíos
• Escrituras sin respuestas (lo que ayudaría a maximizar el rendimiento cuando se transfieren grandes cantidades de datos

Pasos:

1. Determine el PHY que se está utilizando y anote la tasa de transferencia de datos en bruto
   Por ejemplo para 1M PHY -> 1 Mbps, para PHY codificada y S=8 -> 125 kbps
2. Determine el tiempo que se tarda en enviar un paquete de datos y el paquete vacío del receptor.
   El tiempo durante el cual se puede enviar un paquete de datos incluirá lo siguiente:

   Tiempo_de_paquete_de_datos = Tiempo para transmitir el paquete vacío + IFS + Tiempo para transmitir el paquete de datos real + IFS.
   El tiempo de transmisión del paquete vacío puede calcularse de la siguiente manera:

   Tiempo de transmisión del paquete vacío = tamaño del paquete vacío / velocidad de datos brutos

   Un paquete vacío contendrá los siguientes campos:

   Preamble + Dirección de acceso + Cabecera LL + CRC.

   Para 1M PHY, el Preámbulo será de 1 byte, por lo que el tamaño total del paquete vacío = 1 + 4 + 2 + 3 bytes = 10 bytes = 80 bits.
   (para 2M PHY, el tamaño de un paquete vacío será de 88 bits ya que el Preámbulo es de 2 bytes en lugar de 1 byte).

   En base a esto, el tiempo de transmisión de un paquete vacío de 1M PHY será:

   Tiempo de transmisión de un paquete vacío = tamaño del paquete vacío / velocidad de datos brutos = 80 bits / 1 Megabits por segundo = 80 microsegundos

   Un paquete de datos contendrá todos los campos listados en el diagrama de formato del paquete con la excepción del campo MIC (encriptación desactivada).

   Tiempo de transmisión del paquete de datos = tamaño del paquete de datos / tasa de datos brutos

   Si tenemos DLE activado y la MTU de ATT es igual al máximo de bytes permitidos en un paquete: 247 bytes, entonces podemos calcular el tamaño del paquete de datos como:

   Tamaño del paquete de datos = 1 + 4 + 2 + 4 + 247 + 3 bytes = 265 bytes = 265*8 bits = 2088 bits

   Tiempo de transmisión del paquete de datos = 2088 bits / 1 Mbps = 2,088 microsegundos

   Tiempo del paquete de datos = Tiempo para transmitir el paquete vacío + IFS + Tiempo para transmitir el paquete de datos real + IFS = 80 + 2*150 + 2088 = 2.468 microsegundos
   Para comparar, en el caso de 2M PHY, sería:

   Tiempo_de_paquete_de_datos = Tiempo para transmitir el paquete vacío + IFS + Tiempo para transmitir el paquete de datos real + IFS = 88/2 + 2*150 + (2 + 4 + 2 + 4 + 247 + 3)*8/2 = 1.392 microsegundos
   Cuando la DLE está activada y la ATT MTU se establece en menos de 247, acabamos teniendo más sobrecarga (ya que ahora los datos mayores que la ATT MTU se dividen en más paquetes). Por ejemplo, digamos que tenemos la ATT MTU establecida en 158, entonces para transferir 244 bytes de datos de la aplicación, necesitaremos dos paquetes en lugar de uno, causando que el rendimiento baje debido al aumento de la sobrecarga de bytes así como el aumento del IFS entre los paquetes. En otro escenario, podríamos tener DLE desactivado (tamaño de la carga útil hasta 27 bytes) y la MTU de ATT mayor de 27 bytes. Aquí, esto también resultará en más paquetes necesarios para ser enviados para la misma cantidad de datos, causando que el rendimiento baje.

   Nota: El mismo método para calcular los tamaños de los paquetes de datos y vacíos que usamos arriba puede ser usado para el LE Coded PHY.

3. Descubrir cuántos paquetes se pueden transmitir durante un intervalo de conexión
   Este cálculo no siempre es puramente matemático – tendrá que tener en cuenta las limitaciones de la pila y el dispositivo que se utiliza. iOS y Android tienen máximos que cambian con la versión del sistema operativo, por lo que no siempre es fácil de averiguar. Dicho esto, en una MCU, el SDK del proveedor suele indicar el máximo en su documentación. También es útil hacer una prueba y error y averiguar lo que su dispositivo específico soporta.

   Una vez que haya averiguado el máximo, se puede calcular el número máximo teórico de paquetes que cabría dentro de un intervalo de conexión de elección. Por ejemplo, si tuviéramos un intervalo de conexión de 7,5 milisegundos (el más bajo permitido por la especificación), entonces para nuestro ejemplo anterior (utilizando 1M PHY, DLE habilitado):

   Máximo número de paquetes de datos por intervalo de conexión = , donde se redondea al número entero más alto (entero)Máximo número de paquetes de datos por intervalo de conexión = = 3 paquetes

   Por lo general, este número no es realista, ya que hay retrasos de tiempo entre los paquetes que se envían en eventos de conexión consecutivos. Por lo tanto, para nuestro ejemplo, vamos a ir con 2 paquetes en lugar de 3.

4. Una vez que hemos calculado el número máximo de paquetes de datos que se pueden transferir por intervalo de conexión, podemos calcular el rendimiento de datos:Rendimiento de datos = datos por intervalo de conexión / intervalo de conexión = Nº de paquetes de datos por intervalo de conexión * Tamaño de los datos por paquete / intervalo de conexión
   = 2 * 244 * 8 bits / 7.5 milisegundos = 520,533 bits/seg ~= 508 kbps

Prueba y cálculo del rendimiento de datos entre dos kits de desarrollo nRF52

En esta sección, realizaremos múltiples pruebas de transferencia de datos, calcularemos el rendimiento mediante el procedimiento que hemos descrito anteriormente y, a continuación, lo compararemos con el rendimiento medido que nos informa la aplicación que se ejecuta en las placas de desarrollo. Las pruebas se ejecutan sobre la base de la aplicación de demostración proporcionada por Nordic Semiconductor y presentada en esta entrada del blog: Demostración de rendimiento y largo alcance.

El código fuente del ejemplo se puede encontrar en la página de GitHub aquí.

Caso 1 (PHY: 1 Mbps, ATT MTU = 23 bytes, DLE: activado, Intervalo de conexión: 7,5 milisegundos)

Rendimiento de datos informado por el firmware:

Tiempo: 36.11 segundos transcurridos.
Transmisión de datos: 232,29 Kbits/s.
Se enviaron 1048580 bytes de carga útil ATT.

Transmisión de datos calculada:

Con la MTU ajustada a 23 bytes, la DLE no afecta realmente a la transmisión de datos ni al tamaño de los paquetes.

Tiempo para transmitir el paquete de datos = tamaño del paquete de datos / tasa de datos brutos = 1 + 4 + 2 + 4 + 23 + 3 bytes / 1 Mbps= 37*8 bits / 1 Mbps = 296 microsegundos

Tiempo para transmitir el paquete de datos vacío + IFS + Tiempo para transmitir el paquete de datos real + IFS = 80 + 150 + 296 + 150 microsegundos = 676 microsegundos

Número máximo de paquetes de datos por intervalo de conexión = = = 11 paquetes
Total de datos transferidos por intervalo de conexión = 11 * 20 bytes = 11 * 20 * 8 bits = 1760 bits

Rendimiento de datos = Total de datos transferidos por intervalo de conexión/intervalo de conexión = 1760 bits / 7.5 milisegundos = 234,67 Kbits/s
Como podemos ver, el valor calculado y el valor medido están bastante cerca.

Caso 2 (PHY: 2 Mbps, ATT MTU = 23 bytes, DLE: activado, Intervalo de conexión: 7.5 milisegundos)

Proceso de datos informado por el firmware:

Tiempo: 27,23 segundos transcurridos.
Proceso: 307,96 Kbits/s.
Envió 1048580 bytes de carga útil ATT.

Calculado el rendimiento de datos:

Tiempo de transmisión del paquete de datos = tamaño del paquete de datos / tasa de datos brutos = 2 + 4 + 2 + 4 + 23 + 3 bytes / 2 Mbps= 38*8 bits / 2 Mbps = 152 microsegundos

Tiempo de transmisión del paquete de datos vacío + IFS + Tiempo de transmisión del paquete de datos real + IFS = 44 + 150 + 152 + 150 microsegundos = 496 microsegundos

Número máximo de paquetes de datos por intervalo de conexión = = = 15 paquetes
Total de datos transferidos por intervalo de conexión = 15 * 20 bytes = 15 * 20 * 8 bits = 2400 bits

Rendimiento de datos = Total de datos transferidos por intervalo de conexión/intervalo de conexión = 2400 bits / 7.5 milisegundos = 320 Kbits/s
Como podemos ver, el valor calculado y el valor medido están bastante cerca.

Caso 3 (PHY: 1 Mbps, ATT MTU = 158 bytes, DLE: activado, Intervalo de conexión: 7.5 milisegundos)

Rendimiento de datos informado por el firmware:

Tiempo: 17,53 segundos transcurridos.
Rendimiento: 478,36 Kbits/s.
Envió 1048730 bytes de carga útil ATT.

Calculado el rendimiento de datos:

Tiempo de transmisión del paquete de datos = tamaño del paquete de datos / tasa de datos brutos = 1 + 4 + 2 + 4 + 158 + 3 bytes / 1 Mbps= 172*8 bits / 1 Mbps = 1376 microsegundos

Tiempo de transmisión del paquete de datos vacío + IFS + Tiempo de transmisión del paquete de datos real + IFS = 80 + 150 + 1376 + 150 microsegundos = 1756 microsegundos

Número máximo de paquetes de datos por intervalo de conexión = = = 4 paquetes
Total de datos transferidos por intervalo de conexión = 4 * 155 bytes = 4 * 155 * 8 bits = 4960 bits

Rendimiento de datos = Total de datos transferidos por intervalo de conexión/intervalo de conexión = 4960 bits / 7.5 milisegundos = 661,33 Kbits/s

Caso 4 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: activado, Intervalo de conexión: 7.5 milisegundos)

Rendimiento de datos informado por el firmware:

Tiempo: 8,45 segundos transcurridos.
Rendimiento: 992,07 Kbits/s.
Envió 1048712 bytes de carga útil ATT.

Calculado el rendimiento de datos:

Tiempo para transmitir el paquete de datos = tamaño del paquete de datos / tasa de datos brutos = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsegundos

Tiempo de transmisión del paquete de datos vacío + IFS + Tiempo de transmisión del paquete de datos real + IFS = 44 + 150 + 1048 + 150 microsegundos = 1392 microsegundos

Número máximo de paquetes de datos por intervalo de conexión = = = 5 paquetes
Total de datos transferidos por intervalo de conexión = 5 * 244 bytes = 5 * 244 * 8 bits = 9760 bits

Rendimiento de datos = Total de datos transferidos por intervalo de conexión/intervalo de conexión = 9760 bits / 7.5 milisegundos = 1301,33 Kbits/s

Nota: En los dos últimos casos, el número de paquetes por intervalo de conexión es pequeño y cualquier diferencia entre lo que calculamos y lo que se mide tendrá un gran impacto en el rendimiento de datos real. Por ejemplo, si el número de paquetes por intervalo de conexión termina siendo 4 en lugar de 5 en el caso 4, el rendimiento calculado se convierte en 1.041,1 Kbps en lugar de 1.301,33 Kbps (que es una gran diferencia y podría explicar la discrepancia en los números aquí).

Caso 5 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: activado, Intervalo de conexión: 50 milisegundos)

Rendimiento de datos informado por el firmware:

Tiempo: 6,34 segundos transcurridos.
Rendimiento: 1322,33 Kbits/s.
Se enviaron 1048712 bytes de carga útil ATT.

Calculado el rendimiento de datos:

Tiempo para transmitir el paquete de datos = tamaño del paquete de datos / tasa de datos brutos = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsegundos

Tiempo para transmitir el paquete de datos vacío + IFS + Tiempo para transmitir el paquete de datos real + IFS = 44 + 150 + 1048 + 150 microsegundos = 1392 microsegundos

.

Máximo número de paquetes de datos por intervalo de conexión = = = 35 paquetes

Total de datos transferidos por intervalo de conexión = 36 * 244 bytes = 35 * 244 * 8 bits = 68320 bits

Rendimiento de datos = Total de datos transferidos por intervalo de conexión/intervalo de conexión = 70272 bits / 50 milisegundos = 1366.4 Kbits/s

Caso 6 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: activado, Intervalo de conexión: 400 milisegundos)

Rendimiento de datos informado por el firmware:

Tiempo: 6,11 segundos transcurridos.
Rendimiento: 1371,82 Kbits/s.
Se han enviado 1048712 bytes de carga útil ATT.

Calculado el rendimiento de los datos:

Tiempo para transmitir el paquete de datos = tamaño del paquete de datos / tasa de datos brutos = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsegundos

Tiempo para transmitir el paquete de datos vacío + IFS + Tiempo para transmitir el paquete de datos real + IFS = 44 + 150 + 1048 + 150 microsegundos = 1392 microsegundos

.

Máximo número de paquetes de datos por intervalo de conexión = = = 287 paquetes

Total de datos transferidos por intervalo de conexión = 287 * 244 bytes = 287 * 244 * 8 bits = 560224 bits

Rendimiento de datos = Total de datos transferidos por intervalo de conexión/intervalo de conexión =560224 bits / 400 milisegundos = 1400.56 Kbits/s

Optimización para el máximo rendimiento de datos

En base a los factores que hemos repasado, podemos anotar lo siguiente a la hora de optimizar para un alto rendimiento de datos:

• Habilitar siempre el DLE
  Obviamente, si estás usando Bluetooth v4.1 o anterior, esta no es una opción válida. En general, sin embargo, asegúrese de habilitar DLE para maximizar la eficiencia de los datos del paquete a la aplicación
• Utilizar LE 2M PHY
  Si sabe que los dispositivos en ambos extremos soportan Bluetooth 5, entonces utilizar el LE 2M PHY es una de las mejores maneras de maximizar el rendimiento de los datos de su aplicación. El uso de la LE 2M PHY también ayudará a reducir el consumo de energía, ¡así que se matan dos pájaros de un tiro!
• Utilizar notificaciones y escrituras sin respuestas
  Utilizarlas ayudará a eliminar cualquier paquete innecesario que se transmita (en comparación con las indicaciones y las escrituras normales que requieren que el extremo receptor reconozca cada paquete recibido).
• Elija un valor de ATT MTU de al menos más de 247 bytes
  Esto minimizará cualquier sobrecarga en bytes de paquetes.
• Elija un intervalo de conexión que permita el máximo número de paquetes por intervalo de conexión
  Pero tenga en cuenta que el intervalo de conexión afecta al consumo de energía. Cuanto más corto sea el intervalo, más energía consumirá su dispositivo debido al aumento del tiempo de conexión de radio. También debes asegurarte de no elegir un intervalo demasiado alto, ya que, de lo contrario, la experiencia del usuario se verá comprometida (un mayor intervalo de conexión se traduce en una mayor latencia). Una última cosa que hay que tener en cuenta es cualquier limitación de los dispositivos en su sistema en términos del número máximo de paquetes por intervalo de conexión soportado.

Summary & closing

Los valores calculados que hemos enumerado anteriormente son todavía teóricos y pueden no alinearse con el rendimiento de los datos medidos en la práctica y los entornos de la vida real, pero siguen siendo un buen punto de partida y dan una buena indicación de lo que se puede esperar (al menos para un máximo). Las interferencias y los errores de transmisión/recepción también afectan al rendimiento de los datos (los reintentos, la pérdida de datos y el cierre de la conexión provocan un menor rendimiento). Estas interferencias pueden deberse a la presencia de otros dispositivos que utilicen la misma banda de 2,4 GHz que Bluetooth, a una mayor distancia entre los dispositivos, a la existencia de obstáculos entre ellos, etc…