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

12

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

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

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

user934070
источник
4
Какой тип радиосвязи находится между UART и антенной?
jpc

Ответы:

14

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

  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 бесконечно повторяет передачу сотнями попыток в секунду)

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

Supercat
источник
8

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

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

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

Пол Р
источник
2
Основным ограничением предотвращения столкновений является то, что нет гарантии того, что предполагаемые передатчики будут в пределах диапазона приема друг друга, даже если они оба находятся в пределах диапазона приема их предполагаемой цели.
Суперкат
1
Предотвращение столкновений просто обеспечивает некоторое улучшение использования канала. Вы все еще должны сделать подтверждения и повторные передачи. Ключ должен ждать случайное время перед повторной передачей.
Дэвид Шварц
Самое главное, что это работает в режиме реального времени, а также это односторонняя связь. так что если мы сделаем это 2 пути, то это создаст больше помех. :(
user934070 13.09.11
ОК - тогда он никогда не будет надежным или надежным - вы можете прослушивать перед передачей, но кроме формы, что у вас никогда не будет никакой гарантии того, что передача действительно была получена.
Пол Р
4

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

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

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

Мартин
источник
Кроме того, я думаю, что вторая часть могла бы воспользоваться преимуществами CDMA, если бы они знали, что большинству станций обычно не нужно передавать.
Кортук
1
@Kortuk: у меня сложилось впечатление, что одним из преимуществ CDMA является то, что - если получатель может синхронизироваться с отправителем - количество ошибок в битах будет увеличиваться по мере увеличения количества одновременных передатчиков, но в противном случае нет "глушения" как такового.
Суперкат
@supercat, у меня сложилось впечатление, что каждый случайным образом распределяет временные интервалы. Большинство передатчиков говорят только изредка, поэтому вероятность одновременного разговора двух очень мала, но иногда это происходит и проявляется в виде небольшого количества ошибок в битах в этот момент. С чересстрочной разверткой и общим ECC вы можете почти игнорировать это. Тем не менее, каждый имеет заранее определенные временные интервалы, основанные на генераторе случайных чисел, чтобы гарантировать, что никакие два передатчика не занимают одно и то же пространство постоянно и встречаются лишь изредка. Я могу спросить кого-то, кто знает наверняка, и попросить его
войти
1
@Kortuk: Это то, что я привык думать, что имел в виду CDMA, но ряд источников, включая страницу Википедии, предполагают, что это относится к модуляции со скоростью, превышающей скорость передачи в битах; если передатчик инвертирует свой сигнал в соответствии с псевдослучайным потоком битов, и приемник делает то же самое, а затем фильтрует результирующий сигнал, исходный сигнал может быть восстановлен. Подходы, основанные на псевдослучайном временном интервале, полезны, но я не думаю, что CDMA - правильный термин. Самая большая трудность с такими подходами - координация. Я действительно хотел бы, чтобы был широко доступный сигнал времени с высоким разрешением.
Суперкат
1
@Kortuk: WWV своего рода работает для синхронизации цифровых часов и часов, но отправка сигнала времени занимает минуту. Было бы намного приятнее, если бы были широко развернутые трансляции времени, которые можно было прочитать за 10 мс или меньше, и было гарантировано, что они находились в пределах некоторого небольшого допуска времени WWV в Колорадо (это означает, что в местоположении на расстоянии 1000 миль от местно ретранслируемой Временные трансляции должны вести WWV примерно на 5 мс).
суперкат
3

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

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

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

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

Rocketmagnet
источник
2

ВЧ связь с несколькими асинхронными передатчиками является сложной задачей. Чтобы обойти эти проблемы, мы много думали и разрабатывали стандарты 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.

Олин Латроп
источник
2
Все зависит от приложения. Это действительно довольно сложно, но в то же время из этого упражнения можно многому научиться. И то, чему он научится, - это универсальные законы, а не некоторые детали реализации.
jpc
9
«выход из вашей лиги» немного суров. Они немного над головой, и я видел, как люди в таком положении тратят год на решение проблем такого типа ... но это не значит, что они не могут получить совет и заставить его работать. Как сказал jpc, успех здесь может означать значительный скачок в понимании. Если бы они были моим сотрудником с этим вопросом (и я мог бы позволить себе время для урока), я бы подтолкнул их вперед и надеюсь, что они чему-то научатся.
Даррон
3
Это плохая услуга, когда люди приходят на этот сайт в поисках ответов, чтобы узнать о проблеме и решить ее, и вынуждены (посредством голосований) принять решение, которое они не просили или не могут использовать.
Джоэл Б
1
@JoelB upvotes не заставляют принимать ответ.
Крис Страттон
1

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

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

HzJavier
источник
Большое спасибо за предложения. Но на самом деле наша главная проблема заключается в том, что наша система работает в режиме реального времени, поэтому когда и откуда мы получим сигнал, совершенно непредсказуемо. Позвольте мне объяснить это более подробно. фактически все передатчики и приемники размещены в пределах своего диапазона, т.е. предположим, что их диапазон составляет 100 метров, тогда все присутствуют внутри 50 метров, поэтому любой сигнал, исходящий от одного передатчика, может достигать каждого узла, и снова любой сигнал может поступать в любое время. так как мы можем решить это ..
user934070
@ User934070 Системы сотовой связи и Wi-Fi обычно используют какой-то расширенный спектр или, по крайней мере, технологии, которые следуют одним и тем же базовым концепциям. Сотовые телефоны и ноутбуки, как вы описываете, «когда и откуда мы получим сигнал, абсолютно непредсказуемы»
Kellenjb