JP1 Remotes

[mathdon]

[HamburgerHelper1]

I use the JP1/JP1.1/JP1.2/JP1.3 Socket Extension Adapter from diy gadget and it fits better on the pins, but as we know diy gadget has not been responding to orders, unless that has recently changed. Perhaps you could make your own extension
I never noticed the pin difference before this because this adapter has a very good snug fit that i have not had any problems with


https://www.diygadget.com/remote-control-accessories/jp1-jp1-1-jp1-2-jp1-3-socket-extension-adapter

[The Robman]

[dtrump]

FWIW, I have a bench grinder and was able to shave a fraction of an inch off the connector on my cable, a bit short of exposing the female pin. It now holds a bit better on the JP1 of the remote.

I experimented first on my older parallel port cable. I made up both cables myself years ago.

[The Robman]

Well done.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[dtrump]

Now, I just have to get used to the latest tools. Still struggling a bit to make the 3680 do what I want.

[dtrump]

I've made some progress but now I'm trying to sort out how to make use of the Realtime Macros. Nothing that I have tried to capture on the remote seems to make sense when downloaded from the remote and doesn't do what I was expecting anyway. Creating something using the macro editor doesn't seem to do what I think it should.

I want to put pauses between some macro commands. I think that used to be done with an Extender, but not surprisingly there doesn't appear to be an extender for the 3680.

[dtrump]

I finally sorted the Realtime Macros out and it is making sense now.

I think I'm good (for now)!

Dick

[HamburgerHelper1]

Both the URC-3660 and the URC-3680 have a lot of features without and extender
Would you be so kind as to upload your mir setup of the URC-3680
Maybe others can learn from it
Thanks
Randy

[dtrump]

Will do when I feel I'm finished. What I have done isn't terribly fancy. It is for my home office where a 22" Samsung doubles as a 2nd monitor for my PC. I wanted a pair of single buttons to switch between the two modes including powering on if it was off. In TV mode, the STB is a Tivo Mini. I did create a custom RMDU for the TV since none that I tried had both the discretes I needed and worked on volume (that seemed odd). I certainly didn't try them all. It just seemed expedient to take one that was close and add what I needed.

Dick

[dtrump]

This will be a bit lengthy because I think I have stumbled into a bug in RMIR and want to provide as much detail as I can.

I felt the programming for my needs was about complete yesterday, but today opened RMIR and loaded my working rmir file and found that my Realtime Macros were apparently corrupt. Where there had been the typical Hold() commands, instead there were FastFwd(Held)(12.0) commands before each actual desired command.

I started to remove those, but then decided to download the working configuration from the remote. Same results.

Next, I tried loading several prior configurations that I had abandoned in favor of my "nearly final" result. All of those loaded normally with the usual Hold(0.13) preceeding each command. Reloading the working version, showed the same FastFwd(Held)(12.0).

What is most different about that version is that I had created a custom RMDU file for the TV in use, saved it, then on the Devices page of RMIR selected New, then Open selecting the newly created RMDU (that has all the discretes that I wanted or could find for future use).

I tried loading that same RMDU into another prior version, saved it and reopened it to see if that changed the macros. It did not.

Finally, I opened the corrupt RMIR file in a text editor, found the macro section and compared the hex commands with a non-corrupt file. It appeared that the hex value of 74 had been changed to 71 in the corrupt file. So I edited those back to 74, saving it under a new name and reloaded it in RMIR. All instances of the FastFwd command had changed back to Hold(), some with the value 0.13 (normal) and some with a value of (0.53).

One final note: I just remembered that I had also added notes to the macros in the version that became corrupt. I have not explored whether that makes a difference yet.
---
Dick

[HamburgerHelper1]

I'm not sure if it's RMIR or the RDF. I only made the RDF by modifying an existing RDF so I could have made mistakes and We will need expert help on this. Can you please upload any files you deem of value to the diagnosis section (and post links to them).

Thanks

Randy

[dtrump]

Here are the 4 files I have uploaded to the diagnosis folder:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26645
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26646
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26647
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26648

I was unsure about saving the RMDU to the RMIR folder, but figured I
shouldn't save it to Device Upgrades until it is proven to not cause problems.

The final (corrupted) file nearly does what I wanted the two macros to do
except for lack of "Live" taking my Tivo mini out of a sleep mode when it
has been inactive for several hours.

Objective was to have the two macros select the two operating modes either with the TV powered off or already on.

Dick

[mathdon]

I am not clear at what point the corruption is occurring, or whether the file marked corrupt actually works as intended when loaded into the remote. I do not have a URC-3680 and so cannot test this. From what you have written, and from my testing with RMIR, my best guess is that the following is happening.

1. It is the remote that is changing the 74's to 71's. If I load either form into RMIR and re-save the file then those values do not change, so I think it has to be the remote that is doing it.

2. The remote is changing these values because it uses 71 and 72 as timecodes, rather than the 74 and 75 specified in the RDF. In fact, 71 and 72 are the default values in RMIR as these are the values used in the URC-7955 which was the first remote in which these Real Time Macros were seen.

3. If 1 and 2 are correct, the issue is that RMIR is displaying the wrong names, not that the codes in the "corrupt" file are wrong. This would mean that if you load the "corrupt" file into the remote then it works as intended, even though it does not display what you expect when loaded into RMIR.

If I am right about all this, then you can resolve it by editing the RDF as follows:

4. In the RealTimeMacroData entry in the [General] section, delete the values $74 $75 and the preceding comma so that it simply reads

RealTimeMacroData=$2D $2E $2F

It will then use the default values $71 $72

5. Delete the last line but one in the [Buttons] section so that the last two lines become

Backlight=$3C,
Phantom1=$3D,Phantom2,Phantom3

This is needed as the codes $71 and $72 are assigned to buttons FastFwd(Held) and Rewind(Held) in that section, which conflicts with their use as timecodes.

Please try it with these changes and report back on whether or not this resolves the problem. If you make these changes and load the "corrupt" file, it will display as you intend but whether or not it will work in the remote as you intend is something that I cannot test.
_________________
Graham

[dtrump]

Thanks for the analysis. I think you are correct about the display of the time codes. I loaded the "corrupt" file and as you predicted, it operated normally. I have not yet edited the RDF but will try that the next day or two. Meanwhile, my comment about a bug in RMIR stands, but certainly not as serious as I was assuming.

Besides the display issue, I had some of the Hold() commands completely disappear at one point in testing. Inspecting the RMIR file in a text editor confirmed that those $7x entries were missing. That might be traced back to the RMDU or RDF. That happened before I created the more complete RMDU and has not recurred since.

Dick