RC kumandalarda kullanılan veri iletişim protokolü nasildir ?

kiremith

Yeni Uye
Katılım
15 Kas 2015
Mesajlar
6
Tepkime puanı
0
Yaş
43
Merhaba arkadaşlar. Forumdaki ilk başlığımı forumu araştırıp bulamadığım (gözümden kaçtıysa affola) bir konu üzerine açıyorum.

Çeşit çeşit kumandalar ve bu kumandaların sahip olduğu kanallar var. 2.4ghz üzerinde çalışıyor geneli. Soruma gelmeden önce amacımı söylesem daha net olabilir sanırım. kendi kumandamı üretmek istiyorum. (zamanla diğer parçalar hatta anakart yazılımı).

Kumandaların alıcısıyla arasındaki network protokolü nedir ? Analog mudur dijital mi ? dijital ise bildiğimiz tcp/ip mi kullanır ? tcp mi udp mi ya da daha farklı bi protokol mü ?

not : eksiklerim, yanlış bildiklerim mutlaka vardır öğrenmek için buradayım.
 
Alıcı verici arasındaki protokol

RC kumandalarda kullanılan veri iletişim protokolünün, IP Protokol kümeleri(TCP, UDP, ICMP ve benzeri 100 kadar alt protokol ...) ile alakaları bulunmamakta. Temel yapı şu şekilde;

1 - Kumandalar üzerindeki çubuklar ve anahtarlar vasıtası ile kontrol girdisi alınır. Alınan kontrol girdisi, (çubuk pozisyonu, potansiyometre pozisyonu, anahtar pozisyonu) analogdur.

2 - Kontrol girdisi kullanılarak, iletilecek kanal sayısı kadar(6kanal, 8kanal v.b.) veriyi içeren bir sinyal dizisi oluşturulur. Çok genel olarak bu sinyal dizisi PPM denilen bir sinyaldir. RC iletişiminde genellikle, 22.5ms uzunluğa ve 0.3ms darbe başlangıç darbe uzunluğuna sahip, negatif kutuplamalı bir PPM sinyali kullanılır. PPM sinyali, dijital bir sinyaldir.

3 - Oluşturulmuş bu sinyal dizisi, transmitter(TX) modülüne gönderilir. TX modülüne gönderilmiş PPM sinyali, her markanın kendisine özel bir formatta işlenerek(start bit, stop bit, crc kontrolü, varsa telemetri eklentileri, çeşitli ek header bilgilieri v.b.), paketlenir ya da enkapsüle edilir. Buradaki en büyük sıkıntı nerede ise hiç bir markanın birbiri ile uyumlu olmamasıdır, tüm markalar veriyi farklı farklı işleyerek paketler. İlgili markanın protokolü uyarınca, PPM datasının işlenip paketlenmiş hali de hala dijital bir sinyaldir.

4 - Oluşturulmuş olan dijital sinyalin, havada taşınabilmesi için, uygun bir şekilde modüle edilip antene gönderilmesi gerekmektedir. Sinyalin kablosuz olarak taşınabilmesi çin en çok kullanılan iki yöntem Frequency Hopping Spread Spectrum(FHSS) ve Direct Sequence Spread Spectrum(DSSS) denilen, yöntemlerdir. Bu iki yöntemde de, alıcı ve verici tarafından aynı anda bilinen bir sıralama kullanılarak, veriler her seferinde farklı bir frekansta gönderilir. Bu şekilde sabit bir frekansta oluşabilecek(başka bir kumanda, wifi networkü ve bilinmeyen bir çok etken gibi...) parazit nedeni ile sinyal kaybı yaşanmasının önüne geçişmiş olunur. Yanlız buradada, her marka kendilerine özel FHSS ve DSSS varyantlarını kullanmaktadırlar ve birbirleri ile uyumlu değildirler.

5 - Alıcı tarafından okunan sinyal ters işlemlerden geçirilir fakat nihai ürün olarak, genellikle PPM sinyali değil PWM sinyali oluşturulur. PWM sinyali olarak, her bir ayrı kanala(servoya ya da motor+esc ikilisine ) gidecek sinyal oluşturulur. Bu PWM sinyali genellikle 50 Hz frekansındadır yani bir peryodu 20 milisaniye uzunluğundadır. Asıl veriyi taşıyan kısmı olan pozitif kutuplu darbenin uzunluğu ise 1000 mikrosaniye ve 2000 mikrosaniye arasında değişir. ESC veya servonun nasıl davranacağı, bu sürenin 1000 - 2000 mikrosaniyelik aralığın neresinde olduğu ile alakalıdır. Servo için konuşursak, 1000 mikrosaniye uzunluğunda bir darbe okuduğunda en sola yatık durur. 1500 mikrosaniye uzunluğunda bir darbe okuduğunda ortada durur. 2000 mikrosaniye uzunluğunda bir darbe okuduğunda ise en sağa yatık durur.

