Bagaimana cara menghindari gangguan dalam komunikasi nirkabel?

12

Saya sedang mengerjakan sistem komunikasi nirkabel. Kami menggunakan sekitar 10 pasang pemancar dan penerima. Kami menggunakan mikrokontroler atmega16 untuk encoding dan decoding oleh port USART.

Sekarang kami dapat mengirimkan data dan menerima yang sama di ujung penerima, tetapi ada masalah besar, ketika kami menemukan 2 data pemancar datang pada waktu yang sama. Penerima tidak dapat mendapatkannya karena gangguan.

Misalkan satu pemancar mengirim "SENDA" sementara itu pemancar lain mengirim "MENDAPATKAN", pada saat itu penerima tidak dapat menerima data yang tepat. Karena semua pemancar dan penerima bekerja dalam frekuensi yang sama, maka gangguan ini terjadi. Bagaimana saya bisa mengatasi masalah ini?

wireless interference

— pengguna934070
sumber

4

Jenis sirkuit radio apa yang berada di antara UART dan antena Anda?

— jpc

14

Mengembangkan protokol komunikasi RF yang bisa diterapkan sangat cocok untuk menjadi latihan yang rumit tetapi mendidik. Beberapa poin tambahan untuk dipertimbangkan di luar apa yang dikatakan:

Pada beberapa perangkat keras radio, dibutuhkan banyak daya untuk mendengarkan sinyal. Dengan banyak radio, jika tidak sebagian besar radio kecil, mendengarkan sebentar akan mengambil lebih banyak energi daripada mentransmisikan selama satu milidetik; pada beberapa radio, mendengarkan selama satu milidetik mungkin membutuhkan lebih banyak energi daripada mentransmisikan selama satu milidetik. Jika konsumsi saat ini tidak menjadi masalah, mendengarkan secara terus-menerus jauh lebih sederhana daripada mendengarkan secara terputus-putus; Namun, jika konsumsi saat ini menjadi masalah, mungkin perlu untuk mendengarkan sebentar-sebentar. Mungkin bukan ide yang bagus sampai Anda berhasil melakukan sesuatu dengan protokol yang terus-menerus mendengarkan.
Dengar-sebelum-mengirim mungkin "sopan", tapi itu sama sekali tidak berguna dengan RF seperti misalnya kabel Ethernet. Pensinyalan Ethernet dirancang sedemikian rupa sehingga tidak hanya kemungkinan bahwa perangkat yang mendengarkan sebelum mentransmisikan biasanya akan menghindari tabrakan, tetapi juga dirancang sedemikian rupa sehingga perangkat yang transmisinya bertabrakan dengan perangkat lain dijamin dijamin untuk diperhatikan. Transmisi RF tidak menawarkan janji semacam itu. Sangat mungkin bahwa ketika P ingin mentransmisikan ke Q, beberapa perangkat X lain yang lebih dekat ke Q daripada ke P akan mentransmisikan cukup keras untuk mencegah Q mendengar transmisi P, tetapi tidak cukup keras untuk P perhatikan. Satu-satunya cara P akan tahu bahwa Q mungkin tidak menerima transmisinya adalah dengan fakta bahwa P tidak akan mendengar jawaban dari Q.
Sangat penting untuk berhati-hati dengan masalah konsensus - lebih banyak dengan RF daripada dengan pensinyalan kawat. Jika P mengirim ke Q, ada kemungkinan bahwa Q akan mendengar transmisi P dan mengirim pemberitahuan, tetapi P karena berbagai alasan tidak mendengar pengakuan itu. Karena itu, perlu sangat berhati-hati untuk membedakan transmisi ulang dari transmisi "baru".
Masalah konsensus dapat sangat menjengkelkan jika seseorang mencoba menghemat energi dengan mematikan penerima ketika mereka tidak diperlukan. Misalkan dua P dan Q seharusnya berkomunikasi sekali setiap 10 detik, sehingga mereka menyala dan P mengirim Q paket. Q menerima paket itu, mengirimkan pengakuannya, dan - mengetahui bahwa P tidak akan mengirim apa pun selama hampir sepuluh detik, daya turun. Jika P tidak mendapatkan pengakuan Q, ia akan mengirim ulang; karena Q sedang tidur, bagaimanapun, dia tidak akan mendengar pengiriman ulang P. Dari perspektif Q, itu tidak masalah (dia sudah menerima datanya), tetapi itu berarti tidak peduli berapa kali P mencoba, dia tidak akan memiliki cara untuk mengetahui Q mendapatkan paketnya (setidaknya tidak sampai pertemuan berikutnya tentang sepuluh detik).
Sangat mungkin untuk memiliki situasi di mana simpul Q akan dapat menerima transmisi dari P, tetapi P tidak akan dapat menerima transmisi dari Q. Mungkin tidak mungkin untuk berkomunikasi secara bermanfaat dalam skenario seperti itu, tetapi kita harus setidaknya berusaha untuk menghindari melakukan sesuatu yang menjengkelkan (seperti membuat P mencoba ulang transmisi ratusan retries per detik)

