A typical IR signal has a beginning part sent once followed by a repeating part. As the remote records an incomming signal during learning, it attempts to identify the repeat part and only store that once.

The method used by the Pronto firmware to identify the repeat part isn't very smart and it often gets that wrong. In the two Pronto Hex samples from Post 1 of this thread it is clear that the firmware has taken a portion of the beginning part of the signal and incorrectly reduced it as if it were the repeat part. Unfortunately it is not clear what the original signal looked like before that damage.


I am currious to hear whether that worked.

I looked at the signals in that file. I can see that they are the same protocol as the ones that were incorrectly learned for post 1, but they are NOT the same signals (as those would have been if learned correctly).

Maybe there is a difference in the signals between models, in which case it will be harder to use the information from that CCF to help repair the signals for your model.

More likely, the original remote remembers details about the intended state of the device and encodes those details within the signal. So what Luis and the creator of that CCF have both identified as a "Turn On" command is not just a turn on command. It is "turn on" combined with reminding the device about several other settings. So the big difference (other than correctly vs. incorrectly learned) between those two examples of the turn on signal, is the difference in the remembered state of other settings.


Do I understand correctly that you have NOT shown us an PRonto Hex from those learn attempts? Those Pronto Hex samples might Help us figure this out, even though we know they're wrong.


Those are the two samples you posted?


There is no problem with frequency. All these signals use a common frequency that any learning remote can handle without problem.

The problem is the length of the initial part of the signal. It is longer than a typical IR signal, giving the firmware more of a chance to get confused and imagine a repeat pattern where it isn't.

I don't know if these signals have a repeat pattern. Hopefully not. The good learns in that CCF have just a long initial part and no repeat part. The bad learns that have a repeat part all have an incoreect repeat part that is really a portion of the initial part. If there really is a repeat part, it is after the long initial part, beyond what any of the Pronto's learned, and probably not critical for correct operation.

In any case, generating a signal from correct Pronto Hex is much simpler than learning that same signal. I think any Pronto can generate this signal correctly if we figure out the correct Pronto Hex, even though it seems like your firmware version can't learn these signals.

BTW, in using that CCF please note that some of the signals are bad learns. Most seem to be learned correctly, but the following commands are not correct:
Mode Fan
Mode Dry
22
23
26