Free Press

Introduction

In deze tweede post in de serie over Bluetooth 5, behandelen we de nieuwe functie van verbeterde 2x snelheid samen met een algemeen overzicht van doorvoer voor een BLE-applicatie (de vorige post ging over Bluetooth 5’s nieuwe functies in het algemeen en meer specifiek over de verhoogde advertentiecapaciteit functie).

Ten eerste moeten we begrijpen dat de geadverteerde snelheden (1 Mbps en de nieuwe 2 Mbps) slechts theoretisch zijn en worden afgekapt als het gaat om de doorvoer van toepassingen. Dit is te wijten aan meerdere redenen die we in de volgende sectie zullen bespreken.

De Bluetooth 5 “2x snelheid” functie vereist een hardware update, zodat oudere apparaten/chips/modules het niet zullen ondersteunen. Het is ook belangrijk op te merken dat om deze hogere doorvoersnelheid te bereiken, u beide BLE-apparaten die met elkaar communiceren nodig heeft om de nieuwe LE 2M PHY te ondersteunen (die het mogelijk maakt om gegevens met deze hogere snelheid over te dragen).

De nieuwe LE 2M PHY, evenals de oorspronkelijke LE 1M PHY, worden beide Uncoded PHYs genoemd omdat zij een 1-symbol representatie per bit van gegevens gebruiken (in vergelijking met de nieuwe LE Coded PHY die een 2-symbol of 8-symbol representatie per bit van gegevens gebruikt).

Een ander belangrijk ding om op te merken is dat wanneer u de hogere snelheid PHY gebruikt, u eigenlijk een lager stroomverbruik bereikt (gegeven dat u dezelfde hoeveelheid gegevens overdraagt). Dit komt omdat de radio-aan tijd wordt verminderd zonder dat het zendvermogen wordt verhoogd. Dit verbetert op zijn beurt ook de co-existentie met andere draadloze technologieën binnen het 2,4 GHz-spectrum (ook vanwege de kortere radio-aan-tijd).

In dit bericht behandelen we:

• Wat is de praktische doorvoer die u van BLE kunt verwachten?
• Bluetooth 5’s nieuwe 2M PHY voor gegevensoverdracht
• Wat zijn de factoren die de gegevensdoorvoer beïnvloeden/bepalen?
• Hoe berekent u de datadoorvoer van uw toepassing?
• Hoe maximaliseert u uw datadoorvoer?
• Testen, meten en berekenen van de datadoorvoer met behulp van twee nRF52-serie ontwikkelkits

Waarom is het onmogelijk om de theoretische snelheden van BLE te bereiken?

De datasnelheden van 1 Mbps (LE 1M PHY), 2 Mbps (LE 2M PHY), 125 kbps en 500 kbps (beide met behulp van de LE gecodeerde PHY met S=8 en S=2, respectievelijk) zijn de snelheden waarmee de radio gegevens verzendt, maar dit is niet haalbaar voor de toepassing throughput als gevolg van de volgende redenen:

• Limiet aan het aantal pakketten per verbindingsinterval
• Inter Frame Space (IFS) vertraging tussen pakketten (150 us)
• Er moeten lege pakketten van een apparaat worden verzonden, zelfs als er geen gegevens beschikbaar is voor verzending
• Pakketoverhead – niet alle bytes in een pakket worden gebruikt voor payload

Om deze factoren beter te begrijpen en te begrijpen wat invloed heeft op de verwerkingscapaciteit van toepassingen, moeten we een diepere blik werpen op het pakketformaat. De volgende figuur laat zien hoe LE 1M PHY en 2M PHY datapakketten eruit zien:

Het deel waar we in geïnteresseerd zijn (en datgene dat echt de applicatiedata definieert) is de ATT Payload. Zoals u in de figuur kunt zien, zijn er een aantal overhead-bytes die door elke laag in Bluetooth Low Energy worden gebruikt.

