Page 2 of 3
Posted: Wed Nov 25, 2009 1:21 pm
by mvh_2000
I sure may be doing it wrong!! I'm by far no expert.
I have attached my 8910 file if you care to look at what I did?
I'm still trying to understand the previous 3 or 4 posts.
Let me keep reading@
Thanks for the help!!!
MVH
https://www.hifi-remote.com/forums/dload ... le_id=7544
Posted: Wed Nov 25, 2009 1:48 pm
by johnsfine
mvh_2000 wrote:I have attached my 8910 file if you care to look at what I did?
You installed the upgrade as LDP-1976. So far as I understand, you did that correctly.
You created four keymoves with EFC numbers 084, 089, 214 and 219, none of which are correct EFC numbers for any of your signals.
Posted: Wed Nov 25, 2009 2:18 pm
by mvh_2000
Sorry for all the questions!
Let me take one of my "learned codes" for an example: TV:5
Protocol = Gap-550-1687-32?
Device = 122
Sub-Device = 133
OBC = 44
Misc = 7A.85.53.2C
I'm not sure what to do with the 3 or 4 Hex number to get the correct EFC?
I know once I get the correct EFC I use it on the "Helper device" I installed.
Not sure if I convert the HEX value to decimal or subtact something in HEX then convert to decimal?
Thanks
MVH
Posted: Wed Nov 25, 2009 2:47 pm
by vickyg2003
The TIVO 0110 protocol isn't generating the type of signal we want. I'm thinking we need a new protocol for this. One that recalculates the 4th byte of the signal on the fly.
We'd start out with the 2 dev-1cmd scenerio, then change it to a 2 dev-2-cmd and recalculate the 4th byte on the fly.
Posted: Wed Nov 25, 2009 2:52 pm
by johnsfine
I gave you the EFC numbers in my post just after noon (Eastern time) today.
https://www.hifi-remote.com/forums/viewt ... 1499#p81499
I gave them to you because I knew it would not be obvious how you could get them yourself.
Assuming you pressed the wrong button when learning signal number 3, those EFC numbers are 170, 039, 040, 101, 107, 102, 233, 228
mvh_2000 wrote:Sorry for all the questions!
No problem. I'm happy to help you understand.
Let me take one of my "learned codes" for an example: TV:5
Protocol = Gap-550-1687-32?
Device = 122
Sub-Device = 133
OBC = 44
Misc = 7A.85.53.2C
53 hex, which is 83 decimal, is the OBC number. You could also get that by computing 127 minus 44 as described in that other thread, using the wrong OBC number displayed by the decoder.
Then you need to translate from OBC to EFC.
The generic way to translate OBC to EFC is to start to create an upgrade using KM or RM using the correct executor (which in this case is Tivo Official), then type in each OBC number (which in KM requires that first switch the functions sheet to OBC mode) then read the EFC number that KM or RM computes for you.
In my earlier post, I found it easier to do all that than to describe it.
Posted: Wed Nov 25, 2009 2:57 pm
by johnsfine
vickyg2003 wrote:The TIVO 0110 protocol
I thought is was the 0111 protocol.
isn't generating the type of signal we want.
Did you examine the executor or did you test it?
I didn't do either. I just trusted that other thread.
If you tested it, what four byte hex sequence did you get?
Posted: Wed Nov 25, 2009 3:17 pm
by mvh_2000
I tried all 8 of the codes and none of them worked.
Anyway to see if the protocol is the problem or if I should be testing all 255 codes?
My guess is a protocol problem.
Thanks
MVH
Posted: Wed Nov 25, 2009 4:02 pm
by vickyg2003
johnsfine wrote:vickyg2003 wrote:The TIVO 0110 protocol
I thought is was the 0111 protocol.
yep you are right 0111
isn't generating the type of signal we want.
Did you examine the executor or did you test it?
I didn't do either. I just trusted that other thread.
If you tested it, what four byte hex sequence did you get?
I tested the signal with the widget.
Is that part in MISC the four byte hex sequence you are talking about it.
I really only know about matching the bumps in the picture.
This would probably be a lot easier if I spent some time learning hex, because the hex math kind of boggles my mind.
Code: Select all
Device 122
Subdevice 133
unit 1
GAP-580-1650-160-32? 122.133 177 7A.85.4A.B1
GAP-580-1650-160-32? 122.133 161 7A.85.59.A1
GAP-580-1650-160-32? 122.133 161 7A.85.50.A1
GAP-580-1650-160-32? 122.133 161 7A.85.53.A1
GAP-580-1650-160-32? 122.133 161 7A.85.56.A1
GAP-580-1650-160-32? 122.133 161 7A.85.59.A1
GAP-580-1650-160-32? 122.133 161 71.85.5C.A1
Posted: Wed Nov 25, 2009 4:47 pm
by johnsfine
vickyg2003 wrote:
Is that part in MISC the four byte hex sequence you are talking about it.
Correct.
Your results there show the Tivo protocol is similar, but not close enough. We need a different executor.
Code: Select all
7A.85.4A.B1
7A.85.59.A1
7A.85.50.A1
7A.85.53.A1
7A.85.56.A1
7A.85.59.A1
71.85.5C.A1
7A is the device. 85 is FF minus the device. Both correct.
I don't know where that 71 came from.
4A, 59, 50, 53, 59, and 5C are the OBC numbers. That part is good.
The last byte is part check byte and part constant. But it isn't the right parts. The top should be constant and the bottom should be check byte.
I also failed to take proper note of the fact that the OBC values were both above and below 80 but the error of "127 minus" rule in the gap decode didn't vary. That merans no more than 3 bits are constant. The Tivo executor has the bottom 4 bits constant. We need the top 1 to 3 bits constant.
Posted: Wed Nov 25, 2009 10:36 pm
by vickyg2003
Mike try this file and see if it will work your GAP signals,
https://www.hifi-remote.com/forums/dload ... le_id=7545
Posted: Thu Nov 26, 2009 2:45 am
by 3FG
This
link shows a few examples of (I think) what we are seeing here. Yamaha is sometimes using 16 bits of command data. Frequently the last two bytes add up to 7F, as we see with the 665 HDMI commands. But there are counter examples, and a protocol which just makes them add to 7F probably isn't sufficient for the general case.
Note that some of what Yamaha calls the Custom code-- which we call device--are also 16 bits. That's what I was referring to (obscurely) earlier in this thread. But it clearly isn't applicable to this problem with the RX-V665.
Here's a link to all of the
RX-V665 Hex codes, in XLSX format, which means you need Excel 2007 or a converter add-in. I hand decoded a couple of the Input codes (AV1 and HDMI1)--byte 3 and 4 do add to 7F. Not surprisingly, IRtool decodes these as GAP.
Posted: Thu Nov 26, 2009 5:27 am
by vickyg2003
Hmm, the PDF link disappears when I zoom in close enough to see it, and I don't have Excel 7 so I can't open the excel sheet. I went out and downloaded the converter, and now Excel won't open at all. I'm kind of at a loss here.
Posted: Thu Nov 26, 2009 10:20 am
by mvh_2000
vickyg, THANKS!
They all worked!!
How did you get the EFC numbers, just like "johnsfine" posted?
"53 hex, which is 83 decimal, is the OBC number. You could also get that by computing 127 minus 44 as described in that other thread, using the wrong OBC number displayed by the decoder."
Then you need to translate from OBC to EFC.
Happy Thanksgiving!
Thanks again vicky~~
MVH
Posted: Thu Nov 26, 2009 11:25 am
by 3FG
Vicky,
Sorry about the problems with the converter. Here's a zip file with the standard and extended Pront Hex codes in standard Excel format.
https://www.hifi-remote.com/forums/dload ... le_id=7548
Posted: Thu Nov 26, 2009 4:22 pm
by mvh_2000
Hi Vicky,
I figured out the HEX to OBC to EFC conversion.
Thanks everyone for the help
Mike