JP1 Remotes

I've discovered some strange behavior in the RC5 protocall which I think is an error, but I'm not sure. I'm reporting this to see if anyone else has noticed it, and also to see if it can be fixed.

I've had a Philips widescreen TV for about 6 months. I've been controlling my system with a URC-8810. The TV uses the RC5 protocall. I've been noticing occasional strange behavior from the TV every once in a while, usually along the lines of one command in a macro not being executed. Usually it would fail to either power up or down when I executed my global "system power" macro. It worked about 75% of the time, and the other 25% I'd have to manually press "TV" then "Power" to get it synched with the rest of my components.

After adding a new DVD player to my system I had to do a bunch of reprogramming, including exploring some new special protocalls and using an extender. All of a sudden the TV was missing comands all over the place. I experimented with adding delays between commands, and varying the duration of the TV button presses, but the strange behavior kept reoccurring. I finally found a very obsure bug that causes the TV to miss commands in very specific circumstances.

First, how the RC5 protocall is supposed to work (from what I have gathered): Each time a button is pressed on the factory remote, a bit in the infrared pulse train is flipped. Both the TV and the remote need to have this bit in sync, or the TV ignores the command. This bit is flipped every time any key is pressed on the factory remote.

For example, using the factory remote:
POWER: TV turns on
POWER: TV turns off
The TV and remote stay in sync.

Next example:
POWER: TV turns on
POWER with LED blocked: nothing happens
POWER: nothing happens
POWER: TV turns off.
Pressing POWER with the LED blocked gets the TV and remote out of sync. The next POWER command doesn't do anything, but re-syncs the TV and remote. The last POWER command works normally.

Using the 8810 remote,
TV
POWER: TV turns on
POWER: TV turns off

and

TV
POWER: TV turns on
POWER with LED blocked: nothing happens
POWER: nothing happens
POWER: TV turns off.

Just like the factory remote, as we expect. But, look what happens when we do this:
TV
POWER: TV turns on
VCR
POWER: TV does nothing
TV
POWER: TV does nothing
POWER: TV turns off.

Issuing the VCR power command (completely different protocall) has caused the RC5 bit to flip, even though no RC5 command was entered. Look what happens if we add another POWER command to the series:
TV
POWER: TV turns on
VCR
POWER: TV does nothing
VCR
POWER: TV does nothing
TV
POWER: TV turns off.

It looks like everything is functioning normally when actually the RC5 bit is getting toggled each time POWER is pressed.

It appears that the same command key needs to be pressed repeatedly for this to happen. When another key is pressed, the RC5 bit stops flipping:
TV
3: TV responds
3: TV responds
VCR
3: TV does nothing
TV
3: TV does nothing
3: TV responds

TV
3: TV responds
3: TV responds
VCR
3: TV does nothing
3: TV does nothing
TV
3: TV responds

TV
3: TV responds
3: TV responds
VCR
3: TV does nothing
0: TV does nothing
3: TV does nothing
TV
3: TV does nothing
3: TV responds

TV
3: TV responds
3: TV responds
VCR
3: TV does nothing
3: TV does nothing
0: TV does nothing
3: TV does nothing
TV
3: TV responds

An even number of repeats is OK. An odd number of repeats looses sync. What's really freaky is that the RC5 bit gets out of sync only for the key that is repeated. Look at these two results:
TV
3: TV responds
3: TV responds
VCR
3: TV does nothing
TV
3: TV does nothing
3: TV responds

TV
3: TV responds
3: TV responds
VCR
3: TV does nothing
TV
POWER: TV turns off

You can see how this can play havoc with RC5 commands when macros get involved. This was my original "system power" macro:
TV;Power;VCR;Power;RCVR/AMP;Power;CBL;Power;TV;0;3;CBL
Press once to turn everything on, and press again to turn everything off. I could never figure out why half the time it worked, and half the time the TV either wouldn't turn on or off. I thought maybe the VCR power command was messing things up, so I changed it to this:
VCR;Power;RCVR/AMP;Power;CBL;Power;TV;Power;0;3;CBL
Suddenly everything worked, so I patted myself on the back and moved on. In reality, by moving the TV Power command to the end of the macro, I was keeping the RC5 bit from being flipped an odd number of times and getting out of sync.

Remember how I said that my problems came back all of a sudden? It's because I believed the extender would have fixed whatever timing problems I had with the original "system power" macro, so I changed it back to this:
TV;Power;VCR;Power;RCVR/AMP;Power;CBL;Power

Bingo, RC5 sync bit is messed up again. This is when I stopped and did the troubleshooting cases shown above. Now that I understand what is going on, I fixed the problem with this macro:
TV;Power;TV;0;TV;3;VCR;Power;RCVR/AMP;Power;CBL;Power

