Довідка щодо чи підказки щодо декодування ІК-протоколу


10

Деякий час тому я купив простий і дешевий маленький іграшковий вертоліт з іграшкою (такий же, як цей - він називається "Diamond Gyro" або "Diamond Force"). Для задоволення я розглядав можливість контролювати це через Arduino.

Оновлення: з'ясував протокол; див. відповідь

Інші вже поділилися своїми результатами щодо злому іншого ІК-вертольота і розшифровки ІЧ-протоколу. Дуже круто, але, на жаль, мій вертоліт використовує інший протокол. Таку, яку я не можу зовсім зрозуміти. (Додам, що електроніка - це суто хобі для мене, тому я, можливо, не помітив щось очевидне).

Так само, як і у 2-й ланці вище, я розібрав контролер, розмістив IC-контакт, що управляє світлодіодами (до речі, маркування ІС видалено) і підключив логічний аналізатор.

Отримано багато хороших даних, але протокол все ще не можу розібратися. Цей сайт є чудовим ресурсом, але жоден із перерахованих протоколів, здається, не підходить. І ніщо інше, що я знайшов, здається, не відповідає сигналу, який я захопив. Я маю уявити, хоча, що це простий, нестандартний протокол, тільки тому, що це дешева маленька іграшка.

Тож я буду вдячний за будь-які ідеї, які у вас є. Можливо, я просто неправильно дивлюся на це.
(Більше інформації нижче зображення)

Зразки з каналу A

Характеристики сигналу / протоколу

Я захопив це на 16 МГц за допомогою контролера, встановленого на канал A; повинні бути точними, строго визначеними. (Є три ІЧ-канали, з яких можна вибрати, але використання двох інших каналів не змінює характеристики, лише частини самого пакету.) Часи синхронізації дуже узгоджуються (+/- 10 мкс макс.). Пакети повторюються з різними інтервалами, але, як мінімум, приблизно 100 м один від одного.

Носій: 38 кГц при 50% робочого циклу


Мінімальні показники : - Короткі: 285 мкс
- Довгі: 795 мкс


Максимуми : - Короткі: 275 мкс
- Довгі: 855 мкс

Завжди 17 максимумів за пакет.

Управління / входи

Гелі мають 3 елементи керування: "Дросель" (тобто швидкість підйому / обертання), крок (вперед / назад) та позіхання (обертання навколо осі ротора), все це управляється двома кнопочками. Усі вони мають деякий діапазон (не тільки вмикання / вимкнення) і, наскільки я можу сказати, всі передаються в одному пакеті. Лівий / правий входи надсилаються лише у випадку, якщо щось інше надсилається, тому я застосував максимум дроселів під час відбору проб. Введення дроселів та кроків у власні тригерні пакети, що надсилаються, як тільки ви натискаєте на кнопочки пальців через деякий поріг / мертву смугу (на графіку під міткою "хв" для першого пакету, що надсилається, коли повільно натискаєте на контрольний пропуск через його мертву смугу).

