Learned NEC-f16 codes not decoding

[The Robman]

1. Which of the available NEC f16 protocols should I use? I find "NEC-f16 3fixed", "NEC1-f16 Official" and "NEC1-F16x" but no "NEC-f16". Since you include both OBC1 and OBC2 (which is not always the complement of OBC1) I suppose that "NEC-f16 3fixed" is not applicable.

You should use NEC1-f16 Official

2. May I ignore the "id2" data? Am I correct in assuming that these are for the case where a different code set is needed to differentiate commands for a second receiver?

That's a question for Yamaha, I have no idea.

[HoneyBrook]

Wow, the spreadsheet and RMDU files are awesome. I wish I had them when I was setting up my Yamaha receivers a couple years ago. I did make do with older data which was very helpful and got me most of the way plus I did some code conversions and some key learning for some functions which weren't covered yet to get mine taken care of. This new spreadsheet has all the latest Yamaha functions and already converted to what is needed in RM.

Yes ID2 is for a second Yamaha receiver. I have 2 Yamaha receivers (a multi zone RX-A2000 using ID1 and a satellite TSR-5790 that I changed to use ID2). One remote can control both independently.

[rsbrux]

@The Robman
Thanks again for the codes. Your Excel sheet had a couple of duplicates in it; I have uploaded a corrected version to the Audio files, since that is where you put the original. It looks like the place for receivers, even A/V receivers.

I have also uploaded my RMDU and RMIR files to the Audio files section. I made a separate RMDU file for each of the ALL, Main and Zone 2 codes, as discussed above, but each borrows codes from the others, which is why I also uploaded the RMIR (to Combo Audio Systems) to show how they fit together. I left all of the codes in the RMDU files, even the ones which don't apply to the RX-V685. Please see the Notes columns for details.

[mark60050]

I have also uploaded ... the ALL, Main and Zone 2

Hi rsbrux and all:

I was very pleased to find this thread now that I had to replace my old RX-V620 with the RX-V685. I tried to use the files that rxbrux posted to update my old Comcast JP1.3 (30393039) remote with codes for the new RX-V685 "MAIN" rmdu. Unfortunately, my Comcast JP1.3 is not working with the RX-V685. I see that the "AUX" light flash, but none of the codes are recognized by RX-V685.

I noticed that the rmdu for the old RX-V620 rmdu was a NEC1 protocol while the RX-V685 is a "NEC1-f16 Official" protocol. Is it possible that my old Comcast JP1.3 remote can't run the newer protocol? Have I missed a step?

As a side note, I do see that many of the NEC1 RX-V620 commands still with work the RX-V685. I am only missing a few IR commands. Is there a way to translate NEC1-f16 codes to the NEC1 protocol.

Thanks in advance for any help you might offer. And appreciate all the great work you guys are doing here!

-Mark

[The Robman]

Do you understand how zones work with this Yamaha device? The codes that rxbrux created are all zone specific, so make sure that you're using the right code for the right zone.

As for the NEC1-f16 protocol, it should work with your Comcast.

As for what NEC1-f16 is, it's just a more free-form version of the regular NEC1 signal. With the regular NEC1 signal, you get a device code, a sub-device code and an OBC, and unbeknownst to you, the OBC is followed by the complement of the OBC (ie, subtract the OBC from 255 to get the number). With NEC1-f16, the second part of the OBC doesn't have to be the complement.

So, looking at the MAIN Zone upgrade, specifically the first 2 functions (MAIN POWER and MAIN SLEEP), you'll notice that OBC2 is equal to 255-OBC1, so these are regular NEC1 signals, just ignore OBC2. For the next 2 functions however (Bluetooth and USB) this is not true, so these really are NEC1-f16 functions.

[mark60050]

Hi Rob,

Thanks for the quick response and the pointers on NEC1 vs NEC1-f16 protocols. I thought I was using the zones correctly, but I will double check the Yamaha manual. I appreciate the confirmation that the Comcast JP1.3 will support the NEC1-f16 protocol as that will save me some time debugging. I'll post an update once I figure out what I did wrong.

Thanks again!

Mark

[mark60050]

After reviewing my old devices and comparing old files I found something strange.

It seems I was using an old Yamaha HTR-54x0 file to control RX-V620.

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

The keys defined for the HTR-54x0 also seem to work on my RX-V685.

The contents of the HTR-54x0 RMDU file are:

Code: Select all

Protocol=00 5A
Protocol.name=NEC1
ProtocolParms=122 null null 0 0
FixedData=00 A1 00