• In 4.0 en 4.1 is de maximale ATT Payload 20 bytes.
• In 4.2 en 5.0 kan de ATT Payload dankzij een nieuwe functie, Data Length Extensions (DLE), maximaal 244 bytes aan gegevens bevatten.

Bluetooth 5 snelheid : 2x snelheid gebruikmakend van de nieuwe 2M PHY

Het is nuttig om de beperkingen te begrijpen van het gebruik van de nieuwe LE 2M PHY in Bluetooth 5:

• Kan niet worden gebruikt om de primaire advertenties (op de primaire kanalen) te verzenden.
• Kan worden gebruikt voor de secundaire “hulppakketten” die op dezelfde kanalen worden verzonden als de gegevenspakketten (37 kanalen: 0-36).
  Om meer te weten te komen over primaire en secundaire advertenties, raadpleeg mijn vorige blogpost: Bluetooth 5 Advertenties: Alles wat u moet weten.
• LE 1M is verplicht, terwijl LE 2M optioneel is. Dus, niet alle chips beweren Bluetooth 5 ondersteuning kan noodzakelijkerwijs omgaan met de hogere throughput.
• Advertenties en ontdekking kan optreden op de LE 2M PHY, en vervolgens verbindingen optreden op de secundaire advertentie kanaal met behulp van de LE 2M PHY

Overdracht van applicatiegegevens van het ene apparaat naar het andere gebeurt meestal tijdens een verbinding tussen de twee apparaten. De aangesloten apparaten kunnen onderhandelen over het gebruik van een andere PHY via de PHY Update Procedure. Deze kan zowel door de slave als de master worden geïnitieerd nadat een verbinding tot stand is gebracht, maar de master zal uiteindelijk de uiteindelijke beslissing nemen over welke PHY’s voor elke richting worden gebruikt (op basis van het verzoek van de slave en de PHY’s die de master ondersteunt).

Factoren die de gegevensdoorvoer beïnvloeden/bepalen

Er zijn enkele factoren die de gegevensdoorvoer van een BLE-toepassing beïnvloeden. De meest voorkomende zijn:

• PHY die wordt gebruikt (LE 1M vs. LE 2M vs. LE Coded (S=2 of S=8))
• Verbindingsinterval
• Maximaal aantal pakketten per verbindingsinterval
• ATT Maximale Transmissie Eenheid (ATT MTU)
• Data Lengte Uitbreiding (DLE)
• Operatie type: Write with response vs. write without response, Indications vs. Notifications
• Inter Frame Space (IFS): tijdsverschil tussen opeenvolgende pakketten (150 us)
• Transmissie van lege pakketten
• Packet overhead – niet alle bytes, in een pakket, worden gebruikt voor de nuttige lading van de toepassing

Laten we elk van deze in meer detail bespreken.

PHY

Er zijn in principe drie PHYs in Bluetooth 5: de oorspronkelijke 1 Mbps PHY, de nieuwe 2 Mbps, en de gecodeerde PHY (met S=2, of S=8). De gebruikte PHY heeft een directe invloed op de maximale gegevensdoorvoer die u kunt bereiken, omdat deze de feitelijke ruwe gegevenssnelheid bepaalt waarmee pakketten door de lucht worden verzonden.

Verbindingsinterval & max pakketten per verbindingsgebeurtenis

Het verbindingsinterval bepaalt in feite hoeveel pakketten tijdens één verbindingsgebeurtenis kunnen worden verzonden. Hoe hoger de waarde, hoe meer pakketten kunnen worden verzonden in één verbindingsgebeurtenis (tot een bepaalde limiet voor sommige apparaten).

Lees meer over verbindingsintervallen: BLE verbindingsintervallen en gebeurtenissen

Het aantal pakketten per verbindingsgebeurtenis is echter afhankelijk van het apparaat en de BLE-stack, dus het is beperkt en verschilt tussen apparaten en stackversies op een specifiek apparaat. Deze waarde hangt ook af van de werking van het apparaat, dus de radio moet mogelijk andere gebeurtenissen bijwonen en het aantal verzonden pakketten per verbindingsgebeurtenis bereikt mogelijk niet het maximum dat door de stack is toegestaan. Het aantal verschilt bijvoorbeeld tussen iOS en Android en verandert ook afhankelijk van de versie van het OS dat op het apparaat draait.

