JP1 Remotes

Yamaha is now using an "extended" version of the NEC1 protocol where bit0 (ie, the rightmost bit) of the OBC complement is flipped. These signals are currently being reported as a "gap" protocol by DecodeIR.

The first challenge is deciding how to report these signals from DecodeIR and the next one is deciding how to include them in RM and KM.

Unless anyone has a better idea, I would suggest that we suffix a "-y" (for "Yamaha") onto the protocol name, so in this case NEC1 would become NEC1-y. In theory, if anyone else were to start doing this with the other variations of NEC we could also see NEC2-y, NECx1-y and NECx2y.

As this protocol variant only seems to be used for additional discrete code type signals, I don't see any need to make a stand alone executor to handle it. Instead, I have modified the NEC 4Dev Combo executor so that it can generate this NEC variant in addition to all the standard NEC variants.

To make my executor send the Yamaha variant, you need to set bit1.

When I examined the official UEI executor for the 4Dev combo, I noticed that it uses bit5 to determine whether to get the sub-device from the data or to make it the complement of the device code. Obviously, as the data is supplied anyway, this code isn't really necessary, and both KM and RM set this bit regardless and supply the data for the sub-device, even if it's the complement of the device code. So I eliminated this code in my executor and replaced it with the new code to handle the Yamaha signals. The net result is that the new executor is actually smaller.

For the KM implementation, I would suggest that the last character of byte2 should be a "y" to generate this signal, so some examples of byte2 would be:

1 1 = use dev1, NEC1
1 2 = use dev1, NEC2
1 x1 = use dev1, NECx1
1 x2 = use dev1, NECx2
1 1 y = use dev1, NEC1y (the new signal)

the following signals are also possible (though not in use at this time):
1 2 y = use dev1, NEC2y
1 x1 y = use dev1, NECx1y
1 x2 y = use dev1, NECx2y

For RM, the most complete approach would be to double the number of entries in the "Style" column, so the total selections would be:

NEC1
NEC2
NECx1
NECx2
NEC1-y
NEC2-y
NECx1-y
NECx2-y

However, as the NEC1-y is the only "y" variant in use at this time, it might be less confusing to only add that option for now. We can always add the other options if and when the need arises.

For both the KM and RM implementations, if the users remote has the 4Dev executor built in, it would be a good idea to only supply a protocol upgrade if they assign a function that uses the "y" variant to one of their buttons.

I would also suggest that KM and RM continue to set bit5 to retain compatibility with the UEI executor.


The PB file for my new executor is here:
http://www.hifi-remote.com/forums/dload ... le_id=8742

A working upgrade that uses it (currently using "Manual Settings") is here:
http://www.hifi-remote.com/forums/dload ... le_id=8740

The Yamaha signals have been discussed here:
http://www.hifi-remote.com/forums/viewtopic.php?t=12373
http://www.hifi-remote.com/forums/viewt ... 5687#85687
http://www.hifi-remote.com/forums/viewtopic.php?t=11604
http://www.hifi-remote.com/forums/viewtopic.php?t=11789

Any takers?

To get the ball rolling I have put together a new version of KM which can handle these signals. I've called it 9.21 beta because I don't know if Mike already has a 9.21 in the works.

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

I've created a new version of the Yamaha upgrade that I mentioned before that uses the new feature here:

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

Rob, I used KM 9.21 beta to make Yamaha upgrades for a 15-100, a 10820N, a 6131, and a 7800. All worked perfectly. Thanks again.

Rob, using KM 9.21 beta and the new NEC DEV4 protocols to program a 10820N, I notice that several buttons get greyed out when I use the "Y" protocols:

L1
L2
L3
M1
M2
M3
Phantom1
Phantom2
Phantom3
Phantom4

Is this normal?

I don't know, do they get grayed out under 9.20? I'll look into it.

Using 9.20 and your manual settings, the buttons are not greyed out.

Also, adding any "Y" protocol commands greys out all of the shifted buttons.

The Robman wrote:To get the ball rolling I have put together a new version of KM which can handle these signals. I've called it 9.21 beta because I don't know if Mike already has a 9.21 in the works.

Yes, I do already have a 9.21 in progress.

jetstar52 wrote:Rob, using KM 9.21 beta and the new NEC DEV4 protocols to program a 10820N, I notice that several buttons get greyed out when I use the "Y" protocols...Is this normal?

No, it is not normal. I'll have to dig into what Rob did to see where the problem is. However, I am about to leave on vacation, so it may have to wait until I return.

The Robman wrote:For both the KM and RM implementations, if the users remote has the 4Dev executor built in, it would be a good idea to only supply a protocol upgrade if they assign a function that uses the "y" variant to one of their buttons.

I am not thrilled with subverting the standard NEC 4DEV combo this way for what is essentially a "hacked" JP1 protocol, and I think it will be difficult to implement the above in RM. What I would propose is to make a "new" protocol called NEC Yamaha Combo that always provides a protocol upgrade. This way, RM would be able to import KM files using this protocol much easier.

Per Mike's suggestion, I have separated the new executor from the official UEI one, so you will now need to explicitly select "NEC 4Dev Yamaha Combo" as the protocol in order to get the new features.

Revised KM 9.21 beta file here:
http://www.hifi-remote.com/forums/dload ... le_id=8764