Seperti yang dikatakan, protokol komunikasi RF yang bisa diterapkan cenderung menjadi latihan yang rumit. Namun, saya berharap Anda mungkin akan belajar banyak dari pengalaman itu.

— supercat
sumber

8

Jika Anda tidak menggunakan protokol standar untuk ini, maka Anda harus merancang dan mengimplementasikannya, misalnya contoh sederhana:

sebelum mentransmisikan, sebuah node harus mendengarkan untuk memeriksa apakah salurannya gratis
jika setelah mengirim pesan, tidak ada pemberitahuan yang diterima, node harus menunggu periode waktu acak dan kemudian mencoba lagi, menaikkan jumlah maksimum beberapa percobaan ulang

Jadi yang terjadi adalah Anda pertama kali mencoba menghindari "kemacetan" dengan mendengarkan terlebih dahulu, kemudian jika kemacetan masih terjadi, Anda mendeteksi ini melalui kurangnya pengakuan dari node penerima dan kemudian mencoba lagi setelah penundaan acak - dua pemancar gangguan akan gunakan penundaan acak yang berbeda, meminimalkan kemungkinan tabrakan kedua.

— Paul R
sumber

2

Keterbatasan utama penghindaran tabrakan adalah bahwa tidak ada jaminan bahwa calon pemancar akan berada dalam jangkauan satu sama lain, bahkan jika mereka berdua dalam jangkauan jangkauan target yang dituju.

— supercat

1

Penghindaran tabrakan hanya memberikan beberapa peningkatan dalam pemanfaatan saluran. Anda masih harus melakukan ucapan terima kasih dan pengiriman ulang. Kuncinya adalah menunggu waktu acak sebelum transmisi ulang.

— David Schwartz

Yang paling penting adalah ini berfungsi secara real time dan juga komunikasi satu arah. jadi jika kita membuatnya 2 arah maka itu akan membuat lebih banyak gangguan. :(

— user934070

OK - itu tidak akan pernah menjadi kuat atau dapat diandalkan - Anda dapat mendengarkan sebelum mengirim tetapi bentuk terpisah bahwa Anda tidak akan pernah memiliki jaminan bahwa transmisi sebenarnya telah diterima.

— Paul R

4

Berikut adalah dua opsi umum

1) Terapkan algoritma Listen Before Talk (LBT), yang memeriksa apakah ada transmisi yang sedang berlangsung sebelum memulai sendiri, dan jika demikian, mundur untuk jangka waktu tertentu. Periode tersebut harus berisi panjang tetap dan panjang acak sehingga mereka tidak mundur untuk periode yang sama. Banyak protokol radio standar menyertakan prosedur ini, lihat ETSI EN 300-220-1.

2) Menerapkan sistem suar di mana transmisi diatur waktunya dari suar. Setiap pemancar mendapatkan slot waktu sendiri. Anda biasanya menggunakan nomor seri di perangkat untuk menentukan slotnya, dan memiliki sistem untuk menentukan siapa yang mengirim suar. Karena ini bergantung pada semua pemancar yang memiliki slot yang berbeda, itu bukan ide yang baik untuk menyerahkannya kepada pengguna untuk secara unik mengidentifikasi semua pemancar, kecuali Anda memiliki prosedur yang solid untuk ini.