Він також отримав кнопки для обрізки вліво і вправо, як Хелі це не точний інструмент ( на всіх ) і має тенденцію обертатися повільно інакше. На жаль, ліва / права кнопка обрізки, на жаль, не посилає сигнал, який збільшує / зменшує щось для кожного натискання (що було б зручно для з'ясування протоколу); здається, що це лише одна команда, яка говорить гелікоптеру підстригати вліво / вправо, а потім він це відстежує.


Чому б не просто використати сигнальні сліди, які ви вже повинні виписати пакетами в сирому вигляді?
Ігнасіо Васкес-Абрамс

@ IgnacioVazquez-Abrams Ви маєте на увазі просто відтворення записаних сигналів у вертоліт?
Фламбіно

Звичайно. Це не так, як вертоліт зможе сказати різницю ...
Ігнасіо Васкес-Абрамс

@ IgnacioVazquez-Abrams Щоправда, але , наскільки я можу сказати, пакет містить усі 3 елементи керування (дросель / крок / позіхання), а також елементи керування Хелі, жоден з них не просто вмикається / вимикається. Щоб керувати справою шляхом відтворення, я повинен був би захопити кожну конфігурацію ... Крім того, я хочу зрозуміти протокол
Фламбіно,

@ IgnacioVazquez-Abrams На жаль, я якось зіпсував свій останній коментар. Хочеться сказати: "... пакет містить усі 3 елементи керування (дросель / крок / позіхання), і жоден з них не вмикається / вимикається".
Фламбіно

Відповіді:


8

Я смію відповідати на власне запитання, коли я зрозумів більшість з них, і це хороший спосіб поділитися своїми висновками. Дякую Оліну Летропу за те, що він дав мені місце для початку та кілька ідей, щоб спробувати, але в кінцевому підсумку протокол виявився зовсім іншим, ніж здогадки Оліна, отже, я опублікував цю відповідь.


Оновлення: я розмістив подальше запитання щодо останніх 8 біт, яке я не повністю зрозумів, і Дейв Твід зробив це . Я включу тут деталі, тому ця відповідь може працювати як повна специфікація протоколу, але перегляньте відповідь Дейва.


Мені довелося спробувати кілька різних речей, щоб зрозуміти це, але я впевнений, що мені це вдалося. Як не дивно, я не знайшов нічого подібного до цього протоколу в іншому місці, але це може бути звичайним протоколом, про який я просто не знаю.

У будь-якому випадку, ось що я знайшов:

Протокол / кодування

І імпульси, і проміжки між ними використовуються для кодування даних. Довгий імпульс / простір - двійковий (1), а короткий імпульс / простір - бінарний нуль (0). Імпульси передаються за допомогою стандартної інфрачервоної модуляції 38 кГц при 50% робочому циклі.

Час імпульсу / простір є в оригінальному питанні, але я повторю їх тут для повноти:

 Bit    Pulse     Space
-----+---------+---------
  0  |  275µs  |  285µs
  1  |  855µs  |  795µs

Всі ± 10 мкс макс., ± 5 мкс тип .. Це засновано на зразках, знятих за допомогою логічного аналізатора на 16 МГц; У мене немає осцилографа, тому я не знаю точного профілю (тобто часу підйому / падіння).

Пакети повторюються до тих пір, поки застосовуються керуючі входи і, здається, розташовані не менше 100 м один від одного.

Передача пакетів починається з преамбули "імпульс 1", яка є фіксованою і не є частиною даних. Наступний пробіл кодує перший біт даних пакету, а останній імпульс кодує останній біт.

Кожен пакет має 32 біти і містить кожен вхід, який може надати пульт. Значення читаються як мало ендіан, тобто спочатку MSB.

Структура даних

Нижче наведена основна структура окремих пакетів. Останні 8 біт мене збентежили, але це вже з'ясовано (див. Нижче).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
--+---------------------------+-----------+---+-------+-----------
 P|    Yaw    |   Throttle    |   Pitch   | T | Chan. |   Check

P: Preamble (always a pulse-1), T: Trim, Chan.: Channel

Bit    Length    Description (see note below)
-----------------------------------------------
0      1         Preamble. High 1
1-6    6         Yaw. Range 0-36 for left-right, 17 being neutral
7-14   8         Throttle. Range 0-134
15-20  6         Pitch. Range 0-38 for forward-back, 17 being neutral
21-22  2         Trim. Left = 1, right = 2, no trim = 0
23-26  4         Channel. A = 5, B = 2, C = 8
27-32  6         Check bits

Примітка: Діапазони базуються на найвищих показниках, які я отримав. Протокол здатний до більшого діапазону - до 255 для дросельної заслінки, 63 - для нахилу / пронизування - але обмеження приблизно вдвічі менше.
Здається, величина тону має мертву смугу від 14-21 (включно); тільки значення вище чи нижче насправді змушує вертоліт реагувати. Я не знаю, чи те саме для позіхання (важко сказати, так як вертоліт все одно нестабільний і може просто трохи крутитися самостійно).

Ось це в графічному виразі (порівняйте з графікою в оригінальному запитанні)

структура пакету

6 контрольних бітів обчислюються методом XOR'ing всіх попередніх значень. Кожне значення трактується як 6 біт. Це означає, що 2 MSB 8-бітового значення дроселя просто ігноруються. Тобто

check = yaw ^ (throttle & 0x3F) ^ pitch ^ trim ^ channel

Практичні записки

Тимчасові сигнали та модуляція не повинні бути надто точними. Навіть не зовсім точний час мого Ардуїно працює чудово, незважаючи на хитрі модуляції та трохи удару та пропуску тривалості імпульсу / простору порівняно з реальним пультом дистанційного керування.

Я вірю - але не перевіряв - що вертоліт просто зачепить на канал першого знайденого ним сигналу. Якщо воно залишається без сигналу занадто довго (пару секунд), воно, схоже, повернеться до режиму «пошуку», поки знову не набере сигнал.

Якщо дросель дорівнює нулю, вертоліт ігнорує значення висоти та нахилу.

Команди обрізки надсилаються лише один раз за натискання кнопки на пульті дистанційного керування. Імовірно, обрізне значення просто збільшує / зменшує значення у власному контролері вертольота; це не те, що дистанційне управління відстежує. Отже, будь-яка реалізація цього, ймовірно, повинна дотримуватися цієї схеми і надсилати лише випадкові обрізки вліво / вправо, але в іншому випадку за замовчуванням до нульового значення обрізки в пакетах.

Я рекомендую встановити перемикач kill, який просто встановлює газ на нуль. Це призведе до того, що вертоліт випаде з неба, але це понесе менше шкоди, коли він не крутить свої мотори. Тож якщо ви збираєтеся зламати або вдарити щось, натисніть перемикач, щоб уникнути позбавлення зубчастих коліс або зламу лопатей.

ІК-світлодіоди оригінального пульта дистанційного керування мають довжину хвилі> 900 нм, але у мене немає проблем із використанням світлодіода ~ 850 нм.

ІЧ-приймач вертольота в порядку, але не надто чутливий, тому чим яскравіше ваш ІЧ-джерело, тим краще. Пульт дистанційного керування послідовно використовує 3 світлодіоди, які сидять на рейці 9В замість 5V напрямних, використовуваних логікою. Я не перевірив їх поточний розіграш дуже точно, але ставлю на 50mA.

Зразок даних

Ось купа пакетів для всіх, хто цікавиться (так, я написав сценарій декодера; я все це не розшифрував вручну). Пакети каналу A надходять із тих самих зображень, що й графіки в оригінальному запитанні.

Channel A                                                       
Yaw     Throttle  Pitch   Tr  Chan  Check     Description
-----------------------------------------------------------
000100  10000100  000000  00  0101  000101    Left Mid + Throttle
000000  10000110  010001  00  0101  010010    Left Max + Throttle 
100001  10000110  000000  00  0101  100010    Right Mid + Throttle 
100100  10000100  010001  00  0101  110100    Right Max + Throttle
010001  00000000  001011  00  0101  011111    Forward Min 
010001  00000000  000000  00  0101  010100    Forward Max 
010001  00000000  011000  00  0101  001100    Back Min 
010001  00000000  100101  00  0101  110001    Back Max
010001  00000000  010001  01  0101  010101    Left Trim 
010001  00000000  010001  10  0101  100101    Right Trim 
010001  00000011  010001  00  0101  000110    Throttle 01 (min)
010001  00010110  010001  00  0101  010011    Throttle 02
010001  00011111  010001  00  0101  011010    Throttle 03
010001  00101111  010001  00  0101  101010    Throttle 04
010001  00111110  010001  00  0101  111011    Throttle 05
010001  01010101  010001  00  0101  010000    Throttle 06
010001  01011111  010001  00  0101  011010    Throttle 07
010001  01101100  010001  00  0101  101001    Throttle 08
010001  01111010  010001  00  0101  111111    Throttle 09
010001  10000101  010001  00  0101  000000    Throttle 10 (max)

Channel B
Yaw     Throttle  Pitch   Tr  Chan  Check     Description
-----------------------------------------------------------
000000  10000110  010001  00  0010  010101    Left Max + Throttle 
100100  10000110  010001  00  0010  110001    Right Max + Throttle 
010001  00000000  001001  00  0010  011010    Forward Min 
010001  00000000  000000  00  0010  010011    Forward Max 
010001  00000000  010111  00  0010  000100    Back Min 
010001  00000000  100110  00  0010  110101    Back Max
010001  00000000  010001  01  0010  010010    Left Trim 
010001  00000000  010001  10  0010  100010    Right Trim 
010001  00000001  010001  00  0010  000011    Throttle Min 
010001  00110100  010001  00  0010  110110    Throttle Mid 
010001  01100111  010001  00  0010  100101    Throttle High 
010001  10001111  010001  00  0010  001101    Throttle Max 

Channel C
Yaw     Throttle  Pitch   Tr  Chan  Check     Description
-----------------------------------------------------------
000000  10000101  010001  00  1000  011100    Left Max + Throttle 
100100  10000101  010001  00  1000  111000    Right Max + Throttle 
010001  00000000  001010  00  1000  010011    Forward Min 
010001  00000000  000000  00  1000  011001    Forward Max 
010001  00000000  010111  00  1000  001110    Back Min 
010001  00000000  100110  00  1000  111111    Back Max
010001  00000000  010001  01  1000  011000    Left Trim 
010001  00000000  010001  10  1000  101000    Right Trim 
010001  00000001  010001  00  1000  001001    Throttle Min 
010001  00110100  010001  00  1000  111100    Throttle Mid 
010001  01100110  010001  00  1000  101110    Throttle High 
010001  10000101  010001  00  1000  001101    Throttle Max

Як було сказано вище, останні 8 біт були розібрані, але тільки для нащадків ось мої оригінальні думки. Не соромтесь ігнорувати це повністю, так як я сильно помилявся у своїх здогадах.

Останні 8 біт

Останні 8 біт пакету все ще залишаються загадкою.

Усі 4 біти від 23 до 26, здається, повністю визначаються налаштуваннями каналу дистанційного керування. Зміна каналу на пульті дистанційного керування жодним чином не змінює протокол або модуляцію; він змінює лише ці 4 біти.

Але 4 біта вдвічі більше, ніж насправді потрібно для кодування налаштувань каналу; Є лише три канали, тож 2 біта - це багато. Отже, в описі структури, описаному вище, я позначив лише перші два біти як "Канал", а інші два позначив як "X", але це здогад.

Нижче наведено зразок відповідних бітів для кожного налаштування каналу.

Chan.   Bits 23-26
-----+-------------
  A  |  0  1  0  1
  B  |  0  0  1  0
  C  |  1  0  0  0

В основному, на 2 біта більше, ніж потрібно для передачі налаштування каналу. Можливо, у протоколі є 4 біти, відведені для того, щоб пізніше було доступно більше каналів, або так протокол можна використовувати в абсолютно різних іграшках, але я просто не знаю. Для більших значень протокол використовує додаткові біти, які можна залишити (yaw / дросель / крок може пройти трохи менше кожного), але для обрізки - яка також має 3 стани - використовуються лише 2 біти. Тож можна було б підозрювати, що канал також є лише 2 бітами, але це залишає наступні 2 без уваги.

Інша можливість полягає в тому, що контрольна сума пакета становить 8 біт, починаючи з "біт X", і - через магію контрольної суми - вони просто трапляються, щоб якось завжди відображати налаштування каналу. Але знову: я не знаю.

А якщо говорити: я не маю поняття, як формуються ці контрольні біти. Я маю на увазі, що це контрольні біти, оскільки вони не відповідають жодному вхідному керуванню, і вертоліт, схоже, не відповідає, якщо я спішуся з ними. Я здогадуюсь, що це якась CRC, але я не змогла це зрозуміти. Перевірка 6-8 бітам, в залежності від того, як інтерпретувати «X біт», таким чином , є багато способів , які можна було б покласти разом.


6

Це не виглядає так погано. Спочатку зауважте, що всі повідомлення містять рівно 17 імпульсів. Це негайно дає нам чітке уявлення про те, що короткі проміжки в повідомленні не мають значення. Здається, дані кодуються імпульсами, які є короткими або довгими, і що деякий діапазон інтервалу між цими імпульсами прийнятний.

Очевидно, що кожне повідомлення починається з тривалого імпульсу як початковий біт. Це залишає 16 бітів даних. Можливо, декілька ранніх бітів є кодом опкоду, можливо, змінної довжини. Якби я робив це, декілька закінчуваних бітів були б контрольною сумою. Погляньте, що інженери, які написали прошивку, хотіли зробити прості речі для себе, тому можна почати, припустивши, що десь є 8 бітів даних. Тепер подивіться, чи має сенс якесь із повідомлень.

Давайте назвемо довгий 1 і короткий 0. Це може бути навпаки, але ми повинні почати десь. Знімаючи стартовий біт:

1010001101011010 хв дросель
1010011101011000 макс. Дросель
1010000001011111 хв вперед
1010000000011110 макс. Вперед
1010000011011101 максимум спинки
1010000100011010 хв назад
0000010101011100 макс ліворуч + макс. Дросель
0100010101011110 макс. Справа + макс. Дросель
1010000101111111 обробка ліворуч
1010000101011011 обробка справа

Дещо вискакує відразу. Очевидно, що біт 0 є бітом парності. В іншому випадку, здається, є 3-бітове поле <15:13>, 8-бітове значення даних <12: 5> та ще 4-бітове поле <4: 1>.

Схоже, що дані передаються в порядку низького та високого біту, тому, ймовірно, має сенс інтерпретувати цілі 16 біт, відвернуті від того, що я показую.

Мені не подобається витрачати більше часу на це, але, сподіваюся, це дало тобі початок. Я б продовжував перезапис списку вище з позбавленим бітом паритету, ціле число перевернуло LSB на MSB, і кожне припущене поле показано окремо з пробілом між ним та полем, що перебуває підпираючи. Це може призвести до того, що на вас з’явиться більше. Також майте на увазі, що у нас може бути відчуття 1/0 кожного біта назад. Можливо, випишіть нову таблицю в кожний бік і подивіться, чи щось має сенс один із способів.


Дякую, це чудово! Я візьмусь прямо на це і побачу, що я знайду. Подивившись на інші протоколи, я почав думати, що, можливо, пробіли не мають значення, але оскільки у них було два дуже послідовних терміни, я не був такий впевнений. Я подумав, що вони будуть відрізнятися більше, якщо вони не важливі. У всякому разі, я спробую це. Ще раз
дякую

Ага ... наскільки я можу сказати, простори мають значення. Я зосередив увагу на дросельній заслінці і захопив ще кілька зразків у 10 різних положеннях дроселя. Виключення пробілів не дало мені значущих цифр незалежно від того, як я робив конверсії. Але включаючи їх як довгий = 1, короткий = 0 дає плавне прогресування значення дроселя від 1 до 134 (мало ендіан). Ще працюю над іншими параметрами
Flambino

У мене протокол майже повністю розібрався, але є ще трохи таємниці. До мого запитання додали тонну речей, якщо ви хочете поворухнутися. Так чи інакше, дякую за допомогу поки що! Зробив мене в правильному напрямку.
Фламбіно

@Flambino: Схоже, ти добре випереджаєш те, що я зробив для початку, що, як виявилося, в основному невірно здогадується. Я читав ваше оновлене запитання, але все ще не розумію, як саме використовується довжина пробілів. Чи було просто випадковістю, що у всіх показаних вами шаблонах було рівно 17 імпульсів і що останній стався, що вказував на паритет, якщо лише імпульси приймали за 0 або 1?
Олін Латроп

Чесно кажучи, з мого боку це були переважно спроби та помилки. Оскільки два таймінги, які використовуються для пробілів, такі ж точні, як і імпульсні синхронізації, я зрозумів, що вони можуть бути значимими. І, якщо ігнорування пробілів не дало корисних бінарних даних, я просто припустив довгий імпульс = 1 і довгий пробіл = 1 (і короткий простір / імпульс = 0), що відразу дало мені дуже корисні дані. Отже, перший пробіл після імпульсу преамбули - це перший біт (на графіку максимум праворуч + макс дросельної заслінки показано "пробіл 1" як перший біт) з подальшим 16 імпульсами з ще 15 проміжками між ними; 32 біта.
Фламбіно
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.