IR trouble with the Pace DCR7111 (UPC mediabox)

This week we got a new UPC Mediabox; the old Thomson DCI52UPC02 was replaced by a Pace DCR7111(/03). The Thomson was constantly updating itself, went into reboot-loops where only disconnecting power sometimes helped to get it going again. After I finally managed to get in touch with UPC support, 2 days later the new box arrived.

My biggest concern was whether this new Pace box would still work my Pronto/IRTrans combo; would it accept the same Infrared (IR) codes as the Thomson? A quick test revealed that the old Thomson remote could be used to control the new Pace, so at that point I didn’t expect any problems.

Later that evening, when I used the Pronto to control the Pace mediabox, I discovered that the “CH+” and “CH-” buttons of the Pronto didn’t work anymore. To be precise: the first “CH+” did work, but the second time it didn’t…huh? The “CH-” had the same wierd behavior.. first push OK, the second was ignored; and the 3rd, 4th… So selecting a channel with a digit (0..9) did work as before, but zapping through all the channels didn’t? What the ….?

Hmm, time for some investigation. First thing I did was trying to find the Pronto CCF codes for this new model, but that didn’t help. Later I found out that this Pace uses the same IR codes as a Philips DCR-8111 but I couldn’t find any IR codes for that model either.

Well, back to the original symptom then – why do the CH-buttons only work once? After some time I found the cause in a post on the L5 remote forum:

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.

Great, this sounds exactly as what I’m experiencing. Parity (toggle) bits… and the new Pace doesn’t ignore them!

Now that I know what is causing my problem and how it works, I should be able to create a workaround; I can stop searching for the correct IR codes for the CH+/CH- buttons, because a single IR code for a CH button will never work. Instead, I will need to get hold of both IR code ‘versions’ for a single CH button and make sure my system will automatically alternate between those 2 versions.

How do I get those 2 codes for a single button? Well,  PEP1 (Pronto Edit Professional v1) and a Pronto Remote (a TSU9600 in my case) enables you to learn a IR code. So that’s what I did; I learned  a couple of CH+ IR codes, copied the resulting CCF codes to a text editor and searched for differences; and found the 2 different versions for CH+:

[up1][CCF]
0000 0072 0024 0000 000F 000A 0006 000A 0006 0016 0006 000A 0006 000A 0006
001C 0006 000A 0006 000A 0006 000A 0006 0016 0006 0016 0006 0010 0006 0016
0006 000A 0006 0016 0006 000A 0006 000A 0006 0CB7 000F 000A 0006 000A 0006
0016 0006 000A 0006 000A 0006 001C 0006 000A 0006 000A 0006 000A 0006 0016
0006 0016 0006 0010 0006 0016 0006 000A 0006 0016 0006 000A 0006 000A 0006
BEA1

[up2][CCF]
0000 0072 0024 0000 000F 000A 0006 000A 0006 0016 0006 000A 0006 000A 0006
001C 0006 000A 0006 000A 0006 000A 0006 000A 0006 0016 0006 0010 0006 0016
0006 000A 0006 0016 0006 000A 0006 000A 0006 0CB7 000F 000A 0006 000A 0006
0016 0006 000A 0006 000A 0006 001C 0006 000A 0006 000A 0006 000A 0006 000A
0006 0016 0006 0010 0006 0016 0006 000A 0006 0016 0006 000A 0006 000A 0006
BEA1

There’s definitely a difference between those 2 codes, marked in red; so far things are looking good. Now it’s time to test these 2 codes by sending a up1, up2, up1, up2 IR sequence to the Pace mediabox. Yep; the channel increased 4 times – it worked!

The rest is simple. My system uses the IRTRans ASCII interface protocol for sending IR with the IRTrans LAN module. The IR commands that can be used are not predefined in my Domotica system however; they are retrieved from the IRTrans by using the Agetremotes and Agetcommands commands. So all I have to do is ‘tag’ the 2 ‘up’ commands in a way that my system can figure out that there are 2 commands for ‘up’. For example, I could name them [up#1] and [up#2] and let the system pick the right ‘up’ version and send the right ‘up’ command (up#1, up#2) to the IRTrans with the Asnd command whenever a UI sends a ‘up’ request..

No need to change anything at UI level and 10 lines of code should suffice. Problem solved!

Update Monday 06-08-2012:

I received an email from IRTrans (Marcus) with some additional information:

The Pace STB uses RCMM Codes with toggle bits. Newer IRTrans Firmware versions have got a flag you can activate.

Then the IRTrans device will recognize and reassemble the toggle bits automatically.

You can find the setting on the IR Codes page of the IRTrans Device settings.

So if you’re using a IRTrans product, it’s as simple as changing the Device settings. Another thing worth knowing is that if you have a firmware version that doesn’t support this setting (like me), you can request a firmware update via Email.

 

Tagged , . Bookmark the permalink.

2 Responses to IR trouble with the Pace DCR7111 (UPC mediabox)

  1. Maarten Damen says:

    The Pace is a horrible media box, I have the same model. It’s very hard to get it out of sleep mode (every morning I experience this) and IR response is really slow at times.

  2. You’re right! The first 30 seconds or so it doesn’t react to Infrared at all! As if it’s still equipped with old vacuum tubes that need some time to warm up before they start working…
    Nowadays it’s another thing that’s causing the delay – booting ;-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>