If you paste in Pronto Hex that contains any intervals over 32768 microseconds, you get incorrect results. It reduces those intervals module 32768.

Often it makes no serious difference. 32768 microseconds is a long time for an IR interval and once you get that long the receiving device won't care between one long value and other. If it ought to be 50000 and it's reduced to 17232, no harm done.

Sometimes it wrecks the whole signal. If an interval ought to be 33000 and it gets reduced to 232 the result won't work.

Someone who actually has this remote (I don't) might want to mention this to RTI support. I saw an old thread here that someone reported the symptoms of this (without the internal details descibed above) to RTI support and got no response.

Meanwhile, if the problem hits you, there is a decent work around. There are (recently improved) tools for decoding Pronto hex into the form used by the MakeHex program. MakeHex can then re encode to clean Pronto hex. A small edit to the .IRP file would let MakeHex encode to Pronto hex which is immune from this problem.

If you edit the .IRP file so the largest interval(s) will be reduced to about 30000, you will get good results. As described above, reducing a very big interval to 30000 doesn't harm the signal, but letting the bug do its modulo 32768 might reduce a big interval (such as 33000) to a very small interval.

I haven't looked a MakeHex in years. If you need help with that or with .IRP files, the leading expert is jarmstrong who often helps people with MakeHex issues in the "Discrete Hunter" forum at
[Link: remotecentral.com]