Streaming vidéo en utilisant BLE ou Bluetooth 4.0 classique?

BLE n'a qu'une charge utile de 100 Kbps, donc je me demandais s'il était possible de diffuser une vidéo en direct en utilisant Bluetooth Low Energy?

Le Bluetooth 4.0 classique a une charge utile de 2 Mbps, ce qui facilite la transmission de la vidéo, mais je suis plus préoccupé par la puissance totale, alors je veux implémenter le BLE. Puis-je obtenir le même résultat lorsque j'utilise BLE pour diffuser la vidéo?

Le BLE est très inapproprié pour le streaming même à bande passante moyenne (audio ou vidéo), car il est conçu pour le transfert de petits et petits paquets de données avec beaucoup de temps de sommeil entre les deux. C'est pourquoi il est appelé «basse énergie» et non «faible puissance» - il réduit la quantité de picojoules par bit pour les petits paquets par rapport aux normes concurrentes. D'autres normes utilisent généralement plus d'énergie non pas parce qu'elles ont des radios moins efficaces, mais parce qu'au moins le récepteur est constamment alimenté même lorsqu'il y a des accalmies relativement importantes dans le trafic radio, et parce qu'une partie importante des bits transférés ne sont pas de la charge utile mais plutôt des frais généraux - en-têtes de protocole, sommes de contrôle, même juste un espace vide. BLE élimine la plupart de ces puissances inutiles. Mais attention, ça ne marche pas t améliorer comme par magie la consommation d'énergie des émetteurs-récepteurs lorsqu'ils sont actifs. Et lors du transfert vidéo, les émetteurs-récepteurs sont constamment sous tension. Vous perdez le plus gros avantage du BLE.

Ce choix de conception réduit les frais généraux à aussi peu que vous le souhaitez, mais fait également en sorte qu'il ne dispose pas de fonctionnalités de streaming intégrées en natif comme la recombinaison de paquets, l'accusé de réception retardé et les transferts asynchrones. En fait, vous n'avez rien intégré, BLE est aussi brut que possible pour une interface sans fil, sauf peut-être nRF24 et TI CC2x00. En conséquence, vous devrez le faire dans un logiciel (soit sur un microcontrôleur ou sur votre appareil utilisateur) et cela utilise beaucoup plus d'énergie que si vous utilisez un protocole spécialement conçu avec des installations matérielles pour cela, comme Bluetooth 3.0 EDR ou Wifi.

Cela conduit à la notion quelque peu contre-intuitive qu'une fois que vous commencez à entrer dans les débits de données de type audio et plus, Bluetooth Low Energy devient, selon votre implémentation, environ 2x moins efficace que Bluetooth 3.0, et lorsque vous entrez dans la plage des mégabits, il est sensiblement moins efficace que le WiFi. C'est pourquoi le WiFi existe - cela et sans doute la portée sans fil, bien que de nos jours les émetteurs-récepteurs pour les deux normes soient très équivalents. Le WiFi n'a que MIMO et diversité en option.

Ainsi, même en ne tenant pas compte - au moins pour la vidéo - des limites de bande passante et de plage très restrictives imposées par Bluetooth, vous ne pouvez pas atteindre l'objectif de transfert vidéo à faible puissance avec cette méthode.

Eh bien, avec 100 kbps, vous pourrez peut-être diffuser une vidéo de faible qualité de la taille d'un timbre-poste :-)

Sans aucune précision, j'imagine que vous voulez de la HD (pas même de la Full HD) à 30 ips en H264, avec un mouvement moyen (facteur 2), une estimation approximative du débit pourrait être:

(1280 pixels * 720 pixels) * 30 images par seconde * 2 * 0,07 ~ = 3800 kbps

Vous devez donc réduire cela d'un facteur 38 (au moins!).

Disons que vous vous contentez de ~ 320x200 @ 15fps, vous êtes toujours un peu au-dessus (la bande passante théorique , attendez-vous à moins).

Tout mon test s'est retrouvé en dessous de 2000 octets / seconde

Conditions préalables:

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

Tous les tests que j'ai effectués entre Android <-> Linux & Bunget, Android <-> Linux & Bleno, Android <-> ST-Micro Nucleus + blueNRG. Linux et NUCLEO exécutant des serveurs GATT. Android exécutant principalement le client GATT.

• Android-> GATT server NOTIFICATION / WRITE NO RESPONSE ne peut pas être envoyé souvent à 13 ms. Souvent, 13 ms se sont accumulés dans le paquet perdu.

• Server-> Android NOTIFICATION / WRITE NO RESPONSE ne peut pas être envoyé souvent à 15 ms

• Les deux côtés, READ INDICATOR, ne peuvent pas être invoqués souvent au-delà de 15..20 ms.

Cela conduit à 1000 ms / 13 ms -> 77 fois / seconde de 20 octets = 1500 octets / seconde.