Soms is het nuttig om de verbindingsparameters dynamisch bij te werken op basis van de use case. Houd echter in gedachten dat het aan de master is om deze aanbevelingen te accepteren of de parameters aan te passen.

Data Length Extensions (DLE)

Deze eigenschap staat de pakketgrootte toe om een grotere hoeveelheid payload te bevatten (tot 251 bytes vs. 27 wanneer uitgeschakeld). Deze functie werd geïntroduceerd in versie 4.2 van de Bluetooth spec.

ATT Maximum Transmission Unit (ATT MTU)

ATT MTU Bepaalt de maximale hoeveelheid data die kan worden verwerkt door de zender en ontvanger en die zij kunnen vasthouden in hun buffers.

De MTU-waarde is van invloed op de hoeveelheid overhead data (specifiek de ATT-header die 3 bytes is). De minimaal toegestane ATT MTU is 27 bytes. Dit staat een maximum van 20 bytes ATT payload toe (3 bytes worden gebruikt voor de ATT header, en 4 bytes voor de L2CAP header).

Er is geen limiet volgens de spec over hoe hoog de MTU waarde kan zijn, maar de specifieke stack in gebruik kan zijn eigen beperkingen hebben. Als je bijvoorbeeld DLE inschakelt, kun je tot 251 – 4 = 247 bytes overdragen (na aftrek van de L2CAP header grootte). Na rekening te hebben gehouden met de ATT header (3 bytes), houden we 244 bytes over voor de eigenlijke ATT payload data. Als de MTU ten minste 247 bytes is, past het in een enkel pakket. Als de MTU groter is dan 247 bytes, dan zal de MTU meerdere pakketten omvatten waardoor de doorvoer afneemt (vanwege de overhead van het pakket en de timing tussen de pakketten).

De effectieve MTU wordt bepaald door de minimum waarde van ATT MTU die de client en server ondersteunen. Bijvoorbeeld, als een client een ATT MTU van 100 bytes ondersteunt en de server antwoordt dat hij een ATT MTU van 150 bytes ondersteunt, dan zal de client besluiten dat de ATT MTU die vanaf dat moment voor de verbinding moet worden gebruikt, 100 bytes is.

Werkingstype: Write with response vs. write without response, Indications vs. Notifications

Als een hoge doorvoer gewenst is dan kunnen we Write without response of Notifications gebruiken om de gegevens van de client naar de server en van de server naar de client over te brengen. Deze operaties verwijderen de noodzaak voor het andere apparaat om de ontvangst van de gegevens te bevestigen en te antwoorden voordat het volgende blok gegevens kan worden verzonden.

Inter Frame Space (IFS): tijdvertraging tussen opeenvolgende pakketten (150 us)

Uit de Bluetooth-specificatie:

4.1.1 Inter Frame Space

Het tijdsinterval tussen twee opeenvolgende pakketten op dezelfde kanaalindex wordt de Inter Frame Space genoemd. Het wordt gedefinieerd als de tijd vanaf het einde van de laatste bit van het vorige pakket tot het begin van de eerste bit van het volgende pakket.
De interframe-ruimte wordt aangeduid met “T_IFS” en bedraagt 150 μs.

Zenden van lege pakketten

Als het apparaat dat gegevens ontvangt geen gegevens heeft om terug te zenden, moet het toch een leeg pakket zenden volgens de Bluetooth-specificatie.

Pakketoverhead

Zoals we in de figuur van de pakketindeling hebben gezien, bevat het pakket wat overheadgegevens die niet meetellen voor uw toepassingsgegevens (ATT-gegevens). In principe zullen deze bytes een deel van uw transfer data rate verbruiken, terwijl er geen rekening wordt gehouden met bytes die worden verzonden als onderdeel van uw applicatie data.

