Beberapa waktu lalu saya membeli helikopter mainan kecil yang dikontrol IR yang murah dan sederhana (sama seperti yang ini - disebut "Diamond Gyro" atau "Diamond Force"). Untuk bersenang-senang, saya telah mencari cara mengendalikannya melalui Arduino.
Pembaruan: Mendapat protokolnya; Lihat jawaban
Yang lain telah berbagi hasil tentang meretas helikopter mainan IR yang berbeda dan mendekode protokol IR-nya. Sangat keren, tapi sayangnya helikopter saya menggunakan protokol yang berbeda. Salah satu yang saya tidak tahu. (Saya harus menambahkan bahwa elektronik semata-mata merupakan hobi bagi saya, jadi saya mungkin mengabaikan sesuatu yang sudah jelas).
Sama seperti pada tautan ke-2 di atas, saya mengambil pengontrol terpisah, menemukan pin IC yang mengendalikan LED (tanda IC telah dihapus, by the way), dan menghubungkan penganalisis logika.
Punya banyak data bagus, tapi saya masih belum tahu protokolnya. Situs ini adalah sumber yang bagus, tetapi tidak ada satupun protokol yang terdaftar yang cocok. Dan tidak ada lagi yang saya temukan yang cocok dengan sinyal yang saya tangkap. Namun, saya harus membayangkan bahwa ini adalah protokol sederhana yang tersedia, hanya karena itu adalah mainan kecil yang murah.
Jadi saya menghargai ide yang mungkin Anda miliki. Mungkin saya salah melihatnya.
(Info lebih lanjut di bawah gambar)
Karakteristik sinyal / protokol
Saya menangkap ini pada 16MHz dengan controller diatur ke saluran A; harus akurat, tepat waktu. (Ada 3 saluran IR yang dapat Anda pilih, tetapi menggunakan dua saluran lainnya tidak mengubah karakteristik, hanya bagian-bagian dari paket itu sendiri.) Pengaturan waktunya sangat konsisten (+/- 10μs maks). Paket diulangi dengan interval yang bervariasi tetapi minimal berjarak sekitar 100 ms.
Operator: 38kHz @ 50% siklus tugas
Terendah:
- Pendek: 285μs
- Panjang: 795µs
Tertinggi:
- Pendek: 275μs
- Panjang: 855μs
Selalu 17 tertinggi per paket.
Kontrol / input
Heli memiliki 3 kontrol: "Throttle" (yaitu kecepatan angkat / rotor), pitch (maju / belakang), dan yaw (rotasi di sekitar sumbu rotor) semuanya dikontrol dengan 2 thumbsticks. Mereka semua memiliki beberapa jenis jangkauan (tidak hanya on / off) dan sejauh yang saya tahu, semuanya ditransmisikan dalam satu paket. Input kiri / kanan hanya dikirim jika ada sesuatu yang lain dikirim, jadi saya menerapkan kecepatan maksimum ketika mengambil sampel itu. Masukan throttle dan pitch pada paket pemicunya sendiri yang dikirim, segera setelah Anda mendorong ibu jari melewati beberapa ambang batas / deadband (dalam grafik di bawah label "min" adalah untuk paket pertama yang dikirim ketika perlahan-lahan mendorong kontrol melewati deadband-nya).
Ini juga punya tombol untuk memotong kiri & kanan, karena heli itu bukan instrumen presisi ( sama sekali ) dan cenderung berputar lambat jika tidak. Sayangnya tombol trim kiri / kanan sepertinya tidak mengirim sinyal yang menambah / mengurangi sesuatu untuk setiap pers (yang akan berguna untuk mencari protokol); tampaknya hanya perintah tunggal, menyuruh helikopter untuk memotong kiri / kanan, dan kemudian melacaknya.
sumber
Jawaban:
Saya mengambil kebebasan untuk menjawab pertanyaan saya sendiri karena saya mendapatkan sebagian besar jawabannya dan ini adalah cara yang baik untuk berbagi temuan saya. Terima kasih saya kepada Olin Lathrop karena telah memberi saya tempat untuk memulai dan beberapa ide untuk dicoba, tetapi pada akhirnya, protokolnya ternyata sangat berbeda dari dugaan Olin, maka saya memposting jawaban ini.
Pembaruan: Saya memposting pertanyaan tindak lanjut mengenai 8 bit terakhir, yang saya tidak sepenuhnya mengerti, dan Dave Tweed menemukan jawabannya . Saya akan memasukkan detailnya di sini, jadi jawaban ini dapat berfungsi sebagai spesifikasi protokol lengkap, tetapi periksa jawaban Dave.
Saya harus mencoba beberapa hal yang berbeda untuk mendapatkan ini, tetapi saya cukup yakin bahwa saya mendapatkannya. Anehnya, saya belum menemukan sesuatu yang menyerupai protokol ini di tempat lain, tetapi mungkin itu merupakan protokol umum yang tidak saya ketahui.
Bagaimanapun, inilah yang saya temukan:
Protokol / pengkodean
Kedua pulsa dan ruang di antaranya digunakan untuk menyandikan data. Pulsa / spasi panjang adalah biner satu (1), dan pulsa / spasi pendek adalah biner nol (0). Pulsa dikirim menggunakan modulasi inframerah 38kHz konsumen standar @ 50% duty-cycle.
Pengaturan waktu denyut / ruang ada di pertanyaan awal, tapi saya akan mengulanginya di sini untuk kelengkapan:
Semua ± 10μs maks., ± 5µs typ .. Ini didasarkan pada sampel yang ditangkap dengan penganalisa logika pada 16MHz; Saya tidak memiliki osiloskop, jadi saya tidak tahu profil pastinya (yaitu waktu naik / turun).
Paket diulang selama input kontrol diterapkan dan tampak berjarak minimal 100 ms.
Transmisi paket dimulai dengan pembukaan "pulsa 1", yang diperbaiki dan bukan bagian dari data. Spasi berikut mengkode bit data pertama dari paket, dan pulsa terakhir mengkodekan bit terakhir.
Setiap paket panjangnya 32 bit, dan berisi setiap input yang dapat disediakan oleh kendali jarak jauh. Nilai dibaca sebagai endian kecil, yaitu MSB pertama.
Struktur data
Di bawah ini adalah struktur dasar dari paket individu. 8 bit terakhir membuat saya bingung, tapi itu sudah diketahui sekarang (lihat di bawah).
Catatan: Kisaran didasarkan pada pembacaan tertinggi yang saya dapatkan. Protokol ini mampu rentang yang lebih besar - hingga 255 untuk throttle, 63 untuk pitch / yaw - tetapi tutup sekitar setengahnya.
Nilai nada tampaknya memiliki deadband dari 14-21 (termasuk); hanya nilai-nilai di atas atau di bawah yang benar-benar membuat helikopter bereaksi. Saya tidak tahu apakah itu sama untuk menguap (sulit untuk mengatakan, karena helikopter itu tidak stabil, dan mungkin hanya berputar sedikit sendiri).
Ini dalam istilah grafis (bandingkan dengan grafik pada pertanyaan awal)
6 bit cek dihitung dengan XOR'ing semua nilai sebelumnya. Setiap nilai diperlakukan sebagai 6 bit. Ini berarti bahwa 2 MSB dari nilai throttle 8-bit diabaikan begitu saja. Yaitu
Catatan praktis
Pengaturan waktu dan modulasi sinyal tidak harus super akurat. Bahkan timing Arduino saya yang tidak akurat sama sekali bekerja dengan baik meskipun modulasi cerdik dan sedikit hit and miss pada durasi pulsa / ruang dibandingkan dengan remote control yang sebenarnya.
Saya percaya - tetapi belum diuji - bahwa helikopter hanya akan menempel pada saluran sinyal pertama yang ditemukannya. Jika dibiarkan tanpa sinyal terlalu lama (beberapa detik), tampaknya kembali ke mode "pencarian", sampai memperoleh sinyal lagi.
Helikopter akan mengabaikan nilai pitch dan yaw jika throttlenya nol.
Perintah trim dikirim hanya sekali per tombol-tekan pada remote control. Agaknya nilai trim hanya menambah / mengurangi nilai di controller helikopter sendiri; itu bukan sesuatu yang dilacak oleh remote control. Jadi setiap implementasi dari ini mungkin harus tetap berpegang pada skema itu, dan hanya mengirim nilai trim kiri / kanan sesekali, tetapi jika tidak default ke nilai trim nol dalam paket.
Saya sarankan memiliki saklar mematikan yang hanya menetapkan throttle ke nol. Ini akan menyebabkan helikopter jatuh dari langit, tetapi ia akan mengalami kerusakan lebih sedikit ketika tidak memutar motornya. Jadi, jika Anda akan menabrak atau menabrak sesuatu, tekan tombol bunuh untuk menghindari melepaskan gigi atau merusak bilah.
LED IR remote control asli tampaknya memiliki panjang gelombang> 900nm, tapi saya tidak punya masalah menggunakan ~ 850nm LED.
Penerima IR helikopter tidak apa-apa, tetapi tidak super sensitif, jadi semakin terang sumber IR Anda, semakin baik. Remote control menggunakan 3 LED secara seri, duduk di rel 9V bukannya rel 5V yang digunakan oleh logika. Belum memeriksa undian mereka saat ini dengan sangat tepat, tapi saya berani bertaruh itu adalah 50mA.
Contoh data
Berikut adalah banyak paket, untuk siapa saja yang tertarik (ya, saya membuat skrip dekoder; saya tidak mendekodekan semua ini). Paket saluran A berasal dari tangkapan yang sama dengan grafik pada pertanyaan awal.
Seperti disebutkan di atas, 8 bit terakhir telah ditemukan, tetapi hanya untuk anak cucu, inilah pemikiran asli saya. Jangan ragu untuk mengabaikannya sama sekali, karena dugaan saya salah besar.
8 bit terakhir
8 bit terakhir dari paket masih sedikit misteri.
4 bit dari bit 23 hingga 26 semuanya tampaknya sepenuhnya ditentukan oleh pengaturan saluran remote control. Mengubah saluran pada kendali jarak jauh tidak mengubah protokol atau modulasi dengan cara apa pun; itu hanya mengubah 4 bit itu.
Tetapi 4 bit adalah dua kali lipat dari yang sebenarnya dibutuhkan untuk menyandikan pengaturan saluran; hanya ada tiga saluran, jadi 2 bit banyak. Oleh karena itu, dalam uraian struktur di atas, saya hanya memberi label 2 bit pertama sebagai "Saluran", dan meninggalkan dua lainnya berlabel "X", tetapi ini dugaan.
Di bawah ini adalah contoh bit yang relevan untuk setiap pengaturan saluran.
Pada dasarnya, ada 2 bit lebih dari yang dibutuhkan untuk mengirimkan pengaturan saluran. Mungkin protokol memiliki 4 bit yang disisihkan untuk memungkinkan lebih banyak saluran nanti, atau lebih tepatnya protokol dapat digunakan dalam mainan yang sama sekali berbeda, tapi saya tidak tahu. Untuk nilai yang lebih besar, protokol tidak menggunakan bit tambahan yang bisa ditinggalkan (yaw / throttle / pitch bisa bertahan dengan sedikit lebih sedikit masing-masing), tetapi untuk trim - yang juga memiliki 3 status - hanya 2 bit yang digunakan. Jadi orang bisa curiga bahwa saluran tersebut juga hanya 2 bit, tetapi itu membuat 2 berikutnya tidak terhitung.
Kemungkinan lain adalah bahwa checksum paket adalah 8 bit, dimulai dengan "bit X", dan - melalui keajaiban checksumming - mereka kebetulan mencerminkan pengaturan saluran. Tetapi sekali lagi: Saya tidak tahu.
Dan berbicara tentang: Saya tidak tahu bagaimana bit-bit cek terbentuk. Maksudku, mereka adalah bit check, karena mereka tidak sesuai dengan input kendali tunggal, dan helikopter tampaknya tidak merespon jika saya bermain-main dengan mereka. Saya kira ini semacam CRC, tapi saya belum bisa mengetahuinya. Cek tersebut panjangnya 6-8 bit, tergantung pada bagaimana Anda mengartikan "bit X", jadi ada banyak cara yang bisa disatukan.
sumber
Ini tidak terlihat terlalu buruk. Pemberitahuan pertama bahwa semua pesan berisi persis 17 pulsa. Ini segera memberi kita petunjuk kuat bahwa ruang pendek di dalam pesan tidak relevan. Tampaknya data dikodekan oleh pulsa yang pendek atau panjang, dan bahwa beberapa rentang jarak antara pulsa ini dapat diterima.
Jelas, setiap pesan dimulai dengan pulsa panjang sebagai bit awal. Itu menyisakan 16 bit data. Mungkin beberapa bit awal adalah opcode, mungkin panjang variabel. Jika saya melakukan ini, beberapa bit akhir akan menjadi sebuah checksum. Gambar para insinyur yang menulis firmware ingin membuat hal-hal sederhana untuk diri mereka sendiri, sehingga Anda dapat mulai dengan mengasumsikan ada 8 bit data di suatu tempat. Sekarang lihat apakah ada pesan yang masuk akal.
Mari kita sebut panjang 1 dan pendek 0. Mungkin sebaliknya, tapi kita harus mulai dari suatu tempat. Melepas bit awal mulai:
Beberapa hal segera muncul. Jelas bit 0 adalah bit paritas. Kalau tidak, tampaknya ada bidang 3 bit <15:13>, nilai data 8 bit <12: 5>, dan bidang 4 bit lainnya <4: 1>.
Sepertinya nilai data sedang dikirim dalam urutan bit rendah ke tinggi, jadi mungkin lebih masuk akal untuk menginterpretasikan keseluruhan 16 bit yang dibalik dari apa yang saya perlihatkan.
Saya merasa tidak ingin menghabiskan lebih banyak waktu untuk hal ini, tetapi mudah-mudahan ini memberi Anda awal. Saya akan melanjutkan dengan menulis ulang daftar di atas dengan sedikit paritas dilucuti, seluruh angka membalik LSB ke MSB, dan masing-masing bidang diasumsikan ditampilkan secara terpisah dengan ruang di antara itu dan bidang berbatasan. Itu mungkin memungkinkan lebih banyak muncul pada Anda. Juga perlu diingat bahwa kita mungkin memiliki indera 1/0 dari setiap bit mundur. Mungkin menulis tabel baru setiap jalan dan melihat apakah sesuatu lebih masuk akal satu arah.
sumber