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+:

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

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

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.


Updating the all-in-one remote

Pronto Media Player Activity

Pronto Media Player Activity

I got some complaints lately, from “the people in the livingroom”…

For me, the excitement is in being able to control everything, but not in actually using it in the most convenient way… so sometimes I just don’t finish what I should, just because it’s not that exciting anymore – it works, right? So on to the next job! But this week I was remembered to the fact that I have to keep that WAF in mind a bit more. OK.. lets see how I can keep everybody happy again.

A new media player and a new A/V receiver make watching TV or listening to the radio a bit more complex, and I still hadn’t updated my Pronto to deal with those 2 new devices. So in June this year, when we started using the new A/V Receiver and media player, the number of remotes went up from 1 to 3 again; that’s a lot of new buttons to remember and too much for some; cause we’re all used to using just one remote for all A/V equipment – our Pronto TSU9600! A great remote, which can be totally customized to your own taste and needs. The complaints forced me to do something about the fact that the usefulness of the Pronto had dropped a lot (or slightly, in Onkyo terms…). Listening to the radio and using the media player were the 2 activities that had to be added to the Pronto and some other activities needed some adjustments.

I created a Prontoscript library some time ago which makes it very easy to communicate with my Domotica system. It’s based on XML-RPC and with some wrapper routines a single line of Prontoscript code ‘under a button’ can do just about anything I want: lights, A/V, viewing webcams, opening doors, whatever; as long as my Domotica system can do it, I can control it from my Pronto. As an example, here’s the script that will do all that’s necessary to listen to the radio (the last selected radio station, that is):


With just a single touch of a button on the touchscreen of the the Pronto, this script takes care of turning on the A/V receiver, selecting FM radio and setting the master volume to a preset value.

Was it hard to do this? No, it took me less than an hour.  But the result is, that now everybody considers this (home) automation project finished..


New Pronto TSU9600 firmware

Philips Pronto TSU9600

Philips Pronto TSU9600

Today i spent some time on my most expensive User Interface, the Philips Pronto TSU9600.

New firmware was released in December 2009 and also a new version of ProntoEdit Professional (PEP). The previous  major firmware update with a lot of new features was somewhere in July 2009, but due to lack of time i didn’t come very much further than updating the firm- and software and that was it. Now it was time to have a really good look at what this latest firmware and PEP version would bring. I must say, i’m impressed. It’s very clear that Philips has done a lot for making life of those who have to work with PEP a lot more pleasant 🙂

For example the use of PS (ProntoScript) Libraries. Where my old configuration had a lot of the same code on each activity page, it can now be put into 1 PS Library and added to the configuration at system level; no more redundant code!

The HTTP library is also a big improvement. The code i had to interface with my Domotica system was based on a TCPSocket, but when i went through the HTTP Library, i knew i was only 1 step away from implementing XML-RPC on the Pronto. One thing i missed was a way to do a HTTP POST, but that wasn’t that hard to create myself:

  // Convenience method to send text to an HTTP server
  // Parameters:
  //   aUrl      HTTP URL
  //   aBody     the body
  //   aCallback Callback to invoke with text data upon success
  function postHTTP(aUrl, aBody, aCallback)
    var req = new HttpRequest();
    req.postBody = aBody;'POST', aUrl, true);
    req.setRequestHeader("Connection", "close");
                         "*; q=0.2, ISO-8859-15; q=0.9, ISO-8859-1,utf-8");
    req.onreadystatechange = function (aEvt) {
      if (req.readyState === READYSTATE.COMPLETED) {
        if (req.status === 200) {
          if (aCallback) {
        } else {
          System.print("HTTP status: " + req.status);

Next i created an additional Javascript library and some wrapper routines, which make it possible to have the Pronto ‘talk’ to the XML-RPC interface of my Domotica system:

  var httpLib =;
  var msg = new xmlrpc.XMLRPCMessage("SetDevice");

  httpLib.postHTTP('http://xx.xx.xx.xx', msg.xml(), aCallBack);

Now all my User Interfaces (website, ASUS TOP, Pronto) are using the same interface to my system. That really makes me very happy!

After some testing, today i did a complete remake of 2 of the most used activities. And this time it was fun!; i can assure you, it hasn’t always been that way in the past… Now all i have to do is add a ProntoScript one-liner to the Button Action:


This is the script for muting my TV; with no additional code except for the PS Libraries.

I’m very satisfied with my Pronto and how Philips keeps developing new features for it; and i haven’t even come to the features of the latest release yet; there’s still a whole lot more to explore!