I just got a HP Media Center PC, and learned the codes into my Pronto. Here's the weird behavior: For any cursor movements, I cannot repeat the same direction two times in a row. So, if I do UP, I cannot do an UP again (???), unless I do another code first. So I can do left right up down etc, as long as I don't do two operations in a row, no matter the length of time between them. I don't have this problem with the original remote. So, what's going on?

That's the standard behavior for IR protocols that include a "toggle bit".

There are two different versions of each command. When you give the same command twice in a row, the device requires that you alternate between the two versions.

Post a couple samples of the Pronto Hex here for help with a protocol specific solution.

For some toggle-bit protocols the Pronto has special support built in, so you can replace the regular learned signal with a special form that makes the Pronto do the alternation.

For other devices, it is best to find a "do nothing" command and then edit all the learned signals, so they each send the correct command followed immediately by the "do nothing" command. When you press the same command again the device doesn't see it as twice in a row, because of the "do nothing" in between, so the device doesn't require the alternate version.

There are at least two other basic approaches to solving the problem that may be appropriate in more difficult cases.

Thanks. I now remember something in the distant past about toggle codes. Never had to deal with them though.
It looks like my remote is full of them. I can't even do volume consecutively.

I'll post two codes, UP Cursor and Down Cursor.

Up Cursor:
0000 0072 0000 0022 0060 0020 0010 0010 0010 0010 0010 0020 0010 0020 002f 0021 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0020 0011 0010 0010 0010 0010 0010 0010 0010 0020 0010 0010 0010 0010 0010 0010 0020 0020 0010 0010 0010 0010 0010 0010 0010 0010 0020 0011 0010 0010 0010 0010 0010 0020 0010 09c7

Down Cursor:
0000 0072 0000 0022 0060 0020 0010 0010 0010 0010 0010 0020 0010 0020 002f 0021 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0020 0010 0010 0010 0010 0010 0010 0020 0010 0010 0010 0010 0010 0010 0010 0010 0020 0021 0010 0010 0010 0010 0010 0010 0010 0010 0020 0010 0010 0010 0010 0010 0010 0010 0010 09d7

So, what would you suggest next?

The protocol (in the terminology currently used by the JP1 group) is RC6-6-32. The device is 128. The commands are 30 and 31.

I don't recall what support (if any) a Pronto has for signals that are in the RC6 family of protocols but aren't the specific "RC6" protocol normally used by Philips.

Maybe one of the other experts will jump in with that answer.

If there isn't built in support for this, I think there's another way to get it handled perfectly.

In a thread long ago, Eigeny Oulianov figured out how to make a signal with correct toggle behavior in a protocol that had the same bit timing as RC5 but didn't have the same frame structure as RC5. The same approach would work for a signal that has RC6 bit timing but doesn't have the same frame structure as the restricted subset of RC6 that the Pronto considers to be "RC6".

I made the suggestion that got Eigeny to do that, so I understand the basic idea, but there were a couple details I didn't know how to handle. Even after seeing how Eigeny did it for RC5, I'm still not certain how to do that for RC6. Maybe some expert will remind me of a simpler way (as I suggested above). If not, then maybe you can ask Eigeny for help. If none of that goes anywhere, I'll dig up the thread where Eigeny did that for the RC5 like protocol and probably I'll be able to figure it out for RC6.

(For most toggle-bit protocols I would have had the answer immediately).

One more detail: There are a few devices that use a form of RC6 but toggle the wrong bit. We'd need to know that in order to get this right. To find out which bit toggles, you must learn the same command at least twice in a row (without any extra key presses on the original remote in between) to different keys in the Pronto, and post those. Then we can see which bit really toggles.

As luck would have it, I re-learned the codes, and uploaded them, and apparantly found the "toggle bits":

Here are my new UP and DOWN codes:
Up:
0000 0072 0000 0022 0060 0020 0010 0010 0010 0010 0010 0020 0010 0020 002f 0021 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0020 0011 0010 0010 0010 0010 0010 0020 0010 0010 0010 0010 0010 0010 0010 0010 0020 0020 0010 0010 0010 0010 0010 0010 0010 0010 0020 0011 0010 0010 0010 0010 0010 0020 0010 09c7

Down:
0000 0072 0000 0022 0060 0020 0010 0010 0010 0010 0010 0020 0010 0020 002f 0021 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0020 0011 0010 0010 0010 0010 0010 0010 0010 0020 0010 0010 0010 0010 0010 0010 0020 0020 0010 0010 0010 0010 0010 0010 0010 0010 0020 0011 0010 0010 0010 0010 0010 0010 0010 09d7

Comparing with the sequences above, you can see that Words 44 and 46 change. For "UP" They change from 0010 and 0020 in one sequence to 0020 and 0010 in the next. Same thing in "Down".

I'm a complete novice at this, but I assume all of these codes toggle like this, since these both sample the exact same bits. This may be a stupid question, but can I just create the twin of one of these on a text editor and append it in to the IR window of the command I already learned? The command would be twice as long, but would have both toggles.