Bereken uw applicatie data throughput

De grote vraag is: hoe berekenen we onze applicatie throughput?

Zoals we al eerder zeiden, zijn er een paar variabelen die van invloed zijn op de gegevensdoorvoer:

• Bluetooth-versie & PHY gebruikt
• DLE: Data Length Extensions – ingeschakeld of niet
• ATT MTU-waarde
• Verbindingsinterval
• Maximaal aantal pakketten per verbindingsgebeurtenis
• Operatie (schrijft met antwoorden vs. schrijft zonder antwoord, en melding vs. aanwijzing)
• Inter Frame Space (IFS): 150 microseconden

De Bluetooth-versie en PHY bepalen de ruwe data-overdrachtssnelheid. Bijvoorbeeld, als we Bluetooth versie 4.2 en de LE 1M PHY gebruiken, dan is de overdrachtsnelheid 1 Mbps. Als aan de andere kant, we gebruik maken van de Bluetooth 5 LE gecodeerde PHY met S = 8, dan is de gegevensoverdrachtsnelheid daalt tot 125 kbps.

De DLE, ATT MTU, verbinding interval, het maximum aantal pakketten per verbinding interval, Bedrijf, en IFS alle bepalen het deel van de on-radio tijd die wordt gebruikt voor de feitelijke gegevensoverdracht.

Het pakket formaat speelt een grote rol in hoeveel van de gegevens die worden overgedragen is uw werkelijke toepassing gegevens. De LE 1M PHY en LE 2M PHY hebben beide een gelijkaardig pakketformaat. De LE gecodeerde PHY heeft een beduidend andere pakketindeling, dus we zullen deze twee gevallen apart bekijken.

LE 1M PHY en LE 2M PHY berekening

Terugkomend op de pakketindeling voor LE ongecodeerde PHYs:

De hoeveelheid overhead voor elke PHY is iets anders. De Preamble is 1 byte in het geval van de 1M PHY en 2 bytes in het geval van de 2M PHY. Het MIC-veld is een optioneel veld dat alleen voor versleutelde verbindingen wordt gebruikt. Voor de eenvoud zullen we alleen ongecodeerde verbindingen beschouwen – voor het gecodeerde geval voegt het eenvoudig 4 bytes aan overhead toe.

Voor LE gecodeerde PHY’s ziet de pakketindeling er als volgt uit (uit de Bluetooth 5.0 spec Vol 6, Part B, Section 2.2):

Stappen voor het berekenen van de doorvoer (in Mbps):

Voor de eenvoud gaan we uit van het volgende:

