receiver: Yamaha R-N803 / remote: RAX37

[stderr]

1. Device: Yamaha R-N803
2. Type of device: 2.1 channel networked receiver
3. Year: 2020
4. JP1/UEI Remote model: URC-6012
5. Do you have a JP1 cable? Yes
6. Still have original remote? Yes: RAX37
7. Checked the file section? Yes
8. Checked Pronto file section (at R/C)? Yes
9. Partially working setup code? Yes: Yamaha R-S202.rmdu
10. Learning remote question? No
11. Have you tried the JP1 Lookup Tool? No
12. If you have a OARUSB04G, URC-6440 (or similar) remote, have you tried simpleset.com? No

I have tried guessing at some of the codes by copying from a Yamaha RX-V685 rmdu file, but some functions aren't there. Things missing are codes for opt1, opt2, coax1, coax2, memory, bluetooth, etc. The code for memory on the v685 is 19 a4, but on the s202 it's 19 a2, so this I think this is getting me a little off course.

I do not have a learning remote, but I do have a logic analyzer and an ir receiver, and a power supply, and the rax37 remote. Here's what I get when I read each button:

Code: Select all

button	byte1	byte2	byte3	byte4
pwr	7e	81	2a	d5
speaker a	7a	85	9a	65
speaker b	7a	85	9b	64
phono	7a	85	14	eb
sleep	7a	85	30	cf
coax1	7a	85	18	e7
coax2	7f	01	4a	b5
bluetooth	7a	85	be	c1
opt1	7a	85	53	2c
opt2	7a	85	56	29
cd	7a	85	15	ea
line1	7a	85	19	e6
line2	7a	85	c1	e3
line3	7a	85	c0	3f
tuner	7a	85	16	e9
net	7f	01	3f	c0
usb	7f	01	72	0d
band	7a	85	ae	51
tuning+	7f	01	64	1b
tuning-	7f	01	61	1e
memory	7f	01	67	18
preset+	7f	01	5e	21
preset-	7f	01	5b	24
up	7a	85	9d	62
right	7a	85	9e	61
down	7a	85	9c	63
left	7a	85	9f	60
enter	7a	85	de	21
home	7a	85	c2	3d
return	7a	85	aa	55
setup	7a	85	84	7b
option	7a	85	6b	14
now_playing	7a	85	43	3c
mute	7a	85	1c	e3
vol+	7a	85	1a	e5
vol-	7a	85	1b	e4
repeat	7f	01	45	ba
play	7f	01	99	e6
shuffle	7f	01	46	b9
rev	7f	01	6c	93
stop	7f	01	69	96
fwd	7f	01	6d	92

[The Robman]

I made this based off of the codes that you posted:
http://www.hifi-remote.com/forums/dload ... e_id=26205

[stderr]

Thanks for the speedy response!

Unfortunately, the file spec's a protocol name of NEC1-f16 Official, which confuses RemoteMaster when when I load the file. Do I need a protocol upgrade to make this work?

The file I started with had:

Remote.name=URC-601x
Remote.signature=6_806_80
DeviceType=Amp
DeviceIndex=2
SetupCode=504
Protocol=01 AD
Protocol.name=NEC 4DEV Yamaha Combo
ProtocolParms=122 133 126 129 127 1 255 127
FixedData=a1 5e 81 7e 01 7f 00 01

...and it did work for some, but not all, functions.

[The Robman]

Do you have an out-of-date version of RM? I chose the f16 version because it's easier to use, to use the Yamaha version I first need to remind myself what each of the y1/y2/y3 variants mean and then add formula to my spreadsheet to determine which OBC2 value corresponds to each, and I just didn't have the time to do all that.

[mdavej]

Using RMIR 2.10, I just loaded Rob's upgrade into a URC-6012 with no problem.

[stderr]

You are correct; it's an old version: v2.01. I just downloaded v2.12.1, and the data file imports now, but this newer version doesn't see the remote. I can start the old version and it does. Did something change in this new version?

<edit>

I see the v2.01 version I had was installed with a full windows installation script and is an executable, whereas all the others are java programs. I have tried these on both a windows 10 machine and a debian linux machine. The app installs and runs on both machines just fine, but does not see the remote. I have also tried v2.05, and v2.09.

