BLE solo tiene una carga útil de datos de 100 Kbps, así que me preguntaba si es posible transmitir un video en vivo usando Bluetooth Low Energy.
Classic Bluetooth 4.0 tiene una carga útil de datos de 2Mbps que hace que sea más fácil transmitir el video, pero me preocupa más la potencia total, por lo que quiero implementar el BLE. ¿Puedo obtener el mismo resultado cuando uso BLE para transmitir el video?
bluetooth
bluetooth-low-energy
Electrónica curiosa
fuente
fuente
Respuestas:
BLE es muy inadecuado incluso para transmisión de ancho de banda medio (audio o video), ya que está diseñado para transferir pocos y pequeños paquetes de datos con mucho tiempo de inactividad en el medio. Es por eso que se llama 'baja energía' y no 'baja potencia': reduce la cantidad de picojulios por bit para paquetes pequeños con respecto a estándares competitivos. Otros estándares en su mayoría usan más energía no porque tengan radios menos eficientes, sino porque al menos el receptor se enciende constantemente incluso cuando hay pausas comparativamente enormes en el tráfico de radio, y porque una parte significativa de los bits transferidos no son de carga útil, sino de arriba - encabezados de protocolo, sumas de verificación, incluso solo espacio en blanco. BLE elimina la mayoría de estos consumos de energía innecesarios. Pero eso sí, no lo hace Mejora 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 opción de diseño reduce la sobrecarga a esencialmente tan poco como desee, pero también hace que no tenga ningún servicio de transmisión incorporado de forma nativa, como recombinación de paquetes, reconocimiento retrasado y transferencias asíncronas. En realidad, no tiene nada incorporado, BLE es tan simple como puede llegar a una interfaz inalámbrica, salvo tal vez nRF24 y TI CC2x00. Como resultado, tendrá que hacer esto en un software (ya sea en un microcontrolador o en su dispositivo de usuario) y esto usa mucha más energía que si usa un protocolo especialmente diseñado con funciones de hardware para esto como Bluetooth 3.0 EDR o Wifi.
Esto lleva a la noción algo intuitiva de que una vez que comience a obtener velocidades de datos de tipo de audio y superiores, Bluetooth Low Energy se convierte, según su implementación, en aproximadamente 2 veces menos eficiente que Bluetooth 3.0, y cuando ingresa en el rango de megabits es sustancialmente Menos eficiente que el WiFi. Esta es la razón por la cual existe WiFi: ese y posiblemente alcance inalámbrico, aunque hoy en día los transceptores para ambos estándares son muy equivalentes. WiFi solo tiene MIMO opcional y diversidad.
Por lo tanto, incluso si no tiene en cuenta los límites de ancho de banda y rango muy restrictivos que impone el 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.
fuente
Bueno, con 100 kbps, es posible que pueda transmitir un video de baja calidad del tamaño de un sello postal :-)
Sin ninguna precisión, me imagino que quiere 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:
(1280 px * 720 px) * 30 fps * 2 * 0.07 ~ = 3800 kbps
Por lo tanto, debe reducir esto en un factor 38 (¡al menos!).
Digamos que se conforma con ~ 320x200 @ 15 fps, todavía está un poco por encima (el ancho de banda teórico , espere menos).
fuente
Toda mi prueba terminó a menos de 2000 octetos / segundo
Prerrequisitos:
Todas las pruebas que he realizado entre Android <-> Linux & Bunget, Android <-> Linux & Bleno, Android <-> ST-Micro Nucleus + blueNRG. Linux y NUCLEO con servidores GATT. Android ejecuta principalmente el cliente GATT.
El servidor Android-> GATT NOTIFICACIÓN / ESCRIBIR SIN RESPUESTA no se puede enviar con más de 13 ms. A menos de 13 ms encerrado en paquete perdido.
Servidor-> Android NOTIFICACIÓN / ESCRIBIR SIN RESPUESTA no puede enviarse más de 15 ms
Eso lleva hasta 1000ms / 13ms -> 77 veces / segundo de 20 bytes = 1500 octetos / segundo.
fuente