Я работаю над системой беспроводной связи. Мы используем около 10 пар передатчика и приемника. Мы используем микроконтроллер atmega16 для кодирования и декодирования через порты USART.
Теперь мы можем передавать данные и получать то же самое на стороне получателя, но есть большая проблема, когда мы находим данные двух передатчиков, поступающие одновременно. Приемник не может получить его из-за помех.
Предположим, что один передатчик отправляет «SENDA», в то время как другой передатчик отправляет «GETTS», в то время как приемник не может получить надлежащие данные. Поскольку все передатчики и приемники работают на одной и той же частоте, возникают и такие помехи. Как я могу решить эту проблему?
wireless
interference
user934070
источник
источник
Ответы:
Разработка работоспособного протокола радиочастотной связи может быть сложным, но образовательным занятием. Несколько дополнительных моментов для рассмотрения помимо сказанного:
Проблема консенсуса может быть особенно неприятной, если кто-то пытается экономить энергию, отключая приемники, когда они не нужны. Предположим, что два P и Q должны обмениваться данными каждые 10 секунд, поэтому они включаются, и P отправляет Q пакет. Q получает пакет, отправляет его подтверждение и - зная, что P не будет отправлять что-либо в течение почти десяти секунд, выключается. Если P не получит подтверждение Q, он передаст повторно; так как Q спит, однако, он не услышит ретрансляцию P. С точки зрения Q, это не имеет значения (он уже получил свои данные), но это означает, что независимо от того, сколько раз P повторяет попытку, у него не будет возможности узнать, что Q получил свой пакет (по крайней мере, до следующего свидания в десять секунд).
Как уже было сказано, работоспособный протокол радиочастотной связи может оказаться непростым делом. Тем не менее, я ожидаю, что вы, вероятно, многому научитесь из этого опыта.
источник
Если вы не используете стандартный протокол для этого, вам придется спроектировать и реализовать его, например, простой пример:
Итак, что происходит, вы сначала пытаетесь избежать «глушения», сначала слушая, затем, если затор все еще происходит, вы обнаруживаете это через отсутствие подтверждения от принимающего узла, а затем пытаетесь снова после случайной задержки - два передатчика глушения будут используйте разные случайные задержки, сводя к минимуму вероятность второго столкновения.
источник
Вот два общих варианта
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). Если вы не можете изменить свой передатчик, вы должны придерживаться других ответов.
источник