— Martin
sumber

Sebagai tambahan, saya pikir Bagian dua dapat memanfaatkan CDMA jika mereka tahu sebagian besar stasiun biasanya tidak perlu mentransmisikan.

— Kortuk

1

@Kortuk: Saya mendapat kesan bahwa salah satu kelebihan CDMA adalah - jika penerima dapat disinkronkan dengan pengirim - jumlah kesalahan bit akan naik ketika jumlah pemancar simultan meningkat, tetapi sebaliknya ada tidak ada "gangguan" seperti itu.

— supercat

@ supercat, saya mendapat kesan bahwa semua orang mengalokasikan slot waktu secara acak. Kebanyakan pemancar hanya berbicara sesekali sehingga kemungkinan dua berbicara pada saat yang sama sangat kecil, tetapi kadang-kadang terjadi dan muncul sebagai sejumlah kecil kesalahan bit pada saat itu. Dengan interlacing dan ECC umum Anda bisa mengabaikannya. Yang mengatakan, setiap orang memiliki slot waktu yang telah ditentukan berdasarkan generator nomor acak untuk memastikan tidak ada dua pemancar berbagi ruang yang sama secara konstan dan hanya sesekali bertemu. Saya bisa bertanya kepada seseorang yang tahu pasti dan meminta mereka masuk.

— Kortuk

1

@Kortuk: Itulah yang saya pikir dimaksudkan CDMA, tetapi sejumlah sumber, termasuk halaman Wikipedia, menyarankan bahwa itu merujuk pada modulasi pada kecepatan yang lebih tinggi daripada laju bit; jika pemancar membalikkan sinyalnya sesuai dengan bitstream pseudo-acak, dan penerima melakukan hal yang sama dan kemudian menyaring sinyal yang dihasilkan, sinyal asli dapat dipulihkan. Pendekatan berdasarkan slot waktu pseudo-acak berguna, tetapi saya tidak berpikir CDMA adalah istilah yang tepat. Kesulitan terbesar dengan pendekatan semacam itu adalah koordinasi. Saya benar-benar berharap ada sinyal waktu resolusi tinggi yang tersedia secara luas.

— supercat

1

@Kortuk: WWV agak berfungsi untuk menyinkronkan jam digital dan jam tangan, tetapi butuh satu menit untuk mengirimkan sinyal waktu. Akan jauh lebih baik jika ada siaran waktu yang disebarkan secara luas yang dapat dibaca dalam 10 ms atau kurang dan dijamin berada dalam toleransi kecil waktu WWV tertentu di Colorado (yang berarti bahwa pada lokasi 1.000 mil jauhnya yang disiarkan secara lokal waktu siaran sebenarnya harus memimpin WWV sekitar 5ms).

— supercat

3

Seperti yang saya pahami dari komentar dll, kekuatan bukanlah masalah, tetapi kecepatan komunikasi. Jadi, inilah saran saya untuk sebuah protokol.

Beri nomor semua node, 0..n-1. Biarkan setiap simpul tahu nomor mana itu. Node 0 akan menjadi master.

Setiap 15ms, simpul 0 mengirim pesan: "0HELO".
1ms kemudian, simpul 1 mengirim pesan: "1DATA".
1ms kemudian, simpul 2 mengirim pesan: "2NICE".
1ms kemudian, simpul 3 mengirim pesan: "3". (Simpul ini tidak ada artinya)
1ms kemudian, simpul 4 mengirim pesan: "2CATS".
...
1ms kemudian, simpul 9 mengirim pesan: "9MICE".
Lalu ada jeda 5ms.

Node selalu mengirim pesan mereka di slot waktu yang benar, bahkan jika mereka tidak punya apa-apa untuk dikatakan. Dengan cara ini Anda dijamin kecepatan komunikasi 66Hz, tanpa tabrakan.

— Roket
sumber

2

Komunikasi RF dengan beberapa pemancar asinkron adalah masalah yang rumit. Banyak pemikiran dan rekayasa masuk ke standar 802.11 dan 802.15 untuk mengatasi masalah ini. Jika Anda harus bertanya di sini, maka Anda harus tetap berpegang pada perangkat keras rak yang mengimplementasikan salah satu standar ini.

