Can't send NEC IR codes, but no problem for Sony or Samsung

Very simply, I have no trouble sending IR codes that are decoded using the IRremote library by Ken Shirriff. But I cannot get any codes decoded as NEC codes to be recognized.

For example, the Apple remote (that automatically launches iTunes on my Mac when I hit play) yields 0x77E120C5, but when I transmit it, nothing happens. Not so when I decode the code for my Samsung TV, which then transmits fine. Or my Sony DVD player.

I am using an Arduino Uno, with the latest IDE version and the latest versions of the IRremote library. On a Mac running Yosemite (I could not get any ports for the Arduino running El Capitan).

I have searched high and low on the web in general, and in this forum specifically, for someone else who has had a similar problem, but can't find anything.

Thanks

Some protocols require the code to be sent 3 times.

Have you tried sending the code 3 times sequentially?

Yes I have, 3 times sequentially, just as for the Sony, with a 40ms delay between each submission, and without the delay.

Show your code. NEC works fine for me.

#include <IRremote.h>

IRsend irsend;

void setup()
{
}

void loop() {
	for (int i = 0; i < 3; i++) {
                   irsend.sendNEC(0x77E120C5, 32);
                   delay(40);
	}
//	delay(5000); //5 second delay between each signal burst
}

The code I am sending was decoded from the play button of the Apple remote.

I am far too drunk to read it but here:

apple remote codes

this may help?

mamore:

#include <IRremote.h>

IRsend irsend;

void setup()
{
}

void loop() {
for (int i = 0; i < 3; i++) {
                  irsend.sendNEC(0x77E120C5, 32);
                  delay(40);
}
// delay(5000); //5 second delay between each signal burst
}




The code I am sending was decoded from the play button of the Apple remote.

How does it send anything if there’s no LED involved?

Aside from that,

"While the Apple Remote uses the NEC IR protocol for the timing, the 32-bit data package is in a different format. It consists of two 16 bit LSB words."

you code is looping continuously with a 40ms gap.

remove the for loop & send the signal once, but insert the 5 second gap

AnalysIR:
you code is looping continuously with a 40ms gap.

remove the for loop & send the signal once, but insert the 5 second gap

He was sending the signal 3 times rapidly, then pausing for 5 seconds. His code is fine if he uncomments the 5 second delay to get it working that way.

I replied to some of the helpful suggestions, but I don't see it, so forgive me if I repeat myself.

The assignment of the IR LED pin is "managed" by the library routines. Suffice it to say that the sketch works for Sony and Samsung codes.

I have tried all permutations of looping and delays, but to no avail.

As to the internal structure of the Apple remote format, I have wondered if that is the key, but I cannot figure out how the organization of 2 16-bit LSB words would materially affect the sequence of bits I transmit, as I am merely reproducing the sequence of bits the decoder receives?

try

irsend.sendNEC(0xEE8704A3, 32);

I hate to say it, that did not work either. With various permutations of repeating and delays.

By the way, how did you select that code? I have come across the EE87XXXX, but not the 04A3. It perhaps bears noting that the EE87XXXX that is published for the Apple remote bears NO RESEMBLANCE at all to the NEC code decoded by the decoder (instead, I get 77E1). What IS consistent, though, is the fact that it is only the 3rd byte that changes depending upon what key of the remote is pressed; everything else stays the same. In fact, it is only the first nibble of the 3rd byte that seems to change.

...flipping bit order based on one of the links posted earlier.

post the RAW output you get from IRremote (mark/space timings)

77E120C5
Decoded NEC: 77E120C5 (32 bits)
Raw (68): 9100 -4500 
650 -550 600 -1700 600 -1700 600 -1700 
600 -600 550 -1750 550 -1700 600 -1700 
600 -1700 600 -1700 600 -1700 600 -600 
550 -600 600 -550 600 -600 550 -1700 
600 -600 600 -600 550 -1700 600 -600 
600 -550 600 -600 550 -600 600 -600 
550 -1700 600 -1700 600 -600 600 -550 
600 -600 550 -1700 600 -600 600 -1650 
650

That is the raw data for the play. Laid out this way, reading each nibble from right to left, gives EE78 4032. This begins to approximate what is published for the Apple remote, but is not quite there. And I can't understand how the decoding can be so far off from what the published codes are.

Am I wrong in thinking that all I need to is just mirror back to the target device precisely the sequence (and timing) that the remote broadcast??

mamore: Am I wrong in thinking that all I need to is just mirror back to the target device precisely the sequence (and timing) that the remote broadcast??