Yukarıda yazdıklarımdan farklı davranan çeşitli iletişim yöntemleri de vardır. Ama hemen hemen, yukarıda yazdığım mantık çerçevesinde geliştirilmişlerdir. Yani diğerlerini anlamak için yukarıdakileri anlayabiliyor olmanız gerekiyor.

PPM ve PWM sinyalini anladığınız takdirde anakart yapımı çok zor değil, hatta forumumuzda örnekleri bile var.

Ekranlı bir kontrolcünün/anakartın nasıl yapılabileceği ile ilgili değerli büyüğümüz Sümer abi tarafından yapılmış olan DIY Lövye projesini inceleyebilirsiniz.


Sadece inputlardan alınan verinin işlenerek PPM sinyali oluşturulması ile ilgili olarak bana ait simulatör kumandası projesini de inceleyebilirsiniz


PPM sinyali oluşturma kısmından sonraki, sinyali işleme ve kablosuz olarak gönderme(FHSS ve DSSS yerine düz FM bile olabilir ...) kısmı ile ilgili çok bilgi veremem ama o bilgiler için ise aşağıdaki kaynakları inceleyebilirsiniz.



Yukarıdakilerin haricinde ek bilgiler için aşağıdaki linkleri deneyebilirsiniz




 
Alıcı verici arasındaki protokol

Konu ilginç ve güzel. Benim de üzerinde zaman zaman düşündüğüm bir konu.
Ama...
Böylesine ciddi bir konuyu "kire mtih" ile değil adını soyadını bildiğim bir arkadaşımla tartışmayı tercih ederim. Herkesin kendi tercihidir, saygı duyarım ama bu da benim tercihim. Kusura bakmayın lütfen.
 
Alıcı verici arasındaki protokol

Zafer hocam verdiğiniz bilgiler için çok teşekkürler. kumanda üzerindeki stick ve diğer butonlardan alınan analog veriler daha sonra alıcıya dijital aktarılıyor. Anladığım kadarıyla paket tipleri her markada değişiyor bunun böyle olmasını açıkcası anlamlandıramadım. Oturmuş protokoller varken neden her marka kendi paket tipini yaratmış ki ? bunun yerine tcp paketler kullanılıp aktarılcak veri xml olur json olur farklı veri tipleri olur bu şekilde yollansaydı, kanal sayısı sıkıntısı ortadan kalkmaz mıydı ?

örnek xml :

<kanallar>
<kanal1 name="yukari">25</kanal1>
<kanal2 name="saga">20</kanal2>
<kanal3 name="onfarlar">1</kanal3>
....
</kanallar>

gibi olsaydı analoga bağlı kalmasaydık, alıcı ve verici üzerinde ki kanal sayısı farklarından dolayı az olanı kullanma zorunluluğu olmasaydı daha iyi olmaz mıydı ? performans problemi mi yaratırdı ? (diğerine göre daha yavaş olacaktır ancak tolere edilemicek seviyede olur muydu ?)

not : xml örnek olarak verilmiştir hiç sevmem.




Sümer Yamaner' Alıntı:
Konu ilginç ve güzel. Benim de üzerinde zaman zaman düşündüğüm bir konu.
Ama...
Böylesine ciddi bir konuyu "kire mtih" ile değil adını soyadını bildiğim bir arkadaşımla tartışmayı tercih ederim. Herkesin kendi tercihidir, saygı duyarım ama bu da benim tercihim. Kusura bakmayın lütfen.

sümer hocam kesinlikle haklısınız. forumda herkesin ismiyle üye olduğunu daha sonra farkettim. tanışma bölümünde kendimi tanıttığım üzere ismim hakan.
 
Alıcı verici arasındaki protokol

Hakan Bey, 2.4 GHz sistemlerde bir kanal sayısı sıkıntısı artık pek yok zaten. Vericilerin her yerini buton doldurup alıcıları da peş peşe bağlamak birçok markada mümkün. Çünkü artık veri eskisi gibi PPM üzerinden ve her 22.5 mS'de bir iletilmiyor. Ama üreticiler muhtemelen alıcılarda marka bağımlılığı oluşturabilmek adına kendi protokollerini oluşturup kullanıyorlar. Bu da sizin ya da benim oturup kendi protokolümüzü oluşturabileceğimiz anlamına geliyor. "Ben" derken lafın gelişi idi tabii. Network protokollerinden hiç mi hiç anlamam. :)

