JP1 Remotes

I'm having trouble understanding how RM and KM decide which hex values to generate, using the NEC 4 Dev (011A) protocol. I entered dev=122 and dev2=126, and then chose OBC=127. For device 126, both RM and KM calculate the hex data as 01 60, which corresponds to EFC5=17061. Now I know that some Yamaha receivers do respond to dev 126, OBC 127 (from RC files and old posts here) and that they furthermore respond to 17029, which is hex 01 40. See this thread to see the motivation for this post.

If I enter EFC5=17029 (corresponding to 01 40), both programs report that I have selected dev 126, OBC 127. Or in RM, entering either 10 40 or 01 60 yields NEC1, dev 126, OBC 127

In summary, hex data of 01 40 and 01 60 seem to both correspond to device 126 and OBC 127 in this protocol. It turns out that with either program, entering device numbers, style, and OBC, yields an output of 01 60. In this particular case, I suspect that 01 40 is the desired output. At least, 17029 (01 40) is the "official" EFC.

So does the executor treat 01 40 and 01 60 differently? I can see that bits 6 and 7 of the low byte determine which device/subdevice pair are used, and bit 4 selects NEC versus NECx. Bit 0 seems to select NEC1 or NEC2. Does bit 5 matter?

I'm interested in this too. The last person I was trying to help with the RCA combo had similar problems, where the device/OBC didn't produce the correct hex, and when the hex was corrected in RM, the EFC was still wrong. Both decoded to the same device/OBC. https://www.hifi-remote.com/forums/viewtopic.php?t=11237
I could not even figure out how to do this in KM, but RM allows you to work with the hex.

3FG wrote: So does the executor treat 01 40 and 01 60 differently? I can see that bits 6 and 7 of the low byte determine which device/subdevice pair are used, and bit 4 selects NEC versus NECx. Bit 0 seems to select NEC1 or NEC2. Does bit 5 matter?

bit5 determines how the subdevice is calculated. if bit5=1 that means to take the subdevice as is. if bit5=0 that means the subdevice is the complement of device. For the 011A protocol, the 2nd var byte is the control byte which is the same as the first fixed byte in the 005A protocol. The 005A has 3 fixed bytes: control device subdevice.

So both RM and KM handle straight NEC1 by clearing bit 5 if no sub device is specified, and setting it if one is.

In contrast, 4 Dev Combo always sets bit 5, and calculates the subdevice (complement of the device) if it isn't specified.

It's not clear to me why we would want to handle subdevices differently between 005A and 011A. It also appears that our 4 Dev approach (always setting bit 5) is different than UEI's approach. We can see that in the published EFC values, for example Audio 1815.

From my naive standpoint, using the two different approaches is confusing. Wouldn't it be better to use the same method as UEI does for the 4 Dev?

Edited to add: The linked thread in the first post above shows that the approach we take using the 4 Dev Combo (which sets bit 5, and computes the complement) does not work, while clearing bit 5 and letting the 011A executor compute the second byte does work. That's using the new RCA RCRP05B remote.

Our approach assumes implicitly that you can adjust the fixed data as those bytes are part of a device upgrade. That thread points out that when using EFCs, we have no access to the fixed data(subdevice) and may have to use bit5=0 or use the subdevice as listed(bit5=1).