• Encryptie is NIET ingeschakeld (MIC-veld is niet opgenomen in het pakket)
• We zijn geïnteresseerd in de doorvoer voor één richting (bijv. Master naar Slave), dus we nemen aan dat de andere richting alleen lege pakketten overdraagt
• Schrijft zonder antwoorden (wat zou helpen bij het maximaliseren van de doorvoer bij het overdragen van grote hoeveelheden data

Stappen:

1. Bepaal de PHY die wordt gebruikt en noteer de snelheid van de overdracht van ruwe data
   Bijv. voor 1M PHY -> 1 Mbps, voor gecodeerde PHY en S=8 -> 125 kbps
2. Bepaal de tijd die nodig is om één datapakket en het lege pakket van de ontvanger te verzenden.
   De tijd gedurende welke één datapakket kan worden verzonden, omvat het volgende:

   Data_Packet_Time = Tijd om leeg pakket te verzenden + IFS + Tijd om het eigenlijke datapakket te verzenden + IFS.
   De tijd voor het verzenden van een leeg pakket kan als volgt worden berekend:

   Tijd voor het verzenden van een leeg pakket = grootte leeg pakket / ruwe datasnelheid

   Een leeg pakket bevat de volgende velden:

   Preamble + Toegangsadres + LL-header + CRC.

   Voor 1M PHY zal de Preamble 1 byte zijn, en dus de totale grootte van het lege pakket = 1 + 4 + 2 + 3 bytes = 10 bytes = 80 bits.
   (Voor 2M PHY zal de grootte van een leeg pakket 88 bits zijn, aangezien de Premable 2 bytes is in plaats van 1 byte).

   Op basis hiervan is de tijd om een leeg 1M PHY-pakket te verzenden:

   Tijd om een leeg pakket te verzenden = grootte leeg pakket / ruwe datasnelheid = 80 bits / 1 Megabit per seconde = 80 microseconden

   Een datapakket bevat alle velden die in het pakketformaatdiagram worden genoemd, met uitzondering van het MIC-veld (encryptie uitgeschakeld).

   Tijd om gegevenspakket te verzenden = grootte gegevenspakket / ruwe gegevenssnelheid

   Als we DLE hebben ingeschakeld en de ATT MTU gelijk is aan de maximale bytes die in één pakket zijn toegestaan: 247 bytes, dan kunnen we de grootte van het gegevenspakket berekenen als:

   Grootte datapakket = 1 + 4 + 2 + 4 + 247 + 3 bytes = 265 bytes = 265*8 bits = 2088 bits

   Tijd om datapakket te verzenden = 2088 bits / 1 Mbps = 2,088 microseconden

   Data_Packet_Time = Tijd om leeg pakket te verzenden + IFS + Tijd om het eigenlijke gegevenspakket te verzenden + IFS = 80 + 2*150 + 2088 = 2.468 microseconden
   Voor vergelijking, in het geval van 2M PHY, zou het zijn:

   Data_Packet_Time = Tijd om leeg pakket te verzenden + IFS + Tijd om het eigenlijke gegevenspakket te verzenden + IFS = 88/2 + 2*150 + (2 + 4 + 247 + 3)*8/2 = 1.392 microsecs
   Wanneer DLE is ingeschakeld en de ATT MTU is ingesteld op minder dan 247, eindigen we met meer overhead (omdat nu gegevens die groter zijn dan de ATT MTU worden opgesplitst in meer pakketten). Stel bijvoorbeeld dat we de ATT MTU ingesteld hebben op 158, dan zullen we, om 244 bytes applicatiedata over te dragen, twee pakketten nodig hebben in plaats van één, waardoor de doorvoer naar beneden gaat door de toegenomen byte-overhead en de toegenomen IFS tussen de pakketten. In een ander scenario zouden we DLE kunnen uitschakelen (Payload grootte tot 27 bytes) en de ATT MTU groter dan 27 bytes. Ook hier zal dit resulteren in meer pakketten die moeten worden verzonden voor dezelfde hoeveelheid gegevens, waardoor de doorvoer naar beneden gaat.

   Note: Dezelfde methode voor het berekenen van de gegevens en lege pakketgroottes die we hierboven hebben gebruikt, kan worden gebruikt voor de LE Coded PHY.

3. Bereken hoeveel pakketten kunnen worden verzonden tijdens één verbindingsinterval
   Deze berekening is niet altijd zuiver wiskundig – u moet rekening houden met beperkingen van de stack en het apparaat dat wordt gebruikt. iOS en Android hebben maxima die veranderen met de OS-versie, dus het is niet altijd gemakkelijk om erachter te komen. Dat gezegd zijnde, op een MCU, de SDK van de leverancier vermeldt meestal het maximum in hun documentatie. Het is ook nuttig om wat te proberen en uit te zoeken wat uw specifiek toestel ondersteunt.

   Eens u het maximum hebt berekend, kunt u het theoretisch maximum aantal pakketten berekenen dat zou passen binnen een verbindingsinterval naar keuze. Bijvoorbeeld, als we een verbindingsinterval van 7,5 millisecs hadden (het laagste toegelaten door de spec), dan zou voor ons voorbeeld hierboven (met 1M PHY, DLE ingeschakeld):

   Maximaal aantal gegevenspakketten per verbindingsinterval = , waarbij wordt afgerond op het hoogste gehele getal (geheel getal)Maximaal aantal gegevenspakketten per verbindingsinterval = = 3 pakketten

   Natuurlijk is dit aantal niet realistisch omdat er tijdsvertragingen zijn tussen pakketten die op opeenvolgende verbindingsgebeurtenissen worden verzonden. Dus, voor ons voorbeeld, gaan we voor 2 pakketten in plaats van 3.

4. Als we eenmaal het maximale aantal datapakketten hebben berekend dat per verbindingsinterval kan worden verzonden, kunnen we de gegevensdoorvoer berekenen:Gegevensdoorvoer = gegevens per verbindingsinterval / verbindingsinterval = Aantal datapakketten per verbindingsinterval * Gegevensgrootte per pakket / verbindingsinterval
   = 2 * 244 * 8 bits / 7.5 millisecs = 520.533 bits/sec ~= 508 kbps

Gegevensdoorvoer testen en berekenen tussen twee nRF52 ontwikkelkits

In dit gedeelte zullen we meerdere tests van gegevensoverdracht uitvoeren, de doorvoer berekenen met behulp van de procedure die we eerder hebben beschreven, en deze vervolgens vergelijken met de gemeten doorvoer die wordt gerapporteerd door de applicatie die op de ontwikkelboards draait. De tests worden uitgevoerd op basis van de demo-app die door Nordic Semiconductor is geleverd en in dit blogbericht wordt beschreven: Throughput and long range demo.

Broncode voor het voorbeeld kan worden gevonden op de GitHub-pagina hier.

Case 1 (PHY: 1 Mbps, ATT MTU = 23 bytes, DLE: ingeschakeld, Verbindingsinterval: 7,5 millisecs)

Data throughput gerapporteerd door firmware:

Tijd: 36.11 seconden verstreken.
Doorvoer: 232,29 Kbits/s.
Verzonden 1048580 bytes ATT-belasting.

Geberekende gegevensdoorvoer:

Met de MTU ingesteld op 23 bytes, heeft DLE niet echt invloed op de gegevensdoorvoer en pakketgroottes.

Tijd om datapakket te verzenden = datapakketgrootte / ruwe datasnelheid = 1 + 4 + 2 + 4 + 23 + 3 bytes / 1 Mbps= 37*8 bits / 1 Mbps = 296 microsecs

Data_Packet_Time = Tijd om leeg pakket te verzenden + IFS + Tijd om het eigenlijke datapakket te verzenden + IFS = 80 + 150 + 296 + 150 microsecs = 676 microsecs

Maximaal aantal datapakketten per verbindingsinterval = = 11 pakketten
Totaal overgedragen data per verbindingsinterval = 11 * 20 bytes = 11 * 20 * 8 bits = 1760 bits

Data throughput = Totaal overgedragen data per verbindingsinterval/verbindingsinterval = 1760 bits / 7.5 millisecs = 234,67 Kbits/s
Zoals we kunnen zien, liggen de berekende waarde en de gemeten waarde vrij dicht bij elkaar.

Case 2 (PHY: 2 Mbps, ATT MTU = 23 bytes, DLE: ingeschakeld, Verbindingsinterval: 7.5 millisecs)

Data throughput gerapporteerd door firmware:

Tijd: 27,23 seconden verstreken.
Throughput: 307.96 Kbits/s.
Verzonden 1048580 bytes ATT payload.

Gecalculeerde data doorvoer:

Tijd om datapakket te verzenden = grootte datapakket / ruwe datasnelheid = 2 + 4 + 4 + 23 + 3 bytes / 2 Mbps= 38*8 bits / 2 Mbps = 152 microsecs

Data_Packet_Time = Tijd om leeg pakket te verzenden + IFS + Tijd om het eigenlijke datapakket te verzenden + IFS = 44 + 150 + 152 + 150 microsecs = 496 microsecs

Maximaal aantal datapakketten per verbindingsinterval = = 15 pakketten
Totaal overgedragen data per verbindingsinterval = 15 * 20 bytes = 15 * 20 * 8 bits = 2400 bits

Data throughput = Totaal overgedragen data per verbindingsinterval/verbindingsinterval = 2400 bits / 7.5 millisecs = 320 Kbits/s
Zoals we kunnen zien, liggen de berekende waarde en de gemeten waarde vrij dicht bij elkaar.

Case 3 (PHY: 1 Mbps, ATT MTU = 158 bytes, DLE: ingeschakeld, Verbindingsinterval: 7..5 millisecs)

Data throughput gerapporteerd door firmware:

Tijd: 17,53 seconden verstreken.
Throughput: 478.36 Kbits/s.
Verzonden 1048730 bytes ATT payload.

Gecalculeerde data doorvoer:

Tijd om datapakket te verzenden = grootte datapakket / ruwe datasnelheid = 1 + 4 + 2 + 4 + 158 + 3 bytes / 1 Mbps= 172*8 bits / 1 Mbps = 1376 microsecs

Data_Packet_Time = Tijd om leeg pakket te verzenden + IFS + Tijd om het eigenlijke datapakket te verzenden + IFS = 80 + 150 + 1376 + 150 microsecs = 1756 microsecs

Maximaal aantal datapakketten per verbindingsinterval = = 4 pakketten
Totaal overgedragen data per verbindingsinterval = 4 * 155 bytes = 4 * 155 * 8 bits = 4960 bits

Data throughput = Totaal overgedragen data per verbindingsinterval/verbindingsinterval = 4960 bits / 7.5 millisecs = 661,33 Kbits/s

Geval 4 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: ingeschakeld, Verbindingsinterval: 7.5 millisecs)

