Trying to program URC 7800 to control HP MD5880n

[bnam]

# Device: HP Pavilion MD5880n
# Type of device: HDTV
# Year: 2005
# JP1 Remote model: URC 7800 (also have 9811 HT Pro)
# JP1 user? Yes
# Still have original remote? (yes)

# Checked the file section? Yes

# Checked the Pronto file section (at R/C)? Yes. Found a discrete CCF file. Converted it with DecodeCCF to excel file. It indicates that most of the discrete codes are with protocol RC6-6-32


# Partially working setup code?

If your JP1 remote is a learning remote and you do have the original remote, PLEASE EXPLAIN what is preventing you from using learning to capture the signals and then you building an upgrade yourself.

When I learned the key (power toggle in this case), IR.exe shows it as unknown protocol.

In KeyMap Master 8.38, there is no protocol matching the above. Closest were RC6 and RC6a

Also, the CCF file I found only has discrete codes (and not for all functions). At this point I am just looking for the basic codes (like power toggle, source toggle etc.

Any help will be appreciated.

TIA

[gfb107]

If IR isn't giving a useful decode of the learned signals, please upload a copy of your saved .IR file to the Diagnosis Area and provide a link to it.

[bnam]

Greg,
Thanks! Here...

http://www.hifi-remote.com/forums/dload ... le_id=3020

[johnsfine]

# Checked the Pronto file section (at R/C)? Yes. Found a discrete CCF file. Converted it with DecodeCCF to excel file. It indicates that most of the discrete codes are with protocol RC6-6-32

1) Post the URL of the CCF when you discuss a CCF file here.

2) Get a newer DecodeIr.dll, because I'm pretty sure those would decode as "MCE" rather than "RC6-6-32" (MCE is a form of RC6-6-32, but the numbers needed to setup a correct upgrade are simpler when it's decoded as MCE).

3) I don't recall the exact status of RM and/or KM support for MCE or RC6-6-32, but I'm sure some support is available.

When I learned the key (power toggle in this case), IR.exe shows it as unknown protocol.

That was a really crappy learn. I didn't make the effort to diagnose it in detail. But at a glance it is consistent with MCE, so no reason to expect it is different from what you'd find in CCF files.

The bad learn might be due to weak batteries in the HP remote, or maybe the remotes weren't aligned well for learning, or were too close together or too far apart. Sometimes it takes a few tries to find how to get learning right for a given pair of remotes (but try new batteries first if you're retrying the learning at all).

In KeyMap Master 8.38, there is no protocol matching the above. Closest were RC6 and RC6a

I guess I'm out of touch with the way protocols are named in KM.

"RC6" is the name of both a large family of protocols and the name of the single most important protocol in that family. In KM it definitely refers to just the specific protocol. MCE is in that family but is not that protocol.

"RC6a" is the name of a subfamily of at least three different protocols in the RC6 family. MCE is in the RC6a subfamily. But I don't know which specific member of that subfamily "RC6a" might mean in KM. I don't think it means MCE.

Also, the CCF file I found only has discrete codes (and not for all functions). At this point I am just looking for the basic codes (like power toggle, source toggle etc.

Basic MCE command numbers are pretty consistent across models and brands, so there are many sources from which you could get function name to OBC number info.

[bnam]

1) Post the URL of the CCF when you discuss a CCF file here.

http://www.remotecentral.com/cgi-bin/fi ... vision&fc=

2) Get a newer DecodeIr.dll, because I'm pretty sure those would decode as "MCE" rather than "RC6-6-32" (MCE is a form of RC6-6-32, but the numbers needed to setup a correct upgrade are simpler when it's decoded as MCE).

Done.

Thanks for the info. I will try a learn again with fresh batteries.

bnam

[bnam]

This time I tried with my HT PRo and succeeded in learning the Power on/off function.

http://www.hifi-remote.com/forums/dload ... le_id=3030

Now I need to figure out how to create an upgrade with this info. Appreciate any input. I will continue to search/read.

Thanks,
bnam

[bnam]

I've now learned 4 keys and they all work. However, in IR decodeIR (v2.29) does not show any info regarding protocol or OFC/EFC. That section is missing in the Learned Signals tab under signal description.

So, is this possibly a new protocol? Is there any tool for decoding this protocol?

Thanks!
bnam

[johnsfine]

I've now learned 4 keys and they all work.

But you posted a .ir file with only 1 learned signal.

However, in IR decodeIR (v2.29) does not show any info regarding protocol or OFC/EFC. That section is missing in the Learned Signals tab under signal description.

So, is this possibly a new protocol? Is there any tool for decoding this protocol?

It is definitely not a new protocol. It is definitely MCE.

