Free Press

Indledning

I dette andet indlæg i serien om Bluetooth 5 dækker vi den nye funktion med forbedret hastighed på 2x sammen med en generel oversigt over gennemløb for en BLE-applikation (det foregående indlæg gennemgik Bluetooth 5’s nye funktioner generelt og dækkede mere specifikt den øgede reklamekapacitet).

Først skal vi forstå, at de annoncerede hastigheder (1 Mbps og de nye 2 Mbps) kun er teoretiske og skæres ned, når det drejer sig om applikationens gennemløb. Dette skyldes flere årsager, som vi vil gennemgå i næste afsnit.

Bluetooth 5-funktionen “2x hastighed” kræver en hardwareopdatering, så ældre enheder/chips/moduler vil ikke understøtte den. Det er også vigtigt at bemærke, at for at opnå denne højere gennemløbshastighed skal begge BLE-enheder, der kommunikerer med hinanden, understøtte den nye LE 2M PHY (som gør det muligt at overføre data med denne højere hastighed).

Den nye LE 2M PHY samt den oprindelige LE 1M PHY kaldes begge for ukodede PHY’er, da de bruger en 1-symbol repræsentation pr. databit (i sammenligning med den nye LE kodede PHY, der bruger en 2-symbol eller 8-symbol repræsentation pr. databit).

En anden vigtig ting at bemærke er, at når man bruger den højere hastighed PHY, opnår man faktisk et lavere strømforbrug (givet at man overfører den samme mængde data). Dette skyldes, at radio-on-tiden reduceres, uden at sendestyrken øges. Dette forbedrer til gengæld også sameksistensen med andre trådløse teknologier inden for 2,4 GHz-spektret (også på grund af den reducerede radio-on-tid).

I dette indlæg vil vi dække:

• Hvad er det praktiske gennemløb, man kan forvente af BLE?
• Bluetooth 5’s nye 2M PHY til dataoverførsel
• Hvad er de faktorer, der påvirker/bestemmer datatransporten?
• Hvordan beregner du din applikations datatransmission?
• Hvordan maksimerer du din datatransmission?
• Test, måling og beregning af datatransmission ved hjælp af to udviklingskits i nRF52-serien

Hvorfor er det umuligt at opnå de teoretiske hastigheder i BLE?

Datahastighederne på 1 Mbps (LE 1M PHY), 2 Mbps (LE 2M PHY), 125 kbps og 500 kbps (begge ved hjælp af LE Coded PHY med henholdsvis S=8 og S=2) er de hastigheder, som radioen overfører data med, men dette er ikke opnåeligt for applikationens gennemløb af følgende årsager:

• Begrænsning på antallet af pakker pr. forbindelsesinterval
• Inter Frame Space (IFS)-forsinkelse mellem pakker (150 us)
• Tomme pakker, der skal sendes fra en enhed, selv om der ikke er nogen data tilgængelig til transmission
• Pakkeoverhead – ikke alle bytes i en pakke bruges til nyttelast

For bedre at forstå disse faktorer og forstå, hvad der påvirker applikationens gennemstrømning, er vi nødt til at se nærmere på pakkeformatet. Følgende figur viser, hvordan LE 1M PHY- og 2M PHY-datapakker ser ud:

Den del, vi er interesseret i (og den del, der virkelig definerer applikationsdataene), er ATT-payload. Som du kan se på figuren, er der et antal overhead-bytes, der bruges af hvert lag i Bluetooth Low Energy.

• I 4.0 og 4.1 er den maksimale ATT Payload på 20 bytes.
• I 4.2 og 5.0 giver en ny funktion kaldet Data Length Extensions (DLE) mulighed for, at ATT Payload kan indeholde op til 244 bytes data.

Bluetooth 5 hastighed : 2x hastighed ved brug af den nye 2M PHY

Det er nyttigt at forstå begrænsningerne ved brug af den nye LE 2M PHY i Bluetooth 5:

• Kan ikke bruges til at transmittere de primære reklamer (på de primære kanaler).
• Kan bruges til de sekundære “hjælpepakker”, der sendes på de samme kanaler som datapakkerne (37 kanaler: 0-36).
  For at få mere at vide om primære og sekundære reklamer henvises der til mit tidligere blogindlæg: Bluetooth 5 Advertisements: Alt, hvad du har brug for at vide.