Data throughput gerapporteerd door firmware:

Tijd: 8,45 seconden verstreken.
Throughput: 992.07 Kbits/s.
Verzonden 1048712 bytes ATT payload.

Gecalculeerde data doorvoer:

Tijd om datapakket te verzenden = grootte datapakket / ruwe datasnelheid = 2 + 4 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs

Data_Packet_Time = Tijd om leeg pakket te verzenden + IFS + Tijd om het eigenlijke datapakket te verzenden + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs

Maximaal aantal datapakketten per verbindingsinterval = = 5 pakketten
Totaal overgedragen data per verbindingsinterval = 5 * 244 bytes = 5 * 244 * 8 bits = 9760 bits

Data throughput = Totaal overgedragen data per verbindingsinterval/verbindingsinterval = 9760 bits / 7.5 millisecs = 1301,33 Kbits/s

Note: In de laatste twee gevallen is het aantal pakketten per verbindingsinterval klein en elk verschil tussen wat we berekenen en wat gemeten wordt zal een grote impact hebben op de werkelijke gegevensdoorvoer. Bijvoorbeeld, als het aantal pakketten per verbindingsinterval uiteindelijk 4 is in plaats van 5 in Case 4, dan wordt de berekende doorvoer 1.041.1 Kbps in plaats van 1.301.33 Kbps (wat een groot verschil is en de discrepantie in getallen hier zou kunnen verklaren).

