First notice that if IR transmitting in the NG weren't so messed up, the original one would have worked.


I assume you mean you understand the first four fields and understand that this signal has 12 decimal pairs sent once followed by 18 decimal pairs sent repeatedly.

Jon discovered that the correct signal has 18 pairs sent once and 18 pairs sent repeatedly and the two 18-pair sequences differ only in the 12'th pair.

The original learn has the correct first 12 pairs of the 18 to be sent once. Then it has 6 pairs doing double duty. They are encoded as the first 6 of the repeat part but they're actually the last 6 of both parts. Finally it has the 12 pairs that logically begin the repeat part.

To help visualize that, use the letters ABC to represent 3 groups of 6 pairs in the part to be sent once and AbC to represent the 3 groups of 6 pairs to be sent repeatedly, which differ at just one spot from the first set of 3x6.

Logically the signal should be ABC once with AbC repeating, but for some vey good reasons it was learned as AB once with CAb repeating. If you string those together, they're really the same as long as the key is held:
ABC AbC AbC AbC AbC ...
AB CAb CAb Cab CAb ...
Since the spaces I put there aren't really there, the two sequences are the same.

But, you observed that AB with CAb repeating didn't work, while ABC with AbC repeating did work. That needs to be explained.

I notice that in addition to rearranging from AB CAb into ABC AbC, Jon also increased the last duration in b a little (changed a 41 to a 47). Let's assume he knew what he was doing (generally a good bet). Then why in a learn this consistent and generally clean was a value that must have been about 47 in the original learned signal changed by so much?

My best guess is that the IR transmitting firmware is so slow in the NG Prontos, that it adds some extra duration on the repeat boundary. I'll then guess someone at Philips tried to compensate for that elsewhere in the process by subtracting a little from the stored signal at that same boundary. If so then they got the amount wrong. Without relearning the signal from an NG remote to a better learner, we can't be sure, but I think the gap on the boundary is the wrong duration.

Most protocols don't care at all about such tiny changes in a gap length. They especially don't care when those changes occur on a correctly aligned repeat boundary. This protocol needs to care about much smaller relative changes than other protocols do, but it still doesn't care about such changes if they hit on its repeat boundary. But the repeat pattern that a pure pattern match algorythm finds in this signal is CAb as described above. The true repeat is AbC. The protocol can absorb sloppiness at the end of each C but can't absorb slopiness at the end of each B or b.


This message was edited by johnsfine on 08/06/04 10:34.