• LE 1M er obligatorisk, mens LE 2M er valgfri. Så ikke alle chips, der hævder Bluetooth 5-understøttelse, kan nødvendigvis håndtere det højere gennemløb.
• Anmeldinger og opdagelse kan ske på LE 2M PHY’en, og derefter sker der forbindelser på den sekundære annoncekanal ved hjælp af LE 2M PHY’en

Overførsel af applikationsdata fra en enhed til en anden sker normalt under en forbindelse mellem de to enheder. De tilsluttede enheder kan forhandle om brugen af en anden PHY via PHY-opdateringsproceduren. Den kan initieres af enten slave eller master, efter at en forbindelse er etableret, men det er i sidste ende masteren, der træffer den endelige beslutning om, hvilke PHY’er der anvendes i hver retning (baseret på slavens anmodning og de PHY’er, som masteren understøtter).

Faktorer, der påvirker/bestemmer data-gennemstrømningen

Der er et par faktorer, der påvirker data-gennemstrømningen af en BLE-applikation. De mest almindelige er:

• PHY, der anvendes (LE 1M vs. LE 2M vs. LE Coded (S=2 eller S=8))
• Forbindelsesinterval
• Maksimalt antal pakker pr. forbindelsesinterval
• ATT Maximum Transmission Unit (ATT MTU)
• Data Length Extension (DLE)
• Datalængdeforlængelse (DLE)
• Beskyttelsestype: Skrivning med svar vs. skrivning uden svar, indikationer vs. meddelelser
• Inter Frame Space (IFS): tidsrum mellem på hinanden følgende pakker (150 us)
• Sending af tomme pakker
• Pakkeoverhead – ikke alle bytes i en pakke bruges til applikationens nyttelast

Lad os gennemgå hver af disse mere detaljeret.

PHY

Der er grundlæggende tre PHY’er i Bluetooth 5: den oprindelige 1 Mbps PHY, den nye 2 Mbps PHY og den kodede PHY (med S=2 eller S=8). Den anvendte PHY har direkte indflydelse på den maksimale dataoverførsel, du kan opnå, da den bestemmer den faktiske rå datahastighed, hvormed pakker sendes over luften.

Forbindelsesinterval &max pakker pr. forbindelseshændelse

Forbindelsesintervallet bestemmer effektivt, hvor mange pakker der kan sendes i løbet af en forbindelseshændelse. Jo højere værdien er, jo flere pakker kan sendes i en forbindelseshændelse (op til en vis grænse for nogle enheder).

Læs mere om forbindelsesintervaller: BLE-forbindelsesintervaller og -hændelser

Det er dog sådan, at antallet af pakker pr. forbindelseshændelse afhænger af enheden og BLE-stakken, så det er begrænset og varierer mellem enheder og stakversioner på en bestemt enhed. Denne værdi afhænger også af enhedens drift, så radioen kan være nødt til at tage sig af andre hændelser, og antallet af pakker, der sendes pr. forbindelseshændelse, når måske ikke op på det maksimum, der er tilladt af stakken. Antallet er f.eks. forskelligt mellem iOS og Android og ændres også afhængigt af den version af operativsystemet, der kører på enheden.

I nogle tilfælde er det nyttigt at opdatere forbindelsesparametrene dynamisk baseret på anvendelsestilfælde. Husk dog, at det er op til masteren at acceptere disse anbefalinger eller opdatere parametrene for at imødekomme dem.

Data Length Extensions (DLE)

Denne funktion gør det muligt for pakkestørrelsen at rumme en større mængde nyttelast (op til 251 bytes mod 27, når den er deaktiveret). Denne funktion blev indført i version 4.2 af Bluetooth-specifikationen.

ATT Maximum Transmission Unit (ATT MTU)

ATT MTU Bestemmer den maksimale mængde data, der kan håndteres af senderen og modtageren, og som de kan holde i deres buffere.

MTU-værdien påvirker mængden af overheaddata (specifikt ATT-headeren, som er på 3 bytes). Den mindste tilladte ATT MTU er 27 bytes. Dette giver mulighed for maksimalt 20 bytes ATT-nytelast (3 bytes bruges til ATT-headeren og 4 bytes til L2CAP-headeren).

