Kablosuz iletişimde parazit nasıl önlenir?

Kablosuz iletişim sistemi üzerinde çalışıyorum. Yaklaşık 10 çift verici ve alıcı kullanıyoruz. USART portları tarafından kodlama ve kod çözme için atmega16 mikrodenetleyici kullanıyoruz.

Şimdi verileri iletebiliyoruz ve aynısını alıcı ucunda alabiliyoruz, ancak aynı anda gelen 2 verici verisini bulduğumuzda büyük bir sorun var. Alıcı parazit nedeniyle alamıyor.

Bir vericinin "SENDA" gönderirken, diğer bir vericinin "GETTS" gönderdiğini varsayalım, o zaman alıcı doğru verileri alamaz. Tüm vericiler ve alıcılar aynı frekansta çalıştığından, bu girişim meydana gelir. Bu sorunu nasıl çözebilirim?

Çalışılabilir bir RF iletişim protokolü geliştirmek zor ama eğitici bir egzersiz olmaya yatkındır. Söylenenlerin ötesinde düşünülmesi gereken birkaç ek nokta:

1. Bazı radyo donanımlarında, bir sinyali dinlemek çok fazla güç gerektirir. En küçük radyo olmasa da birçoğu ile, bir saniye dinlemek bir milisaniye için iletmekten daha fazla enerji alacaktır; bazı radyolarda, bir milisaniye dinlemek, bir milisaniye iletimden daha fazla enerji alabilir. Mevcut tüketim bir sorun değilse, sürekli dinlemek aralıklı olarak dinlemekten çok daha kolaydır; akım tüketimi bir sorun ise, aralıklı olarak dinlemek gerekebilir. Sürekli dinleme protokolü ile bir şey elde etmeyi başarana kadar muhtemelen iyi bir fikir değildir.
2. İletimden önce dinle "kibar" olabilir, ancak RF ile örneğin Ethernet kablosunda olduğu kadar kullanışlı değildir. Ethernet sinyallemesi, iletimden önce dinleyen bir cihazın genellikle bir çarpışmayı önleyeceği şekilde değil, aynı zamanda iletimi başka bir cihazınki ile çarpışan bir cihazın neredeyse fark edileceği garanti edilecek şekilde tasarlanmıştır. RF iletimi böyle bir vaatte bulunmaz. P, Q'ya iletmek istediğinde, Q'ya P'den daha yakın olan başka bir X cihazının, Q'nun P'nin iletimini duymasını engelleyecek kadar yüksek, ancak P'nin farkına varacak kadar yüksek olmayacağı tamamen mümkündür. P'nin Q'nun iletimini almamış olabileceğini bilmesinin tek yolu, P'nin Q'dan bir yanıt duymamasıdır.
3. Fikir birliği sorununa dikkat etmek önemlidir - RF ile tel sinyallemesinden çok daha fazla moreso. Bir P, Q'ya gönderirse, Q'nun P'nin iletimini duyacağı ve bir bildirim gönderebileceği, ancak P çeşitli nedenlerle bu bildirimi duyamayacağı anlamına gelir. Dolayısıyla, yeniden iletimleri "yeni" iletimlerden ayırmak için çok dikkatli olmak gerekir.

   Mutabakat problemi, ihtiyaç duyulmadığında alıcıları kapatarak enerji tasarrufu yapmaya çalışıyorsa özellikle can sıkıcı olabilir. Diyelim ki iki P ve Q'nun 10 saniyede bir iletişim kurması gerekiyor, bu yüzden güç veriyorlar ve P Q'ya bir paket gönderiyor. Q paketi alır, onayını gönderir ve - P'nin neredeyse on saniye boyunca hiçbir şey göndermeyeceğini bilerek kapanır. P, Q'nun onayını almazsa yeniden iletir; Ancak Q uykuda olduğu için P'nin yeniden iletimini duymaz. Q'nun bakış açısından, bu önemli değil (zaten verilerini aldı), ama P'nin kaç kez tekrarladığı fark etmeksizin, Q'nun paketini aldığını bilmenin hiçbir yolu olmayacak (en azından bir sonraki buluşma tarihine kadar) on saniye).

