On January 31, 2006 at 06:12, lferle said...
Why these controls have problems to learn some
IR codes?
And why the display shows "OK" and after it doesn't
work ?
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.
On January 28, 2006 at 17:19, Lyndel McGee said...
Did you try this file for the Carrier?
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.
On January 28, 2006 at 08:28, lferle said...
I have an air conditioner Springer Carrier model
40 GKX to learn into Pronto TSU3000.
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.
It is almost the same problem, but with Marantz
RC 5400 and air conditioner GREE (remote model
Type Y512).
Those are the two samples you posted?
I thought that should be the frequency out of
range from air, but I didn't find the air's IR
frequency. Do you know if the Pronto TSU 3000
has the same learning frequency than Marantz RC
5200 from 56Khz until 455Khz ? and what I need
to do ? Is possible use the air codes in my Pronto
??
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
Last edited by johnsfine
on January 31, 2006 10:04.
