Free Press

Introduction

Dans ce deuxième post de la série sur Bluetooth 5, nous couvrons la nouvelle fonctionnalité de vitesse 2x améliorée ainsi qu’un aperçu général du débit pour une application BLE (le post précédent a parcouru les nouvelles fonctionnalités de Bluetooth 5 en général et a plus spécifiquement couvert la fonctionnalité de capacité d’annonce accrue).

D’abord, il faut comprendre que les vitesses annoncées (1 Mbps et les nouveaux 2 Mbps) ne sont que théoriques et sont amputées lorsqu’il s’agit du débit des applications. Ceci est dû à de multiples raisons que nous allons aborder dans la section suivante.

La fonctionnalité Bluetooth 5 « 2x speed » nécessite une mise à jour matérielle, donc les anciens appareils/puces/modules ne la supporteront pas. Il est également important de noter que pour obtenir ce débit plus élevé, vous aurez besoin que les deux appareils BLE communiquant entre eux prennent en charge le nouveau PHY LE 2M (qui permet de transférer des données à ce débit plus élevé).

Le nouveau LE 2M PHY, ainsi que le LE 1M PHY original, sont tous deux appelés PHY non codés puisqu’ils utilisent une représentation à 1 symbole par bit de données (par rapport au nouveau LE Coded PHY qui utilise une représentation à 2 ou 8 symboles par bit de données).

Une autre chose importante à noter est que lors de l’utilisation du PHY à plus haut débit, vous obtenez en fait une consommation d’énergie plus faible (étant donné que vous transférez la même quantité de données). Cela est dû au fait que le temps d’activation de la radio est réduit sans que la puissance d’émission soit augmentée. En retour, cela améliore également la coexistence avec d’autres technologies sans fil dans le spectre 2,4 GHz (également en raison de la réduction du temps d’activation radio).

Dans ce post, nous couvrirons :

• Quel est le débit pratique à attendre de BLE ?
• Le nouveau PHY 2M de Bluetooth 5 pour le transfert de données
• Quels sont les facteurs qui impactent/déterminent le débit de données ?
• Comment calculer le débit de données de votre application ?
• Comment maximiser votre débit de données ?
• Tester, mesurer et calculer le débit de données à l’aide de deux kits de développement de la série nRF52

Pourquoi est-il impossible d’atteindre les vitesses théoriques du BLE ?

Les débits de 1 Mbps (LE 1M PHY), 2 Mbps (LE 2M PHY), 125 kbps et 500 kbps (tous deux utilisant le LE Coded PHY avec S=8 et S=2, respectivement) sont les débits auxquels la radio transmet les données, mais cela n’est pas réalisable pour le débit de l’application pour les raisons suivantes :

• Limite du nombre de paquets par intervalle de connexion
• Délai IFS (Inter Frame Space) entre les paquets (150 us)
• Paquets vides devant être envoyés par un dispositif même si aucune donnée n’est disponibles pour la transmission
• Débordement de paquets – tous les octets d’un paquet ne sont pas utilisés pour la charge utile

Pour mieux comprendre ces facteurs et comprendre ce qui a un impact sur le débit des applications, nous devons examiner de plus près le format des paquets. La figure suivante montre à quoi ressemblent les paquets de données LE 1M PHY et 2M PHY :

La partie qui nous intéresse (et celle qui définit vraiment les données de l’application) est la charge utile ATT. Comme vous pouvez le voir sur la figure, il existe un certain nombre d’octets de surcharge qui sont utilisés par chaque couche dans Bluetooth Low Energy.

• Dans les versions 4.0 et 4.1, la charge utile ATT maximale est de 20 octets.
• Dans les versions 4.2 et 5.0, une nouvelle fonctionnalité appelée Data Length Extensions (DLE) permet à la charge utile ATT de contenir jusqu’à 244 octets de données.

Vitesse de Bluetooth 5 : 2x la vitesse en utilisant le nouveau 2M PHY

Il est utile de comprendre les limites de l’utilisation du nouveau LE 2M PHY dans Bluetooth 5 :

