What devices did you use for that learning. You posted Pronto Hex, so one might guess you used some sort of Pronto to learn onto. But lots of other devices translate to of from Pronto Hex, so I don't want to guess. One might also guess you learned from the original remote, but maybe you used some other working remote to learn from.

The reason I ask all that is I think you posted a distorted signal. It may help to know what the real signal is. (But see below, you may be able to do the discrete search perfectly without knowing the exact signal structure).


Sorry. Lots of TV's have discrete codes via RS232 that they don't support via IR.


Usually that is a distorted learn of NEC1. I'm not certain it is ever anything other than a distorted learn of NEC1. I don't have access to most of the original remotes that DecodeIR can decode. I'm working primarily from learned data posted in various online sources and NEC12 is a rare but recurring pattern and exists in places where I can't tell whether the real signal was actually learned.

For most devices expecting NEC1 and/or most commands of a specific such device, NEC12 would work correctly despite not being exactly correct. So if it is all a learning error, ordinary users would likely never notice.

Anyway, the difference between NEC1, NEC2 and NEC12 can't matter to discrete codes (it can matter in non discrete codes and might matter a lot in incremental commands, such as CH+). But for discrete codes searching, NEC1 will be best. If NEC12 was a learning error NEC1 is correct. IF NEC12 is the true signal, NEC1 will still work right for any discrete command and any short press of a non discrete command.

The frequency might be a more serious difference. You signal is at Frequency=40000, but NEC1.irp has Frequency=38000.

Probably the frequency is a learning error and the original remote is really 38000.

Probably the actual device doesn't care whether the signal is 38000 or 40000 and either will work perfectly.

But, in the unlikely event that both the learning wasn't wrong, and the device cares, then you'll need to change the frequency line in NEC1.irp to make that work.

First test that function 0 as output from MakeHex does the power toggle (based on the decode of OBC 0 for the Pronto Hex you posted). If that works, the protocol and frequency are OK and you can try the other functions for discrete codes.


No NECx is a similar protocol, but different enough that using NEC instead of NECx or vice versa often fails. NEC12 is not NECx.