This breaks up the sequential pressing of the Power keys. Note that just moving the TV Power command to the end is OK except when the macro is executed twice in a row. The second execution puts the RC5 bit back out of sync, and the TV won't turn off.

Hopefully this is some help to people trying to work out intermittant, bizarre problems like I was having. Maybe the RC5 protocall can be tweaked to fix the problem.

cheers,
Todd Ferrante

Todd,

See if this explanation explains the behavior you are seeing. The RC5 protocol has a toggle bit. Each time you press and release a button one bit toggles.

For the SAME succesive key, the IR receiver must see the bit change or it doesn't interpret it as a new command. if you cover the transmittter for one button push and try the same button again, then it will not work.

BTW, on TV/0054 have you tried EFC's 018=On and 082=Off?

Thanks for your quick response, Jon. I think my longwindedness has obscured my point.

jon_armstrong wrote:The RC5 protocol has a toggle bit. Each time you press and release a button one bit toggles. For the SAME succesive key, the IR receiver must see the bit change or it doesn't interpret it as a new command. if you cover the transmittter for one button push and try the same button again, then it will not work.

This was how I understood the RC5 protocall to work. I expected that the RC5 protocall, as implimented in the remote itself, to only toggle the RC5 bit if an RC5 command was sent.

Given a TV device using protocall RC5 and a DVD device using protocall RC6, both turned off, and this sequence of keypresses:

TV
POWER
VCR
POWER
TV
POWER

I would expect the VCR to be on and the TV to be off. The RC5 bit should only toggle when a TV (RC5) command is sent, not when a VCR (RC6) command is sent.

Instead of the expected result, what actually results is both the TV and VCR turned on. The second TV command is ignored (by the TV) because the VCR Power command toggled the RC5 bit.

jon_armstrong wrote:BTW, on TV/0054 have you tried EFC's 018=On and 082=Off?

As a matter of fact, when I was searching for discrete AV input codes on my TV I did confirm that these discrete On and Off codes do work. I posted the complete list of working codes not found on the factory remote here.

Todd F.

Todd,
I started to read your post but then checked to see just how long it was and gave up. I mention this only because I suspect others may have done the same. If you can find a way to re-word it in 500 words or less, it might be helpful!

I think Todd's second post was succinct, but I think the problem may stem for the way RC5 and RC6 devices interact and respond to both RC5 and RC6 commands. I need to tackle this problem with a fresh mind

Jon,
Thanks for taking a look.

I gave the second device RC6 as a simplified example, but it seems to happen with all other protocols (at least the ones my components use), not just RC6.
Todd F.

I think you'll find that Todd is correct. The UEI remote toggles an internal bit every time a button that invokes a protocol is pressed, regardless of what protocol is used by the button. The RC5 protocol simply looks at this internal bit to determine which way the IR bit is to be transmitted.

Todd,

It seems like a solution to part of the problem would be discrete power commands. You could simply send the command twice.

As Mike confirmed, for the other commands, you may have to use dummy commands, now that you know that the remote will flip the bit every command regardless of whether the command sent has a toggle. I assume a phantom button in a macro will cause a toggle?

Will that solve the problem? Most DVD players will turn On with the Play command. If so, Play|stop=On and Play|Power Toggle is Off.

For RC6 EFC's 171 and 187 are Off and On (OBC 61 and 63). Some Marantz DVD's use RC5x commands for power.

If you tell us the brands of the other equipment we can help with discret commands if you haven't found them yet. Also on the Philips displays, there are a couple of ccf files at the pronto.philips.com website and I think I know the universe of input commands. They use the same six or seven commands, but it varies by model what they actually do.

jon_armstrong wrote:you may have to use dummy commands, now that you know that the remote will flip the bit every command regardless of whether the command sent has a toggle. I assume a phantom button in a macro will cause a toggle?

Everything the remote thinks is an IR signal will toggle the state. It doesn't matter whether it's triggered directly from the keyboard or from inside a macro. It doesn't matter whether it's a normal keycode or a phantom.

The device select commands (device keys without an extender, or the extender specific commands) are NOT seen as IR signals and do not toggle.

A phantom with nothing assigned to it is not seen as an IR signal and doesn't toggle.