• Ne peut pas être utilisé pour transmettre les annonces primaires (sur les canaux primaires).
• Peut être utilisé pour les « paquets auxiliaires » secondaires envoyés sur les mêmes canaux que les paquets de données (37 canaux : 0-36).
  Pour en savoir plus sur les annonces primaires et secondaires, reportez-vous à mon précédent billet de blog : Annonces Bluetooth 5 : Tout ce que vous devez savoir.
• LE 1M est obligatoire, tandis que LE 2M est facultatif. Ainsi, toutes les puces revendiquant le support de Bluetooth 5 ne peuvent pas nécessairement gérer le débit plus élevé.
• Les annonces et la découverte peuvent se produire sur le PHY LE 2M, puis les connexions se produisent sur le canal d’annonce secondaire en utilisant le PHY LE 2M

Le transfert de données d’application d’un appareil à un autre se produit généralement pendant une connexion entre les deux appareils. Les dispositifs connectés peuvent négocier l’utilisation d’un PHY différent via la procédure de mise à jour du PHY. Elle peut être initiée par l’esclave ou le maître après l’établissement d’une connexion, mais le maître prendra finalement la décision finale sur les PHY utilisés pour chaque direction (en fonction de la demande de l’esclave et des PHY que le maître supporte).

Facteurs qui impactent/déterminent le débit de données

Il existe quelques facteurs qui impactent le débit de données d’une application BLE. Les plus courants sont :

• PHY utilisée (LE 1M vs. LE 2M vs. LE Codé (S=2 ou S=8))
• Intervalle de connexion
• Nombre maximal de paquets par intervalle de connexion
• Unité de transmission maximale ATT (ATT MTU)
• Data Length Extension (DLE)
• Type d’opération : Écriture avec réponse vs écriture sans réponse, Indications vs Notifications
• Inter Frame Space (IFS) : écart de temps entre les paquets conséquents (150 us)
• Transmission de paquets vides
• Surcharge de paquets – tous les octets, dans un paquet, ne sont pas utilisés pour la charge utile de l’application

Reprenons chacun de ces éléments plus en détail.

PHY

Il y a fondamentalement trois PHY dans Bluetooth 5 : le PHY original de 1 Mbps, le nouveau de 2 Mbps, et le PHY codé (avec S=2, ou S=8). Le PHY utilisé aura un impact direct sur le débit maximal de données que vous pouvez atteindre puisqu’il détermine le débit brut réel dans lequel les paquets sont envoyés par voie hertzienne.

Intervalle de connexion & paquets max par événement de connexion

L’intervalle de connexion détermine effectivement le nombre de paquets qui peuvent être envoyés pendant un événement de connexion. Plus la valeur est élevée, plus il est possible d’envoyer de paquets dans un événement de connexion (jusqu’à une certaine limite pour certains appareils).

En savoir plus sur les intervalles de connexion : Intervalles et événements de connexion BLE

Cependant, le nombre de paquets par événement de connexion dépend de l’appareil et de la pile BLE ; il est donc limité et diffère selon les appareils et les versions de pile sur un appareil spécifique. Cette valeur dépend également du fonctionnement de l’appareil, donc la radio peut devoir s’occuper d’autres événements et le nombre de paquets envoyés par événements de connexion peut ne pas atteindre le maximum autorisé par la pile. Par exemple, ce nombre diffère entre iOS et Android et change également en fonction de la version du système d’exploitation exécuté sur le périphérique.

Il est parfois utile de mettre à jour dynamiquement les paramètres de connexion en fonction du cas d’utilisation. Cependant, gardez à l’esprit que c’est au maître d’accepter ces recommandations ou de mettre à jour les paramètres pour les accommoder.

Data Length Extensions (DLE)

Cette fonctionnalité permet à la taille du paquet de contenir une plus grande quantité de charge utile (Jusqu’à 251 octets contre 27 lorsqu’elle est désactivée). Cette fonctionnalité a été introduite dans la version 4.2 de la spécification Bluetooth.

ATT Maximum Transmission Unit (ATT MTU)

ATT MTU Détermine la quantité maximale de données qui peut être traitée par l’émetteur et le récepteur et qu’ils peuvent contenir dans leurs tampons.