Der er ingen grænse i specifikationen for, hvor høj MTU-værdien kan være, men den specifikke stak, der anvendes, kan have sine egne begrænsninger. Hvis du f.eks. aktiverer DLE, kan du overføre op til 251 – 4 = 247 bytes (efter fradrag af L2CAP-headerstørrelsen). Når der er taget højde for ATT-headeren (3 bytes), er der 244 bytes tilbage til de faktiske ATT-nytedata. Hvis MTU’en er mindst 247 bytes, vil MTU’en passe ind i en enkelt pakke. Hvis MTU’en er større end 247 bytes, vil MTU’en strække sig over flere pakker, hvilket får gennemstrømningen til at falde (på grund af pakkeoverheadet og timingen mellem pakkerne).

Den effektive MTU bestemmes af den mindste værdi af ATT MTU, som klienten og serveren understøtter. Hvis en klient f.eks. understøtter en ATT MTU på 100 bytes, og serveren svarer, at den understøtter en ATT MTU på 150 bytes, så vil klienten beslutte, at den ATT MTU, der skal bruges til forbindelsen fra da af, er 100 bytes.

Operationstype: Skriv med svar vs. skriv uden svar, indikationer vs. meddelelser

Hvis der ønskes høj gennemstrømning, kan vi bruge Skriv uden svar eller Meddelelser til at overføre data fra klienten til serveren og fra serveren til klienten. Disse operationer fjerner behovet for, at den anden enhed skal bekræfte modtagelsen af dataene og svare, før den næste blok data kan sendes.

Inter Frame Space (IFS): tidsforsinkelse mellem på hinanden følgende pakker (150 us)

Fra Bluetooth-specifikationen:

4.1.1.1 Inter Frame Space

Tidsintervallet mellem to på hinanden følgende pakker på det samme kanalindeks kaldes Inter Frame Space. Det er defineret som tiden fra slutningen af den sidste bit i den foregående pakke til starten af den første bit i den efterfølgende pakke.
Inter Frame Space betegnes “T_IFS” og skal være 150 μs.

Sending af tomme pakker

Hvis den enhed, der modtager data, ikke har nogen data at sende tilbage, skal den stadig sende en tom pakke i henhold til Bluetooth-specifikationen.

Pakkeoverhead

Som vi så i figuren for pakkeformatet, indeholder pakken nogle overheaddata, der ikke tæller med i dine applikationsdata (ATT-data). Dybest set vil disse bytes forbruge en del af din overførselsdatahastighed, mens der ikke tages højde for eventuelle bytes, der sendes som en del af dine applikationsdata.

Beregning af dit applikationsdatadata-gennemløb

Det store spørgsmål er: Hvordan beregner vi vores applikationsgennemløb?

Som vi nævnte før, er der et par variabler, der har indflydelse på datadata-gennemstrømningen:

• Bluetooth-version & Anvendt PHY
• DLE: Data Length Extensions – aktiveret eller ej
• ATT MTU-værdi
• Forbindelsesinterval
• Maksimalt antal pakker pr. forbindelsesbegivenhed
• Operation (skrivninger med svar vs. skrivninger uden svar og notifikation vs. indikation)
• Inter Frame Space (IFS): 150 mikrosekunder

Bluetooth-versionen og PHY’en bestemmer den rå dataoverførselshastighed. Hvis vi f.eks. bruger Bluetooth-version 4.2 og LE 1M PHY, er overførselshastigheden 1 Mbps. Hvis vi derimod bruger Bluetooth 5 LE Coded PHY med S=8, går datahastigheden ned til 125 kbps.

DLE, ATT MTU, forbindelsesinterval, det maksimale antal pakker pr. forbindelsesinterval, Operation og IFS bestemmer alle den del af radiotiden, der bruges til egentlig dataoverførsel.

Pakkeformatet spiller en stor rolle for, hvor stor en del af de data, der overføres, der er dine egentlige applikationsdata. LE 1M PHY og LE 2M PHY har begge et lignende pakkeformat. LE Coded PHY’en har et væsentligt anderledes pakkeformat, så vi vil se på disse to tilfælde separat.

LE 1M PHY og LE 2M PHY beregning

Hvis vi vender tilbage til pakkeformatet for LE Uncoded PHY’er:

Mængden af overhead for hver PHY er lidt forskellig. Preamble er 1 byte i tilfælde af 1M PHY’en og 2 byte i tilfælde af 2M PHY’en. MIC-feltet er et valgfrit felt, som kun bruges til krypterede forbindelser. For enkelhedens skyld vil vi kun betragte ukrypterede forbindelser – for det krypterede tilfælde tilføjer det blot 4 bytes overhead.

