View previous topic :: View next topic |
Author |
Message |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Mon Dec 12, 2022 6:59 am Post subject: |
|
|
dtrump wrote: | It wasn't obvious in looking at it, but the pins are in fact a bit shorter than any of the other remotes I have. |
Many newer remotes have these shorter pins. I don't know of any solution other than just being careful not to disturb the connector once you have it in place. _________________ Graham |
|
Back to top |
|
|
HamburgerHelper1
Joined: 22 Feb 2014 Posts: 574
|
Posted: Mon Dec 12, 2022 9:32 am Post subject: urc-3680 |
|
|
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 |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Mon Dec 12, 2022 11:31 am Post subject: |
|
|
dtrump wrote: | I might try grinding off a bit of the plastic of the plug to make it go a bit deeper onto the pins. |
That might be worth a try. If you do it, let us know if it makes things any better. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
dtrump
Joined: 21 Sep 2003 Posts: 81 Location: Des Moines, IA |
Posted: Wed Dec 14, 2022 1:26 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Wed Dec 14, 2022 2:00 pm Post subject: |
|
|
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! |
|
Back to top |
|
|
dtrump
Joined: 21 Sep 2003 Posts: 81 Location: Des Moines, IA |
Posted: Wed Dec 14, 2022 4:48 pm Post subject: |
|
|
Now, I just have to get used to the latest tools. Still struggling a bit to make the 3680 do what I want. |
|
Back to top |
|
|
dtrump
Joined: 21 Sep 2003 Posts: 81 Location: Des Moines, IA |
Posted: Wed Dec 14, 2022 11:01 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
dtrump
Joined: 21 Sep 2003 Posts: 81 Location: Des Moines, IA |
Posted: Wed Dec 14, 2022 11:52 pm Post subject: |
|
|
I finally sorted the Realtime Macros out and it is making sense now.
I think I'm good (for now)!
Dick |
|
Back to top |
|
|
HamburgerHelper1
Joined: 22 Feb 2014 Posts: 574
|
Posted: Thu Dec 15, 2022 6:43 am Post subject: urc-3680 |
|
|
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 |
|
Back to top |
|
|
dtrump
Joined: 21 Sep 2003 Posts: 81 Location: Des Moines, IA |
Posted: Thu Dec 15, 2022 10:55 am Post subject: |
|
|
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 |
|
Back to top |
|
|
dtrump
Joined: 21 Sep 2003 Posts: 81 Location: Des Moines, IA |
Posted: Sat Dec 17, 2022 3:15 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
HamburgerHelper1
Joined: 22 Feb 2014 Posts: 574
|
Posted: Sat Dec 17, 2022 4:17 pm Post subject: urc-3680 |
|
|
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 |
|
Back to top |
|
|
dtrump
Joined: 21 Sep 2003 Posts: 81 Location: Des Moines, IA |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sun Dec 18, 2022 9:12 am Post subject: |
|
|
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 |
|
Back to top |
|
|
dtrump
Joined: 21 Sep 2003 Posts: 81 Location: Des Moines, IA |
Posted: Sun Dec 18, 2022 9:09 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
|