You are correct. The Apple Rx device has no idea what code is being run on the Tx...it only cares about the frequency and period and timing of the flashing IR LED.

I could imagine a problem with the carrier frequency. Even if the usual 36, 38 and 40kHz are close to each other, they are slightly different (25-27,7µs), and the receiver chips with their hard coded filters may be a bit picky about such differences. A scope and an ordinary IR diode or transistor may reveal more details about the signals of a specific remote control.

Did you already test another (different type) IR receiver chip? The library can be tuned to such different carrier frequencies as well.

According to a comment in the IRremote library, another problem seems to be a delay in the hardware filter circuit, which can increase the received MARK time and reduce the SPACE times by 100µs (MARK_EXCESS). I already found differences of 50 to 150µs with my receivers.

Finally the expected/accepted values of NEC_BIT_MARK (560), NEC_ZERO_SPACE (560) and NEC_ONE_SPACE (1600) seem not to match your measured (raw) times, 600 and 1700 look better to me. But these values are not really critical, because the comparison allows for 25% variation (TOLERANCE).

Back to your problem, somebody seems to misinterpret the bit order. When decodeNEC reports 77E120C5, and you assume EE78 4032, all digits reflect the same bit pattern, only in LTR and RTL reading - except for the last 2=0010 and 5=0101 nibble. This last digit mismatch may be due to another bug, when (arithmetic) '-' is applied to the entire value instead of (binary complement) '~' somewhere.

If you (obviously) can receive NEC codes, the problem can only reside in IRsend. Here I suspect a bug in the library, because MARK_EXCESS is not used in sending MARK and SPACE! This will result in a duplication of the excess time, once in the reception from the original remote control, and once more in the device receiving the IRsend signal. So IMO in IRsend::mark() the time should be decreased by MARK_EXCESS, and incremented by MARK_EXCESS in IRsend::space(). Then the Arduino should emit the same signal as the original remote control. Unfortunately I don't have an IR LED or photodiode at hand, cannot verify my assumption just now. But you could update the library accordingly, and find out whether your problem disappears.

I decreased Mark by Mark_Excess and increased the Space by the same amount. No improvement.

mamore: That is the raw data for the play.

OK, I have imported your raw signal into AnalysIR and the HEX value is correct: 0x77E120C5

I have also cleaned up the signal and exported it again. Please try sending with sendRAW first and once that works you can try sendNEC.

As before, make sure you only send one signal at most every 5 seconds (no for loop or 40ms delay).

If that fails it is likely that your IR emitter circuit is suspect - so post what you are using & make sure to point the top of the IR LED directly towards the target device.

/*
Automatically Generated by AnalysIR - Batch Export Utility
https://www.AnalysIR.com/
Registered to: xxxxxxxx
Session History
Type : Key : Value : Bits : Carrier Frequency (kHz)
0 : NEC :  : 77E120C5 : 32 : 0
Note: Be sure to use the correct Carrier frequency, for each individual signal, as(or if) indicated above
*/

// NB: Not all protocols are supported by IRremote or IRLib. You may need to edit the code below manually
// Automatically Generated by AnalysIR for xxxxxxxx, visit https://www.AnalysIR.com/ or email info@....... for further details
int khz=38; //NB Change this default value as neccessary to the correct carrier frequency
irsend.sendNEC(0x77E120C5, 32); //AnalysIR Batch Export (IRremote) // AnalysIR IR Protocol: NEC, Key:  



unsigned int Signal_0_0[] = {9000,4500,560,560,560,1690,560,1690,560,1690,560,560,560,1690,560,1690,560,1690,560,1690,560,1690,560,1690,560,560,560,560,560,560,560,560,560,1690,560,560,560,560,560,1690,560,560,560,560,560,560,560,560,560,560,560,1690,560,1690,560,560,560,560,560,560,560,1690,560,560,560,1690,560}; //AnalysIR Batch Export (IRremote) - RAW

irsend.sendRaw(Signal_0_0, sizeof(Signal_0_0)/sizeof(int), khz); //AnalysIR Batch Export (IRremote) - RAW
 // AnalysIR IR Protocol: RAW, Key:

I really appreciate your effort.

Sending the cleaned up raw code DOES work!!

I have applied the values you used to the mark and space durations in ir_NEC.cpp, with and without the changes to take the Mark excess into account, but that still does not work. But now I am fully confident I CAN get it to work. I will tweak it as needs be (between sessions at my [paying] work).

Thank you. Is there any way I can repay you for your helpful spirit? Donate to a favorite website or charity?