For LE Coded PHYs ser pakkeformatet således ud (fra Bluetooth 5.0 spec Vol 6, Part B, Section 2.2):

Stræk til beregning af gennemløb (i Mbps):

For enkelhedens skyld antager vi følgende:

• Kryptering er IKKE aktiveret (MIC-feltet er ikke inkluderet i pakken)
• Vi er interesseret i gennemløb for den ene retning (f.eks. Master til Slave), så vi antager, at den anden retning kun overfører tomme pakker
• Skrivninger uden svar (hvilket ville hjælpe med at maksimere gennemstrømningen, når der overføres store datamængder

Strin:

1. Bestem den anvendte PHY, og noter hastigheden for overførsel af rå data
   Eksempelvis for 1M PHY -> 1 Mbps, for kodet PHY og S=8 -> 125 kbps
2. Bestem den tid, det tager at sende en datapakke og den tomme pakke fra modtageren.
   Den tid, i løbet af hvilken en datapakke kan sendes, vil omfatte følgende:

   Data_Packet_Time = Tid til at sende tom pakke + IFS + Tid til at sende den egentlige datapakke + IFS.
   En tid til transmission af en tom pakke kan beregnes på følgende måde:

   Tid til transmission af tom pakke = tom pakkestørrelse / rå datahastighed

   En tom pakke vil indeholde følgende felter:

   Preamble + Access Address + LL Header + CRC.

   For 1M PHY vil Preamble være 1 byte, og derfor vil den samlede størrelse af den tomme pakke være = 1 + 4 + 2 + 3 bytes = 10 bytes = 80 bits.
   (for 2M PHY vil størrelsen af en tom pakke være 88 bits, da Premable er 2 bytes i stedet for 1 byte).

   Baseret på dette vil tiden til at sende en tom 1M PHY-pakke være:

   Tid til at sende tom pakke = tom pakkestørrelse / rå datahastighed = 80 bits / 1 megabit pr. sekund = 80 mikrosekunder

   En datapakke vil indeholde alle felter, der er anført i pakkeformatdiagrammet, med undtagelse af MIC-feltet (kryptering er deaktiveret).

   Tid til at sende datapakke = datapakkestørrelse / rå datahastighed

   Hvis vi har DLE aktiveret, og ATT MTU’en er lig med de maksimale tilladte bytes i en pakke: 247 bytes, kan vi beregne datapakkestørrelsen som:

   Datapakkens størrelse = 1 + 4 + 2 + 4 + 4 + 247 + 3 bytes = 265 bytes = 265*8 bit = 2088 bit

   Tid til at sende datapakke = 2088 bit / 1 Mbps = 2,088 mikrosekunder

   Data_Packet_Time = Tid til at transmittere tom pakke + IFS + Tid til at transmittere den faktiske datapakke + IFS = 80 + 2*150 + 2088 = 2.468 mikrosekunder
   Til sammenligning ville det i tilfælde af 2M PHY være:

   Data_Packet_Time = Tid til at sende tom pakke + IFS + Tid til at sende den faktiske datapakke + IFS = 88/2 + 2*150 + (2 + 4 + 2 + 4 + 247 + 3)*8/2 = 1.392 mikrosekunder
   Når DLE er aktiveret, og ATT MTU er indstillet til mindre end 247, ender vi med mere overhead (da data, der er større end ATT MTU, nu bliver delt op i flere pakker). Hvis vi f.eks. har ATT MTU indstillet til 158, skal vi for at overføre 244 bytes programdata bruge to pakker i stedet for én, hvilket får gennemstrømningen til at falde på grund af det øgede byte-overhead samt den øgede IFS mellem pakkerne. I et andet scenarie kunne vi have DLE deaktiveret (Payload-størrelse op til 27 bytes) og ATT MTU større end 27 bytes. Her vil dette også resultere i, at der skal sendes flere pakker for den samme mængde data, hvilket medfører, at gennemstrømningen falder.

   Note: Den samme metode til beregning af data- og tom-pakkestørrelser, som vi har anvendt ovenfor, kan anvendes for LE Coded PHY.

3. Beregn, hvor mange pakker der kan sendes i løbet af et forbindelsesinterval
   Denne beregning er ikke altid rent matematisk – du skal tage hensyn til begrænsninger i den stak og enhed, der bruges. iOS og Android har maksimumværdier, der ændrer sig med OS-versionen, så det er ikke altid let at regne ud. Når det er sagt, på en MCU angiver leverandørens SDK normalt maksimumgrænsen i deres dokumentation. Det er også nyttigt at lave en trial and error og finde ud af, hvad din specifikke enhed understøtter.

   Når du har fundet ud af maksimum, kan du beregne det maksimale teoretiske antal pakker, der ville passe inden for et forbindelsesinterval efter eget valg. Hvis vi f.eks. havde et forbindelsesinterval på 7,5 millisekunder (det laveste tilladte i henhold til specifikationen), så er det for vores eksempel ovenfor (ved brug af 1M PHY, DLE aktiveret):

   Maximum # of data packets per connection interval = , hvor der afrundes til det højeste hele tal (heltal)Maximum # of data packets per connection interval = = = 3 packets

   Usuelt er dette tal ikke realistisk, da der er tidsforsinkelser mellem pakker, der sendes ved på hinanden følgende forbindelsesbegivenheder. Så i vores eksempel vil vi gå med 2 pakker i stedet for 3.

4. Når vi har fundet ud af det maksimale antal datapakker, der kan overføres pr. forbindelsesinterval, kan vi beregne data-gennemstrømningen:Data-gennemstrømning = data pr. forbindelsesinterval / forbindelsesinterval = Antal datapakker pr. forbindelsesinterval * Datastørrelse pr. pakke / forbindelsesinterval
   = 2 * 244 * 8 bits / 7.5 millisekunder = 520,533 bits/sek ~= 508 kbps

Test og beregning af data-gennemstrømning mellem to nRF52-udviklingssæt

I dette afsnit vil vi køre flere test af dataoverførsel, beregne gennemstrømningen ved hjælp af den procedure, vi beskrev tidligere, og derefter sammenligne dem med den målte gennemstrømning, der er rapporteret af programmet, som kører på udviklingskortene. Testene køres på baggrund af den demoapp, der er leveret af Nordic Semiconductor og præsenteret i dette blogindlæg: Throughput and long range demo.

Kildekoden til eksemplet kan findes på GitHub-siden her.

Case 1 (PHY: 1 Mbps, ATT MTU = 23 bytes, DLE: enabled, Connection interval: 7.5 millisecs)

Data-gennemstrømning rapporteret af firmware:

Time: 36.11 sekunder er gået.
Gennemløb: 232,29 Kbits/s.
Sendt 1048580 bytes ATT-nytelast.

Beregnet data-gennemløb:

Med MTU’en indstillet til 23 bytes påvirker DLE ikke rigtig data-gennemløb og pakkestørrelser.

Tid til at sende datapakke = datapakkestørrelse / rå datahastighed = 1 + 4 + 2 + 4 + 23 + 3 bytes / 1 Mbps= 37*8 bits / 1 Mbps = 296 mikrosekunder

Data_Packet_Time = Tid til at sende tom pakke + IFS + Tid til at sende den egentlige datapakke + IFS = 80 + 150 + 296 + 150 mikrosekunder = 80 + 150 + 296 + 150 mikrosekunder = 676 mikrosekunder

Maksimalt antal datapakker pr. forbindelsesinterval = = = = = = 11 pakker
Total data overført pr. forbindelsesinterval = 11 * 20 bytes = 11 * 20 * 8 bits = 1760 bits

Datadata-gennemstrømning = Total data overført pr. forbindelsesinterval/forbindelsesinterval = 1760 bits / 7.5 millisekunder = 234,67 Kbits/s
Som vi kan se, er den beregnede værdi og den målte værdi ret tæt på hinanden.

Case 2 (PHY: 2 Mbps, ATT MTU = 23 bytes, DLE: aktiveret, Forbindelsesinterval: 7.5 millisekunder)

Datadata-gennemstrømning rapporteret af firmware:

Tid: 27,23 sekunder er gået.
Gennemstrømning: 307,96 Kbits/s.
Sendt 1048580 bytes ATT-nytelast.

Beregnet data-gennemstrømning:

Tid til at sende datapakke = datapakkestørrelse / rå datahastighed = 2 + 4 + 2 + 2 + 4 + 23 + 3 bytes / 2 Mbps= 38*8 bits / 2 Mbps = 152 mikrosekunder

Data_Packet_Time = Tid til at sende tom pakke + IFS + Tid til at sende den egentlige datapakke + IFS = 44 + 150 + 152 + 150 mikrosekunder = 44 + 150 + 152 + 150 mikrosekunder = 496 mikrosekunder

Maximum antal datapakker pr. forbindelsesinterval = = = = = = 15 pakker
Total data overført pr. forbindelsesinterval = 15 * 20 bytes = 15 * 20 * 8 bits = 2400 bits

Datadata-gennemstrømning = Total data overført pr. forbindelsesinterval/forbindelsesinterval = 2400 bits / 7.5 millisekunder = 320 Kbits/s
Som vi kan se, er den beregnede værdi og den målte værdi ret tæt på hinanden.

Fald 3 (PHY: 1 Mbps, ATT MTU = 158 bytes, DLE: aktiveret, forbindelsesinterval: 7.5 millisekunder)

Datadata-gennemstrømning rapporteret af firmware:

Tid: 17,53 sekunder er gået.
Gennemstrømning: 478,36 Kbits/s.
Sendt 1048730 bytes ATT-nytelast.

Beregnet data-gennemstrømning:

Tid til transmission af datapakke = datapakkestørrelse / rå datahastighed = 1 + 4 + 2 + 4 + 158 + 3 bytes / 1 Mbps= 172*8 bits / 1 Mbps = 1376 mikrosekunder

Data_Packet_Time = Tid til transmission af tom pakke + IFS + Tid til transmission af den faktiske datapakke + IFS = 80 + 150 + 1376 + 150 mikrosekunder = 80 + 150 + 1376 + 150 mikrosekunder = 1756 mikrosekunder

Maksimalt antal datapakker pr. forbindelsesinterval = = = = = = 4 pakker
Total data overført pr. forbindelsesinterval = 4 * 155 bytes = 4 * 155 * 8 bits = 4960 bits

Datadata-gennemstrømning = Total data overført pr. forbindelsesinterval/forbindelsesinterval = 4960 bits / 7.5 millisekunder = 661,33 Kbits/s

Fald 4 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: aktiveret, forbindelsesinterval: 7.5 millisekunder)

