Videos über BLE oder klassisches Bluetooth 4.0 streamen?

BLE ist selbst für Streaming mit mittlerer Bandbreite (Audio oder Video) sehr ungeeignet, da es für die Übertragung weniger und kleiner Datenpakete mit viel Ruhezeit dazwischen ausgelegt ist. Aus diesem Grund wird es als "Low Energy" und nicht als "Low Power" bezeichnet - es reduziert die Menge an Picojoule pro Bit für kleine Pakete im Vergleich zu konkurrierenden Standards. Andere Standards verbrauchen meistens mehr Strom, nicht weil sie weniger effiziente Funkgeräte haben, sondern weil zumindest der Empfänger auch bei vergleichsweise großen Funkstillständen ständig eingeschaltet ist und weil ein erheblicher Teil der übertragenen Bits keine Nutzlast, sondern Overhead sind - Protokollheader, Prüfsummen, sogar nur Leerzeichen. BLE eliminiert die meisten dieser unnötigen Stromverbraucher. Aber wohlgemerkt, das tut es t verbessert auf magische Weise den Stromverbrauch der Transceiver, wenn sie aktiv sind. Und bei der Videoübertragung werden die Transceiver ständig eingeschaltet. Sie verlieren den größten Vorteil von BLE.

Diese Designwahl reduziert den Overhead auf im Wesentlichen so wenig wie Sie möchten, sorgt aber auch dafür, dass es keine nativen Streaming-Funktionen wie Paketrekombination, verzögerte Bestätigung und asynchrone Übertragungen gibt. Sie haben tatsächlich nichts eingebaut, BLE ist so roh, wie Sie zu einer drahtlosen Schnittstelle gelangen können, abgesehen von vielleicht nRF24 und TI CC2x00. Infolgedessen müssen Sie dies in Software tun (entweder auf einem Mikrocontroller oder auf Ihrem Benutzergerät), und dies verbraucht unglaublich viel mehr Energie, als wenn Sie ein speziell entwickeltes Protokoll mit Hardwareeinrichtungen dafür wie Bluetooth 3.0 EDR oder verwenden W-lan.

Dies führt zu der etwas kontraintuitiven Vorstellung, dass Bluetooth Low Energy je nach Implementierung etwa 2x weniger effizient als Bluetooth 3.0 wird, sobald Sie mit Audio-Datenraten und mehr beginnen, und wenn Sie in den Megabit-Bereich kommen, ist es erheblich weniger effizient als WLAN. Aus diesem Grund gibt es WiFi - das und wohl die drahtlose Reichweite, obwohl heutzutage Transceiver für beide Standards sehr gleichwertig sind. WiFi hat nur optionales MIMO und Diversity.

Selbst wenn man die – zumindest für Video – sehr restriktiven Bandbreiten- und Reichweitenbeschränkungen, die Bluetooth auferlegt, nicht berücksichtigt, kann es sein, dass Sie mit dieser Methode das Ziel einer Videoübertragung mit geringem Stromverbrauch nicht erreichen.

Nun, mit 100 kbps können Sie möglicherweise ein Video in niedriger Qualität in der Größe einer Briefmarke streamen :-)

Ohne jegliche Präzision stelle ich mir vor, Sie möchten HD (nicht einmal Full HD) @ 30fps in H264, mit durchschnittlicher Bewegung (Faktor 2), eine ungefähre Schätzung der Bitrate könnte sein:

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

Diesen müssen Sie also um den Faktor 38 reduzieren (mindestens !).

Angenommen, Sie geben sich mit ~ 320 x 200 bei 15 fps zufrieden, Sie sind immer noch etwas darüber (die theoretische Bandbreite, erwarten Sie weniger).

Alle meine Tests endeten bei unter 2000 Oktetten/Sekunde

Voraussetzungen:

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

Alle Tests, die ich zwischen Android <-> Linux & Bunget, Android <-> Linux & Bleno, Android <-> ST-Micro Nucleus+ blueNRG durchgeführt habe. Linux & NUCLEO mit GATT-Servern. Android, auf dem hauptsächlich der GATT-Client ausgeführt wird.

• Android->GATT-Server NOTIFICATION/WRITE NO RESPONSE kann nicht öfter als 13 ms gesendet werden. Oftmals wurden bis zu 13 ms ein Paket verloren.

• Server->Android NOTIFICATION/WRITE NO RESPONSE kann nicht öfter als 15 ms gesendet werden

• Beide Seiten, READ INDICATOR, da nicht oft als 15..20 ms aufgerufen werden kann.

Das führt zu 1000 ms/13 ms -> 77 mal / Sekunde von 20 Bytes = 1500 Oktette/Sekunde.