Toggle Bits

[hoka]

This seems to be the issue:

Parity & Toggle Bits
A somewhat common problem is when a device (such as a cable box) will accept a learned code once but not twice in a row. For instance, you can enter the channel "1 - 2", but not "3 - 3". This is not a fault with your new remote, but rather a very hard to work with design employed by your equipment.
What happens is your original remote tacks on a "parity bit" (sometimes called a "toggle bit") to the end of each code. So, the first time it sends the code it follows up with a "0". The next time it ends with "1". The problem is that a learning remote can only learn or send the signal one way – the way it learned it. Your equipment, unfortunately, will not accept the code again unless it ends with a new parity bit or you send a different code to clear the memory buffer.

The most common example of equipment that uses this system is anything that employs the Philips RC5 or RC6 code format - such as Philips or Marantz products, or even Microsoft Media Center Edition remote controls. As the RC5 and RC6 implementation guidelines make parity bit checking optional, not all RC5/RC6 devices will respond the same way to non-alternating learned codes. Some may require parity bits at all times, some may only require it for certain commands (such as "power"), some may use the parity bit only for closely repeated commands (meaning you could send "3-3-3" quickly with the original remote but only slower using a learned code), while some ignore parity bits completely and show no noticable operational difference with or without.

The Philips Pronto is the only remote that I am aware of that can learn codes with alternating parity bits in the method required for several (not all) brands of equipment. If you have one that is not yet covered you can try tacking on a "do-nothing" code after each real one. So, your button for "3" would send the "3" code followed by another code to clear the buffer. What can that code be? Anything that the equipment senses as a real code but doesn’t affect operation. It may be next to impossible to find such a code.

If the brand is supported, most preprogrammed remotes will properly send parity bits. For example, database codes in the Home Theater Master MX-500 or MX-700) will work correctly with parity bits, but learned codes will not. For other universal remotes, there is not much you can do for this problem.

Is there a solution for this?

[jehill]

You have provided some interesting information! However, I have never experienced the problem myself. I just tried selecting channels 11, 22, 33, 44, 55, 66, 77, 88 and 99 using my L5 remote with learned numbers. There was no problem, except that channels 88 and 99 don't exist so the next higher channel was selected. I am using a Comcast provided DCT-3416 DVR. Could the problem be related to whether or not the "Channel entry method" is set to "Auto-Tune"? Typically, Motorola boxes will only respond to one or two digit channel numbers if "Auto-Tune is selected. Otherwise, you must press the OK/SELECT button after the digits have been entered, regardless of whether one, two or three digits are entered.

In order to select "Auto-Tune", initially I had to press the Menu button twice, select "Setup" and then "Guide Setup" and ensure that "Channel entry method" was set to "Auto-Tune".

[hoka]

I tried the numerical thing a long time ago, but the response was uneven sometimes it would switch to 77 (for instance) but sometimes it would just go to 7. so no luck there.
Using numbers is at best a work around, what needs to be solved is the Chanel up and down function WITH the "toggle bits"

[jehill]

Here is a work around that might work on the L5 remote:
1) Create two hidden buttons for each command that requires a parity bit.
2) Obtain the hex codes for the command with the parity bit set and and the parity bit clear.
3) Assign the hex codes to the two hidden buttons.
4) Create a macro for each command that requires a parity bit that presses both buttons.

The component should respond to one of the button presses. I would go to the Remote Central forums for help obtaining the hex codes required.

[hoka]

These HEX codes are nowhere to be found

[hoka]

I got the hex codes and asigned the two hidden buttons to a macro but now it switches two chanels every time I press the macro.
How do I make a macro that presses one OR the other hidden button?

[jehill]

You can't create a macro that presses one OR the other hidden button. My idea was to send both codes so that if one doesn't work the other should. If the macro switches two channels every time that you press the macro, it sounds to me like the parity bit is being ignored. Otherwise, I would expect that sometimes the macro would only switch one channel.

[hoka]

that's what I thought, if one (A) does not work the other (B) will but then (when B works) the one (A) works again thus resulting in two channel switches

I tried a delay for one of the commands but that works properly in only one of the two cases

I'm not smart enough for this stuff!

[jehill]

Since these are new codes, have you tried using one repeatedly? If that doesn't work, I suspect that what is happening is that the first code is always accepted, which means that the next code with the opposite parity will also be accepted; thus, no problem changing channels as long as it is a multiple of 2 away from the current channel.

[hoka]

they do not work on their own, it needs to be one followed by the other.

what I did now is create two remotes both with a macro button for channel up and down.
remote a has the macro : (channel up 1 - Jump to remote B) and remote B has the macro : (channel up 2 - Jump to remote A)

so far this is doing the trick but it is a bit complicated