Extra bits on RAW that are not converted

[ithinkido]

I have a remote for a Genva Radio that I would like to dump so that I can use it on on an ESP.

The data from the remote looks like this

POWER ON

Protocol  : NEC
Code      : 0xFF00FF (32 Bits)
uint16_t rawData[71] = {8938, 4452,  590, 540,  586, 540,  588, 542,  588, 540,  586, 540,  590, 540,  588, 542,  586, 542,  560, 1696,  562, 1694,  564, 1696,  564, 1692,  564, 1696,  562, 1696,  562, 1696,  560, 1696,  590, 542,  586, 542,  586, 544,  584, 542,  584, 546,  584, 544,  588, 540,  586, 544,  558, 1698,  562, 1698,  558, 1700,  560, 1698,  560, 1698,  560, 1700,  558, 1698,  560, 1702,  586, 41414,  8940, 2278,  588};  // NEC FF00FF
uint64_t data = 0xFF00FF;

At first, I thought this should be easy from her on, but unfortunately there seems to a small quirk in the raw data.

If I try and send the NEC code using irsend.sendNEC(0xFF00FF);
then the receiver dump looks like this

Code      : 0xFF00FF (32 Bits)
uint16_t rawData[67] = {8944, 4504,  542, 588,  542, 588,  542, 588,  542, 590,  542, 588,  566, 566,  542, 588,  542, 588,  542, 1708,  544, 1706,  544, 1706,  542, 1712,  542, 1706,  546, 1706,  546, 1706,  544, 1710,  542, 590,  546, 586,  542, 590,  540, 590,  540, 612,  516, 588,  544, 588,  542, 590,  542, 1708,  542, 1708,  542, 1708,  542, 1706,  544, 1710,  542, 1706,  542, 1706,  546, 1706,  544};  // NEC FF00FF
uint64_t data = 0xFF00FF;

The raw data does not match up with the raw data from the remote. The last few bits seems to be missing. I have tried to decode the raw data using ./gc_decode -raw "8938,...... but I end up with the same NEC output and unfortunately this does not seem to be able to control the radio when sent from the ESP.

Have I missed something with the decoding ? Ant tips here would be appreciated as I have a not been able to see anything myself so far that would cause this .

[NiKiZe]

You have a high value of 41414, should this be 2 messages?

Can you ensure that you have gone thru the FAQ?
Do you have any local modifications to your code?

Also grab more samples to see how repeatable this is.

[ithinkido]

Thanks for the reply. I can not say for sure if it should be two messages, but it is for sure only one button press.
Other button behave in a similar way. eg

Protocol  : NEC
Code      : 0xFF00FF (32 Bits)
uint16_t rawData[71] = {8938, 4452,  590, 540,  586, 540,  588, 542,  588, 540,  586, 540,  590, 540,  588, 542,  586, 542,  560, 1696,  562, 1694,  564, 1696,  564, 1692,  564, 1696,  562, 1696,  562, 1696,  560, 1696,  590, 542,  586, 542,  586, 544,  584, 542,  584, 546,  584, 544,  588, 540,  586, 544,  558, 1698,  562, 1698,  558, 1700,  560, 1698,  560, 1698,  560, 1700,  558, 1698,  560, 1702,  586, 41414,  8940, 2278,  588};  // NEC FF00FF
uint64_t data = 0xFF00FF;


VOL+
Protocol  : NEC
Code      : 0xFFC03F (32 Bits)
uint16_t rawData[71] = {8924, 4468,  550, 578,  550, 580,  576, 552,  572, 556,  574, 556,  544, 584,  572, 554,  550, 580,  548, 1706,  524, 1736,  548, 1708,  524, 1734,  550, 1708,  524, 1736,  522, 1734,  550, 1710,  548, 1710,  522, 1736,  576, 554,  572, 554,  572, 556,  548, 580,  572, 556,  548, 580,  574, 556,  574, 556,  520, 1736,  546, 1712,  550, 1708,  548, 1710,  548, 1710,  550, 1708,  574, 41426,  8932, 2288,  576};  // NEC FFC03F
uint32_t address = 0x0;
uint32_t command = 0x3;
uint64_t data = 0xFFC03F;