Aklımda olan şey ise şu: Şimdi biz sonuçta bir tür WiFi bağlantısı kullanıyoruz. Standart protokoller kullanarak vericideki stik pozisyonlarını dijital olarak iletsek ve karşıdan da verinin doğru alındığına dair bir acknowledge verisi beklesek olmaz mı??? Yani, PPM sinyali falan oluşturmaya hiç gerek yok. Aileron potansiyometresini okuduk. ENdpoint, expo, reverse düzenlemelerini yaptık. Bir sayı elde ettik. Sonuçta elde edeceğimiz sayı standart bir sistemde (1024 çözünürlüklü) 0 - 1023 arasında bir sayı olacak. Yani en fazla 2 byte. Diyelim ki onaltı kanallı bir sistem kuruyoruz. Bir başlangıç sekansını takip eden 16 * 2 byte veri aktarılacak. (Haydi olsun olsun 100 byte veri gitsin). Acknowledge verisi beklenecek. Sonra tekrar veri yollanacak. Bugünkü WiFi sistemleri 150 Mbps düzeylerinde geziniyor. Biz 15 MBps ile çalışsak. Kabaca 1.5 milyon byte / saniye eder. Yani göndereceğimiz veriyi saniyede 15 bin kez gönderebiliriz. Hata düzeltmesi falan yapabiliriz.
Biraz sesli düşündüm işte. :D
 
RC kumandalarda kullanılan veri iletişim protokolü nasildir ?

Yine indekslik sahane bir Kaynak konu geliyor :thumbup: Takipteyiz :RCKolik:
 
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.

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 ...


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.
 
RC kumandalarda kullanılan veri iletişim protokolü nasildir ?

Zafer Hocam,

Bu kadar bilgiyi nerede ne zaman öğreniyorsun da aklında bu kadar net olarak kalıyor :eek: Tek kelime ile harikasın yine :bravo: :halay:
 
RC kumandalarda kullanılan veri iletişim protokolü nasildir ?

Mehmet hocam, soru bildiğim yerden çıktı :) ...

Bence IP protokol kümesi, büyük bilgisayar ağlarının güvenli ve hatasız olarak büyük miktarlada veri gönderebilmesini sağlayan devasa bir kamyon. Ama ihtiyacımız olan, ufak paketleri hızlı bir şekilde taşıyabilecek bir İstanbul motorsikletli kuryesi :D ...

Hoş, WiFi + IP protokolleri veri hızı bağlamında ilk bakışta avantajlı gözüküyor olabilir ama güvenilirlik ve hatasızlığı sağlamak adına ciddi bir ek yüke(paket başlıkları, protokolün kendi içinde tanımlanmış hata kontrol rutinleri, kesintisizliği garanti etmek adına kısıtlı mesafede çalışabilme v.b. ) sahip ...

Ama aslında hazır bu konuya başlamışken Arduino ile bir "RC - Kolik" protokolü inşa etmeye başlasak mı :D ...

Protokol iki farklı modda çalışacak.
* BIND Modu:
BIND modunda, RX modülü sadece BIND datasını(TX modülü ID numarası) okumak için bekliyor olacak. TX Modülü ise sadece BIND datasını bekliyor olacak. Örnek bir BIND datasının içeriği ise, aşağıdaki gibi olabilir.
[START BITS] - [BIND MODE ID] - [TX MODULE ID] - [DUMMY/FILLER DATA] - [CRC] - [STOP BITS] : [0xEE] - [0x01] - [0x44] - [??] - [??] - [0x00]
* Kontrol Modu:
Kontrol modunda RX modülü, çubuk pozisyonlarını okuyup, PWM'e çevirmekle yükümlü olacak... Örnek bir kontrol datasının içeriği ise, aşağıdaki gibi olabilir.
[START BITS] - [CONTROL MODE ID] - [TX MODULE ID] - [CONTROL DATA] - [CRC] - [STOP BITS] : [0xEE] - [0x02] - [0x44] - [??] - [??] - [0x00]

Daha işin başında olduğumuzdan henüz Voltage-controlled oscillator verisi(frekans kontrolü) işin içinde yok ...


