Làm thế nào để tránh nhiễu trong giao tiếp không dây?

Tôi đang làm việc trên hệ thống truyền thông không dây. Chúng tôi đang sử dụng khoảng 10 cặp máy phát và máy thu. Chúng tôi đang sử dụng vi điều khiển atmega16 để mã hóa và giải mã bằng các cổng USART.

Bây giờ chúng tôi có thể truyền dữ liệu và nhận giống nhau ở đầu thu, nhưng có một vấn đề lớn, khi chúng tôi tìm thấy 2 dữ liệu truyền phát cùng lúc. Người nhận không thể có được nó do nhiễu.

Giả sử một máy phát gửi "SENDA" trong khi máy phát khác gửi "NHẬN", tại thời điểm đó, máy thu không thể nhận được dữ liệu thích hợp. Vì tất cả các máy phát và máy thu đều hoạt động ở cùng tần số, nên hiện tượng nhiễu này đang xảy ra. Làm thế nào tôi có thể giải quyết vấn đề này?

Phát triển một giao thức truyền thông RF khả thi là một bài tập khó nhưng mang tính giáo dục. Một vài điểm bổ sung để xem xét ngoài những gì đã nói:

1. Trên một số phần cứng radio, cần rất nhiều năng lượng để nghe tín hiệu. Với nhiều máy, nếu không phải là hầu hết các máy bộ đàm nhỏ, nghe trong một giây sẽ tốn nhiều năng lượng hơn truyền trong một phần nghìn giây; trên một số radio, nghe trong một phần nghìn giây có thể tiêu tốn nhiều năng lượng hơn truyền trong một phần nghìn giây. Nếu tiêu thụ hiện nay không phải là một vấn đề, nghe liên tục là một rất nhiều đơn giản hơn nghe không liên tục; nếu tiêu thụ hiện tại là một vấn đề, tuy nhiên, có thể cần phải nghe không liên tục. Có lẽ không phải là một ý tưởng tốt cho đến khi bạn quản lý để có được một cái gì đó đi với một giao thức nghe liên tục.
2. Nghe trước khi truyền có thể "lịch sự", nhưng nó không hữu dụng với RF như ví dụ như cáp Ethernet. Tín hiệu Ethernet được thiết kế sao cho không chỉ có khả năng một thiết bị nghe trước khi truyền thường sẽ tránh được xung đột mà còn được thiết kế sao cho một thiết bị có đường truyền va chạm với thiết bị khác hầu như được đảm bảo. Truyền RF không hứa hẹn như vậy. Hoàn toàn có thể khi P muốn truyền tới Q, một số thiết bị X khác gần Q hơn P sẽ truyền phát đủ lớn để ngăn Q nghe thấy truyền của P, nhưng không đủ lớn để P chú ý. Cách duy nhất P sẽ biết rằng Q có thể không nhận được đường truyền của mình là do P sẽ không nghe thấy phản hồi từ Q.
3. Điều quan trọng là phải cẩn thận với vấn đề đồng thuận - nhiều vấn đề với RF hơn là tín hiệu dây. Nếu một P gửi đến Q, có thể Q sẽ nghe truyền của P và gửi xác nhận, nhưng P sẽ vì nhiều lý do không nghe thấy xác nhận đó. Do đó, cần phải rất cẩn thận để phân biệt truyền lại với truyền "mới".

   Vấn đề đồng thuận có thể đặc biệt khó chịu nếu một người đang cố gắng tiết kiệm năng lượng bằng cách tắt nguồn máy thu khi không cần thiết. Giả sử cứ sau 10 giây, hai P và Q sẽ liên lạc với nhau, vì vậy chúng sẽ bật nguồn và P gửi Q một gói. Q nhận được gói tin, gửi xác nhận của mình và - biết rằng P sẽ không gửi bất cứ thứ gì trong gần mười giây, tắt điện. Nếu P không nhận được xác nhận của Q, anh ta sẽ truyền lại; Tuy nhiên, vì Q đang ngủ, anh ta sẽ không nghe thấy sự truyền lại của P. Từ quan điểm của Q, điều đó sẽ không thành vấn đề (anh ấy đã nhận được dữ liệu của mình), nhưng điều đó có nghĩa là cho dù P có thử lại bao nhiêu lần đi chăng nữa, anh ấy sẽ không có cách nào để biết Q nhận được gói của mình (ít nhất là cho đến lần gặp tiếp theo về mười giây).

4. Hoàn toàn có thể có một tình huống trong đó nút Q sẽ có thể nhận được truyền từ P, nhưng P sẽ không thể nhận được truyền từ Q. Có thể không thể giao tiếp hữu ích trong các tình huống như vậy, nhưng ít nhất người ta phải nỗ lực để tránh làm bất cứ điều gì đáng ghét (như P không ngừng thử lại hàng trăm lần thử lại mỗi giây)

Như đã nói, một giao thức truyền thông RF hoàn toàn khả thi là một bài tập khó. Tuy nhiên, tôi hy vọng bạn sẽ học được nhiều kinh nghiệm.

Nếu bạn không sử dụng giao thức chuẩn cho việc này thì bạn sẽ phải thiết kế và thực hiện một giao thức, ví dụ: một ví dụ đơn giản:

