JP1 Remotes

stderr · Joined: 07 Aug 2005 Posts: 20

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:

The Robman · Posted: Sat Jan 02, 2021 10:43 pm Post subject:

I made this based off of the codes that you posted:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26205
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

stderr · Joined: 07 Aug 2005 Posts: 20

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 · Posted: Sun Jan 03, 2021 9:56 am Post subject:

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

mdavej · Expert Joined: 08 Oct 2003 Posts: 4501

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

stderr · Joined: 07 Aug 2005 Posts: 20

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 · Expert Joined: 08 Oct 2003 Posts: 4501

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

stderr · Joined: 07 Aug 2005 Posts: 20

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 · Joined: 07 Aug 2005 Posts: 20

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 · Posted: Mon Jan 04, 2021 9:18 am Post subject: Re: Got it...

stderr · Joined: 07 Aug 2005 Posts: 20

Excellent response, thank you!

File uploaded:

http://www.hifi-remote.com/forums/dload.php?action=file&file_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 · Posted: Mon Jan 04, 2021 12:11 pm Post subject:

stderr · Joined: 07 Aug 2005 Posts: 20

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

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 · Posted: Tue Jan 05, 2021 8:55 am Post subject:

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

stderr · Joined: 07 Aug 2005 Posts: 20

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.