Yukarıdaki gibi basit bir alıcı verici ikilisinin rahatlıkla, Arduino nano + NRF24L01 ile yapılabileceğini düşünüyorum. Daha uzun mesafe için PA+LNA'lı bir NRF24L01 kullanmak yerinde olacaktır.

 
RC kumandalarda kullanılan veri iletişim protokolü nasildir ?

Zafer SAHIN' Alıntı:
Mehmet hocam, soru bildiğim yerden çıktı :)

Bu arada soruyu Sorun kardesimiz Boyle bir tablo beklemiyordu galiba, hic yorum yapmamis :laugh:

Zafer SAHIN' Alıntı:
Ama aslında hazır bu konuya başlamışken Arduino ile bir "RC - Kolik" protokolü inşa etmeye başlasak mı :D ...
Sen yaparsan ben kullaniyorum Zafer hocam :thumbup: :RCKolik:
 
RC kumandalarda kullanılan veri iletişim protokolü nasildir ?

Abi yine derin derin bilgiler, o kadar derine inemesekte mantık hakkında fikir ediniyorum gerçekten çok güzel örnekler vererek açıklıyorsun takipteyim.

SM-G900F cihazımdan gönderildi
 
RC kumandalarda kullanılan veri iletişim protokolü nasildir ?

Mehmet Kucuksari' Alıntı:
Bu arada soruyu Sorun kardesimiz Boyle bir tablo beklemiyordu galiba, hic yorum yapmamis :laugh:
Sen yaparsan ben kullaniyorum Zafer hocam :thumbup: :RCKolik:


Mehmet Kucuksari' Alıntı:
Bu arada soruyu Sorun kardesimiz Boyle bir tablo beklemiyordu galiba, hic yorum yapmamis :laugh:
Sen yaparsan ben kullaniyorum Zafer hocam :thumbup: :RCKolik:

beklemediğim değil bir kaç inceleme yaparak cevap vermek istedim o yüzden geciktim.

Zafer Şahin hocamın belirttikleri haricinde yazdıktan sonra gecikmeyle ilgili şöyle birşey aklıma geldi. Wifi de standart iletişimi kullanırsak bağlantı koptuktan sonra tekrardan bağlanma aşamasında şifreleme protokollerinden dolayı ciddi gecikme yaşanacak ve mesafe uzadıkça bağlantıyı doğrulamak büyük problem yaratacak. Şifresiz kullansak çok daha büyük problem. Bunun yanında zafer hocam konuyu olabilecek en detaylı şekilde açıklayarak yazmış ve şifresiz kullanımda güvenlik problemi olmadan işlem yapabilmek için kumandaya özel id kullanmak gerekecek. bu da şu anki sistemlerle aynısı olcak.

Gecikme sebebime gelince bir adet husban mini invader ve dji phantom 3 professional sahibiim ve bunların kumandaları ve alıcıları arasındaki trafiği izlemek istedim. bilgisayarımdaki wireless adaptörümü monitor mode da kullanarak trafiği izlemek istediğim de mini invader ın trafiğini görebiliyorum. (iletilen verinin decode edilme yöntemini bilmediğimden anlamlı bi veri göremiyorum tabi ki. decode için mini invader üstünde reverse kasmak gerekli.). Ancak aynı işlemi dji phantom 3 ile denediğim de herhangi bir şekilde çevremdeki wifilerin ssid broadcastleri haricinde bi paket göremedim. Phantom 3 2.4 ghz üzerinde çalışıyor diyebiliyordum ancak yanılıyor muyum ? (1-2 gün içerisinde frekans tarayıcı ile kullandığı frekansı bularak detaylı bi analiz gerçekleştirince kumanda üzerinde iletişimi nasıl sağladıklarına dair bilgi edinmeyi umuyorum)



Ekte 2 tane dosya yolluyorum.

1. https://mega.nz/#!bMIUST5T!E6H7Q8eaXJ3ASae9EvLjjObJg9fZe9ZfOXHyV61j6wE mini invader a ait. ssid ler haricinde diğer paketleri görebilirsiniz.
2. https://mega.nz/#!3Y40za4A!ydmr_vYjAa6ZQi0FPYL3KY0zwBHGpQxWq0mQoVr4efY ssidler hariç bir paket görünmemekte.

(foruma upload edemedim boyuttan dolayı.)



not : üstteki dosyaları wireshark ile açabilirsiniz. mini invader ve kumandasına ait olduğunu düşündüğim paketlerin kaynak ve alıcı kısımlarında shenzhen veya arcadyan yazmakta. Wifi trafiği olmayan bi yerde incelesek çok net daha sonuç alabiliriz. (ya da filtreleriz.)
 