• trước khi truyền, một nút nên lắng nghe để kiểm tra xem kênh có miễn phí không
• nếu sau khi truyền tin nhắn không nhận được xác nhận, nút sẽ đợi một khoảng thời gian ngẫu nhiên và sau đó thử lại, tăng số lần thử tối đa

Vì vậy, điều xảy ra là trước tiên bạn cố gắng tránh "gây nhiễu" bằng cách lắng nghe trước, sau đó nếu vẫn xảy ra kẹt, bạn phát hiện ra điều này thông qua việc thiếu xác nhận từ nút nhận và sau đó thử lại sau một độ trễ ngẫu nhiên - hai máy phát gây nhiễu sẽ sử dụng độ trễ ngẫu nhiên khác nhau, giảm thiểu khả năng va chạm thứ hai.

Đây là hai lựa chọn phổ biến

1) Thực hiện thuật toán Nghe trước khi nói (LBT), kiểm tra xem có tiến trình truyền trước khi bắt đầu của riêng bạn hay không, và nếu vậy, hãy lùi lại trong một khoảng thời gian. Khoảng thời gian nên chứa một độ dài cố định và độ dài ngẫu nhiên để tất cả chúng không lùi lại trong cùng một khoảng thời gian. Nhiều giao thức vô tuyến tiêu chuẩn bao gồm quy trình này, xem ETSI EN 300-220-1.

2) Thực hiện một hệ thống đèn hiệu trong đó việc truyền được tính thời gian từ đèn hiệu. Mỗi máy phát có khe thời gian riêng. Thông thường bạn sẽ sử dụng số sê-ri trong các thiết bị để xác định vị trí của chúng và có một hệ thống để xác định ai gửi đèn hiệu. Vì điều này phụ thuộc vào tất cả các máy phát có một khe khác nhau, nên không nên để nó cho người dùng xác định duy nhất tất cả các máy phát, trừ khi bạn có một quy trình vững chắc cho việc này.

Theo tôi hiểu từ các ý kiến, vv, sức mạnh không phải là một vấn đề, nhưng tốc độ giao tiếp là. Vì vậy, đây là gợi ý của tôi cho một giao thức.

Đánh số tất cả các nút, 0..n-1. Cho mỗi nút biết đó là số nào. Nút 0 sẽ là chủ.

Cứ sau 15ms, nút 0 sẽ gửi một thông báo: "0HELO".
1ms sau, nút 1 gửi tin nhắn: "1DATA".
1ms sau, nút 2 sẽ gửi một thông báo: "2NICE".
1ms sau, nút 3 gửi tin nhắn: "3". (Nút này không có gì để nói)
1ms sau, nút 4 sẽ gửi một thông báo: "2CATS".
...
1ms sau, nút 9 gửi tin nhắn: "9MICE".
Sau đó là tạm dừng 5ms.

Các nút luôn gửi tin nhắn của họ trong các khe thời gian chính xác, ngay cả khi họ không có gì để nói. Bằng cách này, bạn được đảm bảo tốc độ liên lạc 66Hz, không có va chạm.

Giao tiếp RF với nhiều máy phát không đồng bộ là một vấn đề khó khăn. Rất nhiều suy nghĩ và kỹ thuật đã đi vào các tiêu chuẩn 802.11 và 802.15 để khắc phục những vấn đề này. Nếu bạn phải hỏi ở đây, thì bạn nên bỏ qua phần cứng kệ thực hiện một trong những tiêu chuẩn này.

Lưu ý rằng mặc dù cả hai đều hữu ích và thể hiện rất nhiều thiết kế cẩn thận, nhưng nhìn chung bất kỳ ứng dụng thực tế nào vẫn sẽ phải thực hiện một ngăn xếp giao thức trên các tiêu chuẩn này. Đây sẽ là WiFi và TCP trên 802.11 và Zigbee hoặc Microchip's WiWi hoặc một số loại khác trên 802.15.

Một lần nữa, thiết kế một mạng vô tuyến đa điểm sẽ thoát khỏi liên minh của bạn nếu bạn hỏi những câu hỏi cơ bản như vậy ở đây. Bạn sẽ chỉ mất rất nhiều thời gian và mọi thứ sẽ không luôn luôn hoạt động tốt.

Sự lựa chọn của 802.11 so với 802.15 phụ thuộc chủ yếu vào các yêu cầu về băng thông và phạm vi của bạn và sức mạnh sẵn có. 802.15 nhỏ hơn, công suất thấp hơn, băng thông thấp hơn và phạm vi nhỏ hơn. Với phần mềm cấp cao hơn phù hợp, thiết bị 802.15 có thể chạy rất lâu từ pin, trong khi điều đó thường không đúng với 802.11.

Tôi đồng ý với việc lắng nghe trước khi nói và hệ thống đèn hiệu. Nhưng nếu bạn muốn sử dụng một kênh duy nhất để truyền dữ liệu cùng một lúc, bạn có thể sử dụng kỹ thuật điều chế phổ trải chuỗi trực tiếp (DSSS). Điều này có thể giúp bạn tránh nhiễu.

Nhưng đối với điều này, bạn có thể cần phải mua một con chip thực hiện nó, ví dụ Xbee (dựa trên Zigbee). Nếu bạn không thể thay đổi máy phát của mình, bạn nên giữ nguyên các câu trả lời khác.