Ну взагалі-то можна звичайно використовувати IrDA для прийому команд з звичайних ІК пультів, але з дуже великими обмеженнями. Працює далеко не з усіма пультами. Стабільність розпізнавання команд дуже низька. Якщо використовувати IrDA вбудований в материнську плату, то потрібно чаклувати з драйверами, якщо зовнішній, то потрібно видаляти драйвера або періодично перетикати приймач в інший СОМ порт. USB IrDA взагалі використовувати неможливо, так як до нього не можна звернутися безпосередньо як до СОМ порту (не плутайте з віртуальним СОМ портом).
А тепер детальніше:
Через IrDA дані передаються також як і через COM порт з невеликими відмінностями. Наявність імпульсу - це логічний 0, тривалість імульса становить 3/16 bit time. Зазвичай використовується режим 8 біт, без контролю парності і 1 стоповий біт. Перший імпульс розглядається як стартовий, далі в залежності від обраної швидкості передачі (зазвичай 115200) наявність або відсутність імпульсу в заданий момент часу визначає значення чергового біта (0 чи 1). Байт вважається успішно прийнятим, якщо правильно прийнятий стоповий біт, тобто якщо в потрібний момент не буде ніякого імпульсу. На зображенні показаний сигнал при передачі даних через COM порт (UART) і через IrDA.
Отримати доступ до IrDA як до звичайного COM порту можна тільки якщо пристрій підключається в COM порт або в IrDA роз'єм на материнській платі. У другому випадку доведеться правити руками INF файли, щоб Windows не здогадався що це ІК порт. Використовувати наприклад USB IrDA пристрій для роботи з дистанційкою взагалі не вийде.
Найголовніше - кожен інформаційний імпульс, посланий з дистанційки, насправді - це ІК фон заданої тривалості з частотою від 30 до 56 кГц.
Припустимо що зі стоповим бітом все в порядку, тоді все буде як намалюнку (А). З'явився ІК фон, через 86.8 мкс (при швидкості 115200) взявся перший байт, згенеровано подія RX CHAR EVENT.
Дочекавшись закінчення прийому пакета, підраховуємо кількість байтів і кількість поодиноких молодших бітів в останньому байті, таким чином дізнаємося тривалість імпульсу (T2) з точністю до 9 мкс.
Дочекавшись чергового RX CHAR EVENT і завмерши між ними час дізнаємося T1. Віднявши T2 від T1 дізнаємося тривалість паузи.
Здавалося б є достатньо інформації для декодування команди (відомі тривалості імпульсів і пауз між ними), але.
Якщо в момент зчитування стопового біта в ІК тлі попадеться імпульс, байт не прийметься. Див. Малюнок (B). Таким чином в разі неправильного прийому одного або декількох байтів RX CHAR EVENT може виникнути в точці (1), (2) або (3).
Мало того RX CHAR EVENT може виникнути кілька разів протягом одного інформаційного імпульсу з дистанційки, наприклад в точках (1) і (3). Найбільш вірогідний безпомилковий прийом байта, що перекриває закінчення інформаційного імпульсу з дистанційки (на стоповий біт не потрапить ніякого імпульсу).
Висновок: при певній частоті ІК фону (тобто при певній моделі дистанційки) з великою натяжкою IrDA можна використовувати для прийому команд ДУ з pulse-distance модуляцією і при відносно коротких імпульсах, орієнтуючись при цьому по часу між RX CHAR EVENT (плагін DCD ). IrDA неможливо використовувати для прийому ІК команд від дістанціонок з іншим типом модуляції, а так само якщо в командах присутня довгий перший інформаційний імпульс, що зустрічається досить часто.
Генерування ІК команд ДУ через IrDA
Тут ситуація трохи краща. Якщо знати точний формат команди для даної дистанційки, можна сформувати кілька пакетів і послати їх через IrDA через заданий час. При цьому потрібно використовувати швидкість передачі 38400 (найбільш близька до частоті більшості дістанціонок). Вийде дуже близький до оригіналу сигнал, однак він не буде ідеальним. Через кожні 9 імпульсів буде провал (стоповий біт). Крім того шпаруватість імпульсів становитиме приблизно 19% (має бути 50%). Приймаюча апаратура може сприймати стоповий біт як коротку паузу між інформаційними імпульсами і неправильно декодувати команди.