Free Press

Introduction

Neste segundo post da série sobre Bluetooth 5, nós cobrimos a nova característica de 2x melhorada velocidade junto com uma visão geral do rendimento para uma aplicação BLE (o post anterior passou por cima das novas características de Bluetooth 5 em geral e mais especificamente cobriu a característica de maior capacidade de publicidade).

Primeiro, nós precisamos entender que as velocidades anunciadas (1 Mbps e os 2 Mbps novos) são só teóricas e são cortadas quando vem para baixo a produção de aplicação. Isto é devido a múltiplas razões que nós vamos rever na próxima seção.

A característica Bluetooth 5 “2x velocidade” requer uma atualização de hardware assim dispositivos/chips/módulos mais velhos não o suportarão. Também é importante notar que para alcançar esta maior velocidade você precisará de ambos os dispositivos BLE comunicando entre si para suportar o novo LE 2M PHY (que torna possível a transferência de dados a esta taxa mais alta).

O novo LE 2M PHY, assim como o LE 1M PHY original, são ambos chamados PHYs não codificados uma vez que eles usam uma representação de 1 símbolo por bit de dados (em comparação com o novo LE Coded PHY que usa uma representação de 2 símbolos ou 8 símbolos por bit de dados).

Outra coisa importante a notar é que ao utilizar o PHY de maior velocidade, você na verdade consegue um menor consumo de energia (dado que você transfere a mesma quantidade de dados). Isto acontece porque o tempo de ligação do rádio é reduzido sem que a potência de transmissão seja aumentada. Isto, por sua vez, também melhora a coexistência com outras tecnologias sem fio dentro do espectro de 2,4 GHz (também devido ao tempo reduzido de radio-on).

Neste post, vamos cobrir:

• Qual é a taxa de transmissão prática a esperar do BLE?
• O novo 2M PHY do Bluetooth 5 para transferência de dados
• Quais são os fatores que impactam/determinam a taxa de transmissão de dados?
• Como você calcula a taxa de transferência de dados da sua aplicação?
• Como você maximiza sua taxa de transferência de dados?
• Teste, medição e cálculo da taxa de transferência de dados usando dois kits de desenvolvimento da série nRF52

Por que é impossível atingir as velocidades teóricas do BLE?

As taxas de dados de 1 Mbps (LE 1M PHY), 2 Mbps (LE 2M PHY), 125 kbps e 500 kbps (ambos usando o LE Coded PHY com S=8 e S=2, respectivamente) são as taxas em que o rádio transmite dados, mas isto não é possível para a taxa de transmissão da aplicação devido às seguintes razões

• Limite no número de pacotes por intervalo de conexão
• Espaço do quadro de interface (IFS) entre pacotes (150 us)
• Imprime-se que os pacotes sejam enviados de um dispositivo mesmo que não haja dados disponível para transmissão
• Packet overhead – nem todos os bytes de um pacote são usados para carga útil

A fim de melhor compreender estes fatores e entender o que impacta o rendimento da aplicação, temos de analisar mais a fundo o formato do pacote. A figura seguinte mostra como são os pacotes de dados LE 1M PHY e 2M PHY:

A parte que nos interessa (e aquela que realmente define os dados da aplicação) é o ATT Payload. Como você pode ver na figura, há um número de bytes aéreos que são usados por cada camada no Bluetooth de Baixa Energia.

• Em 4.0 e 4.1, o ATT Payload máximo é de 20 bytes.
• Em 4.2 e 5.0, uma nova funcionalidade chamada Data Length Extensions (DLE) permite que o ATT Payload contenha até 244 bytes de dados.

Bluetooth 5 velocidade : 2x velocidade utilizando o novo 2M PHY

É útil entender as limitações de usar o novo LE 2M PHY em Bluetooth 5:

• Não pode ser usado para transmitir os anúncios primários (nos canais primários).
• Pode ser usado para os “pacotes auxiliares” secundários enviados nos mesmos canais que os pacotes de dados (37 canais: 0-36).
  Para saber mais sobre anúncios primários e secundários, consulte o meu post de blog anterior: Anúncios de Bluetooth 5: Tudo que você precisa saber.