I used to use a parallel port interface, but those are no longer available, so I used an arduino nano with Tim6502's implementation. Frustrating that it worked first try with the v2.01 version, but does not work with anything newer. I can see the arduino is receiving from the host when I attempt to download (lots of blinking lights) but the tx led never lights up, and the communication fails.

<edit #2>

I hooked up the logic analyser and looked at the difference between the two programs. The old one sends 0x45, or 'E' and gets back an ACK from the arduino. The new one/all java ones send out an initial 4-byte message: 0x00, 0x02, 0x51 (Q), 0x53 (S) first, which the arduino ignores. Later an 'E' is sent and it does respond with an ACK, but by then it's too late, and rmir gives up. If I knew how to respond to the 'Q' and 'S' commands, I'd just modify the arduino code and try again. Is this something I can find out?

[mdavej]

Maybe just go back to the old version but replace protocols.ini file with latest version?

[stderr]

What?!? I can do that? I'll give that a shot, if it comes to it.

After playing with the logic analyser a bit, I figured out the arduino board is being reset several times. The usb/serial interface uses the DTR line as a reset, coupling it to the reset pin of the processor through a 100nF cap; asserting DTR triggers a reset, and the RMIR code is not waiting long enough for the processor to restart. I suspect asserting DTR is either unintentional or not in RMIR's control. Anyway, if I jumper the reset line on the arduino board to +5V, the pulse on DTR does not drive it low, and I can program the remote! It fails verification though, not sure why, but the remote does work.

I'm still playing/debugging the code, as I appear to have given Rob some wrong codes to work with.

[stderr]

Much gratitude for the help, rmdu file, and suggestions from everyone!

After a little more fiddling, and some guessing at what the discrete on/off codes might be, I have a working remote. I had the prev+/- codes reversed, and the Line2 code was wrong. I don't seem able to assign the coax1/coax2/phono inputs to shifted numbers on the remote, but I have nothing connected to them for now, soooo... guess I'll let that go.

I do have a few of questions about rmdu files:

1. Is there an algorithm for selecting the device code number? Rob, you used 2000; I had 0504 for my previous amp, so kept it for now.

2. Is there a reason to choose Amp or Rcvr/Amp over VCR, or vice versa? I'm a little puzzled at this part.

3. What does the DeviceIndex parameter do?

Can I upload the data file somewhere? I'll post it here for now:
{deleted}

Side note: I'd love to figure out how to get this arduino code to talk to RMIR without so much trouble; this part was super convenient, and the nano is so inexpensive. One extra data point: the nano I have here does not use an FTDI chip, but instead a CH340, for which a driver is installed and it does seem to work brilliantly. It also worked on a debian laptop without installing a driver, so who wouldn't be pleased?

<edit>
...right after writing the above, while working out the changes to all the macros, program verification started mysteriously working. Now, it just works; wish I knew exactly why... The reset line is still jumpered to +5V, but now RMIR does not complain, and the verify checkbox is still checked.

[The Robman]

... and the Line2 code was wrong.

I wondered if that was the case.I just created a spreadsheet that takes an OBC1 and OBC2 value and determines whether the OBC2 value is NEC, Y1, Y2 or Y3 format, so you can use the NEC 4Dev Yamaha Combo executor if you like. And the line2 OBC2 code shows up as invalid.
http://www.hifi-remote.com/forums/dload ... e_id=26206

1. Is there an algorithm for selecting the device code number? Rob, you used 2000; I had 0504 for my previous amp, so kept it for now.

While UEI might use some logic in assigning setup codes, we don't. You can use whatever number you like. I generally choose 2000 as it's more obviously not a real UEI setup code, whereas 0504 sounds like a real setup code.

2. Is there a reason to choose Amp or Rcvr/Amp over VCR, or vice versa? I'm a little puzzled at this part.

UEI puts setup codes into the correct category, so an amp device like this would definitely end up in one of their Audio groups, but again, we're not restricted to those rules, so for us it's more a case of, which mode has the most buttons available. If using AMP means that you'll have to program 3 or 4 keymoves, whereas using VCR means you won't need keymoves, go ahead and use VCR, we won't tell anyone.

3. What does the DeviceIndex parameter do?

Where are you seeing those?

Can I upload the data file somewhere? I'll post it here for now:
{deleted}

