Как избежать помех в беспроводной связи?

Я работаю над системой беспроводной связи. Мы используем около 10 пар передатчика и приемника. Мы используем микроконтроллер atmega16 для кодирования и декодирования через порты USART.

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

Предположим, что один передатчик отправляет «SENDA», в то время как другой передатчик отправляет «GETTS», в то время как приемник не может получить надлежащие данные. Поскольку все передатчики и приемники работают на одной и той же частоте, возникают и такие помехи. Как я могу решить эту проблему?

Разработка работоспособного протокола радиочастотной связи может быть сложным, но образовательным занятием. Несколько дополнительных моментов для рассмотрения помимо сказанного:

1. На некоторых радиоустройствах для прослушивания сигнала требуется много энергии. При использовании многих, если не самых маленьких радиостанций, прослушивание в течение одной секунды потребует больше энергии, чем передача в течение миллисекунды; на некоторых радиостанциях прослушивание в течение миллисекунды может потребовать больше энергии, чем передача в течение миллисекунды. Если потребление тока не является проблемой, непрерывное прослушивание намного проще, чем прерывистое прослушивание; однако, если текущее потребление является проблемой, может потребоваться прерывистое прослушивание. Возможно, это не очень хорошая идея, пока вам не удастся добиться успеха с протоколом непрерывного прослушивания.
2. Прослушивание перед передачей может быть «вежливым», но это не так полезно с РЧ, как, например, с кабелем Ethernet. Сигнализация Ethernet разработана таким образом, что не только вероятно, что устройство, которое прослушивает перед передачей, обычно избегает столкновения, но также разработано так, что устройство, передача которого сталкивается с передачей другого устройства, практически гарантированно заметит. Радиопередача не предлагает такого обещания. Вполне возможно, что когда P хочет передать на Q, какое-то другое устройство X, которое находится ближе к Q, чем к P, будет передавать достаточно громко, чтобы помешать Q слышать передачу P, но не достаточно громко, чтобы P заметил. Единственный способ, которым P узнает, что Q, возможно, не получил свою передачу, состоит в том, что P не услышит ответ от Q.
3. Важно остерегаться проблемы консенсуса - гораздо больше с радиочастотами, чем с проводной сигнализацией. Если P отправляет Q, возможно, что Q услышит передачу P и отправит подтверждение, но P по разным причинам не услышит это подтверждение. Таким образом, необходимо быть очень осторожным, чтобы отличить повторные передачи от «новых» передач.

   Проблема консенсуса может быть особенно неприятной, если кто-то пытается экономить энергию, отключая приемники, когда они не нужны. Предположим, что два P и Q должны обмениваться данными каждые 10 секунд, поэтому они включаются, и P отправляет Q пакет. Q получает пакет, отправляет его подтверждение и - зная, что P не будет отправлять что-либо в течение почти десяти секунд, выключается. Если P не получит подтверждение Q, он передаст повторно; так как Q спит, однако, он не услышит ретрансляцию P. С точки зрения Q, это не имеет значения (он уже получил свои данные), но это означает, что независимо от того, сколько раз P повторяет попытку, у него не будет возможности узнать, что Q получил свой пакет (по крайней мере, до следующего свидания в десять секунд).

4. Вполне возможно иметь ситуацию, в которой узел Q будет способен принимать передачи от P, но P не сможет принимать передачи от Q. В таких сценариях может оказаться невозможным с пользой общаться, но следует, по крайней мере, попытаться чтобы избежать каких-либо неприятных действий (например, когда P бесконечно повторяет передачу сотнями попыток в секунду)

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

Если вы не используете стандартный протокол для этого, вам придется спроектировать и реализовать его, например, простой пример:

• перед передачей узел должен прослушать, чтобы убедиться, что канал свободен
• если после передачи сообщения подтверждение не получено, узел должен подождать случайный период времени и затем повторить попытку, увеличив максимальное количество попыток

Итак, что происходит, вы сначала пытаетесь избежать «глушения», сначала слушая, затем, если затор все еще происходит, вы обнаруживаете это через отсутствие подтверждения от принимающего узла, а затем пытаетесь снова после случайной задержки - два передатчика глушения будут используйте разные случайные задержки, сводя к минимуму вероятность второго столкновения.

Вот два общих варианта

1) Реализовать алгоритм «Слушай перед разговором» (LBT), который проверяет, идет ли передача в процессе, прежде чем начать свою собственную, и, если да, откатывается на некоторое время. Период должен содержать фиксированную длину и случайную длину, чтобы они не отступали за один и тот же период. Многие стандартные радиопротоколы включают эту процедуру, см. ETSI EN 300-220-1.

2) Внедрить систему маяков, где передачи будут синхронизированы с маяком. Каждый передатчик получает свой собственный временной интервал. Обычно вы используете серийные номера в устройствах для определения их слота, и у вас есть система для определения того, кто посылает маяк. Поскольку это зависит от всех передатчиков, имеющих разные слоты, не стоит оставлять пользователю уникальную возможность идентифицировать все передатчики, если только у вас нет для этого четкой процедуры.

Как я понимаю из комментариев и т. Д., Мощность - это не проблема, а скорость связи. Итак, вот мое предложение для протокола.

Количество всех узлов, 0..n-1. Пусть каждый узел знает, какой это номер. Узел 0 будет хозяином.

Каждые 15 мс узел 0 отправляет сообщение: «0HELO».
Через 1 мс узел 1 отправляет сообщение: «1DATA».
Через 1 мс узел 2 отправляет сообщение: «2NICE».
Через 1 мс узел 3 отправляет сообщение: «3». (Этому узлу нечего сказать)
Через 1 мс узел 4 отправляет сообщение: «2CATS».
...
1мс позже, узел 9 посылает сообщение: «9MICE».
Затем наступает пауза в 5 мс.

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

ВЧ связь с несколькими асинхронными передатчиками является сложной задачей. Чтобы обойти эти проблемы, мы много думали и разрабатывали стандарты 802.11 и 802.15. Если вам нужно спросить здесь, то вам следует придерживаться стандартного оборудования, которое реализует один из этих стандартов.

Обратите внимание на то, что, хотя оба они полезны и представляют много тщательного проектирования, в общем случае любое реальное приложение все равно должно будет реализовать стек протоколов выше этих стандартов. Это будет Wi-Fi и TCP выше 802.11 и Zigbee или Wi-Fi Microchip или некоторые другие выше 802.15.

Опять же, проектирование многоточечной радиосети является выходом из вашей лиги, если вы задаете такие основные вопросы здесь. Вы просто потратите много времени, и все не всегда будет работать правильно.

Выбор 802.11 по сравнению с 802.15 зависит главным образом от вашей пропускной способности, требований к диапазону и доступной мощности. 802.15 меньше, меньше мощность, меньшая пропускная способность и меньший диапазон. При правильном программном обеспечении более высокого уровня устройство 802.15 может долгое время работать от батарей, в то время как, как правило, это не так для 802.11.

Я согласен с прослушиванием перед разговором и системой маяка. Но если вы хотите использовать один канал для передачи данных в одно и то же время, вы можете использовать метод модуляции прямого спектра с расширенным спектром (DSSS). Это может помочь вам избежать вмешательства.

Но для этого вам, возможно, потребуется купить чип, который его реализует, например, Xbee (на основе Zigbee). Если вы не можете изменить свой передатчик, вы должны придерживаться других ответов.