Case 5 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: ingeschakeld, Verbindingsinterval: 50 millisecs)

Data throughput gerapporteerd door firmware:

Tijd: 6,34 seconden verstreken.
Throughput: 1322.33 Kbits/s.
Verzonden 1048712 bytes ATT payload.

Gecalculeerde data doorvoer:

Tijd om datapakket te verzenden = grootte datapakket / ruwe datasnelheid = 2 + 4 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs

Data_Packet_Time = Tijd om leeg pakket te verzenden + IFS + Tijd om het eigenlijke datapakket te verzenden + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs

Maximaal aantal datapakketten per verbindingsinterval = = 35 pakketten

Totaal overgedragen data per verbindingsinterval = 36 * 244 bytes = 35 * 244 * 8 bits = 68320 bits

Data throughput = Totaal overgedragen data per verbindingsinterval/verbindingsinterval = 70272 bits / 50 millisecs = 1366.4 Kbits/s

Geval 6 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: ingeschakeld, Verbindingsinterval: 400 millisecs)

Data throughput gerapporteerd door firmware:

Tijd: 6,11 seconden verstreken.
Throughput: 1371.82 Kbits/s.
Verzonden 1048712 bytes ATT payload.

Gecalculeerde data doorvoer:

Tijd om datapakket te verzenden = grootte datapakket / ruwe datasnelheid = 2 + 4 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs

Data_Packet_Time = Tijd om leeg pakket te verzenden + IFS + Tijd om het eigenlijke datapakket te verzenden + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs

Maximaal aantal datapakketten per verbindingsinterval = = 287 pakketten

Totaal overgedragen gegevens per verbindingsinterval = 287 * 244 bytes = 287 * 244 * 8 bits = 560224 bits

Gegevensdoorvoer = Totaal overgedragen gegevens per verbindingsinterval/verbindingsinterval =560224 bits / 400 millisecs = 1400.56 Kbits/s

Optimaliseren voor maximale gegevensdoorvoer

Gebaseerd op de factoren die we hebben doorgenomen, kunnen we het volgende opmerken bij het optimaliseren voor hoge gegevensdoorvoer:

• Altijd DLE inschakelen
  Het spreekt voor zich dat als u Bluetooth v4.1 of eerder gebruikt, dit geen geldige optie is. In het algemeen moet u er echter voor zorgen dat u DLE inschakelt om de gegevensefficiency van uw pakket naar toepassing te maximaliseren
• Gebruik LE 2M PHY
  Als u weet dat de apparaten aan beide uiteinden Bluetooth 5 ondersteunen, dan is het gebruik van de LE 2M PHY een van de beste manieren om de gegevensdoorvoer van uw toepassing te maximaliseren. Het gebruik van de LE 2M PHY zal ook het stroomverbruik helpen verminderen, zodat u twee vliegen in één klap slaat!
• Gebruik Aanwijzingen en Schrijven zonder Antwoord
  Het gebruik hiervan zal helpen onnodige pakketten te verwijderen die worden verzonden (in vergelijking met Aanwijzingen en normale Schrijven die het ontvangende eind vereisen om elk ontvangen pakket te bevestigen).
• Kies een ATT MTU waarde van tenminste groter dan 247 bytes
  Dit zal de overhead in pakketbytes minimaliseren.
• Kies een verbindingsinterval dat het maximale aantal pakketten per verbindingsinterval toelaat
  Maar houd in gedachten dat het verbindingsinterval het stroomverbruik beïnvloedt. Hoe korter het interval, hoe meer stroom uw toestel zal verbruiken door de langere radio-aan tijd. U moet er ook voor zorgen dat u niet een te hoog interval kiest, anders zal het de gebruikerservaring in het gedrang brengen (een hoger interval leidt tot een hogere latentie). Een laatste ding waar u rekening mee moet houden zijn eventuele beperkingen van de apparaten in uw systeem in termen van het maximum aantal pakketten per verbindingsinterval dat wordt ondersteund.

Samenvatting & afsluiting

De berekende waarden die we hierboven hebben opgesomd zijn nog steeds theoretisch en zullen misschien niet overeenkomen met de gemeten gegevensdoorvoer in de praktijk en echte omgevingen, maar ze zijn nog steeds een goed uitgangspunt en geven een goede indicatie van wat u kunt verwachten (ten minste voor een maximum). Interferentie en transmissie-/ontvangstfouten hebben ook invloed op de gegevensdoorvoer (herhalingen, gegevensverlies en het verbreken van de verbinding resulteren in een lagere doorvoer). Deze kunnen worden veroorzaakt door de aanwezigheid van andere apparaten die gebruik maken van dezelfde 2.4 GHz band als Bluetooth, grotere afstand tussen apparaten, het bestaan van obstakels tussen apparaten, en meer…