VOL-
Protocol  : NEC
Code      : 0xFF609F (32 Bits)
uint16_t rawData[71] = {8878, 4516,  524, 606,  524, 606,  522, 604,  524, 606,  570, 556,  524, 606,  522, 606,  572, 558,  546, 1708,  550, 1710,  544, 1714,  552, 1708,  552, 1706,  558, 1698,  560, 1700,  558, 1698,  586, 544,  560, 1698,  560, 1698,  588, 542,  584, 542,  586, 544,  584, 546,  584, 542,  558, 1700,  584, 544,  584, 542,  560, 1700,  560, 1698,  560, 1696,  562, 1696,  562, 1698,  586, 41416,  8942, 2276,  586};  // NEC FF609F
uint32_t address = 0x0;
uint32_t command = 0x6;
uint64_t data = 0xFF609F;

I have made no mods to the code and I am using the IRdump v3 example and the IRsend example with only small modifications to pin numbers .
I have tested this on some other remote controls and these have worked very well with the code matching the remote and the device responding as expected. It looks like it is just to do with this particular protocol on this remote.

[crankyoldgit]

If try and send the NEC code using irsend.sendNEC(0xFF00FF);

The raw data you've got looks like an NEC message with a single repeat. SHERWOOD is a protocol that forces a NEC message with at least one repeat.

Try: irsend.sendNEC(0xFF00FF, 32, 1); or irsend.sendSherwood(0xFF00FF);
Which will send an 0xFF00FF 32-bit NEC message with 1 repeat.

You can also change the kTimeout constant to 15 in the IRrecvDumpV2/V3 example code, it should detect the two messages in your capture individually. @NiKiZe is correct, there are two messages in your capture.
see:

IRremoteESP8266/examples/IRrecvDumpV3/IRrecvDumpV3.ino

Lines 66 to 100 in ff045f1

	// kTimeout is the Nr. of milli-Seconds of no-more-data before we consider a
	// message ended.
	// This parameter is an interesting trade-off. The longer the timeout, the more
	// complex a message it can capture. e.g. Some device protocols will send
	// multiple message packets in quick succession, like Air Conditioner remotes.
	// Air Coniditioner protocols often have a considerable gap (20-40+ms) between
	// packets.
	// The downside of a large timeout value is a lot of less complex protocols
	// send multiple messages when the remote's button is held down. The gap between
	// them is often also around 20+ms. This can result in the raw data be 2-3+
	// times larger than needed as it has captured 2-3+ messages in a single
	// capture. Setting a low timeout value can resolve this.
	// So, choosing the best kTimeout value for your use particular case is
	// quite nuanced. Good luck and happy hunting.
	// NOTE: Don't exceed kMaxTimeoutMs. Typically 130ms.
	#if DECODE_AC
	// Some A/C units have gaps in their protocols of ~40ms. e.g. Kelvinator
	// A value this large may swallow repeats of some protocols
	const uint8_t kTimeout = 50;
	#else // DECODE_AC
	// Suits most messages, while not swallowing many repeats.
	const uint8_t kTimeout = 15;
	#endif // DECODE_AC
	// Alternatives:
	// const uint8_t kTimeout = 90;
	// Suits messages with big gaps like XMP-1 & some aircon units, but can
	// accidentally swallow repeated messages in the rawData[] output.
	//
	// const uint8_t kTimeout = kMaxTimeoutMs;
	// This will set it to our currently allowed maximum.
	// Values this high are problematic because it is roughly the typical boundary
	// where most messages repeat.
	// e.g. It will stop decoding a message and start sending it to serial at
	// precisely the time when the next message is likely to be transmitted,
	// and may miss it.

[ithinkido]

Try: irsend.sendNEC(0xFF00FF, 32, 1);

Thanks for the help. Repeating the command is working for me .