Yes please, please load it to the Audio folder in the file section, the same place where you downloaded the RM file that I created for you. Please post a link to the file here once it's loaded. I deleted the file contents from this thread.

Side note: I'd love to figure out how to get this arduino code to talk to RMIR without so much trouble; this part was super convenient, and the nano is so inexpensive. One extra data point: the nano I have here does not use an FTDI chip, but instead a CH340, for which a driver is installed and it does seem to work brilliantly. It also worked on a debian laptop without installing a driver, so who wouldn't be pleased?

<edit>
...right after writing the above, while working out the changes to all the macros, program verification started mysteriously working. Now, it just works; wish I knew exactly why... The reset line is still jumpered to +5V, but now RMIR does not complain, and the verify checkbox is still checked.

I was going to suggest that you make a new, separate, post about this in the Software forum, but it seems that you now have it sorted, so well done.

[stderr]

Excellent response, thank you!

File uploaded:

http://www.hifi-remote.com/forums/dload ... e_id=26208

Rcvr/Amp vs VCR: The light finally comes on about the motivation: minimize key moves to minimize memory footprint.

The DeviceIndex parameter is in the rmdu file. I used a text editor to create the file, so I could see all the fields, and was just curious about the meaning of these.

[The Robman]

The DeviceIndex parameter is in the rmdu file. I used a text editor to create the file, so I could see all the fields, and was just curious about the meaning of these.

Ah, ok, so first, just FYI, you should never edit RMDU files yourself as you may do something that will cause RM to crash, you should always let RM edit them for you.

But with that being said, I just did some experimenting to confirm what DeviceIndex does. If you look at the RDF for the URC-601x, you'll see that it has 4 device modes (TV, VCR/DVD, Audio and CBL/SAT) and they are numbered 0 thru 3. You'll also notice that, further down, there is a [ButtonMaps] section where the maps are numbered 0 thru 3, likewise for the [SetupCodes] section.

RM supports many more than 4 device modes, as some remotes have more than what the 6012 has, so the [DeviceTypeAliases] section brings them all back to the 4 basic modes that this remote supports.

When you select a device mode for your upgrade, RM stores the numeric version of that mode (ie, the 0 thru 3 number, in this case) in the RMDU file also.

But again, apart from satisfying your curiosity, you should not have any need to look at the internals of an RMDU file and should certainly never edit it by hand.

[stderr]

Lol, you made my day with the do not edit this file comment. There's something just funny about doing something the wrong way, succeeding despite that, and being (politely) criticized for it. Thank you.

I will say, when I made up the file, I started with an existing one for a different remote talking to a similar amp (yamaha r-s202), stripped all of the button lines out, removed all of the notes, and re-ordered the preliminary text at the top of the file in a way that made sense to me. Then you responded with the first pass, so I pasted in the function codes, protocol number and name from your file, added the discrete power on/off codes, fixed my line2 error, flipped the preset and tuning codes around (both were reversed) modified the remote signature to match mine, gave it a new setup code, loaded it into the device upgrade editor, and assigned the functions to buttons. When I compared the updated file with the one I originally made, it worked, so all's well.

I wouldn't suggest this method, and I should shut up about it; if the karma gods notice, the universe will smite my remote, or worse. Next time I'll try it your way.

The explanation about the DeviceIndex is perfect, so thanks for that too.

[The Robman]

Have you actually used RMIR yet? If not, please give it a try. In fact, do everything that you did via manual edits only this time do it using RMIR, I think you'll find it surprisingly intuitive.

The main reason I was suggesting not to do manual edits is because, if you did do something wrong, you could either mess something up in your remote, or cause RMIR to crash, and in either case, it could be tricky for us to try and resolve it for you.

[stderr]

RMIR is the tool I use to pull all the devices together and program the remote, is it not? I used this on both a windows and a linux machine, as mentioned. Do you mean RMPB or RMDU? Since I wasn't building a new protocol, I did not look at RMPB; that leaves RMDU. This is the tool I used to organize the button assignments after editing the file. I launched RMDU by clicking on the amplifier device in RMIR; so, yes to using both RMIR and RMDU. I'm confused at the question though. Is there another way to program these?

Also, your point about bricking the remote or crashing RMIR is the reason I said, "Next time I'll try it your way." I wouldn't want either of those two outcomes, especially the former.