I have a Pronto TSU 7000 that I’ve completely programmed from scratch. All of the buttons on all of the remotes from each component are learned and work great except for my DircTv H10 receiver. All of the buttons work but they require multiple presses or an extended press time on the Pronto.

A while ago, I posted here, on Remote Central, the problem and johnsfine asked me to post some learned HEX codes. I posted the HEX codes for digits 1 through 9, johnsfine modified them and posted them back. The modified codes worked flawlessly. (Thank you johnsfine) However, I’m still left with the “0” button that is unmodified. Needless to say, macros containing the digit 0 work miserably. Other command buttons work the same.

I took a look at how johnsfine modified digits 1 through 9 and tried modifying the 0 digit the same way. The button still works but there’s no change. The funny thing is, I modified the rest of the command buttons (list, menu, exit, guide, prev. etc..) the same way and they all work flawlessly. What is it with that darn 0?

Here is the digit “0” as it is learned on the pronto:

0000 006C 0001 000A 00E6 002E 002E 002E 0017 0017
0017 002E 0017 0017 0017 0017 0017 002E 002E 0017
0017 0017 0017 048C 0073 002B

And here’s how I modified it:

0000 006C 000A 000A 00E7 002E 002E 002E 0017 0017
0017 0017 0017 002E 0017 0017 0017 002E 0017 002E
002E 0017 0017 0477 0073 002B 002E 002E 0017 0017
0017 0017 0017 002E 0017 0017 0017 002E 0017 002E
002E 0017 0017 0477

Some notes:
1.I’ve changed the duration away from default to .2 all the way up to 1 sec. It was worse, so I went back to default.

2.When the 0 button is pressed and nothing happens, I’ve noticed that the RF6000 repeater isn’t even receiving the signal. Perhaps the pronto isn’t even sending it?

3.I’ve tried changing the channel and ID numbers on the RF6000 but there were no changes.

4.Although other command buttons acted just like the 0 button, after I modified them, they worked flawlessly.

Can someone please help? Is the 0 button on the H10 receiver an inherent problem? Why can’t it be modified to work like the rest of the buttons?
Thanks!

I had a lot of trouble with the forum search to find that other thread. But I found it.
[Link: remotecentral.com]

But I'm not on the right computer to give you a clean signal generated by MakeHex, so I tried manually rotating your learned zero. The result I get is:

0000 006C 000A 000A 00E6 002E 002E 002E 0017 0017 0017 002E 0017 0017 0017 0017 0017 002E 002E 0017 0017 0017 0017 048C 0073 002B 002E 002E 0017 0017 0017 002E 0017 0017 0017 0017 0017 002E 002E 0017 0017 0017 0017 048C

I don't understand what your modification (above) is supposed to be. So I can't tell if you're just misunderstanding a detail or missing the whole concept of manually changing such codes.

Look at your learned signal with parts identified by color:

0000 006C 0001 000A 00E6 002E 002E 002E 0017 0017 0017 002E 0017 0017 0017 0017 0017 002E 002E 0017 0017 0017 0017 048C 0073 002B

The black part is the header. That header says to send the red part once then send the rest (what I colored purple and blue) repeating.

But the correct signal consists of the red part followed by the purple part sent once, then the blue part followed by the purple part sent repeating.

If there were no timing glitches in NG Prontos, then sending a repeat of the purple part followed by the blue part would be just the same as a repeat of the blue part followed by the purple. Either way they alternate long enough that the end doesn't matter. In other words:

Red, Purple Blue, Purple Blue, Purple Blue, ...
would look the same as:
Red Purple, Blue Purple, Blue Purple, Blue Purple, ...
if there was no extra pause on the commas. There aren't supposed to be any extra pauses. But in an NG Pronto there are. So the results are different. So we need to manually "rotate" the signal as I did above.

I changed the header so the "one time" part of the signal was long enough for Red plus Purple, rather than Red alone. So then the "repeat" part starts at the Blue. So then we need an extra copy of the Purple after the Blue.

