RC kumandalarda kullanılan veri iletişim protokolü nasildir ?
Protokol konusunu biraz daha irdelemeden önce "encapsulation" ve "modulation" terimlerine biraz açıklık getirmenin faydalı olacağını düşünüyorum.
Diyelim ki bir mektup yazdınız ve bunu ilk önce mektup zarfının içine koydunuz. Asıl göndermek istediğiniz veri olan kağıdın üzerindeki bilgi, mektup zarfının içine girerek paketlenmiş oldu. Yani "encapsulation" uygulanmış oldu. Daha sonra kargo veya kurye şirketinin poşetine koydunuz ve bir daha "encapsulation" uygulanmış oldu. Sıra ile büyük bir posta çuvalı, ve daha sonra kargo kamyonunun kasasına girerek tekrar "encapsulation" uygulanmış oldu. Mektubun hızlı kurye, gemi ile gönderi, uçak ile gönderi v.b. metotlar arasında farklı "encapsulation" işlemlerine tabi olacağı aşikardır. Ama nihai varış noktasına ulaşana kadar hiç "modulation" işlemine uğramaz.
Peki ne zaman "modulation" işlemine uğrar ?
Aynı bilgiyi telgraf olarak göndermek istediğinizi, ve de bir "Red Kit" çizgi filminin içinde olduğunuzu düşünün. Bunu belirtmemin nedeni, zihin cimnastiği yaparken olayı mümkün olduğunca basite indirgeyerek, zaten eski teknolojilerin evrimleşmiş hali olan günümüz teknolojilerindeki detayların, kafa karıştırmasını önlemek... Sizin düz kağıda yazdığınız bilgi, telgraf operatörüne ulaşana kadar, zarf v.b. gibi paketler vasıtası ile "encapsulation" işlemine tabi olur. Fakat telgraf operatörünün eline ulaştığında MORS KODU olarak "modulation" işlemine uğrar yani dönüştürülür. Karşı taraf ise kendine ulaşan MORS KODUNU demodulation işlemine uğratır. Ve tekrar düz yazı haline getirir. Ama burada dikkat edilmesi gereken bir nokta, her cümle ya da satırdan sonra, yazdığımız kağıtta hiç olmayan "STOP" datasının da mesaja eklendiğidir. Yani asıl datamız, güncel adı ile "STOP BITS" ya da "START BITS" adı verilen çeşitli başlık bilgileri eklenerek büyütülür. Bu başlık bilgileri, asıl verinin anlaşılabilir ve güvenilir olarak transfer edilebilmesi için gereklidir.
Yukarıdaki bilgileri şimdilik bir kenarda tutarak, gelelim WiFi protokolüne... WiFi protokolü, 13 adet sabit alt kanal kullanır. Ve de herkesin bildiği(ya da şu anda öğrendiği
) üzere, bir sabit kanalda aynı anda sadece bir tane veri olabilir yoksa parazit ya da çakışma dediğimiz durum ortaya çıkar. WiFi protokolünde bu durumun önüne geçebilmek için, "Carrier sense multiple access with collision avoidance(CSMA/CA)" denilen bir çakışma engelleme mekanizması kullanılır.
Bu LİNKİ görmek için izniniz yok. Giriş yap veya üye ol
Her bir WiFi istasyonu, ilgili kanalda veri olup olmadığını sezer ve kanal boşaldığı anda kendi verisini ilgili kanala gönderir. Biraz önce belirttiğim, WiFi protokolünde 13 adet alt kanal olmasına rağmen, frekans sarkmaları nedeni ile aynı anda kullanılabilecek alt kanal sayısı ise 3 tane ile sınırlıdır. Kabalalık bir ofiste iseniz, ve wifi üzerinde çok kişi bağlanıyorsa, ping süreniz arta ve bağlantı hızınız düşer. Özellikle helikopter gibi bir aleti, ortam kalabalıklaştıkça hızı düşenı ve "bekleme yapan" bir protokole emanet etmek ise bence çok mantıklı bir fikir değil. Ya farklı alt kanallar(maksimum 3 tane
) kullanacaksınız ya da hiç kullanmayacaksınız ...
Bu LİNKİ görmek için izniniz yok. Giriş yap veya üye ol
Ve birazda "connection-oriented" bir protokol olan ve IP protokolünün bir alt kümesi olan TCP protokolüne bakalım. TCP bağlantısı ile veriyi taşıyabilmek için, herşeyden önce, "3 Way handshake" denilen bir bağlantı işlemini gerçekleştirmeniz gerekir. "3 Way Handshake" işleminin kumanda ve alıcı arasında geçtiğini varsayarsak, işlem kısaca şöyle gerçekleşir.
- KUMANDA : Alıcıya SYN Paketi gönderir ve alıcıya, konuşmak istediğini belirtmiş olur.
- ALICI : Kumandaya ACK paketi gönderir ve alıcının konuşma istediğini aldığını belirtmiş olur.
- KUMANDA : SYN+ACK paketi göndererek, alıcının kendisini kabul ettiğini anladığını, ve konuşmaya başlayacağını belirtir.
Yukarıdakilerden sonra asıl veri tranferi başlar, ama ...
Standart TCP veri iletişiminde, maksimum paket boyutu 1500 byte'dır, bu 1500 byte'lık paketin 1460 byte'ı asıl veri, 40 baytı ise "alıcı adresi, verici adresi, gönderilen paketin kaçıncı paket olduğu v.b." bilgiler yer alır. Yukarıdaki ifadeden kısmen de anlaşılacağı üzere, TCP bağlantısında veriler maksimum 1460 byte'lık parçalara ayrılarak ve "SIRA NUMARASI" verilerek gönderilir. Eğer alıcı tarafında okunan paketlerde, sıra numarasının atlanmış olduğu farkedilirse, alıcı tarafı, eksik paketi yeniden talep eder(RETRANSMISSION).
Aslında TCP kısmını biraz fazla uzun yazdığımın farkındayım ama buradaki amacım, "connection-oriented" bir iletişim protokolünün belki FPV türü bir uçuşta kullanılabilir olsa da, neden özellikle helikopterler için uygun olmayacağını açıklamak.
Helikoterler çok hareketli aletlerdir. İhtiyaçları olan şey, düzenli olarak akan büyük bir veri değil, sadece anlık olarak çubuk pozisyonlarının bilgisidir. Eğer her seferinde TCP iletişimini yeniden başlatmaya kalkarsak, her seferinde "3 Way handshake" işlemini tekrar yapmak zorunda kalırız ki bu minimum 3
kat gecikme demek. Eğer veriyi tek ve kesintisiz bir akış olarak göndermeye kalkarsak, helikopterin hareketliliğinden dolayı oluşacak anlık paket kayıpları nedeni ile devamlı "RETRANSMISSION"lar oluşmaya başlar ve sonuç son derece kesintili ve güvenilirlikten uzak bir veri iletişimi olur.
"connection-oriented" protokolleri bir kenara atıp, işe connectionless "UDP" gibi bir protokol ile devam edelim. Özellikle online First person Shooter oynayan kişilerin bildiği üzere, oyun sunucularında iletişim için UDP tercih edilir ve de kablosuz ağ değil doğrudan kablolu ağ üzerinden oynamak en performanslı olanıdır, hele ki aynı anda bir kaç kişi sizin bulunduğunuz yerde ise...
UDP iletişiminde, paketin karşı tarafa varıp varmadığı ile alakalı olarak teyit alınmaz, dolayısı ile paketi gönderirsiniz ve o paketi unutursunuz, sadece yeni paketi hazırlamaya odaklanırsınız. Paket kayıpları oluşsa bile, ALICI taraf, önceki paketlerin karakteristiğini basit yazılımsal numaralar ile analiz ederek, kayıp paketi tolore edebilir. Ama tabii kayıplar yüksek boyutlara ulaşırsa, bu durum yazılımsal olarak tolore edilemez hale gelir. Bu durumda zaten, hangi protokolü kullanırsanız kullanın, paket kayıpları çok yüksekse, sorun protokol ile alakalı değil, kullandığınız donanım ile alakalıdır.
Bu durumda UDP, kullanılabilir bir protokol gibi dursa da xml, json, soap, csv ya da her ne kullanıyorsanız, kumandanın çubuklarından alacağınız her türlü bilgiyi tek bir UDP paketinin içine sığdırmak zorunda kalırsınız. Sığdırdınız diyelim. Sırada çözmeniz gereken en büyük sorun var. UDP protokolünü wifi ile gönderirseniz, bir alanda aynı anda sadece 3 kişi uçabilir. Spektrum markasının yaptığı bir tanıtımda, aynı anda 200 tane kumanda birbirleri ile çakışma yapmadan kullanılabiliyordu diye hatırlıyorum. Dolayısı ile ne yaparsanız yapın WiFi üzerinde geliştirmeye çalışacağınız bir protokol, Spektrum, Futaba, FrSky, Flysky, Walkera ve benzeri markaların halihazırda yapabildikleri bu yetenekleri yüzünden açıkça ezilir ...
Bütün bunların yanında, ethernet ve wifi protokolleri, paketleri oluşturmak ve çözmek için güçlü ve özelleştirilmiş MCU'lara ihtiyaç duyar. Bu durum, yapacağınız protokole ait alıcının hem pahalı, hem ağır hem de daha fazla güç harcamasına yol açacaktır. Yeteneklerinin, yukarıdaki açıkladığım sebeplerden dolayı kısıtlı olması da cabası...
O zaman elimizde, modülasyon olarak kullanabileceğimiz FHSS, DSSS ve de artık terkedilmiş olsa da FM modülasyonlarından başka bir şey kalmıyor. Frekans kirliliği ve parazite karşı kendisini askeri uygulamalarda bile kanıtlamış olan FHSS(tek başına basit şifreleme amacı ile bile kullanılmaktadır) ve DSSS modülasyonlarının altına ise, az işlemci gücü gereken, CRC ve benzeri hata düzeltme metotlarını destekleyen, data boyutu ufak olan, gerektiğinde sıkıştırılması ve açılması kolay bir metot yazmak ise IP protokolünü elediğimiz için en mantıklı seçenek olacaktır.
Aşağıda, Flysky protokolünün ele alındığı bir başlığı görebilirsiniz.
Bu LİNKİ görmek için izniniz yok. Giriş yap veya üye ol