Streaming wideo przy użyciu BLE lub klasycznego Bluetooth 4.0?


10

BLE ma tylko ładowność 100 Kb / s, więc zastanawiałem się, czy można przesyłać strumieniowo wideo na żywo za pomocą Bluetooth Low Energy?

Klasyczny Bluetooth 4.0 ma ładunek danych 2 Mb / s, co ułatwia przesyłanie wideo, ale bardziej martwię się o całkowitą moc, więc chcę wdrożyć BLE. Czy mogę uzyskać ten sam wynik, gdy używam BLE do strumieniowego przesyłania wideo?


1
To pytanie jest nieaktualne w przypadku Bluetooth 5 dla kontrolerów BLE z PHY 2M (bps).
ZX9,

Odpowiedzi:


12

BLE jest bardzo nieodpowiedni do przesyłania strumieniowego o średniej przepustowości (audio lub wideo), ponieważ jest przeznaczony do przesyłania niewielkiej liczby małych pakietów danych z dużą ilością czasu pomiędzy nimi. Dlatego nazywa się to „niską energią”, a nie „niską mocą” - zmniejsza ilość piko-pików na bit dla małych pakietów w stosunku do konkurencyjnych standardów. Inne standardy wykorzystują głównie więcej energii nie dlatego, że mają mniej wydajne radiotelefony, ale dlatego, że przynajmniej odbiornik jest stale zasilany, nawet gdy występują stosunkowo duże przerwy w ruchu radiowym, a także dlatego, że znaczna część przesyłanych bitów nie jest obciążeniem użytecznym, ale zamiast narzutu - nagłówki protokołu, sumy kontrolne, a nawet puste miejsce. BLE eliminuje większość tych niepotrzebnych poborów mocy. Ale uwaga, to nie robi t magicznie poprawić zużycie energii przez nadajniki-odbiorniki, gdy są one aktywne. Podczas przesyłania wideo urządzenia nadawczo-odbiorcze są stale zasilane. Tracisz największą przewagę BLE.

Ten wybór projektu zmniejsza narzut do zasadniczo tak małego, jak chcesz, ale sprawia również, że nie ma wbudowanych żadnych funkcji przesyłania strumieniowego, takich jak rekombinacja pakietów, opóźnione potwierdzanie i asynchroniczne transfery. W rzeczywistości nie masz nic wbudowanego, BLE jest tak surowy, jak tylko możesz dostać się do interfejsu bezprzewodowego, z wyjątkiem nRF24 i TI CC2x00. W rezultacie musisz to zrobić w oprogramowaniu (na mikrokontrolerze lub na urządzeniu użytkownika), a to zużywa niewiarygodnie więcej energii niż w przypadku użycia specjalnie zbudowanego protokołu z urządzeniami sprzętowymi do tego celu, takimi jak Bluetooth 3.0 EDR lub WiFi.

Prowadzi to do nieco sprzecznego z intuicją pojęcia, że ​​kiedy zaczniesz wchodzić w prędkości transmisji danych typu audio i wyższe, Bluetooth Low Energy staje się, w zależności od implementacji, około 2x mniej wydajny niż Bluetooth 3.0, a kiedy wchodzisz w zakres megabitów, jest to znacznie mniej wydajny niż WiFi. Właśnie dlatego istnieje WiFi - ten i prawdopodobnie bezprzewodowy zasięg, chociaż obecnie urządzenia nadawczo-odbiorcze dla obu standardów są bardzo równoważne. WiFi ma tylko opcjonalne MIMO i różnorodność.

Nawet jeśli nie bierze się pod uwagę - przynajmniej w przypadku wideo - bardzo restrykcyjnych limitów przepustowości i zasięgu nałożonych przez Bluetooth, możesz nie osiągnąć celu, jakim jest przesyłanie wideo o niskiej mocy za pomocą tej metody.


8

Cóż, przy 100 kb / s możesz być w stanie przesyłać strumieniowo wideo niskiej jakości wielkości znaczka pocztowego :-)

Bez jakiejkolwiek precyzji wyobrażam sobie, że chcesz HD (nawet Full HD) @ 30 klatek na sekundę w H264, przy średnim ruchu (współczynnik 2), przybliżone oszacowanie przepływności może być następujące:

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

Musisz to zmniejszyć o 38 (przynajmniej!).

Powiedzmy, że zgadzasz się na ~ 320 x 200 przy 15 klatkach na sekundę, wciąż jesteś nieco powyżej ( teoretyczna przepustowość, oczekuj mniej).


1
Jaki jest średni współczynnik ruchu? A jaka jest wartość 0,07?
m.Alin

@ m.Alin Być może .07 to dźwięk?
ZX9,

0

Cały mój test skończył z prędkością poniżej 2000 oktetów / sekundę

Wymagania wstępne:

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

Wszystkie testy, które przeprowadziłem między Androidem <-> Linux i Bunget, Androidem <-> Linux i Bleno, Androidem <-> ST-Micro Nucleus + blueNRG. Linux i NUCLEO z serwerami GATT. Android głównie działa z klientem GATT.

  • Android-> serwer GATT POWIADOMIENIE / NAPISZ BRAK ODPOWIEDZI nie może być wysyłane często niż 13 ms. Często tracono ponad 13 ms w pakiecie.

  • Serwer-> Android POWIADOMIENIE / NAPISZ BRAK ODPOWIEDZI nie może być wysyłane często niż 15 ms

  • Obie strony, CZYTAJ WSKAŹNIK, ponieważ nie można wywoływać częściej niż 15..20 ms.

To prowadzi do 1000ms / 13ms -> 77 razy / sekundę z 20 bajtów = 1500 oktetów / sekundę.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.