Datadata-gennemstrømning rapporteret af firmware:

Tid: 8,45 sekunder er gået.
Gennemstrømning: 992,07 Kbits/s.
Sendt 1048712 bytes ATT-nytelast.

Beregnet data-gennemstrømning:

Tid til transmission af datapakke = datapakkestørrelse / rå datahastighed = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 mikrosekunder

Data_Packet_Time = Tid til transmission af tom pakke + IFS + Tid til transmission af den egentlige datapakke + IFS = 44 + 150 + 1048 + 150 mikrosekunder = 44 + 150 + 1048 + 150 mikrosekunder = 1392 mikrosekunder

Maksimalt antal datapakker pr. forbindelsesinterval = = = = = = 5 pakker
Total data overført pr. forbindelsesinterval = 5 * 244 bytes = 5 * 244 * 8 bits = 9760 bits

Datadata-gennemstrømning = Total data overført pr. forbindelsesinterval/forbindelsesinterval = 9760 bits / 7.5 millisekunder = 1301,33 Kbits/s

Bemærk: I de to sidste tilfælde er antallet af pakker pr. forbindelsesinterval lille, og enhver forskel mellem det, vi beregner, og det, der måles, vil have en stor indvirkning på det faktiske datadataoverførselstal. Hvis antallet af pakker pr. forbindelsesinterval f.eks. ender med at være 4 i stedet for 5 i tilfælde 4, bliver det beregnede gennemløb 1.041,1 Kbps i stedet for 1.301,33 Kbps (hvilket er en stor forskel og kan forklare diskrepansen i tallene her).

