How reliable is decoding an IR command into specific protocol such as "Is it an NEC or PINOEER"?

[liudr]

The reason I asked was I was exploring the provided example code to understand how the developers intend the users to use the library. I have recently read enough IR protocols to discern between a few different protocols and manually decode if necessary. I want to make a device that can recognize the type of protocol or brand/model of remote if I press a couple of buttons on the remote. So I am hoping that the decoding capability will give me the exact protocol. I'm using Tasmota to read the protocol decoded.
I have a SHARP smart TV remote that has been decoded as either NEC or PIONEER rather randomly. So I got the specs of both protocols from their respective library code and listed against my IR learner IC with scope results, two separate button presses. I can see that in both cases the decoded timing match that of NEC but Tasmota says PIONEER. I am wondering whether the library can discern between similar protocols/brands when they are similar like NEC and PIONEER.

<style> </style>

Protocol	Tick(us)	HeaderMark(Tk)	HeaderMark(us)	HeaderSpace(Tk)	HeaderSpace(us)	BitMark(Tk)	BitMark(us)	OneSpace(Tk)	OneSpace(us)	ZeroSpace(Tk)	ZeroSpace(us)	RptSpace(Tk)	RptSpace(us)
NEC	560	16	8960	8	4480	1	560	3	1680	1	560	4	2240
PIONEER	534		8506		4191	1	568	3	1542	1	487
Sharp remote			9000		4480		570		1672		570
Sharp remote			9000		4450		576		1670		558

I wonder if this is how decoding is done: start down a list, see if the header mark and space match that of any protocol down the list within say 15% accuracy, if a match is found, consider that the protocol is found. But that doesn't explain why sometimes NEC and othertimes PIONEER, it would always be the one closer to the top of the list that gets matched if it were going down a fixed list.

[crankyoldgit]

PIONEER messages are 64 bits. NEC are 32 bits.

The library tries to decode a message first as a PIONEER format/size, and if it isn't, it goes on to try NEC.
e.g.

IRremoteESP8266/src/IRrecv.cpp

Lines 634 to 653 in 9bdf8ab

	#if DECODE_PIONEER
	DPRINTLN("Attempting Pioneer decode");
	// Try decodePioneer() before decodeNEC() because the protocols are
	// similar in timings & structure, but the Pioneer one is much longer than
	// the NEC protocol (2x32 bits vs 1x32 bits) so this one should be tried
	// first to try to reduce false detection as a NEC packet.
	if (decodePioneer(results, offset)) return true;
	#endif
	#if DECODE_EPSON
	DPRINTLN("Attempting Epson decode");
	// Try decodeEpson() before decodeNEC() because the protocols are
	// similar in timings & structure, but the Epson one is much longer than the
	// NEC protocol (3x32 identical bits vs 1x32 bits) so this one should be tried
	// first to try to reduce false detection as a NEC packet.
	if (decodeEpson(results, offset)) return true;
	#endif
	#if DECODE_NEC
	DPRINTLN("Attempting NEC decode");
	if (decodeNEC(results, offset)) return true;
	#endif

[liudr]

Thanks for the quick response! Here is what I got from Tasmota:
13:53:43.114 RSL: RESULT = {"IrReceived":{"Protocol":"PIONEER","Bits":64,"Data":"0x20DF10EF20DF11EE","DataLSB":"0x4FB08F704FB8877","Repeat":0}}
Here is my scope:

The delay between the two distinct 32-bit messages is 39.2ms. I manually decoded both messages. The first message was 0x4FB08F7(LSB) and the second one 0x4FB8877(LSB). I don't know how they were chained together as a single PIONEER 64-bit message. Does PIONEER come in as a 64-bit message or two 32-bit ones?

[crankyoldgit]

The latter. If you read the code, you will see it.

[liudr]

Thanks for your response. There were literal 2 in various places of the decoder hinting two separate messages.
So would you say it's easier decoding AC remotes if I disable decoding on TV protocols? I read a few .cpp/.h files on ACs in the library and they have very different header and space lengths from the few I read.

Would you recommend disabling decoding by modifying IRremoteESP8266.h as hinted in these comments?

// Supported IR protocols
// Each protocol you include costs memory and, during decode, costs time
// Disable (set to false) all the protocols you do not need/want!
// The Air Conditioner protocols are the most expensive memory-wise.
//

<style> </style>

Protocol	Tick(us)	HeaderMark(Tk)	HeaderMark(us)	HeaderSpace(Tk)	HeaderSpace(us)	BitMark(Tk)	BitMark(us)	OneSpace(Tk)	OneSpace(us)	ZeroSpace(Tk)	ZeroSpace(us)	RptSpace(Tk)	RptSpace(us)
NEC	560	16	8960	8	4480	1	560	3	1680	1	560	4	2240
PIONEER	534		8506		4191	1	568	3	1542	1	487
LG AC	550		8500		4250								2250
LG32 AC			4500		4450
LG2	480		3200		9900
SAMSUNG	560	8	4480	8	4480	1	560	3	1680	1	560	4	2240
SAMSUNG AC	690		17844				586		1432		436
SAMSUNG36			4515		4438		512		1468		490

FYI this reference link in the code have expired.
https://www.pioneerelectronics.com/PUSA/Support/Home-Entertainment-Custom-Install/IR+Codes/A+V+Receivers

I found information on PIONEER here.
http://www.adrian-kingston.com/IRFormatPioneer.htm