I decoded it by hand (which tends to be a little error prone with this sort of signal) and I get MCE device 18.17, command 12.

I don't think I've ever seen MCE device 18 before.

Command 12 in the RC6 family almost always means power toggle as it does in this example.

Subdevice 17 in MCE means "HP" as it does in this example.

I wish I were confident my hand decode of 18 is correct. Anyway I'm sure it is NOT device 2.17, matching that CCF file.

In RemoteMaster it would be quite simple to select MCE protocol, device 18, subdevice 17, and put typical RC6 function (OBC) values in, such as 12 for power toggle and the digits themselves for digits, then test to see how much works.

I'm sure it can be done in KM as well, but I haven't checked the details.

Your learned signal has several of what we call "phase glitches". That means the original remote's modulation phase reversed where there is a bit boundary without a signal transition.

Some IR learning devices ignore phase glitches. But those such as OneForAll that are designed to learn a wide variety of modulated and unmodulated signals using the same low level capture system, tend to maginify phase glitches into extra transitions. So they store a seriously wrong signal.

BUT, the device itself is not watching the whole signal. It knows the correct clock rate and samples the signal a certain moments. The bit boundaries where the signal is wrong are the places it intentionally avoids sampling, so the wrong learned signal works.

Making generic decode software ignore such glitches is a lot trickier. There is only one protocol for which DecodeIr is programmed to ignore phase glitches, and it isn't in the RC6 family. I don't think I've ever seen phase glitches in RC6 before.

I may look into adding the complex code needed to decode the RC6 family despite phase glitches. But meanwhile we don't have a good way to decode your learned signals.

You don't happen to have any other brands of learning remote do you? Many brands of learning remote ignore phase glitches, so they learn the signal without the glitch. Then you can learn the glitch free signal from the other learning remote to the OFA and get a glitch free copy there as well.

[bnam]

THANKS!!!

http://www.hifi-remote.com/forums/dload ... le_id=3031

Here's the link to the 4 learned codes.

Unfortunately, I don't have another brand -- just OFA 9811 and 7800.

I will try your suggestion on creating an upgrade using RC6 info.

B

[bnam]

THANKS! It worked.

http://www.hifi-remote.com/forums/dload ... le_id=3032


Now to find the OBC codes for the other functions. Where can I find the RC6 codes for other functions?

bnam

[johnsfine]

Here's the link to the 4 learned codes.

Hand decoded:

TV/VID ... OBC=139
Menu ...... OBC=116
Info ........ OBC=129

I will try your suggestion on creating an upgrade using RC6 info.

Remember the upgrade must be MCE protocol, not RC6. The only RC6 characteristics I was suggesting were the fact that power toggle is OBC 12 and digits' OBCs are themselves.

[bnam]

Hand decoded:

TV/VID ... OBC=139
Menu ...... OBC=116
Info ........ OBC=129

I will try your suggestion on creating an upgrade using RC6 info.

Remember the upgrade must be MCE protocol, not RC6. The only RC6 characteristics I was suggesting were the fact that power toggle is OBC 12 and digits' OBCs are themselves.

OBC=116 did not work, but the others did. Yes, it was based on MCE protocol.

.rdmu for the upgrade based on the working OBCs
http://www.hifi-remote.com/forums/dload ... le_id=3030

.ir based on above plus learned codes for the critical controls. These learned codes all work.

http://www.hifi-remote.com/forums/dload ... le_id=3020

Thanks for decode the prior learns. Is there a tutorial anywhere to learn how to hand decode so that I can try to do myself?

Thanks!!!

bnam

[The Robman]

Is there a tutorial anywhere to learn how to hand decode so that I can try to do myself?

The best way to start is to learn about the format of IR signals, which you can do here...

http://www.hifi-remote.com/infrared/

[johnsfine]

OBC=116 did not work

I must have hand decoded it wrong (this is a hard protocol to decode by hand).

I am testing a copy of DecodeIr.dll that understands phase glitches in the RC6 family, and the decodes it gets for the learned signals you just posted are:

169 = L2
85 = Exit
84 = Menu
88 = Up
89 = Down
90 = Left
91 = Right
92 = Select

After more testing and updating the documentation, I'll release the new DLL so you can use it yourself.

I already ran it against my entire library of downloaded CCF files and it didn't change ANY output vs. the prior version. That probably means my change has no unintended side effects. But if my change is correct, it also means that in all the learns in all those CCF files there isn't a single example of a phase glitch in a learn of an RC6 family signal.

[johnsfine]

I released the new DecodeIR.dll with code to understand RC6 family signals even if they have phase glitches.

You can download it from
http://john.fine.home.comcast.net/ir/Decode_IR_DLL.zip