John Fine,

You helped me resolve a problem I had in January, about converting Yamaha codes 7DE1 and 7DE2 to into URC-Universal-Browser-acceptable codes. Thanks again.

I now have to convert some codes from a DLO HomeDockPro into URC-Universal-Browser-acceptable codes. The codes are in the format: "900a 006d 0000 0001 ee87 80f1" I have gotten most of the way there on my own, I just have a question.

By reading another one of your forum posts, I learned that the first part of the code, "900a 006d 0000 0001" means NEC1 protocol and that "ee" means device 238. I created a ccf file using makehex and IRpanels for all 256 codes for device 238.

I now need to know which of the 256 commands in this ccf file are the commands I need.
Do I convert the last two hex characters, "f1" into a number and then use this number command?
If so, what do the "87" and "80" mean?

Thanks

Ira Guthrie

I looked at the DLO CCF file here:
[Link: remotecentral.com]

I don't see any pattern MakeHex could use in the last byte (5E, F1 or F2) of those signals, so you would need to run MakeHex/IrPanels once for each of those values.

As I said in the email, This protocol is like NEC1 except for that last byte, so you can edit nec1.irp as follows:

1) Change the first line to

Device=238.135

That encodes the ee87

2) Change the ~F on the last line to one of 94, 241 or 242. (5e hex is 94 decimal. f1 hex is 241 decimal. f2 hex is 242 decimal).

The second to last byte (80 for power On, 40 for power off, etc.) is hex for the function number. You need to convert it to decimal in order to know which button to drag from the MakeHex output.

Thanks, John

I'm going to try this out and will let you know.

Ira

I am missing the significance of this number. If this has nothing to do with the Device or Function numbers what is its relevance. Can someone shed some light on this for me? Thanks.

That's the byte we were talking about in the other thread on this topic. The one that is the last two hex digits of the "900A" condensed form of the signal. The one that seems to vary between otherwise identical Apple remotes. The one whose significance (to Apple) no one seems to have explained yet.

In the "900A" form those two digits are in hex. In the .irp file they must be decimal (up to three digits).

For what you're doing now, you should ignore the set of three values (94, 241, 242) I gave for that in my post in April. That set of three values was based on the context of this thread at that time. Now you have other values from your learned signals and/or testing you've done so far and/or other threads about the device you're trying to control.

Great.

I will look at this whole deal with fresh eyes now and see if I can determine the differences between units as I encounter them.

Thanks again.