The NEC1 protocol has 32 bits of data, which we use to call device (D), subdevice (S, often 255-D) and function code (F), then comes the 1-complement of F (255-F).

Note that the first and second byte of the numbers sum up to 0xFF, as does the third and fourth. (Assuming that the first one is 807F 1AE5 not 807F 1AES...)

with this interpretation, you can put these parameters into IrScrutinizer (enter "0x80" as D etc, i.e. 4 characters ) and render Pronto hex within that program. For example, the first one comes out as

0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 05F7 015B 0057 0016 0E6C

There is another possible interpretation (no-one can be sure what the author of the original document meant, in particular since you do not show it...), and that is the opposite bit order. That is instead of 0x80 you enter 0x01, instead of 0x1A you enter 58 etc.


Actually, it does accept NEC1, as "short form pronto". Your first one is

900A 006C 0000 0001 8077 1AE5

I leave the other ones as exercise for the reader...