Well, I tried that, and just get an error message that says "Data does not define a Valid IR code". I guess it's not that simple.

John, the Pronto supports directly something it calls RC6 mode 0 and something else called RC6 mode 6a

the 6a has three fields
customer code
system
command

You can splice together two commands. It's a little harder than just tacking the Pronto Hex of one after the Pronto hex of the other, because the first four numbers of the Pronto Hex are a header. You need to change the first header and discard the second header and splice the rest together.

But you don't want the two versions of one command put together that way. That would always send the command twice. You want to send the command once, but then leave the remote ready to send it correctly the next time.

One solution to a toggle-bit problem is to find a "do nothing" command in the same protocol and splice it onto the end of each real command, so the device never sees the same command twice in a row. One problem with that approach is that it's hard to get the normal "repeat while held" feature of the remote to work right.

Another solution is to have two identical looking panels and have opposite versions of each command on the two panels and have an automatic jump to the other panel after each button press. With a Pronto, I think that solution completely kills the repeat while held feature.

This protocol does toggle the wrong bit (vs. the defined RC6 standard). I think it is exactly the one helped someone else with quite a while back. I don't remember who or where, but it must have been for a JP1 remote, because I don't think I ever learned the details needed to do this for Pronto. Have you tried to contact Eigeny to see if he'll join this thread? He just knows the details I'd need to research.

This is defintely some kind of "mode 6" (vs. regular RC6, which is mode 0). I don't know what Philips means by "6a". It's encouraging that 6a has an extra field because this RC6-6-32 does have an extra field vs. normal RC6. But I wouldn't know what to put in those three fields to try to duplicate these signals. I don't own any model of Pronto. Do you or someone else in this thread have two Prontos or a Pronto plus some other IR learning device?

Assuming no other expert jumps in with an explanation of mode 6a, it would be nice to enter a few mode 6a signals into a Pronto with different customer code, system and command numbers and then learn them to another remote and decode the results and see if they are RC6-6-32 and if so, then which field is which.

Also I'm worried because this protocol toggles the wrong bit. I wouldn't expect Philips to toggle the wrong bit, so even if mode 6a were RC6-6-32, it still probably won't work.

I just suddenly remembered something from the last time this came up, which is that it was a Microsoft product in which the wrong bit of RC6 was toggled (as you'd expect) but someone in that thread had a plausible sounding claim that it wasn't actually Microsoft's fault that the wrong bit was toggled.

You might try using codes that were for Streamzap as well. They use an extended RC6 scheme. Eigeny developed a CCF for me using Pronto's 7000 IR code series that also worked on my Marantz.

Search for Streamzap in this forum and in the file forum. If you can't find a Streamzap file email me and I can reply with the file to try.

Lyndel

Lyndel, thanks for the reminder. You made it easy for me to find the right thread
[Link: remotecentral.com]

I hadn't searched before because I didn't know which words to search for.

But you're wrong about "extended RC6". Streamzap is an extended form of RC5 not RC6. There is no chance that the streamzap signals will work this device. The best shot is for someone to do to this protocol what Eigeny did for Streamzap in that thread.

I really appreciate everyone's help on this.

Actually, I already resorted to using a "do nothing" command last night, which I found to be "Clear". Work's well with 90% of my commands. The commands it doesn't work well with are cursor up & down and page up & down commands. Well, it "works", but these commands are ones where "repeat while held" are nearly essential, since they will be used for speeding through long album and song lists. All other commands I can live with the discrete nature of the command. If I ever want to use the numerical inputs, then I'd be hosed, but currently I have no plans for that.

I saw a thread by Eigeny, and sent him a message (to a hotmail address). Don't know if that's the right one, maybe I'll try again.

Hmmmm.....if the reason that appending two commands together doesn't work is that I will always get at least two commands for cursor up/down, but I am principally interested in fast "repeat while held", I wonder if I can use the appended command for fast scrolling, and another button for fine tuning (using my do nothing command).

So, to append these together, what specifically would I have to do? I'd give it a try!

More news: I was searching MS web-site, and came across a forum dedicated to Windows Media Center Edition called "the greenbutton". Evidently, Microsoft had a forgiving IR receiver in the original MCE, but went to requiring toggle mode in MCE 2004.

[Link: thegreenbutton.infopop.cc]

is a link that claims that if I follow these directions, the PC will no longer require toggled signals. Others have said they tried it and it works. I'll let everyone know the outcome tonight...

Bad news...kind of. Baiscally, the driver is still on some MCE PCs, not mine once I upgraded to 2004. Others who had upgraded may still have the file saved, see the instructions. Now I'm trying to find someone who had the old irbus.sys driver.

Even worse news. I contacted HP (my PC manufacturer)and requested the old IR driver. They basically refused, and said that if the PC works with my HP remote, that's good enough, and I should contact the maker of my universal remote, and get the driver for that remote from them. Hmmm.....they clearly don't understand what I requested or what the problem is.

So, has anyone gotten this patch? Can it be emailed to me? I'm running out of alternatives. Maybe I'll have to go back to merging two commands together.