RC kumandalarda kullanılan veri iletişim protokolü nasildir ?

"Packet dump" datalarını inceledim. Ama mini invader'in "dump" datasında gördüğünü düşündüğün şeyi gördüğümü zannetmiyorum. Zaten görülmüyor olması lazım. Niye dersen ;

WiFi protokolü modülasyon olarak OFDM ve DSSS(sadece 802.11b) kullanır.

Zafer SAHIN' Alıntı:
3 - Oluşturulmuş bu sinyal dizisi, transmitter(TX) modülüne gönderilir. TX modülüne gönderilmiş PPM sinyali, her markanın kendisine özel bir formatta işlenerek(start bit, stop bit, crc kontrolü, varsa telemetri eklentileri, çeşitli ek header bilgilieri v.b.), paketlenir ya da enkapsüle edilir. Buradaki en büyük sıkıntı nerede ise hiç bir markanın birbiri ile uyumlu olmamasıdır, tüm markalar veriyi farklı farklı işleyerek paketler. İlgili markanın protokolü uyarınca, PPM datasının işlenip paketlenmiş hali de hala dijital bir sinyaldir.

4 - Oluşturulmuş olan dijital sinyalin, havada taşınabilmesi için, uygun bir şekilde modüle edilip antene gönderilmesi gerekmektedir. Sinyalin kablosuz olarak taşınabilmesi çin en çok kullanılan iki yöntem Frequency Hopping Spread Spectrum(FHSS) ve Direct Sequence Spread Spectrum(DSSS) denilen, yöntemlerdir. Bu iki yöntemde de, alıcı ve verici tarafından aynı anda bilinen bir sıralama kullanılarak, veriler her seferinde farklı bir frekansta gönderilir. Bu şekilde sabit bir frekansta oluşabilecek(başka bir kumanda, wifi networkü ve bilinmeyen bir çok etken gibi...) parazit nedeni ile sinyal kaybı yaşanmasının önüne geçişmiş olunur. Yanlız buradada, her marka kendilerine özel FHSS ve DSSS varyantlarını kullanmaktadırlar ve birbirleri ile uyumlu değildirler.
RC kontrol sistemleri ise modülasyon olarak tamamen şahıslarına münhasır FHSS ve DSSS varyantlarını kullanırlar. Yani zaten WiFi adaptörü monitor modda olsa bile anlayamadığı bir şekilde modüle edilmiş Hubsan datasını dinleyemez. Ki deviationtx projesinin incelersen, Hubsan'ın bir nevi FHSS varyantı kullandığını görebilirsin.... Velhasıl dinledi diyelim.

Şu yukarıda göreceğin FlySky protokolü incelemesinde de görebileceğin üzere WiFi ve Ethernet protokolüne ait paket başlıklarının ve paket içeriklerinin, RC kontrol datası ile uzaktan yakından alakası yoktur. Dolayısı ile sadece WiFi ve Ethernet protokollerini anlayabilecek WiFi adaptörü + Wireshark ikilisinin bu dataları yorumlayabilmesi ya da data zannedebilmesi mümkün değil. Bunun olmasının tek yolu Hubsan Mini Invader'in, diğer tüm Hubsan'lardan farklı olarak gerçekten WiFi ve Ethernet protokollerini kullanması olacaktır ki hiç zannetmiyorum. Yukarıda uzun uzun açıkladığım üzere böyle bir şeyi yapmak, hiç mantıklı değil.

Aynı şekilde 5.8Ghz'de çalışan DJI datasını da wifi adaptörü ile okumak mümkün değildir. Elmaları ve portakalları birbiri ile karıştırmayın. 2.4Ghz'de çalışmaları haricinde, ne modülasyon, ne frame yapısı olarak birbirine benzerliği olmayan protokoller bunlar ... RC Groups'daki RC Protokolleri ile ilgi bir sayfa, lütfen inceleyin...
 
RC kumandalarda kullanılan veri iletişim protokolü nasildir ?

Ne bu yaaa... 35 MHz kumandaların gözünün yağını yiyeyim. :D :D :D
 
RC kumandalarda kullanılan veri iletişim protokolü nasildir ?

Sümer Yamaner' Alıntı:
Ne bu yaaa... 35 MHz kumandaların gözünün yağını yiyeyim. :D :D :D
Bunlar hep teknoloji tuzaklari Abi :laugh: ;D