Windows MCE Remote -- RC6 w/"Toggle"...

mdburkey · Post by **mdburkey** » Thu Nov 27, 2003 1:19 am

I am trying to create a device upgrade with the codes from my Windows MCE remote for use with one of my (many) JP1'able remotes.

I've been using a 2104 to learn the codes and then decoded them via DecodeIR.

So far so good...

It detects them as RC6-6-32, device 128, but with a subdevice
that alternates between keypresses -- i.e. it changes from 3844 to 3972 between each successive keypress.
And the USB dongle will not recognize another 3844 until it sees a 3972...etc.

Has anyone else created a device upgrade for this remote yet?
If so, how?
If not, does anyone have a good idea on how to do so?
(might the RC-6a protocol upgrade be able to do this?)
Or do I need to create a new protocol for this?

Any comments greatly appreciated!

johnsfine · Post by **johnsfine** » Thu Nov 27, 2003 7:23 am

We have discussed this protocol a few times both here and at RC. It is a form of RC6 in which the wrong bit toggles. I think there is an upgrade for it somewhere in the files in the Yahoo site, but I don't have time now to search either files or messages to find it (A message on the subject would probably refer to both "RC6" and "Microsoft").

I don't recall if any JP1'ers ever made a protocol for this. Either instead of that or in addition to it, I'm pretty sure someone (Rob?) got UEI's version of the upgrade for this protocol.

mdburkey · Post by **mdburkey** » Fri Nov 28, 2003 9:50 am

I did a quick search of this forum and the old Yahoo stuff and I don't see anything on either.

If anyone does have a protocol upgrade for this, I would REALLY appreciate it.

Otherwise, it looks like I'll have to be writing one (blech).

johnsfine · Post by **johnsfine** » Fri Nov 28, 2003 10:01 am

It's this thread
http://groups.yahoo.com/group/jp1/message/23688

Notice that thread discusses the fact that the remote toggles the wrong bit and the device doesn't care whether the bit toggles at all. In a related thread at RC there was discussion of the fact that a newer version of the device software DOES care about the toggle. IIRC a Pronto user had to back out to older device software because it was too hard to make the Pronto toggle correctly. I hope the protocol Jon (Jonnyboy_25) posted does the toggle. I haven't checked it.

mdburkey · Post by **mdburkey** » Fri Nov 28, 2003 5:51 pm

Ah....just d/l'ed it and will test it shortly!
Windows_Media_Center.txt

Thanks!

mdburkey · Post by **mdburkey** » Mon Dec 01, 2003 5:31 pm

Well, it doesn't work.

All the codes are ok and it receives the RC6 just fine -- but the toggle but issue still rears its ugly head.

The version of the IR receiver I have apparently REQUIRES the toggle bit between identical commands for it to work properly.

And, of course, the toggle it needs is not in the normal bit position.

Which I guess means I'm going to have to modify the protocol by hand to get that bit toggling.

Any suggestions from anyone on the best place to start?

johnsfine · Post by **johnsfine** » Mon Dec 01, 2003 5:45 pm

mdburkey wrote: Which I guess means I'm going to have to modify the protocol by hand to get that bit toggling.

Any suggestions from anyone on the best place to start?

Find Jonnyboy_25's email address (I assume it's somewhere in a profile here or in the Yahoo group or at RemoteCentral, but I don't have it handy on this computer) and ask him. He probably fixed it already and didn't repost the file. He knows how to fix it. So do Rob and I. I might find time to do that shortly, but I'm not sure I will find time, so I won't promise.

johnsfine · Post by **johnsfine** » Thu Dec 04, 2003 1:43 pm

I had time for a quick look at Jonnyboy_25's version. It looks like it is designed to support the toggle all three ways: Right-bit, Wrong-bit, and No-Toggle. But I didn't read carefully nor test, so I'm not certain.

I think it is controlled by the low two bits of the first byte of fixed data.
The upgrade he posted has E2 as its first byte of fixed data, so it should be toggling the "wrong" bit as required by Microsoft. Are you sure it wasn't? If you change that to E1 it should toggle the other bit, though that doesn't seem to be what you need.

Post by **The Robman** » Thu Dec 04, 2003 3:54 pm

I've just noticed this thread and have taken a quick look at the protocol code. Here's what I see that's being done:

The code tests bit1 of the first fixed byte and if it's set, it toggles bit7 of the 4th fixed byte. It then goes onto test bit0 of the first fixed byte. If it's set, they toggle it, if it's clear they leave it alone.