• LE 1M é obrigatório, enquanto LE 2M é opcional. Então, nem todas as fichas que reivindicam apoio de Bluetooth 5 podem necessariamente segurar o rendimento mais alto.
• Anúncios e descoberta podem ocorrer no LE 2M PHY, e então conexões ocorrem no canal secundário de anúncio usando o LE 2M PHY

Transferência de dados de aplicação de um dispositivo para outro geralmente acontece durante uma conexão entre os dois dispositivos. Os dispositivos conectados podem negociar o uso de um PHY diferente através do procedimento de atualização do PHY. Ele pode ser iniciado tanto pelo escravo quanto pelo mestre depois que uma conexão é estabelecida, mas o mestre finalmente tomará a decisão final sobre quais PHYs são usados para cada direção (baseado no pedido do escravo e nos PHYs que o mestre suporta).

Fatores que impactam/determinam a produção de dados

Há alguns fatores que impactam a produção de dados de uma aplicação BLE. Os mais comuns são:

• PHY sendo usado (LE 1M vs. LE 2M vs. LE Coded (S=2 ou S=8))
• Intervalo de conexão
• Número máximo de pacotes por intervalo de conexão
• ATT Unidade máxima de transmissão (ATT MTU)
• Extensão de comprimento de dados (DLE)
• Tipo de operação: Write with response vs. write without response, Indications vs. Notifications
• Inter Frame Space (IFS): time gap between consequent packets (150 us)
• Transmissão de pacotes vazios
• Packet overhead – nem todos os bytes, em um pacote, são usados para a carga útil da aplicação

Vamos rever cada um deles com mais detalhes.

PHY

Existem basicamente três PHYs no Bluetooth 5: o PHY original de 1 Mbps, o novo PHY de 2 Mbps, e o PHY codificado (com S=2, ou S=8). O PHY usado terá impacto direto na máxima taxa de transmissão de dados que você pode alcançar, uma vez que ele determina a taxa real de dados brutos em que os pacotes são enviados pelo ar.

Intervalo de conexão &Máximo de pacotes por evento de conexão

O intervalo de conexão efetivamente determina quantos pacotes podem ser enviados durante um evento de conexão. Quanto maior o valor, mais pacotes podem ser enviados em um evento de conexão (até um certo limite para alguns dispositivos).

Aprenda mais sobre intervalos de conexão: Intervalos e eventos de conexão BLE

No entanto, o número de pacotes por evento de conexão depende do dispositivo e da pilha BLE, portanto é limitado e difere entre dispositivos e versões de pilha em um dispositivo específico. Este valor também depende do funcionamento do dispositivo, portanto o rádio pode ter que atender a outros eventos e o número de pacotes enviados por evento de conexão pode não atingir o máximo permitido pela pilha. Por exemplo, o número difere entre iOS e Android e também muda dependendo da versão do SO em execução no dispositivo.

Por vezes é útil atualizar dinamicamente os parâmetros de conexão com base no caso de uso. Entretanto, tenha em mente que cabe ao master aceitar essas recomendações ou atualizar os parâmetros para acomodá-los.

Data Length Extensions (DLE)

Esta característica permite que o tamanho do pacote contenha uma quantidade maior de carga útil (Até 251 bytes vs. 27 quando desabilitado). Este recurso foi introduzido na versão 4.2 da especificação Bluetooth.

ATT Maximum Transmission Unit (ATT MTU)

ATT MTU Determina a quantidade máxima de dados que podem ser manipulados pelo transmissor e receptor e que eles podem manter em seus buffers.

O valor MTU afeta a quantidade de dados de sobrecarga (especificamente o cabeçalho ATT que é 3 bytes). O MTU mínimo ATT permitido é de 27 bytes. Isto permite um máximo de 20 bytes de carga útil ATT (3 bytes são usados para o cabeçalho ATT, e 4 bytes para o cabeçalho L2CAP).

