Yamaha HDMI discretes - Protocol Help??

[mvh_2000]

I have a Yamaha RX-V665 A/V receiver

I am learning some of the HDMI input OBC codes and I'm having a problem with the protocol??

It reads::
Protocol=GAP-550-1687-32?
Device=122
Sub-Device=133
OBC = Varies for each input

Can someone send me in the correct direction?

Thanks for any help
MVH

[3FG]

I don't know why you are gettng these decodes, but Yamaha receivers use NEC1 protocol, device 122. By default in the NEC protocol, if a subdevice isn't specified, it set to (255-device). So that's where the 133 comes from.

Just set up NEC1, device 122, and use the OBCs from your learns. Or you could use one of the more recent Yamaha receiver upgrades available here.

More extensive lists of devices (e.g. 126 and 125) and all sorts of commands are available at Yamaha.uk

[vickyg2003]

3fg, that Yamaha.uk is another cool site. Thanks for posting it.

MVH_2000, often when we get a bad learn it decodes as a GAP protocol.

So what can cause bad learns.

1) Poor batteries in either remote.
2) lighting situation (flourescent lighting or direct sunlight) can contribute to bad learns. I've found that low lighting situations give me much cleaner learns.
3) Not using the proper learning techinique as outlined here
4) moving one of the remotes during the learning process.
5) pressing the OEM button before the learning remote has indicated it was ready for learning.

6) The signals. Some signals types such as XMP are impossible to learn.

7) Unknown protocol. The GAP signal is kind of a catch-all. Many unknown protocols decode as GAP.

If you correct #'s 1,5 and you are still getting GAP signals, post your IR file and we'll check for # 6 and #7.

[johnsfine]

Somewhere in a gap decode it displays the sequence of hex values decoded. For a 32 bit gap decode, that would by four 2-digit hex values. You might need to slide the column widths in IR.EXE decoded signal display to see that part of the decode.

The two likely reasons for this type of signal to show up as GAP rather than NEC1 are the check byte is wrong or the lead-in is missing. If the check byte is wrong, the third and fourth hex values added together won't be FF.

Some manufacturers have extended NEC protocol to put extra info in place of the check byte. If that is the case, the third and fourth bytes won't add up to FF and DecodeIR won't decode the signals no matter how well you learn them, and we ought to modify DecodeIR.dll to recognize that new form. Also the JP1 upgrade can't be done as an ordinary NEC1 upgrade.

If the lead in is missing, that could in theory also be a change by the manufacturer. But more likely it is a learning flaw: Bad batteries or maybe learning with the two remotes too close to each other. In that case an ordinary NEC1 Yamaha upgrade should work just fine.

Just set up NEC1, device 122, and use the OBCs from your learns.

If they are ordinary NEC1 signals that failed to decode because of something like a bad lead in, the OBC portion of the Gap decode is not the OBC of the original NEC1. To get the correct OBC from the bad learn, you need to compute 255 minus the displayed OBC.

[mvh_2000]

Thanks For all the help,

I'm pretty confindent the "learn" is good. I did it 4 times with mulitpy key and I get the same results every time. The same buttons show with NEC1 each time as do the same ones show with GAP each time.

The Vol and pwr buttons show up as NEC1 and the Input buttons all show up as GAP.

I believe it's the check byte problem you stated above??
Each of my last 2 values always add to "7F".

What options do I have from here?

Should I still post a file?

Thanks again
MVH

[johnsfine]

Should I still post a file?

Yes.

[mvh_2000]

Link is below.

I have 2 vol learns and 8 input learns.

https://www.hifi-remote.com/forums/dload ... le_id=7540

Thanks
MVH

[johnsfine]

That file confirms everything you said. They are perfectly good learns and the last bit is different from a valid NEC1 signal.

Somewhere we have upgrades for Apple and I think some other brands that have signals that are almost NEC1 but with a with a difference in the check byte. I forget which brands and upgrades. Maybe I can search later. But hopefully one of the other experts has a better memory.

But you might want to ask why you want a decode or upgrade. There may be a good reason and it wouldn't be all that hard to dig up and modify some upgrade from some other almost NEC1 signal. But if there is no good reason, then what is wrong with leaving the 8 problem signals as learned signals. Do you want to use an extender or do you have some other important use for the learned signal memory?

