Công nghệ không dây tối ưu cho tốc độ dữ liệu cao và ứng dụng IoT có độ trễ thấp


8

Tôi đang dự định sử dụng Cảm biến định hướng tuyệt đối BNO055 để thu thập các phép đo gia tốc kế, từ kế và con quay cho một ứng dụng. Đến bây giờ tôi muốn dữ liệu được gửi ở tốc độ 10 Hz đến một thực thể thu thập dữ liệu (Pi hoặc BeagleBone với công nghệ không dây).

Thiết lập có thể là:

  • 3 điều IoT như vậy
  • 1 bộ sưu tập trung tâm Thing
  • Cấu trúc liên kết sao với điểm thu thập ở trung tâm

Theo kinh nghiệm của tôi, 802.11 WLAN dường như là lựa chọn tối ưu duy nhất trái ngược với 802.15.4 ZigBee và / hoặc Bluetooth LE (4.0) . Lý do là các bộ dữ liệu lớn mà BNO055 sẽ tạo và gửi với tốc độ rất nhanh (~ 0,1 giây ). Tôi chỉ tạo một nguyên mẫu đơn giản và do đó tôi muốn sử dụng UDP đơn giản để gửi dữ liệu ra ngoài.

Tôi hiện đang tập trung vào yếu tố phạm vi vì vị trí sẽ nằm trong thân thuyền và điều đó cũng ngụ ý rằng sẽ có sự mất mát dữ liệu đáng kể do bề mặt kim loại. Nhưng tôi có thể tự do chạy các nút trên toàn bộ năng lượng (được kết nối với nguồn điện hoặc pin Li-ION cao)

Câu hỏi:

  1. WLAN có phải là lựa chọn đúng đắn của công nghệ không dây cho ứng dụng không? Nếu không, tôi nên thử công nghệ nào khác?

  2. Điều gì có thể là những trở ngại có thể xảy ra đối với loại ứng dụng IoT có độ trễ thấp (10 Hz) như vậy mà tôi có thể tránh hoặc chú ý đến?


1
802.11 chắc chắn sẽ cung cấp cho bạn tốc độ dữ liệu phong phú. Là một phạm vi xem xét ở đây? Ngoài ra, bạn có biết cảm biến của bạn sẽ gửi bao nhiêu dữ liệu mỗi chu kỳ không?
nức nở

1
Là những thứ cạnh pin cung cấp năng lượng?
Helmar

@Helmar, tôi đoán bạn đang hỏi vì sử dụng WiFi trên các thiết bị chạy bằng pin sẽ tiêu hao chúng khá nhanh?
nức nở

Tôi hiện đang tập trung vào yếu tố phạm vi vì vị trí sẽ nằm trong thân thuyền và điều đó cũng ngụ ý rằng sẽ có sự mất mát dữ liệu đáng kể do bề mặt kim loại. Nhưng tôi có thể tự do chạy các nút trên toàn bộ sức mạnh (kết nối với nguồn điện hoặc pin Li-ION cao)
Shan-Desai

1
@ Shan-Desai Tôi đã chỉnh sửa câu hỏi của bạn để bao gồm những thông tin này. Luôn luôn thích có tất cả thông tin trong câu hỏi. Hãy thoải mái chỉnh sửa trong một hình thức nhiều hơn theo ý thích của bạn.
Helmar

Câu trả lời:


7

Độ trễ so với tỷ lệ

loại ứng dụng IoT có độ trễ thấp (10 Hz)

Đây là một lỗi khái niệm. Độ trễtỷ lệ phần lớn là độc lập. Bạn có thể có một hệ thống ghi lại hàng ngàn lượt đọc mỗi giây, lưu trữ chúng trên thẻ SD và mỗi tháng một lần ai đó truy cập trang web từ xa, trích xuất thẻ và gửi thư cho bạn - hệ thống đó sẽ có tốc độ cao nhưng cũng cực kỳ độ trễ . Hoặc bạn có thể có một hệ thống báo cáo các bài đọc trong vòng vài micro giây khi chúng được thực hiện, nhưng chỉ mất một lần đọc mỗi giờ.