Não há limite por especificação de quão alto o valor MTU pode ser, mas a pilha específica em uso pode ter suas próprias limitações. Por exemplo, se você ativar DLE então você pode transferir até 251 – 4 = 247 bytes (depois de deduzir o tamanho do cabeçalho L2CAP). Após levar em conta o cabeçalho ATT (3 bytes), ficamos com 244 bytes para os dados reais de carga útil ATT. Se a MTU for de pelo menos 247 bytes, então a MTU caberá em um único pacote. Se a MTU for maior que 247 bytes, então a MTU irá abranger vários pacotes causando a queda da produção (por causa da sobrecarga do pacote e do tempo entre os pacotes).

A MTU efetiva é determinada pelo valor mínimo da MTU ATT que o cliente e o servidor suportam. Por exemplo, se um cliente suporta uma ATT MTU de 100 bytes e o servidor responde que suporta uma ATT MTU de 150 bytes, então o cliente decidirá que a ATT MTU a ser usada para a conexão a partir daí é de 100 bytes.

Operação tipo: Write with response vs. write without response, Indicações vs. Notificações

Se for desejado um alto rendimento, então podemos usar Write without response ou Notificações para transferir os dados do cliente para o servidor e do servidor para o cliente. Estas operações eliminam a necessidade do outro dispositivo confirmar a recepção dos dados e responder antes que o próximo bloco de dados possa ser enviado.

Inter Frame Space (IFS): tempo entre pacotes consecutivos (150 us)

Da especificação Bluetooth:

4.1.1 Inter Frame Space

O intervalo de tempo entre dois pacotes consecutivos no mesmo índice de canal é chamado de Inter Frame Space. É definido como o tempo desde o final do último bit do pacote anterior até o início do primeiro bit do pacote subsequente.
O Inter Frame Space é designado “T_IFS” e deve ser 150 μs.

Transmissão de pacotes vazios

Se o dispositivo que recebe os dados não tem dados para enviar de volta, ele ainda precisa enviar um pacote vazio, conforme a especificação Bluetooth.

Packet overhead

Como vimos na figura do formato do pacote, o pacote inclui alguns dados overhead que não contam para os dados de sua aplicação (dados ATT). Basicamente, esses bytes irão consumir parte da sua taxa de transferência de dados, sem contabilizar nenhum byte sendo enviado como parte dos dados da sua aplicação.

Cálculo da taxa de transferência de dados da sua aplicação

A grande questão é: como calculamos a taxa de transferência da nossa aplicação?

Como mencionamos anteriormente, existem algumas variáveis que afetam a taxa de transferência de dados:

• Versão dente de azul & PHY usado
• DLE: Extensões de comprimento dos dados – ativadas ou não
• Valor MTU da ATT
• Intervalo de conexão
• Número máximo de pacotes por evento de conexão
• Operação (escreve com respostas vs. Escreve sem respostas, e notificação vs. indicação)
• Espaço do quadro de interface (IFS): 150 microssegundos

A versão Bluetooth e PHY determinam a taxa de transferência de dados brutos. Por exemplo, se estamos usando a versão Bluetooth 4.2 e o LE 1M PHY, então a taxa de transferência é de 1 Mbps. Por outro lado, se estivermos usando o Bluetooth 5 LE PHY Codificado com S=8, então a taxa de transferência de dados desce para 125 kbps.

O DLE, ATT MTU, intervalo de conexão, o número máximo de pacotes por intervalo de conexão, Operação, e IFS, todos determinam a parte do tempo no rádio que é utilizada para a transferência de dados reais.

O formato do pacote tem um grande papel no quanto dos dados que estão sendo transferidos são os dados reais da sua aplicação. O LE 1M PHY e LE 2M PHY têm ambos um formato de pacote similar. O LE Coded PHY tem um formato de pacote significativamente diferente, então estaremos analisando esses dois casos separadamente.

LE 1M PHY e LE 2M PHY cálculo

Referring back to the packet format for LE Uncoded PHYs:

