Bits within byte reversed when sending NEC1?

[eudoxos]

I create a small sketch which sends the same frame repeatedly using 3 different libs: IRremote, IRLib2 and Infrared4Arduino. On another board (both boards are Arduino Nano), IRrecvDumpV2 is dumping the frames received to the serial console. With device ID 0x00 and command 0xe0 (0b1110'0000), I correctly receive the frame 0x00ffe01f with both IRremove and IRLib2.

With Infrared4Arduino, the receiver reports 0x00ff07f8 (cmd 0b0000'0111, bits backwards). I tried other commands, e.g. 0b1110'0001, receiving 0b100000111. The reversal is also the case for device ID when its bits are not symmetric (like 0x01 is received as 0x80).

What is going on here? Is my sender's crystal perhaps running at negative frequency, reversing time sense?

The sending-side sketch is here as gist: https://gist.github.com/eudoxos/f2c1439adb56ac0b01f7dc523a6d8978

PS a working function to make "correct" signal for me is like this:

#define REVBITS __builtin_avr_insert_bits(0x01234567,b,0)
IrSignal* makeSig(uint8_t devId, uint8_t cmd){
   union{ uint16_t data; byte b[2]; };
   frame.b[0]=REVBITS(cmd);
   frame.b[1]=REVBITS(0xff-cmd);
   return Nec1Renderer::newIrSignal(REVBITS(devId),cmd2.data);
}

[bengtmartensson]

The NEC protocol(s) do send the parameters in the least-significant-bit-first order. See for example https://www.sbprojects.net/knowledge/ir/nec.php

It is IRremote and IRLib2 that gets it wrong. Their implementations of the NEC(1) protocol are incorrect.

[eudoxos]

Thanks for the explanation. Is this not low-level detail of transmission protocol detail which should be hidden by the API?

Or is IRremote nad IRLib2 implementing also the receiving side incorrect, meaning all the IR commands floating around the internet (like RGB light remotes, in my case) intercepted by their libs and for use with their libs, are reversed?

[bengtmartensson]

Is this not low-level detail of transmission protocol detail which should be hidden by the API?

It is "hidden by the API". But when someone request says 0x03 instead of 0xC0, no API hiding helps here.

Or is IRremote nad IRLib2 implementing also the receiving side incorrect, meaning all the IR commands floating around the internet (like RGB light remotes, in my case) intercepted by their libs and for use with their libs, are reversed?

Yes, unfortunately. You can browse sites like http://www.hifi-remote.com/forums/ and http://www.remotecentral.com/cgi-bin/mboard/forums.cgi to see how often I (username "Barf") and others have answered this question. Ken Shirriff and Chris Young have not exactly done the community a favor here. IrpTransmogrifier (and thus also IrScrutinizer) has a protocol "NEC-Shirriff-32" for compatibility.

[eudoxos]

I appreciate your library very much, just as your explanation now. I was googling for my problem, ignorant it was not arduino-specific, so did not reach those forums. Not sure if adding some big warning to the docs of i4a would help others in the future. For me, the issue is resolved. Thanks a lot.