Jak uniknąć zakłóceń w komunikacji bezprzewodowej?

Pracuję nad systemem komunikacji bezprzewodowej. Korzystamy z około 10 par nadajnika i odbiornika. Używamy mikrokontrolera atmega16 do kodowania i dekodowania przez porty USART.

Teraz jesteśmy w stanie przesyłać dane i odbierać je na końcu odbiornika, ale istnieje poważny problem, gdy znajdujemy 2 dane nadajnika przychodzące w tym samym czasie. Odbiornik nie może go uzyskać z powodu zakłóceń.

Załóżmy, że jeden nadajnik wysyła „SENDA”, podczas gdy inny nadajnik wysyła „GETTS”, w tym czasie odbiornik nie może odebrać odpowiednich danych. Ponieważ wszystkie nadajniki i odbiorniki pracują na tej samej częstotliwości, występują zakłócenia. Jak mogę rozwiązać ten problem?

Opracowanie funkcjonalnego protokołu komunikacji RF może być trudnym, ale edukacyjnym ćwiczeniem. Kilka dodatkowych kwestii do rozważenia poza tym, co zostało powiedziane:

1. W przypadku niektórych urządzeń radiowych słuchanie sygnału wymaga dużej mocy. Przy wielu, jeśli nie większości małych radiotelefonach, słuchanie przez sekundę zajmie więcej energii niż transmisja przez milisekundę; w niektórych radiotelefonach nasłuchiwanie przez milisekundę może wymagać więcej energii niż przesyłanie przez milisekundę. Jeśli pobór prądu nie stanowi problemu, ciągłe słuchanie jest znacznie prostsze niż słuchanie z przerwami; jeśli jednak zużycie prądu stanowi problem, konieczne może być przerywane słuchanie. Prawdopodobnie nie jest to dobry pomysł, dopóki nie uda ci się uzyskać czegoś z protokołem ciągłego nasłuchiwania.
2. Słuchaj przed transmisją może być „uprzejmy”, ale nie jest tak przydatny w przypadku RF, jak np. W przypadku kabla Ethernet. Sygnalizacja Ethernet jest zaprojektowana tak, że nie tylko jest prawdopodobne, że urządzenie, które nasłuchuje przed transmisją, zwykle uniknie kolizji, ale jest również zaprojektowane tak, że urządzenie, którego transmisja koliduje z transmisją innego urządzenia, jest praktycznie gwarantowane. Transmisja RF nie daje takiej obietnicy. Jest całkiem możliwe, że gdy P chce transmitować do Q, jakieś inne urządzenie X, które jest bliżej Q niż do P, będzie transmitować wystarczająco głośno, aby uniemożliwić Q usłyszenie transmisji P, ale nie wystarczająco głośno, aby P mógł to zauważyć. Jedynym sposobem, w jaki P będzie wiedział, że Q mógł nie odebrać jego transmisji, jest fakt, że P nie usłyszy odpowiedzi od Q.
3. Ważne jest, aby uważać na problem konsensusu - dużo więcej z RF niż z sygnalizacją przewodową. Jeśli P wysyła do Q, możliwe, że Q usłyszy transmisję P i wyśle ​​potwierdzenie, ale P z różnych powodów nie usłyszy tego potwierdzenia. Dlatego należy bardzo uważać, aby odróżnić retransmisje od „nowych” transmisji.

   Problem konsensusu może być szczególnie dokuczliwy, jeśli ktoś próbuje oszczędzać energię poprzez wyłączanie odbiorników, gdy nie są one potrzebne. Załóżmy, że dwa P i Q powinny komunikować się co 10 sekund, więc włączają się, a P wysyła Q pakiet. Q odbiera pakiet, wysyła potwierdzenie i - wiedząc, że P nie wyśle ​​niczego przez prawie dziesięć sekund, wyłącza się. Jeśli P nie otrzyma potwierdzenia Q, retransmituje; ponieważ Q śpi, nie usłyszy retransmisji P. Z punktu widzenia Q nie będzie to miało znaczenia (już otrzymał swoje dane), ale oznacza to, bez względu na to, ile razy P spróbuje ponownie, nie będzie w żaden sposób wiedział, że Q otrzymał swój pakiet (przynajmniej nie do następnego spotkania dziesięć sekund).

4. Jest całkowicie możliwa sytuacja, w której węzeł Q będzie mógł odbierać transmisje z P, ale P nie będzie mógł odbierać transmisji z Q. W takich sytuacjach może nie być możliwe użyteczne komunikowanie się, ale należy przynajmniej spróbować aby uniknąć robienia czegokolwiek okropnego (np. ciągłe ponawianie próby P transmisji setki prób na sekundę)

Jak powiedziano, praktyczny protokół komunikacyjny RF może być trudnym ćwiczeniem. Mimo to spodziewam się, że prawdopodobnie nauczysz się wiele z tego doświadczenia.

Jeśli nie używasz do tego standardowego protokołu, będziesz musiał zaprojektować i wdrożyć jeden, np. Prosty przykład:

• przed transmisją węzeł powinien nasłuchiwać, aby sprawdzić, czy kanał jest wolny
• jeśli po przesłaniu komunikatu nie zostanie odebrane potwierdzenie, węzeł powinien odczekać losowy okres czasu, a następnie spróbować ponownie, maksymalnie pewną liczbę ponownych prób

Tak więc dzieje się tak, że najpierw próbujesz uniknąć „zakleszczenia”, najpierw słuchając, a następnie, jeśli zakleszczenie nadal występuje, wykrywasz to przez brak potwierdzenia z węzła odbiorczego, a następnie próbujesz ponownie po losowym opóźnieniu - dwa zakłócające nadajniki używaj różnych losowych opóźnień, minimalizując ryzyko drugiej kolizji.

Oto dwie typowe opcje

1) Wdróż algorytm Listen Before Talk (LBT), który sprawdza, czy transmisja jest w toku przed uruchomieniem własnego, a jeśli tak, to wycofuje się na pewien czas. Okres powinien zawierać ustaloną długość i losową długość, aby nie wszystkie wycofały się w tym samym okresie. Wiele standardowych protokołów radiowych obejmuje tę procedurę, patrz ETSI EN 300-220-1.

2) Wdrożenie systemu sygnałów nawigacyjnych, w którym transmisje są synchronizowane z sygnałem nawigacyjnym. Każdy nadajnik ma własny przedział czasowy. Zwykle używasz numerów seryjnych w urządzeniach, aby określić ich gniazdo, i masz system do określania, kto wysyła sygnał nawigacyjny. Ponieważ zależy to od wszystkich nadajników mających inne gniazdo, nie jest dobrym pomysłem pozostawienie użytkownikowi jednoznacznej identyfikacji wszystkich nadajników, chyba że masz do tego solidną procedurę.

Jak rozumiem z komentarzy itp., Moc nie jest problemem, ale szybkość komunikacji jest. Oto moja propozycja protokołu.

Numeruj wszystkie węzły, 0..n-1. Poinformuj każdy węzeł, który to numer. Węzłem 0 będzie master.

Co 15 ms, węzeł 0 wysyła komunikat: „0HELO”.
1ms później węzeł 1 wysyła komunikat: „1DATA”.
1ms później węzeł 2 wysyła komunikat: „2NICE”.
1ms później węzeł 3 wysyła komunikat: „3”. (Ten węzeł nie ma nic do powiedzenia) 1
ms później, węzeł 4 wysyła komunikat: „2CATS”.
...
1ms później węzeł 9 wysyła komunikat: „9MICE”.
Następnie następuje przerwa 5ms.

Węzły zawsze wysyłają swoje wiadomości we właściwych przedziałach czasowych, nawet jeśli nie mają nic do powiedzenia. W ten sposób masz gwarancję szybkości komunikacji 66 Hz, bez kolizji.

Komunikacja RF z wieloma nadajnikami asynchronicznymi jest trudnym problemem. Wiele pomysłów i inżynierii przeszło na standardy 802.11 i 802.15, aby obejść te problemy. Jeśli musisz zapytać tutaj, powinieneś trzymać się z półki sprzętu, który implementuje jeden z tych standardów.

Zauważ, że chociaż oba są przydatne i reprezentują wiele starannego projektowania, generalnie każda rzeczywista aplikacja będzie musiała wdrożyć stos protokołów powyżej tych standardów. Mogłyby to być WiFi i TCP powyżej 802.11 oraz WiWi Zigbee lub Microchip lub niektóre inne powyżej 802.15.

Ponownie zaprojektowanie wielopunktowej sieci radiowej jest daleko od twojej ligi, jeśli zadajesz tutaj takie podstawowe pytania. Spędzisz dużo czasu, a rzeczy nie zawsze będą działać poprawnie.

Wybór standardu 802.11 zamiast 802.15 zależy głównie od przepustowości i zasięgu oraz dostępnej mocy. 802.15 to mniejszy, mniejszy pobór mocy, mniejsza przepustowość i mniejszy zasięg. Przy odpowiednim oprogramowaniu wyższego poziomu urządzenie 802.15 może długo pracować na bateriach, podczas gdy ogólnie nie jest to prawdą w przypadku 802.11.

Zgadzam się na słuchanie przed rozmową i system beacon. Ale jeśli chcesz użyć jednego kanału do jednoczesnego przesyłania danych, możesz użyć techniki modulacji z bezpośrednim sekwencją rozproszonego widma (DSSS). Może to pomóc w uniknięciu zakłóceń.

Ale w tym celu być może trzeba kupić układ, który go implementuje, na przykład Xbee (oparty na Zigbee). Jeśli nie możesz zmienić nadajnika, powinieneś trzymać się innych odpowiedzi.