La valeur MTU affecte la quantité de données de surcharge (spécifiquement l’en-tête ATT qui est de 3 octets). Le MTU ATT minimum autorisé est de 27 octets. Cela permet un maximum de 20 octets de charge utile ATT (3 octets sont utilisés pour l’en-tête ATT, et 4 octets pour l’en-tête L2CAP).

Il n’y a pas de limite par la spécification sur la hauteur de la valeur MTU, mais la pile spécifique utilisée peut avoir ses propres limitations. Par exemple, si vous activez DLE alors vous pouvez transférer jusqu’à 251 – 4 = 247 octets (après déduction de la taille de l’en-tête L2CAP). Après avoir pris en compte l’en-tête ATT (3 octets), il nous reste 244 octets pour les données utiles ATT réelles. Si la MTU est d’au moins 247 octets, elle tiendra dans un seul paquet. Si le MTU est supérieur à 247 octets, alors le MTU s’étendra sur plusieurs paquets, ce qui entraînera une baisse du débit (en raison de l’overhead des paquets et du timing entre les paquets).

Le MTU effectif se détermine par la valeur minimale du MTU ATT que le client et le serveur supportent. Par exemple, si un client supporte un ATT MTU de 100 octets et que le serveur répond qu’il supporte un ATT MTU de 150 octets, alors le client décidera que l’ATT MTU à utiliser pour la connexion à partir de là est de 100 octets.

Type d’opération : Écriture avec réponse vs écriture sans réponse, Indications vs Notifications

Si un débit élevé est souhaité alors nous pouvons utiliser l’écriture sans réponse ou les Notifications pour transférer les données du client au serveur et du serveur au client. Ces opérations suppriment la nécessité pour l’autre dispositif d’accuser réception des données et de répondre avant que le bloc de données suivant puisse être envoyé.

Inter Frame Space (IFS) : délai entre des paquets consécutifs (150 us)

Dans la spécification Bluetooth :

4.1.1 Inter Frame Space

L’intervalle de temps entre deux paquets consécutifs sur le même indice de canal est appelé Inter Frame Space. Il est défini comme le temps entre la fin du dernier bit du paquet précédent et le début du premier bit du paquet suivant.
L’Inter Frame Space est désigné « T_IFS » et doit être de 150 μs.

Transmission de paquets vides

Si le dispositif recevant les données n’a pas de données à renvoyer, il doit tout de même envoyer un paquet vide conformément à la spécification Bluetooth.

Transmission de paquets

Comme nous l’avons vu dans la figure du format de paquet, le paquet comprend quelques données de surcharge qui ne comptent pas pour vos données d’application (données ATT). Fondamentalement, ces octets consommeront une partie de votre taux de données de transfert tout en ne comptabilisant aucun octet envoyé dans le cadre de vos données d’application.

Calcul du débit de vos données d’application

La grande question est : comment calculer le débit de notre application ?

Comme nous l’avons mentionné précédemment, il y a quelques variables qui ont un impact sur le débit de données :

• Version Bluetooth & PHY utilisé
• DLE : Data Length Extensions – activé ou non
• Valeur MTUATT
• Intervalle de connexion
• Nombre maximal de paquets par événement de connexion
• Opération (écritures avec réponses vs. écritures sans réponses, et notification vs indication)
• Espace inter-trame (IFS) : 150 microsecondes

La version Bluetooth et le PHY déterminent le taux de transfert des données brutes. Par exemple, si nous utilisons la version Bluetooth 4.2 et le PHY LE 1M, alors le taux de transfert est de 1 Mbps. Si d’autre part, nous utilisons le Bluetooth 5 LE Coded PHY avec S=8, alors le débit de données descend à 125 kbps.

Le DLE, ATT MTU, l’intervalle de connexion, le nombre maximum de paquets par intervalle de connexion, Operation, et IFS déterminent tous la portion du temps on-radio qui est utilisée pour le transfert réel de données.

Le format des paquets joue un rôle important dans la quantité de données transférées qui sont les données réelles de votre application. Le LE 1M PHY et le LE 2M PHY ont tous deux un format de paquet similaire. Le LE Coded PHY a un format de paquet sensiblement différent, nous allons donc examiner ces deux cas séparément.

Calcul du LE 1M PHY et du LE 2M PHY

