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.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.
369006 URC-3680
-
HamburgerHelper1
- Posts: 720
- Joined: Sat Feb 22, 2014 2:58 pm
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-contro ... on-adapter
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-contro ... on-adapter
-
The Robman
- Site Owner
- Posts: 21995
- Joined: Fri Aug 01, 2003 9:37 am
- Location: Chicago, IL
- Contact:
That might be worth a try. If you do it, let us know if it makes things any better.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.
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
-
The Robman
- Site Owner
- Posts: 21995
- Joined: Fri Aug 01, 2003 9:37 am
- Location: Chicago, IL
- Contact:
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!
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
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.
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.
-
HamburgerHelper1
- Posts: 720
- Joined: Sat Feb 22, 2014 2:58 pm
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
Would you be so kind as to upload your mir setup of the URC-3680
Maybe others can learn from it
Thanks
Randy
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
Dick
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
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
- Posts: 720
- Joined: Sat Feb 22, 2014 2:58 pm
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
Thanks
Randy
Here are the 4 files I have uploaded to the diagnosis folder:
https://www.hifi-remote.com/forums/dload ... e_id=26645
https://www.hifi-remote.com/forums/dload ... e_id=26646
https://www.hifi-remote.com/forums/dload ... e_id=26647
https://www.hifi-remote.com/forums/dload ... e_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
https://www.hifi-remote.com/forums/dload ... e_id=26645
https://www.hifi-remote.com/forums/dload ... e_id=26646
https://www.hifi-remote.com/forums/dload ... e_id=26647
https://www.hifi-remote.com/forums/dload ... e_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
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.
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
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
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