Як уникнути втручання в бездротовий зв’язок?

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

Тепер ми маємо змогу передавати дані та отримувати те саме в кінці приймача, але існує велика проблема, коли ми знаходимо 2 дані передавача, що надходять одночасно. Одержувач не може отримати його через перешкоди.

Припустимо, один передавач посилає "SENDA", тим часом інший передавач посилає "GETTS", і тоді приймач не може отримувати належних даних. Оскільки всі передавачі та приймачі працюють з однаковою частотою, то така перешкода відбувається. Як я можу вирішити цю проблему?

Розробка працездатного протоколу зв’язку РФ може бути складним, але навчальним вправою. Кілька додаткових моментів, які слід врахувати понад сказане:

1. На деяких радіоапаратурах для прослуховування сигналу потрібно багато сил. У багатьох, якщо не в більшості малих радіостанцій, прослуховування секунди забирає більше енергії, ніж передача на мілісекунду; на деяких радіостанціях прослуховування мілісекунди може зайняти більше енергії, ніж передача на мілісекунду. Якщо споживання струму не є проблемою, безперервне прослуховування набагато простіше, ніж прослуховування з перервами; якщо споживання струму є проблемою, однак, можливо, доведеться слухати його з перервами. Напевно, це не дуже гарна ідея, поки вам не вдалося домогтися чогось із протоколом безперервного прослуховування.
2. Прослуховування перед передачею може бути "ввічливим", але це ніде не так корисно з RF, як, наприклад, з 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, щоб обійти ці проблеми. Якщо вам доведеться запитати тут, вам слід дотримуватися обладнання, що реалізує один із цих стандартів.

Зауважте, що хоча обидва є корисними та представляють багато ретельної конструкції, як правило, будь-якій реальній програмі все одно доведеться реалізувати стек протоколу вище цих стандартів. Це буде WiFi та TCP вище 802.11, а Zigbee або WiWi Microchip або деякі інші вище 802.15.

Знову ж таки, проектування багатоточкової радіомережі - це вихід з вашої ліги, якщо ви задаєте тут основні питання. Ви просто витратите багато часу, і все одно не завжди буде правильно.

Вибір 802.11 проти 802.15 залежить в основному від вашої пропускної здатності та діапазону, а також від доступної потужності. 802.15 - менша, менша потужність, менша пропускна здатність і менший діапазон. Завдяки правильному програмному забезпеченню більш високого рівня, пристрій 802.15 може довго працювати від батарей, тоді як це, як правило, не стосується 802.11.

Я погоджуюсь із прослуховуванням перед розмовою та системою маяків. Але якщо ви хочете одночасно використовувати один канал для передачі даних, ви можете використовувати модуляцію модуляції прямого послідовності спектру (DSSS). Це може допомогти вам уникнути втручання.

Але для цього вам, можливо, потрібно придбати чіп, який реалізує його, наприклад Xbee (заснований на Zigbee). Якщо ви не можете змінити передавач, слід дотримуватися інших відповідей.