Wow, that's a lot to take in. Thank you for your time and effort. I'm really trying hard to understand Barry Gordon's article. From what I gather, the learned 0 in the pronto has a single burst pair for the first burst pair sequence and 10 burst pairs for the second burst pair sequence. I simply changed the header to 000A/000A to reflect 10/10 burst pair sequences and then added in the 1st burst pair sequence to equal 10 burst pairs. How can you tell which burst pair sequence is repeating and how do you modify a burst pair sequence to repeat? Also is the learned header incorrect? How do you know the correct signal is red/purple once followed by blue/purple repeating. Is it the same for most remotes?
Thanks for your help, johnsfine, it is greatly appreciated. I've learned a lot from you.

Right. And the first sequence is always the "one time" part and the second sequence is always the "repeating" part.

In some Pronto Hex strings, one or the other part might be zero pairs long. The third and fourth values in the header tell you the lengths of those two parts.

You did that correctly.

I can't see that in the Pronto Hex you posted.

Hopefully what I said above already explains that. The header gives the lengths of the two sequences, then those two sequences follow.

Depends on what you mean by incorrect. The learned header is consistent with the rest of the learned signal. The whole learned signal represents a correct enough Pronto Hex representation of the true signal. But unfortunately in a form an NG Pronto can't send correctly (because of the small extra pauses it injects).

Mainly because I've seen these signals in many forms before. But even if I didn't know that, I would have done the same manual transformation of the signal, because of a more generic rule:

If the Pronto Hex has any repeat part, then an NG Pronto can't send the signal correctly unless the repeat part ends with a large value (again because of those small pauses it incorrectly adds).

So I needed to rearranged the Pronto Hex into a form that ends the repeat with a large value, but which has all the same bursts sent in the same sequence (at least until you release the button).

No it's rare. Most IR protocols have patterns that would cause the NG Pronto's learning firmware to put the largest value on the end of the repeat pattern. Once learned that way, there wouldn't be a problem sending it.

Actually most IR protocols have the entire signal repeating (so the "one-time" part is zero length and the largest value is last.

0000 006C 0001 000A 00E6 002E 002E 002E 0017 0017 0017 002E 0017 0017 0017 0017 0017 002E 002E 0017 0017 0017 0017 048C 0073 002B

I changed 0001 to 000A making it 10/10 burst pairs. So we have

0000 006C 000A 000A

From there, I changed the lead in burst pair from 00E6 002E to 00E7 002E. I did this because it was consistent with the rest of the digits 1-9.

0000 006C 000A 000A 00E7 002E

I then continued the rest of burst sequence 1 until there were 10 burst suqences ending in 0017 0477

So now we have

0000 006C 000A 000A 00E7 002E 002E 002E 0017 0017
0017 0017 0017 002E 0017 0017 0017 002E 0017 002E
002E 0017 0017 0477

From there, I changed the 2nd lead in burst pair to 0073 002B because that was also consistent with the digits 1-9 So now we have

0000 006C 000A 000A 00E7 002E 002E 002E 0017 0017
0017 0017 0017 002E 0017 0017 0017 002E 0017 002E
002E 0017 0017 0477 0073 002B 002E 002E 0017 0017
0017 0017 0017 002E 0017 0017 0017 002E 0017 002E
002E 0017 0017

I then added 0477 at the end.

I didn't know about rotating the 1st and 2nd sequences. It's starting to come together but it will take some more practice. I downloaded Makehex but it seems very complex. Makehex would modify a learned code so that it will better? I'll have to figure out how that works.

BTW the modified 0 HEX code

0000 006C 000A 000A 00E6 002E 002E 002E 0017 0017 0017 002E 0017 0017 0017 0017 0017 002E 002E 0017 0017 0017 0017 048C 0073 002B 002E 002E 0017 0017 0017 002E 0017 0017 0017 0017 0017 002E 002E 0017 0017 0017 0017 048C

Didn't work at all. I'm still trying to see if I can modify it to work.
One last question. When the last duration in a signal's repeat pattern is short, how do you determine how long it should be?

MakeHex generates clean codes from the protocol name, device number and function number.

I first use the JP1 version of IrTool with DecodeIr.dll to try to find the protocol, device and function from the bad Pronto Hex and/or from other Pronto Hex of the same device.

Sorry. I'm still not at a computer where I can use my programs to find out whether I made some simple error in modifying that code.

I don't know. Since it isn't correct to just increase the last value and usually the best you can do is whatever value is largest, you just "rotate" the signal as I did to bring the largest last and hope that is good enough.