Updated KM upgrade file here:
http://www.hifi-remote.com/forums/dload ... le_id=8765

I have also fixed the issue where the shifted buttons are getting grayed out.

I have found some time to work on adding this to RM/RMIR, but I see the approach has changed. Please rephrase the original request so I know what to do in RM.

The approach hasn't changed, the only difference is that, rather than changing the existing "NEC 4Dev Combo" executor, I saved it as a new executor called "NEC 4Dev Yamaha Combo", where the new executor does everything that the old one does, plus it also handled the new Yamaha signals.

This was per Mike's suggestion to make it easier to implement in RM. In other words, we are now forcing the user to explicitly state that they want a protocol upgrade up front, rather than just giving them a protocol upgrade if they enter some Yamaha signals.

Well, I sprained my ankle severely yesterday, so I'm a little cranky. I've posted this before, but the "new" Yamaha signals have more variety than what Rob has implemented. [Actually, I have trouble understanding Rob's description of "bit0 (ie, the rightmost bit) of the OBC complement is flipped." I would have said bit 7 of the OBC complement is set to zero.]

Anyway, from Yamaha's description of the IR signals for the RX-V1800, I think the various possibilities are described by the following examples of the "data code", as Yamaha terms it. Codes are in hexadecimal notation.

06 79 (This signal can be sent by Rob's executor)
06 78 (Only seen in ID2 setting, not ID1)
03 7D (Only seen in ID2 setting, not ID1)
CE 31 (Standard NEC1)
CE 30 (Only seen in ID2 setting, not ID1)
FB 05 (Only seen in ID2 setting, not ID1)

Standard NEC1 signals send the complement of the OBC as the second byte of data; another way of describing this is to note the the sum of the 2 bytes is always 0FF or 255 decimal. Another way to describe this is that the XOR of the 2 bytes is always 0FF. The 5 non-standard signals above have sums of FE, 100, 7E, 7F, and 80. Here are the example codes, the sums, and one method of calculating the second byte.

06 79 7F (complement and set bit 7 to 0)
06 78 7E (add 1, comp and set bit 7 to 0)
03 7D 80 (subtract 1, comp, bit 7 to 0)
CE 31 FF (complement)
CE 30 FE (add 1, comp)
FB 05 100 (subtract 1, comp)

I think that there are 4 states described here, and so at the minimum, it would take 2 control bits to instruct the (more complicated) executor on which signal is desired.

The above codes are listed in the Yamaha Master at RC. The "gap" codes tend to be written in red. See the RX-V1800 pdf under AV receivers.

3FG wrote:[Actually, I have trouble understanding Rob's description of "bit0 (ie, the rightmost bit) of the OBC complement is flipped." I would have said bit 7 of the OBC complement is set to zero.]

That's because you're looking at the binary from Yamaha's POV, whereas my description was based on looking at the binary from the executor's POV. (Keep in mind that the NEC protocol is LSB and the data in the Yamaha PDFs is presented in it's natural form, but the data needs to be reversed when it's fed into a UEI executor).

3FG wrote:Anyway, from Yamaha's description of the IR signals for the RX-V1800, I think the various possibilities are described by the following examples of the "data code", as Yamaha terms it. Codes are in hexadecimal notation.

06 79 (This signal can be sent by Rob's executor)
06 78 (Only seen in ID2 setting, not ID1)
03 7D (Only seen in ID2 setting, not ID1)
CE 31 (Standard NEC1)
CE 30 (Only seen in ID2 setting, not ID1)
FB 05 (Only seen in ID2 setting, not ID1)

Standard NEC1 signals send the complement of the OBC as the second byte of data; another way of describing this is to note the the sum of the 2 bytes is always 0FF or 255 decimal. Another way to describe this is that the XOR of the 2 bytes is always 0FF. The 5 non-standard signals above have sums of FE, 100, 7E, 7F, and 80. Here are the example codes, the sums, and one method of calculating the second byte.

06 79 7F (complement and set bit 7 to 0)
06 78 7E (add 1, comp and set bit 7 to 0)
03 7D 80 (subtract 1, comp, bit 7 to 0)
CE 31 FF (complement)
CE 30 FE (add 1, comp)
FB 05 100 (subtract 1, comp)

I think that there are 4 states described here, and so at the minimum, it would take 2 control bits to instruct the (more complicated) executor on which signal is desired.

Looking at the RX-V1800 file I see that there is another flavor, in addition to bit0 being complimented, some of the ID2 codes have bit7 complimented. Sometimes this is instead of bit0 and sometimes this is in addition to bit0.

06 79 (bit0 complemented)
06 78 (bit0 and bit7 complemented)
03 7D (bit0 and bit7 complemented)
CE 31 (Standard NEC1)
CE 30 (bit7 complemented)
FB 05 (bit7 complemented)

I have just updated the executor included in my beta version of KM 9.21 so that it can now produce all of the Yamaha variations (that we know of).

So now, there are three Yamaha variations in play:

NEC1-y1 - where bit0 of the OBC complement is flipped
NEC1-y2 - where bit7 of the OBC complement is flipped
NEC1-y3 - where bit0 and bit7 of the OBC complement are flipped

NOTE: the bit0 and bit7 references are based on viewing the binary as it's presented to the executor (ie, 76543210). It's NOT based on how the signals are presented in the Yamaha PDFs.