The key invoking a DSM or LKP (or other KeyMove that pretends to be a macro) is normally seen as an IR signal (even though it actually isn't) so it would toggle the state an extra time (beyond what the keys inside it do), except for most such protocols we went to some extra effort to cover that up, so the toggle state matches real signals and doesn't include that extra.

Simple "special protocols", such as those in the special protocol spreadsheet do not include corrective code to fix the toggle state, so they do induce a toggle even though they don't send an IR signal. If you need to bump the toggle an extra time to compensate for problems in the toggle bit (from device switches) you might find using a special protocol is cleaner (and executes faster) than sending a dummy signal. If you got the right register number and value from the author of whatever extender you're using, you could even use the "advanced select" protocol instead of one or more of the device select steps in order to merge a device change with a bump of the toggle state.

mr_d_p_gumby wrote:The UEI remote toggles an internal bit every time a button that invokes a protocol is pressed, regardless of what protocol is used by the button.

johnsfine wrote:Everything the remote thinks is an IR signal will toggle the state.

Mike and John,
From my testing, I think these statements may be mistaken. I need to get home from work to test more definitive counterexamples, but here is one:

TV
3: TV responds
3: TV responds
VCR
3: TV does nothing
TV
3: TV does nothing

Just as we expect, but look at this:

TV
3: TV responds
3: TV responds
VCR
3: TV does nothing
TV
POWER: TV turns off

A second counterexample is in my solution to my "system power" macro problem. The macro that gives me problems is:

TV;Power;VCR;Power;RCVR/AMP;Power;CBL;Power

I changed it to this and the problems went away:

TV;Power;TV;0;TV;3;VCR;Power;RCVR/AMP;Power;CBL;Power

The only difference is the addition of two IR commands after the TV Power command. If the bit toggling worked the way you are saying, both macros should leave the TV out of sync after the macro is executed the first time. In actuality, the second macro works every time it's executed.

Todd F.

ToddF wrote: From my testing, I think these statements may be mistaken.

You missed an important rule about the device receiving the command. Our description of the toggle behavior was for the UEI remote sending the command.

Each RC5 signal has a toggle bit and a command number. The receiving device ignores a signal if it has the same toggle bit AND the same command number as the previous command.

So you only need to worry about the toggle bit when you want to send the same command twice in a row to a device.

Since the tests you described earlier highlighted that behavior, I assumed you understood that part and not the part about what the remote was sending.

Jon,

Thanks for the discrete power commands suggestion. Like I said in the post above, I actually solved my macro problem. My new macro never gets the TV and the remote out of sync because it does not allow an RC5 IR command to be directly followed by the same button press. This seems to have completely solved the out of sync problems (thus far, anyway).

Todd F.

johnsfine wrote: You missed an important rule about the device receiving the command. ... you only need to worry about the toggle bit when you want to send the same command twice in a row to a device.

John,
You are right. I did not know this. Thanks for pointing it out. I'll have to think through this behavior and how it relates to what I was doing.
Todd F.

I did a couple more test cases that show that John and Mike are right about how the bit is toggled. It is flipped on every IR command, not just when it is the same key pressed.

TV
3: TV responds
3: TV responds
VCR
0: TV does nothing
TV
3: TV does nothing
3: TV responds

TV
3: TV responds
3: TV responds
VCR
0: TV does nothing
0: TV does nothing
TV
3: TV responds

So, the key to preventing the out-of-sync condition introduced by the URC remote is this: Do not allow an RC5 device to receive the same IR command twice in a row if any other protocall IR commands have been issued. If you allow this to happen, you have a 50-50 chance that the remote will be out of sync with the RC5 device, and the command will fail. No big deal if you are doing something like manually changing channels, but in a macro, things can really get screwed up.

I inadvertantly solved my macro problems (twice) by following the TV power command by a channel change to 03. It is extremely unlikely that after using my system for music, TV watching, movie watching, etc. that the next TV command would be "3". Therefore, the out-of-sync condition never caused the next RC5 command to fail.

The whole RC5 out-of-sync issue can be avoided by making the last IR command sent to an RC5 device in a macro be something very unlikely to be repeated.

Or the RC5 protocall could be modified to have it's own flag bit that only flips when an RC5 IR command is issued. But, that's probably a lot of trouble to go to.

Thanks for the help, all.
Todd F.

ToddF wrote: The whole RC5 out-of-sync issue can be avoided by making the last IR command sent to an RC5 device in a macro be something very unlikely to be repeated.

But as you said earlier, it's not the manual step after a macro where the sync issue is serious, it's the manual step before the macro that's serious.

So you want more care to start a macro with a command that is very unlikely to be the last used manual command.

Most devices with toggle bits predecode every command with the right device number, even if the OBC doesn't correspond to anything they understand. So the device's internal "last command number" setting can be set to command numbers the device otherwise ignores.

So the extreme solution may be to find some OBC that the device "ignores" and send that at the start (maybe also at the end) of a macro so that any command can safely follow it in either toggle state.