Fald 5 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: aktiveret, Forbindelsesinterval: 2 Mbps, ATT MTU = 247 bytes, DLE: aktiveret, Forbindelsesinterval: 50 millisekunder)

Datadata-gennemstrømning rapporteret af firmware:

Tid: 6,34 sekunder er gået.
Gennemstrømning: 1322,33 Kbits/s.
Sendt 1048712 bytes ATT-nytelast.

Beregnet data-gennemstrømning:

Tid til at sende datapakke = datapakkestørrelse / rå datahastighed = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 mikrosekunder

Data_Packet_Time = Tid til at sende tom pakke + IFS + Tid til at sende den egentlige datapakke + IFS = 44 + 150 + 1048 + 150 mikrosekunder = 1392 mikrosekunder

Maximum antal datapakker pr. forbindelsesinterval = = = = = = 35 pakker

Total data overført pr. forbindelsesinterval = 36 * 244 bytes = 35 * 244 * 8 bits = 68320 bits

Datadata-gennemstrømning = Total data overført pr. forbindelsesinterval/forbindelsesinterval = 70272 bits / 50 millisekunder = 1366.4 Kbits/s

Case 6 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: aktiveret, forbindelsesinterval: 400 millisekunder)

Datadata-gennemstrømning rapporteret af firmware:

