JP1 Remotes

rsbrux · Joined: 25 Dec 2015 Posts: 52

I am trying to create an upgrade for the Yamaha RX-V685 Receiver. I found many, but not all, of the needed codes in various tables and RMDU files in the file area. I therefore used my URC-8603 to find the best built-in match (2061) and then learn the missing keys. The learned keys fall into 3 types of NEC codes, however, those recognized as NEC-f16 are not decoded. How can I get proper codes to embed in a stand-alone RMDU?
The RMIR file with the learned codes can be found here.

mathdon · Posted: Fri Nov 29, 2019 12:28 pm Post subject:

These signals are not recognised by IrpTransmogrifier, which is the default decoder in RMIR v2.09. However, if you use Options > Set IR Decoder to change to DecodeIR, they are decoded as NEC1-y1 signals. To create a device upgrade with these signals, select the protocol NEC 4DEV Yamaha Combo. The notes for that protocol explain the various options. Under the Functions tab you will find a column headed YStyle. Y1 is one of the styles in the drop-down list that column gives you.
_________________
Graham

Barf · Expert Joined: 24 Oct 2008 Posts: 1140

I assume you are using RM 2.09build6.

If a signal is "recognized as NEC-f16" it *is*, per definition, decoded. Just that for some reason the parameters are lost here. I extracted the raw signals from the "Timing Summary", and fed it through IrpTransmogrifier and got:

rsbrux · Joined: 25 Dec 2015 Posts: 52

Barf · Expert Joined: 24 Oct 2008 Posts: 1140

I started RMIR in the debugger, and here is what happens:

LearnedSignalDecode( Decode decode, Value[] matchDevParms, Executor executor ) is called with the third argument null, it makes an effort to find an executor, which fails (executor == null). Then it just returns, without filling in the parameters (return on line 101 in LearnedSignalDecode).

There are two problems here:

1. Why is no executor for NEC1-f16 found?
2. If no executor is found, this case is to be handled gracefully.

I leave #1 to Graham. Independent of this, #2 should be addressed, because there will always be protocols for which an executor, for whatever reason, is not found.

It appears that the only thing needed for #2 is to make sure that the parameters are assigned (line 124 to 139) before we bail out. I tested by just moved those lines, and everything seemed to work. Graham?

mathdon · Posted: Sun Dec 01, 2019 9:30 am Post subject:

Apologies, rsbrux. I find that there was an omission in the IrpTransmogrifier support in RMIR for the NEC-f16 protocol. Please download rmProtocols.xml and copy it into your RMIR installation folder. That is a patch file for the RMIR support for IrpTransmogrifier which should make NEC-f16 be recognised properly. You should be able to select a mixture of NEC, NEC1 and NEC-f16 learned signals and have the Convert to Device Upgrade convert the whole set into a single upgrade. Remember that you can use the Up and Down buttons on the Learned Signals tab to reorder the signals you want so that they can be selected as a single block. Alternatively the conversion process allows you to add further signals to an existing upgrade. Remember also to set the decoder back to IrpTransmogrifier if you still have it as DecodeIR Confused

.

Please try this and let me know if it works, so that I can include the patch file in the next RMIR build.
_________________
Graham

mathdon · Posted: Sun Dec 01, 2019 9:58 am Post subject:

Barf · Expert Joined: 24 Oct 2008 Posts: 1140

@Graham:

sounds good. Just a note on the patch file semantics: the patch file's content is merged with the original content, so please do not repeat what is already in the original: it just makes it harder to understand what really changed.

mdavej · Expert Joined: 08 Oct 2003 Posts: 4093

Here are all the codes for your receiver: file1, file2.

mathdon · Posted: Sun Dec 01, 2019 6:01 pm Post subject:

The Robman · Posted: Sun Dec 01, 2019 11:06 pm Post subject:

rsbrux · Joined: 25 Dec 2015 Posts: 52

Wow, you guys are amazing! Many thanks for all the help!
As you can see, I haven't had time for this in a while.
Right now I need to prepare a class I'm teaching tomorrow, but I have downloaded all the files you have posted and will try to give you some feedback in a more reasonable time frame Wink

On an unrelated issue, the wiki article "Getting started with Xsight and Nevo" says,

"Xsight does not and never will have an extender."
"It also has enough LCD buttons that long, short, double, shifted and double shifted buttons aren't needed either."

I respectfully disagree with the second statement. The Yamaha has Zone 2 buttons which I have learned on a separate device for lack of buttons (hard or soft) in one device. I find it inconvenient to have to switch to another device to access the Zone 2 functions and would prefer to implement them as shift functions in the main device. However, based on the first statement, I assume that is impossible. If this assumption is wrong, this probably deserves its own thread.

mdavej · Expert Joined: 08 Oct 2003 Posts: 4093

Not sure why you found it necessary to learn any Yamaha functions at all since we have many complete Yamaha upgrades.

If you listed the functions that you use often enough to warrant switching devices, perhaps we could help you combine 2 zones onto one device.

In any case, shifts are impossible, as are extenders for this remote. If shifts are absolutely necessary, you'll need to use a different remote.

The Robman · Posted: Sun Jan 05, 2020 3:04 pm Post subject:

Adding to what Dave said, the f16 format allows you to combine everything into a single upgrade, your only limitation is the number of buttons on the remote, so you could add in a few zone2 buttons with a zone1 upgrade if you like.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

rsbrux · Joined: 25 Dec 2015 Posts: 52

@mathdon
After adding your XML file to my installation directory, I now get Device, Sub-Device, OBC and Hex Cmd codes for the codes learned as NEC-f16. Thanks for the update!

@mdavej
When I started this project, I searched the file are thorouhgly and found several useful RMDU files and code tables. However (as mentioned at the start of this thread), I was still missing some important functions.

@The Robman
Many thanks for the PDFs and especially for the Excel table! With such complete data I should have no trouble making an RMDU without recourse to learned codes. However, I still have some questions:

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.
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?