IR signal: different libs, different bit/byte ordering? For IR sender at Nano Every (ATMega4809-based) I am using infrared4arduino to send simple remote control codes. I am double-checking those with a Nano-based receiver with IRrecvDumpV2 example from IRremote library but I am receiving something else what I am sending (I think):

The sender has the following code using Infrared4Arduino:

   IrSignal* sig=Nec1Renderer::newIrSignal(0,0x906f); // cmd 0x90
   IrSenderPwm::getInstance(true)-&gt;sendIrSignal(*sig,1);


but the receiver dumps (besides some garbage like 0-bit JVC and SANYO frames):

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


0x00 and 0xff (first 2 bytes of the "packet") are device and its logical complement, those are fine.

The command sent as 0x90 (followed by its logical complement 0x6f) is decoded as 0xF6 (plus its logical complement 0x09). Why? Is it an accident that 906f is f609 backwards?

What's going on here? 

I will try to run both sender and receiver with the same lib (IRremote is not ported to Nano Every) but before I go ahead, better ask. Perhaps I am only doing some IR-beginner's mistake.
It is the receiver (IRremote-based) which is decoding bits in reverse order. IRremote and IRLib2 implement the NEC protocol incorrectly (both on sending and receiving sides). More details in the issue report https://github.com/bengtmartensson/Infrared4Arduino/issues/52 .