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


10

Полезная нагрузка BLE составляет всего 100 Кбит / с, поэтому мне было интересно, можно ли передавать потоковое видео с помощью Bluetooth Low Energy?

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


1
Этот вопрос устарел для Bluetooth 5 для контроллеров BLE с PHY 2 М (бит / с).
ZX9

Ответы:


12

BLE очень непригоден для потоковой передачи даже со средней пропускной способностью (аудио или видео), поскольку он предназначен для передачи небольших и малых пакетов данных с большим количеством времени ожидания между ними. Вот почему он называется «с низким энергопотреблением», а не «с низким энергопотреблением» - он уменьшает количество пикоджоулей на бит для небольших пакетов по сравнению с конкурирующими стандартами. Другие стандарты в основном используют больше энергии не потому, что у них менее эффективные радиостанции, а потому, что, по крайней мере, приемник постоянно включен, даже когда в радиотрафике есть сравнительно огромные затишья, а также потому, что значительная часть передаваемых битов - это не полезная нагрузка, а издержки - заголовки протокола, контрольные суммы, даже просто пробел. BLE устраняет большинство из этих ненужных силовых розыгрышей. Но учти, это не t волшебным образом улучшают энергопотребление трансиверов, когда они активны. А при передаче видео трансиверы постоянно включаются. Вы теряете самое большое преимущество BLE.

Этот выбор конструкции уменьшает накладные расходы до практически любого необходимого вам размера, но также делает его не имеющим потоковые объекты встроенный изначально как рекомбинации пакетов, задержки подтверждения и асинхронной передачи. У вас на самом деле ничего нет встроенного, BLE настолько сырой, насколько вы можете добраться до беспроводного интерфейса, за исключением, может быть, nRF24 и TI CC2x00. В результате вам нужно будет делать это программно (либо на микроконтроллере, либо на вашем пользовательском устройстве), и это потребляет невероятно больше энергии, чем при использовании специально созданного протокола с такими аппаратными средствами, как Bluetooth 3.0 EDR или Вай-фай.

Это приводит к несколько нелогичному представлению о том, что, как только вы начинаете переходить на скорости передачи данных аудио-типа и выше, Bluetooth Low Energy становится, в зависимости от вашей реализации, примерно в 2 раза менее эффективным, чем Bluetooth 3.0, и когда вы попадаете в мегабитный диапазон, это существенно менее эффективен, чем WiFi. Вот почему существует WiFi - и, возможно, беспроводной диапазон, хотя в настоящее время приемопередатчики для обоих стандартов в значительной степени эквивалентны. WiFi просто имеет дополнительный MIMO и разнообразие.

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


8

Что ж, при скорости 100 кбит / с вы сможете передавать видео низкого качества размером с почтовую марку :-)

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

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

Таким образом, вы должны уменьшить это в 38 раз (по крайней мере!).

Скажем, вы согласны на ~ 320x200 при 15 кадрах в секунду, вы все еще немного выше ( теоретическая пропускная способность, ожидайте меньше).


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 мс в пакете потерялся.

  • Server-> Android УВЕДОМЛЕНИЕ / НАПИСАТЬ НЕТ ОТВЕТА не может быть отправлено часто, чем 15 мс

  • Обе стороны, READ INDICATOR, as не могут быть вызваны чаще, чем 15..20 мс.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.