>A quantidade de despesas gerais para cada PHY é ligeiramente diferente. O Preâmbulo é 1 byte no caso do PHY 1M e 2 bytes no caso do PHY 2M. O campo MIC é um campo opcional que é usado apenas para conexões criptografadas. Para simplificar, vamos considerar apenas conexões não criptografadas – para o caso criptografado, ele simplesmente adiciona 4 bytes de overhead.

Para LE Coded PHYs, o formato do pacote se parece com este (da especificação Bluetooth 5.0 Vol 6, Parte B, Seção 2.2):

Passos para calcular a taxa de transferência (em Mbps):

Para simplificar, assumimos o seguinte:

• A encriptação NÃO está ativada (o campo MIC não está incluído no pacote)
• Estamos interessados na taxa de transferência para uma direção (por exemplo Master to Slave), então assumimos que a outra direção transfere apenas pacotes vazios
• Escritas sem respostas (o que ajudaria a maximizar a taxa de transferência ao transferir grandes quantidades de dados

Passos:

1. Determinar o PHY sendo usado e anotar a taxa de transferência de dados brutos
   E.g. para 1M PHY -> 1 Mbps, para Coded PHY e S=8 -> 125 kbps
2. Determine o tempo que leva para enviar um pacote de dados e o pacote vazio do receptor.
   O tempo durante o qual um pacote de dados pode ser enviado incluirá o seguinte:

   Data_Packet_Time = Tempo para transmitir pacote vazio + IFS + Tempo para transmitir o pacote de dados real + IFS.
   Um tempo de transmissão de pacote vazio pode ser calculado da seguinte forma:

   Tempo para transmitir pacote vazio = tamanho do pacote vazio / taxa de dados brutos

   Um pacote vazio conterá os seguintes campos:

   Preamble + Endereço de acesso + Cabeçalho LL + CRC.

   Para 1M PHY, o Preâmbulo será 1 byte, e assim o tamanho total do pacote vazio = 1 + 4 + 2 + 3 bytes = 10 bytes = 80 bits.
   (para 2M PHY, o tamanho de um pacote vazio será 88 bits já que o Preâmbulo é 2 bytes ao invés de 1 byte).

   Baseado nisso, o tempo para transmitir um pacote vazio de 1M PHY será:

   Tempo para transmitir um pacote vazio = tamanho do pacote vazio / taxa de dados brutos = 80 bits / 1 Megabits por segundo = 80 micro segundos

   Um pacote de dados conterá todos os campos listados no diagrama de formato do pacote com exceção do campo MIC (criptografia desabilitada).

   Tempo para transmitir o pacote de dados = tamanho do pacote de dados / taxa de dados brutos

   Se tivermos DLE ativado e a ATT MTU for igual ao máximo de bytes permitidos em um pacote: 247 bytes, então podemos calcular o tamanho do pacote de dados como:

   Tamanho do pacote de dados = 1 + 4 + 2 + 4 + 247 + 3 bytes = 265 bytes = 265*8 bits = 2088 bits

   Tempo para transmitir o pacote de dados = 2088 bits / 1 Mbps = 2,088 micro segundos

   Data_Packet_Time = Tempo para transmitir o pacote vazio + IFS + Tempo para transmitir o pacote de dados real + IFS = 80 + 2*150 + 2088 = 2.468 microsecs
   Para comparação, no caso de 2M PHY, seria:

   Data_Packet_Time = Tempo para transmitir o pacote vazio + IFS + Tempo para transmitir o pacote de dados real + IFS = 88/2 + 2*150 + (2 + 4 + 2 + 2 + 4 + 247 + 3)*8/2 = 1.392 microsecs
   Quando o DLE está ativado e o ATT MTU está configurado para menos de 247, acabamos com mais overhead (já que agora os dados maiores do que o ATT MTU são divididos em mais pacotes). Por exemplo, digamos que temos o ATT MTU configurado para 158, então para transferir 244 bytes de dados de aplicação, precisaremos de dois pacotes ao invés de um, fazendo com que a taxa de transferência caia devido ao aumento da sobrecarga de bytes, assim como o aumento do IFS entre os pacotes. Em outro cenário, poderíamos ter o DLE desabilitado (tamanho de carga útil até 27 bytes) e o ATT MTU maior que 27 bytes. Aqui, isso também resultará em mais pacotes a serem enviados para a mesma quantidade de dados, fazendo com que a taxa de transferência caia.

   Note: O mesmo método para calcular os dados e tamanhos de pacotes vazios que usamos acima pode ser usado para o LE Coded PHY.

3. Descobre quantos pacotes podem ser transmitidos durante um intervalo de conexão
   Este cálculo nem sempre é puramente matemático – você precisará levar em conta as limitações da pilha e do dispositivo sendo usado. O iOS e o Android têm máximos que mudam com a versão do SO, então nem sempre é fácil de descobrir. Dito isto, em uma MCU, o SDK do fornecedor normalmente lista o máximo em sua documentação. Também é útil fazer uma tentativa e erro e descobrir o que seu dispositivo específico suporta.

   Após ter descoberto o máximo, você pode calcular o número máximo teórico de pacotes que caberia dentro de um intervalo de conexão de escolha. Por exemplo, se nós tivéssemos um intervalo de conexão de 7,5 milisecs (o menor permitido pela especificação), então para o nosso exemplo acima (usando 1M PHY, DLE ativado):

   Máximo # de pacotes de dados por intervalo de conexão = , onde arredonda para o maior número inteiro (inteiro)Máximo # de pacotes de dados por intervalo de conexão = = 3 pacotes

   Usualmente, este número não é realista, pois há atrasos entre os pacotes sendo enviados em eventos de conexão consecutivos. Então, para o nosso exemplo, vamos com 2 pacotes em vez de 3.

4. Após descobrirmos o # máximo de pacotes de dados que podem ser transferidos por intervalo de conexão, podemos calcular a taxa de transferência de dados:Taxa de transferência de dados = dados por intervalo de conexão / intervalo de conexão = No. de pacotes de dados por intervalo de conexão * Tamanho dos dados por pacote / intervalo de conexão
   = 2 * 244 * 8 bits / 7.5 milisecs = 520,533 bits/seg ~= 508 kbps

Teste e cálculo da transferência de dados entre dois kits de desenvolvimento nRF52

Nesta seção, executaremos múltiplos testes de transferência de dados, calcularemos a transferência usando o procedimento que descrevemos anteriormente e, em seguida, compará-los com a taxa de transferência medida relatada pela aplicação em execução nas placas de desenvolvimento. Os testes são executados com base na aplicação demo fornecida pela Nordic Semiconductor e apresentada neste post do blog: Taxa de transferência e demo de longo alcance.

Código fonte para o exemplo pode ser encontrado na página do GitHub aqui.

Casa 1 (PHY: 1 Mbps, ATT MTU = 23 bytes, DLE: habilitado, intervalo de conexão: 7.5 milisecs)

Taxa de transferência de dados reportada pelo firmware:

Tempo: 36.11 segundos decorridos.
Passagem: 232,29 Kbits/s.
Enviado 1048580 bytes de carga útil ATT.

Passagem de dados calculados:

Com a MTU configurada para 23 bytes, o DLE não afeta realmente a taxa de transferência de dados e o tamanho dos pacotes.

Tempo para transmitir o pacote de dados = tamanho do pacote de dados / taxa de dados brutos = 1 + 4 + 2 + 4 + 4 + 23 + 3 bytes / 1 Mbps= 37*8 bits / 1 Mbps = 296 microsecs

Data_Packet_Time = Tempo para transmitir pacote vazio + IFS + Tempo para transmitir o pacote de dados real + IFS = 80 + 150 + 296 + 150 microsecs = 676 microsecs

Máximo # de pacotes de dados por intervalo de conexão = = = = 11 pacotes
Total de dados transferidos por intervalo de conexão = 11 * 20 bytes = 11 * 20 * 8 bits = 1760 bits

Rendimento de dados = Total de dados transferidos por intervalo de conexão/intervalo de conexão = 1760 bits / 7.5 milisegs = 234,67 Kbits/s
Como podemos ver, o valor calculado e o valor medido estão bem próximos.

Case 2 (PHY: 2 Mbps, ATT MTU = 23 bytes, DLE: habilitado, Intervalo de conexão: 7.5 milisecs)

Rendimento de dados reportados pelo firmware:

Tempo: 27,23 segundos.
Rendimento: 307,96 Kbits/s.
Enviado 1048580 bytes de carga útil ATT.

Perda de dados calculada:

Tempo para transmitir pacote de dados = Tamanho do pacote de dados / taxa de dados brutos = 2 + 4 + 2 + 4 + 4 + 23 + 3 bytes / 2 Mbps= 38*8 bits / 2 Mbps = 152 microsecs

Data_Packet_Time = Tempo para transmitir pacote vazio + IFS + Tempo para transmitir o pacote de dados real + IFS = 44 + 150 + 152 + 150 microsecs = 496 microsecs

Máximo # de pacotes de dados por intervalo de conexão = = = = 15 pacotes
Total de dados transferidos por intervalo de conexão = 15 * 20 bytes = 15 * 20 * 8 bits = 2400 bits

Rendimento de dados = Total de dados transferidos por intervalo de conexão/intervalo de conexão = 2400 bits / 7.5 milisegs = 320 Kbits/s
Como podemos ver, o valor calculado e o valor medido estão bem próximos.

Caso 3 (PHY: 1 Mbps, ATT MTU = 158 bytes, DLE: habilitado, Intervalo de conexão: 7.5 milisecs)

Rendimento de dados reportados pelo firmware:

Tempo: 17,53 segundos.
Rendimento: 478,36 Kbits/s.
Enviado 1048730 bytes de carga útil ATT.

Perda de dados calculada:

Tempo para transmitir pacote de dados = tamanho do pacote de dados / taxa de dados brutos = 1 + 4 + 2 + 4 + 158 + 3 bytes / 1 Mbps= 172*8 bits / 1 Mbps = 1376 microsecs

Data_Packet_Time = Tempo para transmitir pacote vazio + IFS + Tempo para transmitir o pacote de dados real + IFS = 80 + 150 + 1376 + 150 microsecs = 1756 microsecs

Máximo # de pacotes de dados por intervalo de conexão = = = = 4 pacotes
Total de dados transferidos por intervalo de conexão = 4 * 155 bytes = 4 * 155 * 8 bits = 4960 bits

Rendimento de dados = Total de dados transferidos por intervalo de conexão/intervalo de conexão = 4960 bits / 7.5 milisecs = 661,33 Kbits/s

Case 4 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: habilitado, Intervalo de conexão: 7.5 milisecs)

