Kenwood uzaktan kumanda kodlarını okuma

[ete]

Çalışmayan nedir?
Ete

[canbulut]

Bu iletilerdeki 1. sayfa, ikinci mesajınızdaki kenwood_ete.rar içindeki .pbp dosyası hocam. zaten sizde çalışırsa diye yazmışsınız.

[rexo]

 Yıldırım AK – İnferruj Data Transferleri Protokolleri hakkında detaylı bilgiler örnek uygulamalar. Emeği geçen hazırlayan kişilere teşekkürler.

[kılıckaya]

Ete Hocam, infruraj vericide 555 kullanmasak olur mu? 38 KHz lik taşıyıcı dalgayı 555 kullanmadan PİC Basic kullanarak oluşturduğumuz yazılım sonucu bu taşıyıcı dalgayı elde edebilir miyiz? Piyasadaki fabrikasyon infruraj kumandalarda sanırım bu yöntem izleniyor. Teşekkürler.

[ete]

Önemli olan 38khz lik sinyali oluşturmak değildir. Zira bu sinyal kolaylıkla hpwm kullanılarak üretilebilir. Önemli olan bu sinyale data bilgisini bindirmektir.
Bundan dahada güzeli pic pininden direk data bindirilmiş sinyali çıkarmaktır. Biraz kafa yormak gerekir.

Ete

[canbulut]

hocam rc5 protokolünü sürelerini ölcerek kontrol edebilirmiyiz?sitenizdeki rc5 kodunuzu inceledim değişik kombinasyonlar var anlayamadım.süre ölçümlerine bakarak işlem yapabilirsek program algoritmasının kullanacağı yerde daha uygun olur diye düşündüğümden süre ölçümü ile yapılabilir mi diye soruyorum..

[ete]

Bir protokolün süre ölçerekmi yoksa başka bir metodlamı okunacağını protokolü inceleyerek kararkaştırmak gerekir.
RC5 protokolünde ;
"1"= 900us LOW + 900us HIGH
"0"=900us HIGH + 900us LOW
şeklinde uygulanıyor. Burada bence süre ölçerek okumak pek mantıklı olmaz. Bütün bitlerin sürelerini kayıt ettin. Ama o bit HIGH mı yoksa LOW mu belli değil. Bir işine yaramayacaktır.
Bence en akıllı yol, Paket başını bulup bit olarak okumak en doğrusu olur. İlk biti kayıt ettin. araya 1800us boşluk verip ikinciyi okursan bir sonraki bitin ilk bitine ulaşmış olursun. Programlarda bu garanti olsun diye 1800us değil 1780us gibi bir değerde tutulur. Böylece komut gecikmelerinin yol açtığı olumsuzluğu kaldırmış olursun.
Sonuç olarak ilk bitleri (ikinci bitleride okuyarak yapılabilir) okuyup kayıt ederek gelen kodu okumuş olursun.

Ete

[canbulut]

hocam yazdığınız progamda (rc5) nümeric key'ler iyi çıkıyor fakat aşağıdaki renkli tuşlardan kırmızıya basınca 20 bir daha basınca 23 bir daha basınca 20 çıkıyor.yeşil sarı mavidede benzer 19-25, 18-27, 17-29 olarak bastıkça bir döngü oluyor.başka bir rc5 kumandada bazı keyler doğru çıkıyor iken bazıları doğru çıkmıyor.

[ete]

RC5 sisteminde bazı farklı versiyonlar mevcut. Elindeki kumanda onlardan birisi olabilir.
Aşağıdaki linkte Akıl Defterim2 isimli PDF dosyası mevcut. RC5 ile ilgili açıklamaları okursan anlarsın.
Evde kullanıyorum Vestel kumandaları RC5 dir. Bütün tuşları sorunsuz okuyor.

https://dl.dropbox.com/u/25364674/Ak%C4%B1l%20Defterimv2.pdf

Ete

[canbulut]

gösterdiğiniz pdf'te RC5'i okudum. Tuş bilgisinden önce start, field ve kontrol biti varmış. Hocam bana sadece tus bilgisi lazım. Diğer bilgilere bakmadan tuş bilgilerini ve diğer rc5e farklı versiyon protokoller ile de hatasız tuş bilgisini nasıl alabilirim.

IR_OKU:     
        TUS=255:ZAMAN=0
        while IR_Goz=1
          zaman=zaman+1
          IF ZAMAN=2000 then RETURN
        wend

      pulsin IR_gOZ,1,zaman '1. start bitine ait low okundu
      pauseus 3000     'toggle bitini aşmış olduk
      FOR I = 10 to 0 STEP - 1 ' 11 pulses MSB to LSB
        PAKET.0[I] = IR_gOZ ' Y.Bit.Loop = data bit
        pauseus 1750
      NEXT  
      zaman=paket
      IF PAKET.Byte0=255 then IR_OKU
      Tus=PAKET.Byte0 & %00111111
      PAKET=PAKET<<2     
      Cihaz=PAKET.byte1 & %00011111 
      RETURN   

[ete]

Bak programın içinde mevcut,
Tus=PAKET.Byte0 & %00111111
şeklinde onu kullanırsan TUŞ bilgisi elinde demektir.

Ete

[canbulut]

