ИК-сигнал: разные библиотеки, разный порядок битов/байтов?

Для ИК-передатчика в Nano Every (на базе ATMega4809) я использую инфракрасный порт 4arduino для отправки простых кодов дистанционного управления. Я дважды проверяю те, у кого есть приемник на основе Nano, с примером IRrecvDumpV2 из библиотеки IRremote, но я получаю что-то другое, что я отправляю (я думаю):

У отправителя есть следующий код, использующий Infrared4Arduino:

   IrSignal* sig=Nec1Renderer::newIrSignal(0,0x906f); // команда 0x90
   IrSenderPwm::getInstance(true)->sendIrSignal(*sig,1);

но приемник сбрасывает (помимо некоторого мусора вроде 0-битных кадров JVC и SANYO):

Encoding  : NEC
Code      : FFF609 (32 bits)
unsigned int  data = 0xFFF609;

0x00 и 0xff (первые 2 байта «пакета») — это устройство и его логическое дополнение, это нормально.

Команда, отправленная как 0x90 (за которой следует его логическое дополнение 0x6f), декодируется как 0xF6 (плюс его логическое дополнение 0x09 ). Почему? Это случайно, что 906f f609 наоборот?

Что здесь происходит?

Я попытаюсь запустить отправителя и получателя с одной и той же библиотекой (IRremote не перенесен на Nano Every), но прежде чем я продолжу, лучше спросите. Возможно, я просто делаю какую-то ошибку новичка в IR.

, 👍1

Обсуждение

Команда отправлена как 0x90 (с последующим логическим дополнением 0x6f) ... откуда вы это знаете?, @jsotola

вы выбрали данные, которые читаются одинаково независимо от порядка битов... 1001 одинаково в обоих направлениях... код передачи, например 1000, @jsotola

@jsotola Насколько я понимаю, так работает протокол. Идентификатор устройства (в данном случае 0x00), его битовое дополнение 0xff (для избыточности), а затем команда 0x90 (0b10010000) и его битовое дополнение 0x6f (0b01101111, опять же для избыточности)., @eudoxos

вы выбрали симметричные данные... 10010000 читает 0x90 в одном битовом порядке и 0x09 в другом битовом порядке, поэтому не очевидно, как данные передаются и принимаются... вместо этого выберите что-то вроде 11000100, которое читает 0xC4 в одном битовом порядке и 0x23 в другом порядке битов, @jsotola

Решено, смотрите ответ ниже., @eudoxos


1 ответ

1

Это приемник (на основе IRremote), который декодирует биты в обратном порядке. IRremote и IRLib2 некорректно реализуют протокол NEC (как на отправляющей, так и на принимающей стороне). Подробнее читайте в отчете о проблеме https://github.com/bengtmartensson/Infrared4Arduino/issues/52. р>

,
Смотрите также: