Been trying to get MCE2004 remote codes to work on TSU3000.

Tried the old MCE2002 irbus.sys file. (Version 5.1.2600.1106 maybe somebody has a newer one)

No IR Response at all when it is installed in place of the new one from Pronto or even the MCE Remote. I have the silver Philips MCE Remote ($32 at www.newegg.com with free shipping)

Restored my MCE2004 irbus.sys file. (Version 5.1.2600.1321)

On commands where I expect to need repeated inputs which would be killed by the toggle, (up, down, left, right, ch+, ch-, back etc.) I just linked to the command then added a second link to the command "clear". This seems to work fine.

This doesn't work if you manually want to enter channels like 11, 22, 33,44,55 66,77 etc. because "clear" clears the channel change window. On these I tried a different sequence: link to "3", link to "Vol+", link to the second "3", then a link to "Vol-" to return to the same state.

I looked at the apps at [Link: home.tiscali.nl] but even this didn't yield any usable RC6 codes as MCE follows a different format.

In WinLIRC, there is a mini-app called SerialWatcher, and with the PackardBell Serial IR Remote ([Link: tekgems.com] for $10.98) attached to the PC, it directly displays the incoming IR Codes in Decimal, Hex or Ascii...unfortunately none of these bear any resemblance to Pronto codes. Any idea how to use these? I tried copying them to the MAJOOR app "Pronto v3.00" too. (as stated above, the app works but the results are not the MCE implementation of RC6)

An interesting note on the Packard Bell IR Remote is that it reads anything...as I was sitting here working, random results were popping onto the screen and I finally figured out my laptop's SMC IrCC Fast Infrared port is apparently jabbering on its own...weird as it isn't configured as a network or printing device (I'm wirelessly networked 802.11b/g and do not use IR Printing)...this could conceivably be a security issue I imagine. Wondering if anybody knows if IrCC Fast Infrared is Consumer IR or just another name for the typical IrDa that is on most PDAs???

Even read the ideas in the RC5000 forum; [Link: remotecentral.com]
and the [Link: hifi-remote.com] forum
where I picked up some hints.

What I am wondering is if there actually is a difference in the emitter IR code from the MCE remote if the same key is pressed twice in a row.

If so, a workable solution for the touchscreen would be to create 2 identical pages; MCE1 and MCE2.

In any multiple keypress you would press MCE1 "3" then JUMP to MCE2 and press "3" on that screen. If you began a command on MCE2, you would likewise be jumped back to MCE1. Lag could be a factor.

A further stretch to include hard buttons would be to jump between devices instead of pages within the same device: MCE1:Key Up>"up","jump MCE2" and your next Key Up would be executed on device MCE2 and then jump back to device MCE1.

The real trick here, though, is to figure out a reliable way of capturing the toggled codes in the first place.
I guess you could "learn" to one button with a single keypress, and if successful, switch to the other page/device and "learn" the same command again. So long as the seperate learns are accomplished with two consecutive keypresses, it ought to work. Again, this is assuming that there is an actual difference in the codes between 2 keypresses.

Sure would be easier if there was a working irbus.sys between the versions I have...

If anybody has a working config that includes MCE2004 using this technique, something similar, or even a brilliantly hand-edited IR code, please let me know at [email protected].



Thanks for reading this long post!

Tom

Since other people have solved the toggle problem with some version of that file, I expect someone will tell you what version you need.


I would expect that to be very slow (because of the delay between steps in a macro). If you want to send another command after each of those commands, I suggest you edit the Pronto Hex (or MakeHex's .irp file, see below) to splice the second command onto the Pronto Hex of the first.

Also, I expect that a "do nothing" command (probably any command number with no defined meaning) would work much better for that purpose than a "clear" command.


That's one advantage to using a "do nothing" command.


It sounds like you want a macro for a specific channel rather than to make the digits work right manually. For all macros you shouldn't use the method of inserting extra commands. Just use both versions of the commands you want. Send one version of '3' then the other version of '3'.



I assume those are the command numbers, which you can use to select which item from the output of MakeHex is which command. But you don't really need that since there are better ways to find all the command numbers.


Yes. The RC6 standard specifies that a certain bit in the command toggle with each new press. But whoever designed that remote misunderstood the standard. It toggles the wrong bit. In effect it switches between two different subdevice numbers.


That's the standard method with some other touch screen remotes, but switching automatically between pages is too slow (and has other consequences) in a Pronto. So having both versions on a hidden page is a solution for sequences, but having both versions on visible pages doesn't do the job for manual keying.


Use MakeHex
[Link: john.fine.home.comcast.net]

The RC6-M-L.IRP file there is already set up to produce clean Pronto Hex for all 256 possible commands for one of the two subdevices for the RC6-6-32 used by MCE. I forget the second subdevice number, but I'll do a search later and post that.

Search done: found [Link: hifi-remote.com]

The subdevice switches between 3844 and 3972, so you can edit the RC6-M-L.IRP file and change the 3972 to 3844 and then create the other set of 256 possible commands.


This message was edited by johnsfine on 02/15/04 07:40.

Thank you John.

I really appreciate your help.

I still don't understand how to get the Pronto to do the toggle without the jumps.

The delay caused by inserting the "clear" command is not bad at all, and for my macros on station icons, when I press the CNN icon, I do get a flash of the volume between "4" and "4", but it is gone by the time the tuning is stable.

Obviously not elegant, but workable.

Still, I'd prefer if the Pronto would toggle for me.

The Hard Button cursor and surrounding buttons work nicely for MCE remote emulation.



This message was edited by tintruder on 02/15/04 20:33.

John,

I used your app and it is superb!

I edited rc6-M-L.irp to change 128.3972 to 128.3844 and created the two resulting .hex files, so I now see that the 44th and 46th groups of 4 digits toggle between 0020 and 0010 (0020 0010 0010 to 0010 0010 0020).

I assume that is the toggle?

I am going to try the device jump/jump back method and see how it works for now.

I also recall seeing somewhere that somebody had discovered some undocumented button commands besides those you listed which might be useful, but can't find it again. If anybody is aware of these, I'd sure appreciate a link.

Perhaps the folks who deal closely with Philips on the TSU3000 and 7000 could suggest that this particular RC6 format be included in a future firmware release?
While it may have come from an error in implementing the standard, it isn't going away so maybe it should be addressed and incorporated?

Yes.


What's wrong with the idea of splicing on a "do nothing" command?

I assume you have the numbers of the valid commands from somewhere, or you couldn't do much with MakeHex. It should be easy to test a few of the other numbers to find one that really does nothing.

Then verify that an ordinary command followed by the do nothing command followed by the ordinary command again really makes the MCE see the second instance of the ordinary command.

Then you just need to do the splicing. You may want to use MakeHex for that.

I think you could change the .irp file to

Device=128.3972
Function=0..255
Define M=6
Define L=32
Default N=123
Protocol=RC6
Frequency=36000
Time Base=444
Message Time=200m
Zero=-1,1
One=1,-1
Prefix=6,-2,1,-1
First Bit=MSB
Default S=0
Form=*,M:3,-2,2,D:8,S:(L-16),F:8,-150,*,M:3,-2,2,D:8,(S^128):(L-16),N:8

Replace the 123 in N=123 with the number of your do nothing command.

It's possible that PENG will have some trouble with the part of the Pronto hex generated by that "-150" gap in the middle. But I'm confident it could be tweaked to work in a little experimentation if it doesn't work first try. And the results should run much faster than other methods of fixing this.

Also, this method should be usable to make pairs of commands that run faster than a sequence. Instead of using Function=0..255 to make all possible single commands, use (for example) Function=3.3 (notice there is only one .) to make a single Pronto Hex splicing together the two different forms of the '3' command, which runs faster than having those two in a sequence and much faster than having one of them used twice with a "do nothing" in between.

Even if it toggled the right bit, Pronto Hex has no special format for it.

The "RC6" with special support in the firmware is just the base form of RC6 with M=0 and L=16. The "RC6a" support in ProntoEdit (I think that is M=6, L=20) is just ProntoEdit support, not actual firmware support. The device using it doesn't need the toggle so translating to 0000 format is correct. The RC6 for MCE has M=6 and L=32 making it an entirely different protocol.

Eigeny tweaked the 7000 format for an older Pronto to generate StreamZap protocol, which is related to the RC5 protocol in the same way this RC6-6-32 is related to ordinary RC6.

7000 format was not designed to support variants for RC5 and RC6, but (at least in the older Prontos) it can be used to do so.

So far as I know, no one has tried that for RC6-6-32. On an older Pronto I think it would work. But I'm not sure I know quite enough to do it. It may need Eigeny's level of knowledge. On the NG Prontos, even much of the basic behavior of 7000 format doesn't work, so experimenting with an intentional misuse of 7000 format is even harder.

As for a suggestion for future firmware versions, they ought to fix the 7000 format so it really works and make sure it is general enough that its misuse for things like Streamzap work as well (that's easier an cleaner than trying to build specific support for Streamzap and RC6-6-32 and every other strange toggle format anyone ever comes up with).

One last thing on the Streamzap subject. I think someone dealt with his RC6-6-32 problem by making his MCE device respond to Streamzap protocol instead of RC6-6-32, and then using Eigeny's trick to generate correct Streamzap. I might have misunderstood. The thread shouldn't be too hard to find and read for yourself.

John,

I am still unclear how to splice.

You obviously have a tremendous in-depth understanding of this technology. I don't.


Would I splice UP(3844) with DO NOTHING(3844) or with DO NOTHING(3972)?


Can you add comments to your .irp to explain what each entry means and how you deduced these codes were the right ones for any specific remote?:

(for instance, if I have a RCA remote for my TV, how would I (1) identify the codes and (2) splice 3 presses of the volume key as one command?)

Device=128.3972
Function=0..255
Define M=6
Define L=32
Default N=123
Protocol=RC6
Frequency=36000
Time Base=444
Message Time=200m
Zero=-1,1
One=1,-1
Prefix=6,-2,1,-1
First Bit=MSB
Default S=0
Form=*,M:3,-2,2,D:8,S:(L-16),F:8,-150,*,M:3,-2,2,D:8,(S^128):(L-16),N:8

Replace the 123 in N=123 with the number of your do nothing command.



Thank you so much for the MCE part...and for your patience as I learn from you

Tom

Pronto Hex has a header portion that tells various information including how much "one time" data and how much "repeating" data follows.

After the header, the rest of the Pronto Hex is timing details of the actual signal. I often splice signals by hand. That involves pasting the timing detail part of one signal right after the timing detail of the other and changing the header so that it introduces twice as much data (usually I also have to change the header to make all the data "one time" rather than "repeating").

In this case I spliced signals by editing the MakeHex IRP file, so MakeHex would generate the spliced signal directly, rather than needing the Pronto Hex to be edited.


I'm pretty sure it wouldn't matter. The MCE recognises the change in command when either the command number or the toggle bit changes. The .IRP file I provided reverses the toggle bit between the two frames because that lets the same .IRP file be used for 2 command mini macros even when it is two of the same command.


See below.


1) Use my DecodeCCF program (from the Yahoo JP1 group) to decode any CCF file containing RCA TV commands. It will tell you the protocol (RCA), the device number (probably 0 or 15) and the command number of each command.

2) There is probably no practical way to do that. RCA protocol has no toggle bit, so the only thing that tells the TV you released and repressed the key is the large delay between frames.


That is the device and subdevice number I got from decoding MCE commands people posted in several other threads.


That is a command to MakeHex telling it to generate all function numbers from 0 to 256.


The general form of the RC6 protocol has two structural characteristics that distinguish one particular kind of RC6 from another. One is a value that Philips named "M" when they defined RC6. The other is "data length" which I named "L" because MakeHex needs one letter names for its parameters. The RC6 used by MCE has the above values M=6 and L=32. This .IRP file is designed to handle any form of RC6 in which L is above 16 and below 48. The primary form of RC6 (M=0, L=16) has its own file RC6.irp, and all the other forms of RC6 we have seen have L of 20, 24 or 32, so they can be made with RC6-M-L.irp by editing the M and L values.


"N" is the letter MakeHex uses to represent a second function number. I just guessed 123 as a "do nothing" function number. I don't have a list handy of the known MCE function numbers.


That's actually just a comment line. MakeHex.exe ignores it.


Like most IR signals, RC6 is modulated and you need to tell MakeHex the modulation frequency so it can compute the modulation wavelength which is second value in the Pronto Hex header.


That tells MakeHex to multiply all ordinary duration values by 444 microseconds. The RC6 protocol is based on 444 microsecond intervals. Other protocols are based on other unit intervals.


That tells MakeHex to pad the total signal out to a total of 200 milliseconds. In the normal RC6-M-L file (for single repeating frames) the pad value was important to get the right repeat rate. In this file (two frames non repeating) the value just has to be large enough to avoid math errors. PENG will ignore that detail of the Pronto Hex on a non repeating signal anyway.


Those represent elements of the signal structure of RC6 and are in units of TimeBase (444 microseconds).


Most IR signals transmits bits "Least Significant Bit" first. RC6 transmits them the other way, MSB first.


"S" is the MakeHex letter for subdevice. In the device line the subdevice is the part after the ".". Many protocols don't have subdevices, so someone might get confused and try a device number without a "." in a protocol, like this, which needs a subdevice. Providing a default value of S keeps makeHex from crashing if the user does that, and the default is ignored if the user provides the subdevice the normal way.


That describes the full signal MakeHex is supposed to create. The part
*,M:3,-2,2,D:8,S:(L-16),F:8
describes one frame of ordinary RC6-M-L with the official toggle bit disabled. The part
*,M:3,-2,2,D:8,(S^128):(L-16),N:8
describes a second frame of RC6-M-L using the second function value N instead of the function value F and changing one bit of the subdevice to match the MCE behavior of toggling the wrong bit.

Just wanted to bump this back up because it is such a superb explanation of how toggles work.

There are also a couple more threads asking about MCE, including the registry hack to disable the "debounce" feature.

If you use the hack, the registry path was mistyped and where it says idIr it should be HidIr...


I'm interested in hearing if anybody has compared the 3 methods for MCE enough to say which is best?

Regedit
Append do-nothing command to cause toggle
Device/Page swap

Especially interested in the function of repeating keys such as the hard button cursor control.