On May 23, 2007 at 00:50, Lyndel McGee said...
The code you posted follows the NEC protocol.
Correct. It is NEC1 protocol, device 124, function 131 (as you determined from the pdf file).
(See Barry
Gordon's document in the Classic Pronto Files Section,
User Documentation Subsection on the Pronto Hex IR format)
Why should an ordinary user look at that? He has no reason to want to know the internal structure of a Pronto Hex string.
If you want to decode a Pronto Hex string (find out the protocol, device and function) use IrTool and DecodeIr.dll
[Link: remotecentral.com][Link: john.fine.home.comcast.net]So, you can use MakeHex and the file NEC1.irp to generate
a set of codes. Edit this file to use Device 124 and
then generate all functions 0..255. From there, you should
be able to take function 131 and test it to see if it
will work. Bet it does!!!
I agree. But two more comments:
1) Notice the learned signal is modulated at 36Khz, where NEC1.irp specifies 38Khz. Probably the learning is wrong and 38Khz is correct. But maybe this is an unusual device and 36Khz is correct. Probably the IR receiver in the device doesn't care much whether the modulation is 36Khz or 38Khz. But maybe it cares. Most similar IR receivers have a spec saying that a 10% error in modulation frequency degrades the signal the same amount as a factor of two increase in the distance between the remote and the device. Both of those (frequency error and distance) multiply their effects with each other and with degradation due to the signal angles. This 5.6% error in frequency (36 vs. 38) might have detectable consequences at some angle and distance.
2) See instructions in the MakeHex readme for geting MakeHex output labeled in hex rather than decimal. That should be easier than individually translating each function code from the pdf from hex to decimal.