Perhatikan bahwa meskipun keduanya berguna dan mewakili banyak desain yang cermat, umumnya setiap aplikasi nyata masih harus menerapkan tumpukan protokol di atas standar ini. Ini akan menjadi WiFi dan TCP di atas 802.11 dan Zigbee atau MicroWip WiWi atau yang lain di atas 802.15.

Sekali lagi, merancang jaringan radio multi-point jauh dari kemampuan Anda jika Anda mengajukan pertanyaan mendasar semacam itu di sini. Anda hanya akan menghabiskan banyak waktu dan segala sesuatunya tidak akan selalu berhasil.

Pilihan 802.11 versus 802.15 sebagian besar tergantung pada bandwidth dan persyaratan jangkauan serta daya yang tersedia. 802.15 lebih kecil, daya lebih rendah, bandwidth lebih rendah, dan jangkauan lebih kecil. Dengan perangkat lunak tingkat tinggi yang tepat, perangkat 802.15 dapat berjalan lama dari baterai, sedangkan itu umumnya tidak benar untuk 802.11.

— Olin Lathrop
sumber

2

Itu semua tergantung aplikasi. Memang sangat sulit tetapi pada saat yang sama banyak yang dapat dipelajari dari latihan ini. Dan hal-hal yang akan dia pelajari adalah hukum universal dan bukan beberapa detail implementasi spesifik.

— jpc

9

"jalan keluar dari liga Anda" agak keras. Mereka berada di atas kepala mereka agak, dan saya telah melihat orang-orang dalam posisi seperti ini menghabiskan satu tahun pada masalah jenis ini ... tetapi itu tidak berarti mereka tidak dapat menerima saran dan membuatnya bekerja. Seperti kata jpc, sukses di sini bisa berarti lompatan yang signifikan dalam pemahaman. Jika mereka adalah karyawan saya dengan pertanyaan ini (dan saya dapat memberikan waktu untuk pelajaran) saya akan mendorong mereka dan berharap mereka belajar sesuatu.

— darron

3

Ini merugikan ketika orang-orang datang ke situs ini mencari jawaban untuk belajar tentang dan menyelesaikan masalah dan dipaksa (oleh upvotes) menjadi solusi yang tidak mereka minta atau tidak bisa gunakan.

— Joel B

1

Suara positif @ JoelB tidak memaksa penerimaan jawaban.

— Chris Stratton

1

Saya setuju dengan mendengarkan sebelum berbicara dan sistem suar. Tetapi jika Anda ingin menggunakan saluran tunggal untuk mentransmisikan data pada saat yang sama Anda bisa menggunakan teknik modulasi direct-sequence spread spectrum (DSSS). Ini bisa membantu Anda menghindari gangguan.

Tetapi untuk ini, Anda mungkin perlu membeli chip yang mengimplementasikannya, misalnya Xbee (berdasarkan Zigbee). Jika Anda tidak dapat mengubah pemancar Anda, Anda harus tetap berpegang pada jawaban lainnya.

— HzJavier
sumber

Terima kasih banyak atas sarannya. Tetapi, sebenarnya masalah utama kami adalah bahwa sistem kami bekerja secara real time, jadi kapan dan dari mana kami akan mendapatkan sinyal sama sekali tidak dapat diprediksi. Biarkan saya jelaskan lebih terinci. sebenarnya semua pemancar dan penerima ditempatkan dengan jangkauan mereka yaitu misalkan jangkauan mereka adalah 100 meter maka semua ada di dalam 50 meter sehingga, setiap sinyal yang keluar dari satu pemancar dapat mencapai ke setiap node dan lagi sinyal dapat datang kapan saja. jadi bagaimana kita bisa menyelesaikan ini ,, ..

— user934070

@ User934070 Sistem telepon seluler dan wifi biasanya menggunakan spektrum sebaran atau setidaknya teknologi yang mengikuti konsep dasar yang sama. Ponsel dan laptop sama seperti yang Anda gambarkan "kapan dan dari mana kita akan mendapatkan sinyal sama sekali tidak dapat diprediksi"

— Kellenjb