Streaming video tramite BLE o Bluetooth 4.0 classico?


10

BLE ha solo un payload di dati di 100 Kbps, quindi mi chiedevo se è possibile eseguire lo streaming di un video live utilizzando Bluetooth Low Energy?

Il Bluetooth 4.0 classico ha un payload di dati di 2 Mbps che semplifica la trasmissione del video, ma sono più preoccupato per la potenza totale, quindi voglio implementare il BLE. Posso ottenere lo stesso risultato quando utilizzo BLE per lo streaming del video?


1
Questa domanda non è aggiornata per Bluetooth 5 per controller BLE con un PHY 2M (bps).
ZX9

Risposte:


12

BLE è molto inadatto per lo streaming anche di larghezza di banda media (audio o video), perché è progettato per il trasferimento di pochi e piccoli pacchetti di dati con un sacco di tempo di inattività. Questo è il motivo per cui viene chiamato "bassa energia" e non "bassa potenza": riduce la quantità di picojoule per bit per i piccoli pacchetti rispetto agli standard concorrenti. Altri standard utilizzano principalmente più potenza non perché dispongono di radio meno efficienti, ma perché almeno il ricevitore è costantemente alimentato anche quando ci sono cali relativamente ampi nel traffico radio e perché una parte significativa dei bit trasferiti non è un carico utile, ma piuttosto un sovraccarico - intestazioni di protocollo, checksum, anche solo spazio vuoto. BLE elimina la maggior parte di questi inutili assorbimenti di potenza. Ma attenzione, non lo fa migliorare magicamente il consumo energetico dei ricetrasmettitori quando sono attivi. E quando si esegue il trasferimento video, i ricetrasmettitori vengono costantemente accesi. Perdi il più grande vantaggio di BLE.

Questa scelta di progettazione riduce sostanzialmente le spese generali al minimo che desideri, ma fa anche in modo che non abbia alcuna funzionalità di streaming integrata nativamente come la ricombinazione dei pacchetti, il riconoscimento ritardato e i trasferimenti asincroni. In realtà non hai nulla incorporato, BLE è grezzo quanto puoi arrivare a un'interfaccia wireless, salvo forse nRF24 e TI CC2x00. Di conseguenza, dovrai farlo nel software (su un microcontrollore o sul tuo dispositivo utente) e questo consuma incredibilmente molta più energia che se usi un protocollo appositamente costruito con funzionalità hardware per questo come Bluetooth 3.0 EDR o Wi-Fi.

Questo porta all'idea un po 'controintuitiva che una volta che inizi a entrare nella velocità dei dati di tipo audio e superiore, Bluetooth Low Energy diventa, a seconda della tua implementazione, circa 2 volte meno efficiente di Bluetooth 3.0 e quando entri nella gamma dei megabit è sostanzialmente meno efficiente del WiFi. Questo è il motivo per cui esiste il WiFi - questo e probabilmente il raggio d'azione wireless, sebbene al giorno d'oggi i ricetrasmettitori per entrambi gli standard siano molto equivalenti. WiFi ha solo MIMO opzionale e diversità.

Pertanto, anche se non si prendono in considerazione - almeno per i video - limiti di larghezza di banda e portata molto restrittivi che il Bluetooth impone, con questo metodo non è possibile raggiungere l'obiettivo del trasferimento video a bassa potenza.


8

Bene, con 100kbps, potresti essere in grado di trasmettere in streaming un video di bassa qualità delle dimensioni di un francobollo postale :-)

Senza alcuna precisione, immaginerò che tu voglia HD (nemmeno full HD) @ 30fps in H264, con movimento medio (fattore 2), una stima approssimativa del bitrate potrebbe essere:

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

Quindi devi ridurlo di un fattore 38 (almeno!).

Supponi di accontentarti di ~ 320x200 @ 15fps, sei ancora un po 'sopra (la larghezza di banda teorica , aspetti meno).


1
Qual è un fattore di movimento medio? E qual è il valore 0,07?
m.,

@ m.Alin Forse .07 è audio?
ZX9

0

Tutti i miei test sono finiti a meno di 2000 ottetti / secondo

Prerequisiti:

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

Tutti i test che ho fatto tra Android <-> Linux & Bunget, Android <-> Linux & Bleno, Android <-> ST-Micro Nucleus + blueNRG. Linux e NUCLEO che eseguono server GATT. Android che esegue principalmente client GATT.

  • Android-> server GATT NOTIFICATION / WRITE NO RESPONSE non può essere inviato spesso di 13 ms. Ofthen of 13ms enaded in packet lost.

  • Server-> Android NOTIFICATION / WRITE NO RESPONSE non può essere inviato spesso di 15 ms

  • Entrambi i lati, LEGGERE INDICATORE, poiché non possono essere invocati spesso per 15-20 ms.

Ciò porta a 1000ms / 13ms -> 77 volte / secondo di 20 byte = 1500 ottetti / secondo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.