Vì vậy, điều đầu tiên bạn sẽ cần làm là làm rõ yêu cầu của bạn - bạn có cần lấy nhiều dữ liệu hay bạn cần lấy nó trong khi nó vẫn còn rất hiện tại, hoặc cả hai?

Tốc độ cập nhật 10 Hz tương đối khả thi đối với hầu hết các sơ đồ truyền kỹ thuật số, ngoại trừ những nơi có giới hạn quy định về số lượng truyền trong một khoảng thời gian hoặc những nơi có tốc độ dữ liệu thấp như vậy (vì chúng là băng thông hẹp cho liên kết hiệu quả, hoặc vì chúng thô sơ) mà họ chỉ không thể di chuyển lượng dữ liệu bạn muốn gửi đủ nhanh.

Độ trễ so với độ tin cậy và độ phức tạp

Vì thời gian lan truyền thực tế trong các khu vực nhỏ đòi hỏi phải đo mạch kỳ lạ, đối với các hệ thống vô tuyến cục bộ, thời gian để di chuyển một thông điệp về cơ bản là thời gian để mã hóa nó - trừ khi các khía cạnh thiết kế hệ thống thêm nhiều hơn. Một hệ thống cần thực hiện nhiều "suy ngẫm" về một thông điệp có thể gây thêm độ trễ, mặc dù với phần mềm khá có thể sẽ nhẹ. Một yêu cầu một số chu kỳ "thảo luận" qua lại cho mỗi tin nhắn nhất thiết phải tăng thời gian bằng số chu kỳ và bất kỳ thời gian quay vòng nào của liên kết hoặc giao thức.

Nhưng nguồn chậm trễ có khả năng nhất là Lớp Độ tin cậy - nếu một thông báo bị thiếu hoặc bị hỏng, hệ thống phải làm gì? Nếu nó cố gắng một lần nữa, điều đó gần như luôn luôn có nghĩa là thêm độ trễ, trong khi nếu nó chỉ làm rơi tin nhắn và di chuyển trên đó có thể có nghĩa là khoảng trống.

Đối với loại ứng dụng của bạn, những gì có thể hoạt động tốt là một sơ đồ không đáng tin cậy , nhưng một trong đó mỗi gói không chỉ bao gồm một phép đo hiện tại, mà còn lặp lại một vài lần trước đó (hoặc cho một ứng dụng đếm, tổng số đang chạy). Và những điều đó không nhất thiết phải là các phép đo gần đây ngay lập tức - tùy thuộc vào các kiểu nhiễu, sơ đồ tốt nhất có thể dễ dàng kết thúc giống như hiện tại, trước đó, tiếp theo trước, thứ 5 trước, 13 trước hoặc bất cứ điều gì, để các gói thông qua có xu hướng có cơ hội cao bao gồm cả dữ liệu không có.

Hệ thống thực hành

Nhiều hệ thống 2,4 GHz ngoài luồng có thể sẽ hoạt động tốt trong ví dụ của bạn, nếu có các đường ngắm hợp lý hoặc đường dẫn rò rỉ giữa các thành phần.

  • nRF24L01 - radio kỹ thuật số 2,4 GHz kiểu cách sẽ dễ dàng xử lý tốc độ dữ liệu và dễ dàng được sử dụng để tạo ra các hệ thống nhảy kênh có độ trễ khá thấp - ví dụ, chúng và các đối thủ của chúng được sử dụng để bay tương tác nhiều máy bay không người tiêu dùng rẻ tiền.

  • BTLE có các chế độ với độ phức tạp trạng thái có thể có vấn đề, tuy nhiên chế độ quảng cáo đủ đơn giản và có thể được chạy ở loại tỷ lệ lặp lại mà bạn đang tìm kiếm. Các máy thu tùy chỉnh được xây dựng xung quanh các bảng nhúng như đề xuất của bạn sẽ có thể theo kịp và cung cấp cho bạn các chi tiết đầy đủ của mỗi gói. Ngoài ra còn có một số khả năng tương thích chéo với điện thoại thông minh, tuy nhiên trong trường hợp đó, hệ điều hành máy chủ có thể chỉ cung cấp cho bạn một lượng nhỏ lưu lượng và có thể không thông báo cho bạn khi nội dung gói thay đổi.

  • tất nhiên có nhiều sự lựa chọn khác

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.