The rest of the code is too complicated to do a quick analysis. John, I have a question for you though. There are sections of code that are CALLed that contain JUMP statements, is this valid? I expect control to be returned after a CALL statement, but not after a JUMP statement, so wouldn't the JUMP statements cause control to exit?

Post by **The Robman** » Fri Dec 05, 2003 1:27 pm

I've just got word from someone that they tested this code and compared the output with that of the Windows remote, and they matched, so it should work.

johnsfine · Post by **johnsfine** » Fri Dec 05, 2003 2:00 pm

The Robman wrote:John, I have a question for you though. There are sections of code that are CALLed that contain JUMP statements, is this valid? I expect control to be returned after a CALL statement, but not after a JUMP statement, so wouldn't the JUMP statements cause control to exit?

It is valid and quite common when you're trying to save a little space in ASM code.

Imagine that the last thing subroutine X wants to do is call subroutine Y. You could make the last two instructions of Subroutine X a call to Y followed by a return, but you're better of using just a jump to Y instead of the call.

When Y finishes it will return. Since X jumped to Y instead of calling Y, when Y returns that goes back to whatever called X rather than going back to X.

The CPU makes no distinction between RAM and ROM code, so it may look strange when X and the caller of X are both in RAM and Y is in ROM, but it works regardless of that.

I used to use that method a lot, in my non JP1 programming. But now the branch prediction logic of some CPU's is thrown off by that in some cases. If so, then it is better to do two returns which are predicted correctly than one return that is predicted wrong. For JP1 programming, I don't do that much simply because I avoiding any calls from ram code to ram code. If you look at some of the protocols I've written vs. the same thing in an upgrade from UEI, one big reason that my version is smaller is that I use nested loops where they use ram to ram calls. Both the nature of most IR signals and the structure of S3C80 machine code give advantages in most cases to a nested loop structure vs. a subroutine structure.

johnsfine · Post by **johnsfine** » Fri Dec 05, 2003 2:03 pm

The Robman wrote:I've just got word from someone that they tested this code and compared the output with that of the Windows remote, and they matched, so it should work.

What does "matched" mean?
We already knew that the signal worked for the older Windows device that ignorred the toggle, so it had two match at least one of the two toggle states of the original.

Did the person you spoke to match both toggle states of this signal against both toggle states of the original? Or did he just look at one toggle state of each and that one happened to match?

mdburkey · Post by **mdburkey** » Sat Dec 13, 2003 10:32 pm

I finally had some time to look at this again -- not much sadly (and won't have much actually til I'm off work for Christmas for a few days) -- but at least from what I can tell right now, this protocol does not work properly with the current version of the MCE remote/receiver combination.

I downloaded it to my remote and have tested it and it DOES send the correct commands out and they work -- ONCE.

If I press a single button twice in a row (or more) it is only received the first time. If I press a different button, it is handled fine -- but the same button pressed multiple times is apparently not toggling correctly.

I may look at the protocol code a bit myself and compare what it outputs to the output of the real remote (i.e. learn both, then decode & compare).

Mr Cinema7 · Post by **Mr Cinema7** » Sun Dec 14, 2003 1:14 pm

Rob was speaking for me, as he emailed me asking about this code. I have loaded the upgrade I posted into an 8910 and looked at the signal in an analyzer. I then compared this with the original MCE remote and it is identical for multiple keypresses. i.e. power key pressed twice on 8910 toggles identically to the MCE power key pressed twice. I will take a much closer look but I don't have the remote with me at the moment (it is borrowed). If you can learn a few key presses, I can take a look at those and see if I find any differences there with my upgrade as well.

mdburkey · Post by **mdburkey** » Wed Dec 31, 2003 12:48 am

Well, I finally had time to look at this some more and got it working....
with basically no effort involved.

First off, the code posted works fine -- on an 8810, which I hadn't
been using for testing (I was using the crappy 2104 I use for learning).

On the 2104, the upgrade doesn't seem to work properly (micro differences perhaps?).

So, I guess the fault is mine for not checking into this far enough.

To everyone -- many thanks for helping with this, now I can ditch the MS remote and be back down to one remote for everything! Hallelujah!

MDB

JP1 Remotes

Windows MCE Remote -- RC6 w/"Toggle"...

Windows MCE Remote -- RC6 w/"Toggle"...

Hmmm...

Crap.

Re: Crap.

It works!!