Tid: 6,11 sekunder er gået.
Gennemstrømning: 1371,82 Kbits/s.
Sendt 1048712 bytes ATT-nytelast.

Beregnet data-gennemstrømning:

Tid til at sende datapakke = datapakkestørrelse / rå datahastighed = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 mikrosekunder

Data_Packet_Time = Tid til at sende tom pakke + IFS + Tid til at sende den egentlige datapakke + IFS = 44 + 150 + 1048 + 150 mikrosekunder = 1392 mikrosekunder

Maximum antal datapakker pr. forbindelsesinterval = = = = = = 287 pakker

Total data overført pr. forbindelsesinterval = 287 * 244 bytes = 287 * 244 * 8 bits = 560224 bits

Datadata-gennemstrømning = Total data overført pr. forbindelsesinterval/forbindelsesinterval =560224 bits / 400 millisekunder = 1400.56 Kbits/s

Optimering for maksimalt datadataforløb

Baseret på de faktorer, vi gennemgik, kan vi bemærke følgende, når vi optimerer for højt datadataforløb:

• Aktiver altid DLE
  Oplysende nok er dette ikke en gyldig mulighed, hvis du bruger Bluetooth v4.1 eller tidligere. Generelt skal du dog sikre dig, at du har aktiveret DLE for at maksimere effektiviteten af din pakke til applikationsdata
• Brug LE 2M PHY
  Hvis du ved, at enhederne i begge ender understøtter Bluetooth 5, er det at udnytte LE 2M PHY en af de bedste måder at maksimere din applikationsdatadøgngennemstrømning på. Brug af LE 2M PHY vil også bidrage til at reducere strømforbruget, så du slår to fluer med ét smæk!
• Brug Notifikationer og skrivninger uden svar
  Genbrug af disse vil bidrage til at fjerne alle unødvendige pakker, der sendes (sammenlignet med indikationer og normale skrivninger, som kræver, at den modtagende ende skal kvittere for hver modtaget pakke).
• Vælg en ATT MTU-værdi på mindst større end 247 bytes
  Dette vil minimere ethvert overhead i pakkebytes.
• Vælg et forbindelsesinterval, der giver mulighed for det maksimale antal pakker pr. forbindelsesinterval
  Men husk på, at forbindelsesintervallet påvirker strømforbruget. Jo kortere intervallet er, jo mere strøm vil din enhed forbruge på grund af den øgede radio-on-tid. Du skal også sørge for, at du ikke vælger et for højt interval, da det ellers vil gå ud over brugeroplevelsen (et højere forbindelsesinterval resulterer i højere latenstid). En sidste ting, du skal sørge for at tage højde for, er eventuelle begrænsninger for enhederne i dit system med hensyn til det maksimale antal pakker pr. understøttet forbindelsesinterval.

Summary & closing

De beregnede værdier, som vi har anført ovenfor, er stadig teoretiske og stemmer muligvis ikke overens med den målte datatransmission i praksis og i virkelige miljøer, men de er stadig et godt udgangspunkt og giver en god indikation af, hvad du kan forvente (i det mindste for et maksimum). Interferens og transmissions-/modtagelsesfejl påvirker også datadata-gennemstrømningen (genforsøg, datatab og lukning af forbindelsen resulterer i lavere gennemstrømning). Disse kan skyldes tilstedeværelsen af andre enheder, der anvender det samme 2,4 GHz-bånd som Bluetooth, længere afstand mellem enhederne, tilstedeværelsen af forhindringer mellem enhederne og mere …