Твитнуть
По многочисленным просьбам был написан плагин для СОМ IrDA, подробнее о всех ограничениях и сложностях использования см. на http://slydiman.narod.ru/scr/plugins/ir210.htm.
Через IrDA данные передаются также как и через COM порт с небольшими отличиями. Наличие импульса - это логический 0, длительность имульса составляет 3/16 bit time. Обычно используется режим 8 бит, без контроля четности и 1 стоповый бит. Первый импульс рассматривается как стартовый, далее в зависимости от выбранной скорости передачи (обычно 115200) наличие или отсутствие импульса в заданный момент времени определяет значение очередного бита (0 или 1). Байт считается успешно принятым, если правильно принят стоповый бит, т.е. если в нужный момент не будет никакого импульса. На картинке показан сигнал при передаче данных через COM порт (UART) и через IrDA.
Получить доступ к IrDA как к обычному COM порту можно только если устройство подключается в COM порт или в IrDA разъем на материнской плате. Во втором случае придется править руками INF файлы, чтобы Windows не догадался что это ИК порт. Использовать например USB IrDA устройство для работы с дистанционкой вообще не получится.
Теория:
Допустим что со стоповым битом все в порядке, тогда все будет как нарисунке (А). Появился ИК фон, через 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). Наиболее вероятен безошибочный прием байта, перекрывающего окончание информационного импульса с дистанционки (на стоповый бит не попадет никакого импульса).
Все это относится к случаю, когда для анализа команды с дистанционки используется плагин DCD, или IR210, (принцип работы аналогичен WinLIRC). Плагин UIR, http://slydiman.narod.ru/scr/plugins/uir.htm вообще не имеет понятия о кодировках различных пультов, от тупо анализирует последовательность принятых байтов. Вероятность того что для одной и той же команды пульта IrDA будет давать одинаковые байты очень маленькая. Результат, например, может меняться от расстояния между IrDA приемником и пультом. И наоборот для разных команд пульта могут быть получены одинаковые байты.
Вывод: при определенной частоте ИК фона (т.е. при определенной модели дистанционки) с большой натяжкой IrDA можно использовать для приема команд ДУ с pulse-distance модуляцией и при относительно коротких импульсах, ориентируясь при этом по времени между RX CHAR EVENT (плагин DCD). IrDA невозможно использовать для приема ИК команд от дистанционок с другим типом модуляции, а так же если в командах присутствует длинный первый информационный импульс, что встречается довольно часто.
Генерирование ИК команд ДУ через IrDA
Здесь ситуация чуть лучше. Если знать точный формат команды для данной дистанционки, можно сформировать несколько пакетов и послать их через IrDA через заданное время. При этом нужно использовать скорость передачи 38400 (наиболее близкая к частоте большинства дистанционок). Получится очень близкий к оригиналу сигнал, однако он не будет идеальным. Через каждые 9 импульсов будет провал (стоповый бит). Кроме того скважность импульсов будет составлять примерно 19% (должно быть 50%). Принимающая аппаратура может воспринимать стоповый бит как короткую паузу между информационными импульсами и неправильно декодировать команды.