hocam tuş bilgisi ne geliyorsa lcd'de gösteriyorum. nümerik keyler düzgün çıkıyor. Fakat normalde kullanılmayan kırmızı-yeşil-sarı-mavi keyler bir basışlarda değişiyor. mesela kırmızı keyde  bir basışta 19 bir basışta 25, tekrar bas 19, tekrar bas 25 şeklinde gidiyor. iş böyle olunca bir şey yapamıyorum. diğer rc5 protokolü olduğunu düşündüğümüz protokoller ise nümerikleri bile zaten iyi okumuyordu yine aynı.

[ete]

Bu durum gösteriyor ki ya senin kullandığın pic de bir zamanlama hatası var ki bu hata genellikle dahili OSC kullanıldığınd frekansın tam da 4Mhz olmamasından kaynaklanır yada kumandanın bit zamanları doğru değil. Başka açıklaması yok bunun.
Evde TV kumandası ile kontrol ettiğim bir ayaklı lambam var. Bu lamba kırmızı tuş ile aktif oluyor mavi tuş ile kapanıyor.
Sorunsuz çalıştığına göre sorun senin tarafta bir yerlerde olsa gerek.

Yapılacak iş bir skop ile gelen sinyale bakmak ve ona göre kod üzerinde tadilat yapmak.

Ete

[canbulut]

hocam skop ile baktım sorun yok. harici osc kullanıyorum. muhtemelen bit sırasında bir sorun var. diger protokollerde işlemler yapabiliyorum fakat rc5 de sizin yazdığınız kodlardan öteye gidemediğimden bir kontrol yapamıyorum. sadece bir yorum yapmamı beklerseniz toggle biti sürekli değişiyor ki bizim tuş bilgisi ile işimiz var ve önemi yok toggle bitini atlar iken ve zaman diye bir bekleme kalıbı var onlarda bir değişiklik yapılması bekleniyor diye düşünüyorum.

[ete]

RC5 protokolünün en önemli özelliği bütün bitlerinin sabit uzunlukta olmasıdır. Her nekadar açıklamada 900Us+900us=1800 us olarak verilmiş isede gerçek bit uzunluğunun 1778us olduğu her yerde belirtilmektedir.
Bu durumda paket verisine bakıldığı zaman başta start biti (2 bit halinde) + 1 adet toggle biti olduğu görülmektedir. Ardından 11 bitlik cihaz ve tuş kodu verilmektedir. BU hesaba göre bir veri paketinde toplam 14 bit bulunur. Toplam veri paketi boyu ise , 14*1778=24892us dir. Bunun 11*1778=19558us lik kısmı TUŞ ve CİHAZ koduna aittir. O halde geriye START+Toggle bitleri için  (24892-19558=)5334us lik bir süre kalmaktadır.
Burada amacımız start bitini yakalamak olacaktır. Dikkat edilirse protokolde ara bekleme LOW gözükmesine rağmen IR gözden bu bölüm HIGH olarak alınır. O halde uzun bir HIGH sinyali beklenir. Bunu sağlamanın yolu şöyle olabilir, Giriş pinine bak HIGH ise 1 ms bekle yeniden bak şayet LOW ise paketin arasındasın demektir. Ama 1 ms sonra bakınca pin hala HIGH ise demekki ara beklemedesin. Bu şekilde arayı yakaladık diyelim.
Sonrasında gelecek ilk bit LOW olup gözden bu bit HIGH olarak çıkacaktır. Ara beklemede HIGH olacağına göre bu ilk konumu (yarım bit=889us) atlamamız gerekecektir. O halde elimizde tus koduna kadar , 5334-(1778/2)=4445us lik süre kalmış olacaktır. Bu durumda uzun bir HIGH aralığından sonra gelecek bit LOW olacaktır. Bunu boşuna değerlendirmemek için Uzun aradan sonra yeniden HIGH ararsak 3 adet yarım biti atlamış olacağız. Bir tanesini (ilk start bitinin HIGH olan kısmını) toplam süreden düşmüş idik. O halde 2 yarım bitlik süre daha düşeceğiz.
4445-1778=2667us. Şimdi bulunduğumuz noktadan data bitlerinin başına kadar 2667us lik bir süremiz var.
Data bitlerini artık süre değilde bitin 1 yada 0 olmasına göre değerlendirip alacağımız için ilk data bitinin ortasına kadar gitmemiz akıllıca olacaktır. Bundan sonra sürekli olarak araya 1778us bekleme koyarak bir sonraki data bitinin ortasına ulaşırız. O halde 889us olan bir yarım bitin yarısını bekleme süremize eklememiz uygun olacaktır.
2667 + 444=3111 us lik bir bekleme koymamız gerekiyor. Demekki bulunduğumuz noktadan sonra bir 3111us lik gecikme koyarsak ilk data bitinin ortasına gelmiş olacağız. Bundan sonrası zaten gelen bitleri bir dizi değişkenine yada 16 bitlik bir değişkene atmaktan ibarettir.
Toparlarsak programda bir kusur yok. Toggle bit süreleri sabit olduğu için değişsede geçecek süre aynı kalacaktır. Bu nedenle benim mantığım doğrudur. Senin yapman gereken şey 3111us olan bekleme süresini azaltıp çoğaltarak (50us lik dilimler halinde) deneme yapmak ve sonucun değişip değişmediğini gözlemlemek olmalıdır.

Not: daha iyi anlamak için aşağıdki linkte verilen şekilleride incelemende yarar var.

http://users.telenet.be/davshomepage/rc5.htm

Ete