I'm glad you posted the info anyway. Now we know Yamaha extends NEC1 that way. So we should understand it the next time someone asks about it.

[mvh_2000]

Hi John,

I use a 8910 extended remote as my main remote.
I just use the 8811 to learn protocols and OBC codes to help me program the 8910.

If there is a way to get the other protocol working I would like to do that.

Thanks
MVH

[vickyg2003]

Two years ago this Yamaha Nec1 was addressed in this thread.

If you read through, you'll see on page 3 of this thread that Mike posted a protocol upgrade for this type of signal.

You'll also note that there isn't any feedback as to whether this worked or not. Nor is there any upgrade in the file area. This is a pet peeve of mine.

[mvh_2000]

Thanks Vickyg2003,

I read the thread and install the new device.
It doesn't seem to be working for me??

How do I know what OBC codes to use?
Do I use the ones found from the Learned codes with the GAP protocol?

Thanks
MVH

[3FG]

I suspect this situation is similar to one discussed here. It may not be obvious from that thread, but I believe it shows that some UEI executors, which we describe as NEC1 device 122 (in the above link, the behavior is shown for device 126) actually send a "Yamaha" protocol. Specifically, the setup code 1815 (a 4 DEV combo protocol) will send a signal that the Yamaha receiver understands-- but only if the executor itself calculates the second device byte. If instead RM/KM specifies the second device byte, then the executor sends ordinary NEC signals.

The 8910 is an older remote, so it may or may not have an executor with that behavior. But I would try setup code 1176 (NEC1, device 122) and keymove in the EFCs corresponding to the HDMI OBCs. I suspect that the learned OBC values are correct, since the learns are good. The idea here is to use a UEI written executor which, hopefully, knows about the "Yamaha" protocol.

[johnsfine]

I read the thread and install the new device.
It doesn't seem to be working for me??

How are you using that new device? It was described for use as a helper upgrade or for keymoves. (Use of a helper upgrade is translated into keymoves or you could set up the keymoves yourself).

How do I know what OBC codes to use?

The OBC numbers are (as described in that thread) each 127 minus the gap decode's OBC number, so for your learned signals they are:
71, 74, 89, 80, 83, 86, 89, 92
(You learned the same signal for 3 and 7).

But what would you do with OBC numbers using keymoves or a helper upgrade? The OBC numbers would only be useful if you were creating a full upgrade with the Tivo protocol.

For keymoves, you need the EFC numbers:

170, 039, 233, 101, 107, 102, 233, 228

I don't know/remember enough about the Tivo executor to know whether we are getting all the details right here. If it doesn't work with the above EFC numbers, the easiest way to diagnose it and fix some detail would be to decode the signals sent by those keymoves in the 8910. Since you have a second JP1 remote, you could learn from the non working keymoves in the 8910 into the other remote. I assume that would be a gap..32 decode even if many details are wrong. Then the four 2-digit hex values from that decode would tell us what detail is wrong.

BTW, assuming you pressed the wrong button when learning code 3, we can extrapolate that code 3 should have been OBC 77, which is EFC 040.

[vickyg2003]

3FG, I didn't understand that post the first time. I still don't understand it now. Can you dumb this down a little bit for me?

John I don't quite understand the subtracting the 127 either. I think that me because I have no idea of what a GAP code actually looks like, (it wasn't described in DecodeIRhtml).

[johnsfine]

3FG, I didn't understand that post the first time. I still don't understand it now. Can you dumb this down a little bit for me?

I didn't understand 3FG's post or the thread linked either. So I just jumped to the conclusion that it doesn't really apply to this situation. But of course I'm not sure.

John I don't quite understand the subtracting the 127 either. I think that me because I have no idea of what a GAP code actually looks like, (it wasn't described in DecodeIRhtml).

The OBC in a gap decode is just the LSB value of the last byte.

I expect you know an NEC signal has four bytes
1: device
2: either subdevice or 255 minus device
3: OBC
4: 255 minus OBC

These particular Yamaha signals happen to have 127 minus the OBC in the fourth byte instead of 255 minus the OBC. That's why they don't decode as NEC.

NEC has OBC in the third byte. But DecodeIR doesn't know these signals are a form of NEC, so it guesses OBC is in the last byte. The last byte is actually 127 minus OBC.