All the key definitions are 2 digit hex which I assume are the obc1 codes that Rob had refered to. Not sure then where I find the dev and sub, but I am guessing it is the ProtocolParms and FixedData.

I am puzzled why this old HTR-54x0 works on the RX-V685 I just purchased from Best Buy last week? I guess there is some backward compatibility.

The new factory remote that came with the receiver is a RAV570 (ZZ47560).

If this rings bell as familiar problem anyone else has bumped into please let me know. In the meantime, I will keep tinkering. Thanks!

[mdavej]

Same Yamaha codes work on at least a couple decade's worth of models. Not unusual at all. Back in '03 we simply didn't know NEC1-f16 existed, so NEC1 was close enough.

If you look at each command in both files, you'll see they're pretty much the same. For example Vol Up in both is dev 122, obc 26.

Post your RMIR file so we can see how the newer upgrade went south when you added it to your remote.

[The Robman]

It looks like you're looking at the RMDU file using Notepad, you really should be viewing it using RMIR as it will give you much more information.

From what you've posted, that RMDU file is using the regular NEC1 protocol with device code 122. The fact that there's no sub-device means that the sub-device position in the signal is the complement of the device code, so as 255-122=133, if you look at an NEC1-f16 file and see device code 122 with sub-device code 133, that's the same. The variable data is always 1 byte with NEC1 (regardless of whether there are 1 or 2 device codes) because the executor code will generate the complement of the OBC for you, whereas with NEC1-f16 you have to supply it yourself.

[mark60050]

Post your RMIR file so we can see how the newer upgrade went south when you added it to your remote.

Hi mdavej,

Thanks for offer for the help with the RMIR. As I was cleaning my RMIR, I inadvertently solved my problem.

For the benefit of others, I had replaced the old device Yamaha HTR-54x0 rmdu with a the new Yamaha RX-V685 rmdu. The AV receiver is a 5th device in my 4 device Comcast JP1 remote. As result, I used key moves to include select functions from the AV receiver such as vol+, vol-, mute, discrete on and discrete off. Turns out I never deleted the key moves that were referencing the old AV receiver (using the old device code) that I had replaced with the new AV receiver having a different device code (effectively deleting the old device). Granted in my test build I mapped the AV receiver to the 3rd device in the 4 device remote. I was not using the keys with the key moves but the keys on the RX-V685 device were not working. Once I deleted the erroneous key moves, the RX-V685 device began working.

So it looks like having the erroneous key moves were some how messing the programming up. I don't pretend to know why. I just know that it works now.

Thanks for the help. You guys are great!

[mark60050]

It looks like you're looking at the RMDU file using Notepad, you really should be viewing it using RMIR as it will give you much more information.

From what you've posted, that RMDU file is using the regular NEC1 protocol with device code 122. The fact that there's no sub-device means that the sub-device position in the signal is the complement of the device code, so as 255-122=133, if you look at an NEC1-f16 file and see device code 122 with sub-device code 133, that's the same. The variable data is always 1 byte with NEC1 (regardless of whether there are 1 or 2 device codes) because the executor code will generate the complement of the OBC for you, whereas with NEC1-f16 you have to supply it yourself.

Your right. I should use RMIR. It is a beautiful piece of software very impressive. I am grateful it exists. I have been using it in one form or another since 2009. I just went to the RMDR to understand what info was imported. I am assembly programmer at heart.

Also, thanks for the patience in explaining the difference between the NEC1 and NEC1-f16. That clicked for me. I was considering just using the NEC1 protocol and hoping the new keys I needed were compatible. However, I have solved my problem (see my response to mdavej).

Again, thanks for all the help. This is a great community!

[The Robman]

So it looks like having the erroneous key moves were some how messing the programming up. I don't pretend to know why. I just know that it works now.

If you left keymoves from an old upgrade behind, those would indeed mess up the programming for the buttons that they are programmed to. In other words, when you test those buttons, you would be testing the old keymove rather than the new upgrade.

I am assembly programmer at heart.

Any familiarity with Samsung S3C8, Motorola HCS08, MAXQ610 or Texas Instruments TI 254x assembler? Those are the main languages that our protocol executors are written in.

[mathdon]

Any familiarity with Samsung S3C8, Motorola HCS08, MAXQ610 or Texas Instruments TI 254x assembler? Those are the main languages that our protocol executors are written in.

The MAXQ610 and TI254x protocol executors do not use the assembly language of those processors. They use a UEI-created pseudocode that is common to the executors of both these very different processors.