Retour au format de paquet pour les LE Uncoded PHYs:

La quantité de surcharge pour chaque PHY est légèrement différente. Le préambule est de 1 octet dans le cas du PHY 1M et de 2 octets dans le cas du PHY 2M. Le champ MIC est un champ facultatif qui n’est utilisé que pour les connexions cryptées. Pour simplifier, nous ne considérerons que les connexions non cryptées – pour le cas crypté, il ajoute simplement 4 octets de surcharge.

Pour les PHY codés LE, le format du paquet ressemble à ceci (tiré de la spécification Bluetooth 5.0 Vol 6, partie B, section 2.2):

Étapes de calcul du débit (en Mbps):

Pour simplifier, nous supposons ce qui suit:

• Le cryptage n’est PAS activé (le champ MIC n’est pas inclus dans le paquet)
• Nous sommes intéressés par le débit pour une direction (par exemple. Maître à Esclave), donc nous supposons que l’autre direction ne transfère que des paquets vides
• Ecritures sans réponses (ce qui aiderait à maximiser le débit lors du transfert de grandes quantités de données

Etapes:

1. Déterminer le PHY utilisé et noter le taux de transfert de données brutes
   Ex. pour un PHY 1M -> 1 Mbps, pour un PHY codé et S=8 -> 125 kbps
2. Déterminer le temps nécessaire pour envoyer un paquet de données et le paquet vide du récepteur.
   Le temps pendant lequel un paquet de données peut être envoyé comprendra les éléments suivants :

   Data_Packet_Time = Temps pour transmettre le paquet vide + IFS + Temps pour transmettre le paquet de données réel + IFS.
   Un temps de transmission du paquet vide peut être calculé comme suit :

   Temps de transmission du paquet vide = taille du paquet vide / débit de données brutes

   Un paquet vide comprendra les champs suivants :

   Préambule + adresse d’accès + en-tête LL + CRC.

   Pour 1M PHY, le Préambule sera de 1 octet, et donc la taille totale du paquet vide = 1 + 4 + 2 + 3 octets = 10 octets = 80 bits.
   (pour 2M PHY, la taille d’un paquet vide sera de 88 bits puisque le Préambule est de 2 octets au lieu de 1 octet).

   Sur cette base, le temps de transmission d’un paquet vide 1M PHY sera :

   Temps de transmission d’un paquet vide = taille du paquet vide / débit de données brut = 80 bits / 1 Mégabits par seconde = 80 micro secondes

   Un paquet de données contiendra tous les champs énumérés dans le diagramme de format de paquet à l’exception du champ MIC (cryptage désactivé).

   Temps pour transmettre un paquet de données = taille du paquet de données / débit brut

   Si nous avons DLE activé et que le MTU ATT est égal au maximum d’octets autorisés dans un paquet : 247 octets, alors nous pouvons calculer la taille du paquet de données comme :

   Taille du paquet de données = 1 + 4 + 2 + 4 + 247 + 3 octets = 265 octets = 265*8 bits = 2088 bits

   Temps pour transmettre le paquet de données = 2088 bits / 1 Mbps = 2,088 microsecondes

   Data_Packet_Time = Temps de transmission du paquet vide + IFS + Temps de transmission du paquet de données proprement dit + IFS = 80 + 2*150 + 2088 = 2,468 microsecondes
   Pour comparaison, dans le cas d’un PHY 2M, ce serait :

   Data_Packet_Time = Temps de transmission du paquet vide + IFS + Temps de transmission du paquet de données réel + IFS = 88/2 + 2*150 + (2 + 4 + 2 + 4 + 247 + 3)*8/2 = 1 392 microsecondes
   Lorsque DLE est activé et que l’ATT MTU est défini à moins de 247, nous nous retrouvons avec plus de surcharge (puisque maintenant les données plus grandes que l’ATT MTU sont divisées en plus de paquets). Par exemple, si la MTU ATT est fixée à 158, pour transférer 244 octets de données d’application, il faudra deux paquets au lieu d’un, ce qui entraînera une baisse du débit en raison de l’augmentation du nombre d’octets et de l’augmentation de l’IFS entre les paquets. Dans un autre scénario, nous pourrions avoir DLE désactivé (taille de la charge utile jusqu’à 27 octets) et le MTU ATT supérieur à 27 octets. Ici, cela se traduira également par un plus grand nombre de paquets nécessaires à envoyer pour la même quantité de données, ce qui entraînera une baisse du débit.

   Note : La même méthode de calcul de la taille des paquets de données et des paquets vides que nous avons utilisée ci-dessus peut être utilisée pour le PHY codé LE.

3. Découvrez combien de paquets peuvent être transmis pendant un intervalle de connexion
   Ce calcul n’est pas toujours purement mathématique – vous devrez prendre en compte les limitations de la pile et du dispositif utilisé. iOS et Android ont des maximums qui changent avec la version de l’OS, donc ce n’est pas toujours facile à déterminer. Cela dit, sur un MCU, le SDK du fournisseur indique généralement le maximum dans sa documentation. Il est également utile de faire un essai et une erreur et de déterminer ce que votre périphérique spécifique prend en charge.

   Une fois que vous avez déterminé le maximum, vous pouvez calculer le nombre théorique maximum de paquets qui s’inscriraient dans un intervalle de connexion de votre choix. Par exemple, si nous avions un intervalle de connexion de 7,5 millisecs (le plus bas autorisé par la spécification), alors pour notre exemple ci-dessus (en utilisant 1M PHY, DLE activé) :

   Nombre maximal de paquets de données par intervalle de connexion = , où arrondit au nombre entier le plus élevé (nombre entier)

   Nombre maximal de paquets de données par intervalle de connexion = = 3 paquets

   En général, ce nombre n’est pas réaliste car il y a des délais entre les paquets envoyés sur des événements de connexion consécutifs. Donc, pour notre exemple, nous irons avec 2 paquets au lieu de 3.

4. Une fois que nous avons déterminé le # maximum de paquets de données qui peuvent être transférés par intervalle de connexion, nous pouvons calculer le débit de données :Débit de données = données par intervalle de connexion / intervalle de connexion = Nbre de paquets de données par intervalle de connexion * Taille des données par paquet / intervalle de connexion
   = 2 * 244 * 8 bits / 7.5 millisecs = 520,533 bits/sec ~= 508 kbps

Test et calcul du débit de données entre deux kits de développement nRF52

Dans cette section, nous allons effectuer plusieurs tests de transfert de données, calculer le débit en utilisant la procédure que nous avons décrite précédemment, puis les comparer avec le débit mesuré rapporté par l’application exécutée sur les cartes de développement. Les tests sont effectués sur la base de l’application de démonstration fournie par Nordic Semiconductor et présentée dans cet article de blog : Débit et démo longue portée.

Le code source de l’exemple peut être trouvé sur la page GitHub ici.

Case 1 (PHY : 1 Mbps, ATT MTU = 23 octets, DLE : activé, Intervalle de connexion : 7,5 millisecs)

Débit de données rapporté par le firmware:

Temps : 36.11 secondes écoulées.
Débit : 232,29 Kbits/s.
Envoyé 1048580 octets de charge utile ATT.

Débit de données calculé:

Avec le MTU fixé à 23 octets, DLE n’affecte pas vraiment le débit de données et la taille des paquets.

Temps pour transmettre le paquet de données = taille du paquet de données / débit brut = 1 + 4 + 2 + 4 + 23 + 3 octets / 1 Mbps= 37*8 bits / 1 Mbps = 296 microsecondes

Data_Packet_Time = Temps pour transmettre le paquet vide + IFS + Temps pour transmettre le paquet de données réel + IFS = 80 + 150 + 296 + 150 microsecondes =. 676 microsecondes

Nombre maximal de paquets de données par intervalle de connexion = = = = 11 paquets
Données totales transférées par intervalle de connexion = 11 * 20 octets = 11 * 20 * 8 bits = 1760 bits

Data throughput = Données totales transférées par intervalle de connexion/intervalle de connexion = 1760 bits / 7.5 millisecs = 234,67 Kbits/s
Comme on peut le voir, la valeur calculée et la valeur mesurée sont assez proches.

Cas 2 (PHY : 2 Mbps, ATT MTU = 23 octets, DLE : activé, intervalle de connexion : 7.5 millisecs)

Débit de données rapporté par le firmware :

Temps : 27,23 secondes écoulées.
Débit : 307,96 Kbits/s.
Envoyé 1048580 octets de charge utile ATT.

Débit de données calculé :

Temps de transmission du paquet de données = taille du paquet de données / débit brut = 2 + 4 + 2 + 4 + 23 + 3 octets / 2 Mbps= 38*8 bits / 2 Mbps = 152 microsecs

Data_Packet_Time = Temps de transmission du paquet vide + IFS + Temps de transmission du paquet de données réel + IFS = 44 + 150 + 152 + 150 microsecs =. 496 microsecondes

Nombre maximal de paquets de données par intervalle de connexion = = = = 15 paquets
Données totales transférées par intervalle de connexion = 15 * 20 octets = 15 * 20 * 8 bits = 2400 bits

Data throughput = Données totales transférées par intervalle de connexion/intervalle de connexion = 2400 bits / 7.5 millisecs = 320 Kbits/s
Comme on peut le voir, la valeur calculée et la valeur mesurée sont assez proches.

Cas 3 (PHY : 1 Mbps, ATT MTU = 158 bytes, DLE : activé, Intervalle de connexion : 7.5 millisecs)

Débit de données rapporté par le firmware :

Temps : 17,53 secondes écoulées.
Débit : 478,36 Kbits/s.
Envoyé 1048730 octets de charge utile ATT.

Débit de données calculé :

Temps de transmission du paquet de données = taille du paquet de données / débit brut = 1 + 4 + 2 + 4 + 158 + 3 octets / 1 Mbps= 172*8 bits / 1 Mbps = 1376 microsecs

Data_Packet_Time = Temps de transmission du paquet vide + IFS + Temps de transmission du paquet de données effectif + IFS = 80 + 150 + 1376 + 150 microsecs =. 1756 microsecondes

Nombre maximal de paquets de données par intervalle de connexion = = = = 4 paquets
Données totales transférées par intervalle de connexion = 4 * 155 octets = 4 * 155 * 8 bits = 4960 bits

Data throughput = Données totales transférées par intervalle de connexion/intervalle de connexion = 4960 bits / 7.5 millisecs = 661.33 Kbits/s

Cas 4 (PHY : 2 Mbps, ATT MTU = 247 bytes, DLE : activé, Intervalle de connexion : 7.5 millisecs)

Débit de données rapporté par le firmware :

Temps : 8,45 secondes écoulées.
Débit : 992,07 Kbits/s.
Envoyé 1048712 octets de charge utile ATT.

Débit de données calculé :

Temps de transmission du paquet de données = taille du paquet de données / débit brut = 2 + 4 + 2 + 4 + 247 + 3 octets / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs

Data_Packet_Time = Temps de transmission du paquet vide + IFS + Temps de transmission du paquet de données réel + IFS = 44 + 150 + 1048 + 150 microsecs =… 1392 microsecondes

Nombre maximal de paquets de données par intervalle de connexion = = = = 5 paquets
Données totales transférées par intervalle de connexion = 5 * 244 octets = 5 * 244 * 8 bits = 9760 bits

Data throughput = Données totales transférées par intervalle de connexion/intervalle de connexion = 9760 bits / 7.5 millisecondes = 1301,33 Kbits/s

Note : Dans les deux derniers cas, le nombre de paquets par intervalle de connexion est faible et toute différence entre ce que nous calculons et ce qui est mesuré aura un grand impact sur le débit de données réel. Par exemple, si le nombre de paquets par intervalle de connexion finit par être de 4 au lieu de 5 dans le cas 4, le débit calculé devient 1 041,1 Kbps au lieu de 1 301,33 Kbps (ce qui est une grande différence et pourrait expliquer l’écart dans les chiffres ici).

Cas 5 (PHY : 2 Mbps, ATT MTU = 247 octets, DLE : activé, intervalle de connexion : 50 millisecs)

Débit de données rapporté par le firmware :

Temps : 6,34 secondes écoulées.
Débit : 1322,33 Kbits/s.
Envoyé 1048712 octets de charge utile ATT.

Débit de données calculé :

Temps pour transmettre le paquet de données = taille du paquet de données / débit brut = 2 + 4 + 2 + 4 + 247 + 3 octets / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs

Data_Packet_Time = Temps pour transmettre le paquet vide + IFS + Temps pour transmettre le paquet de données réel + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs

.

Nombre maximal de paquets de données par intervalle de connexion = = = = 35 paquets

Données totales transférées par intervalle de connexion = 36 * 244 octets = 35 * 244 * 8 bits = 68320 bits

Débit de données = Données totales transférées par intervalle de connexion/intervalle de connexion = 70272 bits / 50 millisecs = 1366.4 Kbits/s

Cas 6 (PHY : 2 Mbps, ATT MTU = 247 octets, DLE : activé, intervalle de connexion : 400 millisecs)

Débit de données rapporté par le firmware :

Temps : 6,11 secondes écoulées.
Débit : 1371,82 Kbits/s.
Envoyé 1048712 octets de charge utile ATT.

Débit de données calculé :

Temps pour transmettre le paquet de données = taille du paquet de données / débit brut = 2 + 4 + 2 + 4 + 247 + 3 octets / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs

Data_Packet_Time = Temps pour transmettre le paquet vide + IFS + Temps pour transmettre le paquet de données réel + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs

.

Nombre maximal de paquets de données par intervalle de connexion = = = = 287 paquets

Données totales transférées par intervalle de connexion = 287 * 244 octets = 287 * 244 * 8 bits = 560224 bits

Débit de données = Données totales transférées par intervalle de connexion/intervalle de connexion =560224 bits / 400 millisecs = 1400.56 Kbits/s

Optimisation pour un débit de données maximal

Sur la base des facteurs que nous avons survolés, nous pouvons noter ce qui suit lors de l’optimisation pour un débit de données élevé :

• Toujours activer DLE
  Evidemment, si vous utilisez Bluetooth v4.1 ou antérieur, ce n’est pas une option valide. En général, cependant, assurez-vous d’avoir activé DLE pour maximiser l’efficacité des données de votre paquet à l’application
• Utiliser LE 2M PHY
  Si vous savez que les appareils aux deux extrémités supportent Bluetooth 5, alors l’utilisation du LE 2M PHY est l’une des meilleures façons de maximiser le débit de données de votre application. L’utilisation du PHY LE 2M aidera également à réduire la consommation d’énergie, donc vous faites d’une pierre deux coups !
• Utiliser les notifications et les écritures sans réponses
  L’utilisation de celles-ci aidera à supprimer tout paquet inutile transmis (par rapport aux indications et aux écritures normales qui nécessitent que l’extrémité réceptrice accuse réception de chaque paquet reçu).
• Choisissez une valeur MTU ATT au moins supérieure à 247 octets
  Cela minimisera toute surcharge en octets de paquets.
• Choisissez un intervalle de connexion qui permet le # maximum de paquets par intervalle de connexion
  Mais gardez à l’esprit que l’intervalle de connexion affecte la consommation d’énergie. Plus l’intervalle est court, plus votre appareil consommera de l’énergie en raison de l’augmentation du temps d’activation de la radio. Vous devez également vous assurer que vous ne choisissez pas un intervalle trop élevé, sinon cela compromettra l’expérience de l’utilisateur (un intervalle de connexion plus élevé entraîne une latence plus importante). Une dernière chose dont vous devez vous assurer de tenir compte est toute limitation des périphériques de votre système en termes de nombre maximal de paquets par intervalle de connexion pris en charge.

Summary & closing

Les valeurs calculées que nous avons énumérées ci-dessus sont encore théoriques et peuvent ne pas s’aligner sur le débit de données mesuré dans la pratique et les environnements réels, mais elles constituent tout de même un bon point de départ et donnent une bonne indication de ce à quoi il faut s’attendre (au moins pour un maximum). Les interférences et les erreurs de transmission/réception affectent également le débit de données (les tentatives, les pertes de données et les événements de fermeture de la connexion entraînent une baisse du débit). Elles peuvent être causées par la présence d’autres appareils utilisant la même bande de 2,4 GHz que Bluetooth, une plus grande distance entre les appareils, l’existence d’obstacles entre les appareils, etc…

.