Truyền phát video bằng BLE hoặc Bluetooth 4.0 cổ điển?


10

BLE chỉ có tải trọng dữ liệu là 100Kb / giây, vì vậy tôi đã tự hỏi liệu có thể truyền phát video trực tiếp bằng Bluetooth Low Energy không?

Bluetooth cổ điển 4.0 có tải trọng dữ liệu là 2Mb / giây giúp truyền video dễ dàng hơn nhưng tôi lo ngại hơn về tổng công suất nên muốn triển khai BLE. Tôi có thể nhận được kết quả tương tự khi tôi sử dụng BLE để truyền phát video không?


1
Câu hỏi này đã lỗi thời đối với Bluetooth 5 đối với bộ điều khiển BLE với PHY 2M (bps).
ZX9

Câu trả lời:


12

BLE rất không phù hợp để phát trực tuyến băng thông trung bình (âm thanh hoặc video), vì nó được thiết kế để truyền một vài gói dữ liệu nhỏ và nhỏ với nhiều thời gian ngủ ở giữa. Đây là lý do tại sao nó được gọi là 'năng lượng thấp' chứ không phải 'năng lượng thấp' - nó làm giảm lượng picojoules mỗi bit cho các gói nhỏ đối với các tiêu chuẩn cạnh tranh. Các tiêu chuẩn khác chủ yếu sử dụng nhiều năng lượng hơn không phải vì chúng có bộ đàm kém hiệu quả hơn, mà vì ít nhất máy thu liên tục được cấp nguồn ngay cả khi có các khoảng trống tương đối lớn trong lưu lượng vô tuyến và vì một phần đáng kể các bit được truyền không phải là tải trọng mà thay vào đó là chi phí - tiêu đề giao thức, tổng kiểm tra, thậm chí chỉ trống không gian. BLE loại bỏ hầu hết các sức mạnh không cần thiết này. Nhưng nhớ bạn, nó không ' T kỳ diệu cải thiện việc sử dụng năng lượng của các máy thu phát khi chúng hoạt động. Và khi thực hiện chuyển video, các bộ thu phát liên tục được cấp nguồn. Bạn mất lợi thế lớn nhất của BLE.

Sự lựa chọn thiết kế này làm giảm chi phí về cơ bản ít như bạn muốn, nhưng cũng làm cho nó không có bất kỳ phương tiện phát trực tuyến nào được tích hợp sẵn như tái hợp gói, nhận chậm trễ và chuyển không đồng bộ. Bạn thực sự không có bất cứ thứ gì được tích hợp sẵn, BLE vẫn nguyên vẹn như bạn có thể truy cập vào giao diện không dây, có thể là nRF24 và TI CC2x00. Do đó, bạn sẽ cần thực hiện việc này trong phần mềm (trên vi điều khiển hoặc trên thiết bị người dùng của bạn) và điều này sử dụng nhiều năng lượng hơn nhiều so với việc bạn sử dụng giao thức được xây dựng có mục đích với các phương tiện phần cứng cho Bluetooth 3.0 EDR hoặc Wifi.

Điều này dẫn đến một quan niệm hơi trái ngược rằng một khi bạn bắt đầu có tốc độ dữ liệu âm thanh trở lên, Bluetooth Low Energy sẽ phụ thuộc vào việc triển khai của bạn, kém hiệu quả hơn gấp 2 lần so với Bluetooth 3.0 và khi bạn bước vào phạm vi megabit thì nó thực sự là kém hiệu quả hơn WiFi. Đây là lý do tại sao WiFi tồn tại - đó là phạm vi không dây được cho là, mặc dù hiện nay các bộ thu phát cho cả hai tiêu chuẩn tương đương nhau rất nhiều. WiFi chỉ có MIMO tùy chọn và đa dạng.

Vì vậy, ngay cả khi không xem xét - ít nhất là đối với video - giới hạn băng thông và phạm vi rất hạn chế mà Bluetooth áp đặt, bạn có thể không đạt được mục tiêu truyền video công suất thấp bằng phương pháp này.


8

Chà, với 100kb / giây, bạn có thể truyền phát video chất lượng thấp với kích thước của tem bài :-)

Không có bất kỳ độ chính xác nào, tôi sẽ tưởng tượng bạn muốn HD (thậm chí không phải là full HD) @ 30 khung hình / giây trong H264, với chuyển động trung bình (yếu tố 2), ước tính bitrate gần đúng có thể là:

(1280px * 720px) * 30 khung hình / giây * 2 * 0,07 ~ = 3800kb / giây

Vì vậy, bạn phải giảm điều này bằng một yếu tố 38 (ít nhất là!).

Giả sử bạn giải quyết với ~ 320x200 @ 15fps, bạn vẫn ở trên một chút ( băng thông lý thuyết , mong đợi ít hơn).


1
Hệ số chuyển động trung bình là gì? Và giá trị 0,07 là gì?
m.Alin 17/8/2016

@ m.Alin Có lẽ .07 là âm thanh?
ZX9

0

Tất cả các thử nghiệm của tôi đã kết thúc ở mức dưới 2000 octet / giây

Điều kiện tiên quyết:

  • Android: Nexus Gall Wax Tab 7 Android 6.0.1 (ứng dụng khách GATT)
  • Linux: R-PI + BCM20702A0 (máy chủ GATT)
  • NUCLEO-F411RE: BlueNRG (máy chủ GATT)

Tất cả các thử nghiệm tôi đã thực hiện giữa Android <-> Linux & Bunget, Android <-> Linux & Bleno, Android <-> ST-Micro Nucleus + blueNRG. Linux & NUCLEO chạy các máy chủ GATT. Android chủ yếu chạy ứng dụng khách GATT.

  • Android-> Máy chủ GATT THÔNG BÁO / VIẾT KHÔNG CÓ TRẢ LỜI không thể gửi thường xuyên hơn 13 ms. Ofthen hơn 13ms bị mất trong gói bị mất.

  • Máy chủ-> Thông báo / VIẾT Android KHÔNG CÓ TRẢ LỜI có thể được gửi thường xuyên hơn 15 ms

  • Cả hai mặt, CHỈ ĐỊNH ĐỌC, vì không thể được gọi thường xuyên hơn 15..20 ms.

Điều đó dẫn đến 1000ms / 13ms -> 77 lần / giây 20 byte = 1500 octet / giây.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.