Потокове відео за допомогою BLE або класичного Bluetooth 4.0?


10

BLE має лише завантаженість даних у 100 Кбіт / с, тому мені було цікаво, чи можна передавати відео в реальному часі за допомогою Bluetooth Low Energy?

Класичний Bluetooth 4.0 має завантаженість даних у 2 Мбіт / с, що полегшує передачу відео, але мене більше турбує загальна потужність, тому хочу реалізувати BLE. Чи можу я отримати такий же результат, коли використовую BLE для передачі відео?


1
Це питання застаріло для Bluetooth 5 для контролерів BLE з PHY 2M (bps).
ZX9

Відповіді:


12

BLE дуже непридатний для навіть середньої смуги пропускання (аудіо чи відео), оскільки він призначений для передачі декількох і малих пакетів даних з великою кількістю часу сну між ними. Ось чому його називають "низькою енергією", а не "малою потужністю" - це зменшує кількість пікожулів на біт для невеликих пакетів щодо конкуруючих стандартів. Інші стандарти в основному використовують більше енергії не тому, що вони мають менш ефективні радіоприймачі, а тому, що принаймні приймач постійно працює, навіть якщо в радіо трафіку є порівняно величезні затримки, а також тому, що значна частина переданих бітів не є корисним навантаженням, а замість накладних витрат - заголовки протоколів, контрольні суми, навіть просто вивільнення місця. BLE виключає більшість цих непотрібних енергозатрат. Але зауважте, це не так t значно покращити енергоспоживання приймачів, коли вони активні. А при здійсненні відеопередачі приймачі постійно живляться. Ви втрачаєте найбільшу перевагу BLE.

Такий дизайн знижує накладні витрати , по суті , так само мало , як вам подобається, але і робить його , що він не має жодних - або потокові об'єкти вбудований спочатку як рекомбінації пакетів, затримки підтвердження і асинхронноїпередачі. Насправді у вас немає нічого вбудованого, BLE такий же сирий, як і ви можете дістатися до бездротового інтерфейсу, забороняючи, можливо, nRF24 і TI CC2x00. Як результат, вам потрібно буде це зробити в програмному забезпеченні (або на мікроконтролері, або на пристрої користувача), і це використовує неймовірно набагато більше енергії, ніж якщо ви використовуєте спеціальний протокол із апаратними засобами для цього, наприклад Bluetooth 3.0 EDR або WiFi.

Це призводить до дещо протиінтуїтивної думки про те, що коли ви починаєте отримувати швидкість передачі даних про аудіо-тип і вище, низька енергія Bluetooth стає, в залежності від вашої реалізації, приблизно в 2 рази менш ефективною, ніж Bluetooth 3.0, і коли ви потрапляєте в мегабітний діапазон, це істотно менш ефективний, ніж WiFi. Ось чому існує WiFi - той і, можливо, бездротовий діапазон, хоча нині трансивери для обох стандартів дуже рівнозначні. WiFi просто має додатковий MIMO та різноманітність.

Тож навіть якщо не брати до уваги - принаймні для відео - дуже обмежувальну смугу пропускної здатності та діапазону, яку встановлює Bluetooth, ви можете не досягти мети передачі відео з низькою потужністю за допомогою цього методу.


8

Що ж, зі 100 кбіт / с ви, можливо, зможете передати відео низької якості розміром поштової марки :-)

Без будь-якої точності, я можу уявити, що ви хочете, щоб HD (навіть не повний HD) @ 30 кадрів в секунду в H264, при середньому русі (коефіцієнт 2), приблизна оцінка бітрейта може бути:

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

Тож вам доведеться зменшити це на коефіцієнт 38 (принаймні!).

Скажімо, ви дотримуєтесь ~ 320x200 @ 15fps, ви все ще трохи вище ( теоретична пропускна здатність, очікуйте менше).


1
Що таке середній коефіцієнт руху? І яке значення 0,07?
м.Алін

@ m.Alin Можливо .07 звук?
ZX9

0

Весь мій тест закінчився нижче 2000 октетів / секунду

Передумови:

  • Android: Nexus Gallaxy Tab 7 Android 6.0.1 (клієнт GATT)
  • Linux: R-PI + BCM20702A0 (сервер GATT)
  • NUCLEO-F411RE: BlueNRG (сервер GATT)

Всі тести, які я робив між Android <-> Linux & Bunget, Android <-> Linux & Bleno, Android <-> ST-Micro Nucleus + blueNRG. Linux та NUCLEO, що працюють на серверах GATT. Android в основному працює з клієнтом GATT.

  • Android-> GATT-сервер ПОВІДОМЛЕННЯ / ЗАПИСЬ НЕ ВІДПОВІДЬ не можна надсилати часто більше 13 мс. Після втрати понад 13 мс в пакеті.

  • Сервер-> Android ПОВІДОМЛЕННЯ / ЗАПИСЬ НЕ ЗАВДАННЯ не можна надсилати часто, ніж 15 мс

  • Обидва сторони, ЧИТАТИ ПОКАЗНИК, як не можна викликати часто, ніж 15..20 мс.

Це призводить до 1000 мс / 13 мс -> 77 разів / секунду з 20 байт = 1500 октетів / секунду.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.