¿Transmitir video usando BLE o Bluetooth 4.0 clásico?

BLE es muy inadecuado incluso para la transmisión de ancho de banda medio (audio o video), porque está diseñado para la transferencia de pocos y pequeños paquetes de datos con mucho tiempo de inactividad en el medio. Por eso se llama 'baja energía' y no 'baja potencia': reduce la cantidad de picojulios por bit para paquetes pequeños con respecto a los estándares de la competencia. Otros estándares en su mayoría usan más energía no porque tengan radios menos eficientes, sino porque al menos el receptor está constantemente encendido incluso cuando hay pausas comparativamente grandes en el tráfico de radio, y porque una parte significativa de los bits transferidos no son carga útil sino sobrecarga. - encabezados de protocolo, sumas de verificación, incluso solo espacios en blanco. BLE elimina la mayoría de estos consumos de energía innecesarios. Pero ojo, no Mejoran mágicamente el uso de energía de los transceptores cuando están activos. Y cuando se realiza la transferencia de video, los transceptores se encienden constantemente. Pierdes la mayor ventaja de BLE.

Esta elección de diseño reduce la sobrecarga esencialmente al mínimo que desee, pero también hace que no tenga funciones de transmisión integradas de forma nativa, como la recombinación de paquetes, el reconocimiento demorado y las transferencias asíncronas. En realidad, no tiene nada incorporado, BLE es tan crudo como puede llegar a una interfaz inalámbrica, salvo tal vez nRF24 y TI CC2x00. Como resultado, necesitará hacer esto en el software (ya sea en un microcontrolador o en su dispositivo de usuario) y esto usa increíblemente mucha más energía que si usa un protocolo especialmente diseñado con instalaciones de hardware para esto como Bluetooth 3.0 EDR o Wifi.

Esto lleva a la noción un tanto contraria a la intuición de que una vez que comienza a ingresar velocidades de datos de tipo audio y superiores, Bluetooth Low Energy se vuelve, dependiendo de su implementación, aproximadamente 2 veces menos eficiente que Bluetooth 3.0, y cuando ingresa al rango de megabits es sustancialmente menos eficiente que WiFi. Esta es la razón por la que existe WiFi, y posiblemente el alcance inalámbrico, aunque hoy en día los transceptores para ambos estándares son muy equivalentes. WiFi solo tiene MIMO y diversidad opcionales.

Por lo tanto, incluso si no se tiene en cuenta el ancho de banda y los límites de rango muy restrictivos que impone Bluetooth, al menos para el video, es posible que no logre el objetivo de la transferencia de video de baja potencia con este método.

Bueno, con 100 kbps, puede transmitir un video de baja calidad del tamaño de un sello postal :-)

Sin ninguna precisión, me imagino que quieres HD (ni siquiera Full HD) a 30 fps en H264, con movimiento promedio (factor 2), una estimación aproximada de la tasa de bits podría ser:

(1280px*720px)*30fps*2*0.07 ~= 3800kbps

Así que tienes que reducir esto por un factor de 38 (¡al menos!).

Digamos que te conformas con ~320x200 @ 15fps, todavía estás un poco por encima (el ancho de banda teórico , espera menos).

Toda mi prueba terminó por debajo de 2000 octetos/segundo

requisitos previos:

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

Todas las pruebas que he hecho entre Android <-> Linux y Bunget, Android <-> Linux y Bleno, Android <-> ST-Micro Nucleus+ blueNRG. Linux y NUCLEO ejecutando servidores GATT. Android principalmente ejecutando el cliente GATT.

• Android->Servidor GATT NOTIFICACIÓN/NO ESCRIBIR RESPUESTA no se puede enviar con una frecuencia de 13 ms. A menudo, más de 13 ms terminaron en paquetes perdidos.

• Servidor-> NOTIFICACIÓN de Android/NO ESCRIBIR RESPUESTA no se puede enviar con una frecuencia de 15 ms

• Ambos lados, LEER INDICADOR, ya que no se puede invocar con una frecuencia de 15 a 20 ms.

Eso conduce a 1000ms/13ms -> 77 veces/segundo de 20 bytes = 1500 octetos/segundo.