Streaming de vídeo usando BLE ou Bluetooth 4.0 clássico?


10

O BLE tem apenas uma carga útil de dados de 100 Kbps, então eu queria saber se é possível transmitir um vídeo ao vivo usando Bluetooth Low Energy?

O Classic Bluetooth 4.0 possui uma carga útil de dados de 2 Mbps, o que facilita a transmissão do vídeo, mas estou mais preocupado com a potência total, portanto, desejo implementar o BLE. Posso obter o mesmo resultado quando uso o BLE para transmitir o vídeo?


1
Esta questão está desatualizada para o Bluetooth 5 para controladores BLE com um PHY de 2M (bps).
ZX9

Respostas:


12

O BLE é muito inadequado para streaming de largura de banda média (áudio ou vídeo), porque foi projetado para a transferência de poucos e pequenos pacotes de dados com muito tempo de inatividade. É por isso que é chamado de 'baixa energia' e não 'baixa energia' - reduz a quantidade de picojoules por bit para pacotes pequenos em relação aos padrões concorrentes. Outros padrões geralmente usam mais energia, não porque eles tenham rádios menos eficientes, mas porque pelo menos o receptor é constantemente ligado, mesmo quando há intervalos relativamente grandes no tráfego de rádio, e porque uma parcela significativa dos bits transferidos não é de carga, mas sim de sobrecarga - cabeçalhos de protocolo, somas de verificação e até apenas espaço em branco. O BLE elimina a maioria desses consumos desnecessários de energia. Mas lembre-se, isso não acontece t melhorar magicamente o uso de energia dos transceptores quando eles estiverem ativos. E ao fazer a transferência de vídeo, os transceptores são constantemente ligados. Você perde a maior vantagem do BLE.

Essa opção de design reduz a sobrecarga para essencialmente o tamanho que você desejar, mas também faz com que não tenha nenhum recurso de streaming embutido nativamente, como recombinação de pacotes, reconhecimento atrasado e transferências assíncronas. Você realmente não tem nada incorporado, o BLE é o mais bruto possível para uma interface sem fio, exceto o nRF24 e o TI CC2x00. Como resultado, você precisará fazer isso em software (em um microcontrolador ou no dispositivo do usuário) e isso consome incrivelmente muito mais energia do que se você usasse um protocolo específico com recursos de hardware como Bluetooth 3.0 EDR ou Wi-fi.

Isso leva à noção um tanto contra-intuitiva de que, quando você começa a obter taxas de dados do tipo áudio e acima, o Bluetooth Low Energy se torna, dependendo da sua implementação, cerca de duas vezes menos eficiente que o Bluetooth 3.0, e quando você atinge o alcance de megabits, é substancialmente menos eficiente que o WiFi. É por isso que o WiFi existe - esse e sem dúvida o alcance sem fio, embora atualmente os transceptores para ambos os padrões sejam muito equivalentes. O WiFi apenas possui MIMO e diversidade opcionais.

Portanto, mesmo que você não considere os limites de largura de banda e alcance muito restritivos que o Bluetooth impõe, pelo menos para o vídeo, talvez você não atinja a meta de transferência de vídeo de baixa potência com esse método.


8

Bem, com 100kbps, você poderá transmitir um vídeo de baixa qualidade do tamanho de um carimbo de postagem :-)

Sem precisão, imagino que você queira HD (nem mesmo full HD) a 30fps no H264, com movimento médio (fator 2), uma estimativa aproximada da taxa de bits pode ser:

(1280px * 720px) * 30fps * 2 * 0,07 ~ = 3800kbps

Então você tem que reduzir isso em um fator 38 (pelo menos!).

Digamos que você aceite ~ 320x200 a 15fps, você ainda está um pouco acima (a largura de banda teórica espera menos).


1
O que é um fator de movimento médio? E qual é o valor 0,07?
m.Alin

@ m.Alin Talvez o .07 seja áudio?
ZX9 04/08/19

0

Todo o meu teste terminou abaixo de 2000 octetos / segundo

Pré-requisitos:

  • Android: Nexus Gallaxy Tab 7 Android 6.0.1 (cliente GATT)
  • Linux: R-PI + BCM20702A0 (servidor GATT)
  • NUCLEO-F411RE: BlueNRG (servidor GATT)

Todos os testes que fiz entre Android <-> Linux e Bunget, Android <-> Linux e Bleno, Android <-> ST-Micro Nucleus + blueNRG. Linux e NUCLEO executando servidores GATT. Android executando principalmente o cliente GATT.

  • O servidor Android-> GATT NOTIFICATION / WRITE NO RESPONSE não pode ser enviado com frequência superior a 13 ms. Freqüentemente, 13ms foram perdidos em pacotes perdidos.

  • Servidor-> Android NOTIFICATION / WRITE NO RESPONSE não pode ser enviado com frequência superior a 15 ms

  • Ambos os lados, LEIA O INDICADOR, como não podem ser chamados com frequência maior que 15 a 20 ms.

Isso leva a 1000ms / 13ms -> 77 vezes / segundo de 20 bytes = 1500 octetos / segundo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.