Rendimento de dados reportados pelo firmware:

Tempo: 8,45 segundos.
Rendimento: 992,07 Kbits/s.
Enviado 1048712 bytes de carga útil ATT.

Perda de dados calculada:

Tempo para transmitir pacote de dados = Tamanho do pacote de dados / taxa de dados brutos = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs

Data_Packet_Time = Tempo para transmitir pacote vazio + IFS + Tempo para transmitir o pacote de dados real + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs

Máximo # de pacotes de dados por intervalo de conexão = = = = 5 pacotes
Total de dados transferidos por intervalo de conexão = 5 * 244 bytes = 5 * 244 * 8 bits = 9760 bits

Rendimento de dados = Total de dados transferidos por intervalo de conexão/intervalo de conexão = 9760 bits / 7.5 milisecs = 1301,33 Kbits/s

Nota: Nos dois últimos casos, o número de pacotes por intervalo de conexão é pequeno e qualquer diferença entre o que calculamos e medimos terá um grande impacto sobre a taxa de transferência de dados real. Por exemplo, se o número de pacotes por intervalo de conexão acabar sendo 4 ao invés de 5 no caso 4, a taxa de transferência calculada se torna 1.041,1 Kbps ao invés de 1.301,33 Kbps (o que é uma grande diferença e poderia explicar a discrepância em números aqui).

Caso 5 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: habilitado, Intervalo de conexão: 50 milisecs)

Rendimento de dados reportados pelo firmware:

Tempo: 6,34 segundos.
Rendimento: 1322,33 Kbits/s.
Enviado 1048712 bytes de carga útil ATT.

Perda de dados calculada:

Tempo para transmitir pacote de dados = Tamanho do pacote de dados / taxa de dados brutos = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs

Data_Packet_Time = Tempo para transmitir pacote vazio + IFS + Tempo para transmitir o pacote de dados real + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs

Máximo # de pacotes de dados por intervalo de conexão = = = = 35 pacotes

Total de dados transferidos por intervalo de conexão = 36 * 244 bytes = 35 * 244 * 8 bits = 68320 bits

Rendimento de dados = Total de dados transferidos por intervalo de conexão/intervalo de conexão = 70272 bits / 50 milisecs = 1366.4 Kbits/s

Case 6 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: habilitado, Intervalo de conexão: 400 milisecs)

Rendimento de dados reportados pelo firmware:

Tempo: 6,11 segundos decorridos.
Rendimento: 1371,82 Kbits/s.
Enviado 1048712 bytes de carga útil ATT.

Perda de dados calculada:

Tempo para transmitir pacote de dados = tamanho do pacote de dados / taxa de dados brutos = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs

Data_Packet_Time = Tempo para transmitir pacote vazio + IFS + Tempo para transmitir o pacote de dados real + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs

Máximo # de pacotes de dados por intervalo de conexão = = = = 287 pacotes

Total de dados transferidos por intervalo de conexão = 287 * 244 bytes = 287 * 244 * 8 bits = 560224 bits

Rendimento de dados = Total de dados transferidos por intervalo de conexão/intervalo de conexão =560224 bits / 400 milisecs = 1400.56 Kbits/s

Optimização para máxima transmissão de dados

Baseado nos fatores que passamos, podemos notar o seguinte ao otimizar para alta transmissão de dados:

• Ativar sempre DLE
  Obviamente, se você estiver usando Bluetooth v4.1 ou anterior, esta não é uma opção válida. No entanto, em geral, certifique-se de ativar o DLE para maximizar a eficiência do seu pacote para a aplicação de dados
• Use o LE 2M PHY
  Se você sabe que os dispositivos em ambas as extremidades suportam Bluetooth 5, então usar o LE 2M PHY é uma das melhores maneiras de maximizar a taxa de transferência de dados da sua aplicação. O uso do LE 2M PHY também ajudará a reduzir o consumo de energia, então você atinge dois pássaros com uma cajadada!
• Usar Notificações e Escritos sem Respostas
  Utilizá-los ajudará a remover quaisquer pacotes desnecessários sendo transmitidos (em comparação com as Indicações e Escritos normais que requerem que a extremidade receptora reconheça cada pacote recebido).
• Escolha um valor ATT MTU de pelo menos 247 bytes
  Isso irá minimizar qualquer sobrecarga nos bytes de pacotes.
• Escolha um intervalo de conexão que permita o máximo # de pacotes por intervalo de conexão
  Mas tenha em mente que o intervalo de conexão afeta o consumo de energia. Quanto menor o intervalo, mais energia seu dispositivo irá consumir por causa do aumento do tempo de ligação do rádio. Você também quer ter certeza de não escolher um intervalo muito alto, caso contrário, ele comprometerá a experiência do usuário (um intervalo de conexão maior resulta em maior latência). Uma última coisa a ter em conta é qualquer limitação dos dispositivos em seu sistema em termos do número máximo de pacotes por intervalo de conexão suportado.

Resumo & fechamento

Os valores calculados que listamos acima ainda são teóricos e podem não se alinhar com a produção de dados medidos na prática e em ambientes reais, mas ainda são um bom ponto de partida e dão uma boa indicação do que esperar (pelo menos para um máximo). Interferências e erros de transmissão/recepção também afetam a produção de dados (novas tentativas, perda de dados e fechamento de eventos de conexão resultam em menor produção). Estes podem ser causados pela presença de outros dispositivos que utilizam a mesma banda de 2,4 GHz do Bluetooth, maior distância entre dispositivos, existência de obstáculos entre dispositivos, e mais…