4. Q düğümünün P'den iletim alabileceği bir duruma sahip olmak tamamen mümkündür, ancak P Q'dan iletim alamaz. Bu tür senaryolarda yararlı bir şekilde iletişim kurmak mümkün olmayabilir, ancak en azından çaba gösterilmelidir. iğrenç bir şey yapmaktan kaçınmak için (P'nin şanzımanı saniyede yüzlerce yeniden denemeyi tekrar denemesi gibi)

Söylendiği gibi, uygulanabilir bir RF iletişim protokolü zor bir alıştırma olmaya eğilimlidir. Yine de, muhtemelen deneyimden çok şey öğreneceğinizi umuyorum.

Bunun için standart bir protokol kullanmıyorsanız, o zaman bir tane tasarlamak ve uygulamak zorunda kalacaksınız, örneğin basit bir örnek:

• iletimden önce, bir düğüm kanalın ücretsiz olup olmadığını kontrol etmelidir
• bir iletiyi ilettikten sonra bir onay alınmazsa, düğüm rastgele bir süre beklemeli ve sonra tekrar denemelidir, maksimum sayıda yeniden deneme

Öyleyse ilk önce dinleyerek "sıkışmadan" kaçınmaya çalışmanız, daha sonra bir sıkışma meydana gelmesi durumunda bunu alıcı düğümden onay eksikliği ile tespit edersiniz ve sonra rastgele bir gecikmeden sonra tekrar denersiniz - iki sıkışma vericisi ikinci bir çarpışma ihtimalini en aza indirerek farklı rastgele gecikmeler kullanın.

İşte iki yaygın seçenek

1) Kendi başınıza başlamadan önce iletimin sürüp sürmediğini kontrol eden ve bir süre sonra geri çekilen Konuşmadan Önce Dinle (LBT) algoritması uygulayın. Dönem sabit bir uzunluk ve rastgele bir uzunluk içermelidir, böylece hepsi aynı dönem boyunca geri çekilmez. Birçok standart radyo protokolü bu prosedürü içerir, bkz. ETSI EN 300-220-1.

2) Şanzımanların işaretten zamanlandığı bir işaret sistemi uygulayın. Her verici kendi zamanlama yuvasını alır. Yuvalarını belirlemek için normalde aygıtlarda seri numaraları kullanırsınız ve işaretçiyi kimin göndereceğini belirlemek için bir sisteminiz olur. Bu, farklı bir yuvaya sahip tüm vericilere dayandığından, bunun için sağlam bir prosedürünüz yoksa, tüm vericileri benzersiz bir şekilde tanımlamak için kullanıcıya bırakmak iyi bir fikir değildir.

Yorumlardan vb. Anladığım gibi, güç bir sorun değil, iletişim hızıdır. İşte bir protokol önerim.

Tüm düğümleri numaralayın, 0..n-1. Her düğümün hangi sayı olduğunu bilmesini sağlayın. 0 düğümü efendi olacaktır.

Her 15 ms'de, 0 düğümü bir mesaj gönderir: "0HELO".
1 ms sonra, düğüm 1 bir mesaj gönderir: "1DATA".
1ms sonra, düğüm 2 bir ileti gönderir: "2NICE".
1 ms sonra, düğüm 3 bir mesaj gönderir: "3". (Bu düğümün söyleyecek bir şeyi yoktur)
1 ms sonra, düğüm 4 bir mesaj gönderir: "2CATS".
...
1ms sonra, düğüm 9 bir mesaj gönderir: "9MICE".
Sonra 5 ms'lik bir duraklama var.

Düğümler, söyleyecek bir şeyleri olmasa bile, mesajlarını her zaman doğru zaman aralıklarında gönderirler. Bu şekilde, çarpışma olmadan 66Hz iletişim hızı garanti edilir.

Birden fazla asenkron vericiyle RF iletişimi zor bir sorundur. Bu sorunların üstesinden gelmek için birçok düşünce ve mühendislik 802.11 ve 802.15 standartlarına girdi. Burada sormak zorunda kalırsanız, bu standartlardan birini uygulayan raf donanımına bağlı kalmalısınız.

Her ikisi de yararlı olsa da ve çok dikkatli bir tasarımı temsil etse de, genellikle herhangi bir gerçek uygulamanın yine de bu standartların üzerinde bir protokol yığını uygulaması gerekecektir. Bu, 802.11'in üzerindeki WiFi ve TCP ve Zigbee veya Microchip'in WiWi veya 802.15'in üzerindeki diğerleri olabilir.

Yine, burada çok temel sorular soruyorsanız, çok noktalı bir radyo ağı tasarlamak liginizin dışındadır. Sadece çok zaman harcayacaksınız ve işler her zaman doğru çalışmayacak.

802.11 ve 802.15'in seçimi çoğunlukla bant genişliğiniz ve aralık gereksinimlerinize ve mevcut gücünüze bağlıdır. 802.15 daha küçük, daha düşük güç, daha düşük bant genişliği ve daha küçük aralıktır. Doğru yüksek seviye yazılımla, 802.15 cihazı pillerden uzun süre çalışabilirken, 802.11 için bu genellikle doğru değildir.

Konuşmadan önce dinleme ve işaret sistemini kabul ediyorum. Ancak aynı anda veri iletmek için tek bir kanal kullanmak istiyorsanız, doğrudan dizili yayılma spektrumu (DSSS) modülasyon tekniğini kullanabilirsiniz. Bu, girişimden kaçınmanıza yardımcı olabilir.

Ancak bunun için, onu uygulayan bir çip satın almanız gerekebilir, örneğin Xbee (Zigbee tabanlı). Vericinizi değiştiremiyorsanız, diğer yanıtlara bağlı kalmalısınız.