NEC signals in receive exmaple doesnt seem to match Convert_Old_Nec

[m5sib]

The "old" Nec signals converted to to new one
FF9A65 --> 0xFF00, 0xA659
FFA25D --> 0xFF00, 0xBA45
FF1AE5 --> 0xFF00, 0xA758

same three buttons pressed in Receive example
Address: 0xFF00
Command: 0x59

Address: 0xFF00
Command: 0x45

Address: 0xFF00
Command: 0x58

Command seems to be missing first two digits 0xA659 vs 0x59 ; 0xBA45 vs 0x45 ; 0xA758 vs 0x58

[rpv-tomsk]

Command seems to be missing first two digits 0xA659 vs 0x59 ; 0xBA45 vs 0x45 ; 0xA758 vs 0x58

0xA6 = 0x59 xor 0xFF
0xBA = 0x45 xor 0xFF
0xA7 = 0x58 xor 0xFF

As we know, NEC proto send 8bit address and 8bit data, and sent it twice, non-inverted and inverted.

• I don't understand/know something why this library returns 16bit value as Nec_address_t
• Why address bits inversion is not checked in CNec::checksum

[oqibidipo]

• I don't understand/know something why this library returns 16bit value as Nec_address_t
• Why address bits inversion is not checked in CNec::checksum

Not all remotes do the xor thing to the address field. The value can be a true 16-bit value.

[rpv-tomsk]

Not all remotes do the xor thing to the address field. The value can be a true 16-bit value.

Do they use the trick so that the number of zeros and ones in address + ^address is the same, or use a variable (non-standart) length of packet?

[oqibidipo]

The remotes that I have tested(*) do not always balance the number of zeros and ones. The number of "one" bits in the address bytes ranges from 1 to 12.

(*) A universal remote in device scan mode is very handy for testing a big pile of different codes.