Page 4 of 8

Re: urc-3680

Posted: Sat Dec 24, 2022 12:10 pm
by The Robman
HamburgerHelper1 wrote:I went back to original RDF again and all is fine.
It does appear though that 71 and 72 affect 74 75 or vise versa
Curiosity are 74 and 75 in the button map?
Nope.

[ButtonMaps]
0 = ($3A, $30, $31, $32, $33, $34, $35, $36, $37, $38), ($23, $26, $27), ($25, $28),
$01, $03, $0F, $72, $10, $11, $71, $12, $13, $14, $15, $16, $17, $18, $19, $1A,
$1B, $1C, $1D, $1E, $1F, $20, $21, $22, $24, $29, $2A, $2B, $2C, $2D, $2E, $2F,
$39, $3B, $04, $05, $06, $07, $08, $09, $0E, $0B, $0C, $0D, $0A, $3C, $02

urc-3680

Posted: Sat Dec 24, 2022 1:48 pm
by HamburgerHelper1
Lets add some more confusion to the mix
I took dtrump's 3680-Samsung-corrupt.rmir and change the 71 to 74 in the macros of this file like he did earlier in this thread.
I uploaded it to my 3680 and downloaded the remote again. All the macros remained as as they were originally setup.
The "watch tv" button did indeed turn on my samsung and set it to hdmi.
Perhaps everything is fine and the corruption came from the bad connection on his cable that he had earlier.
We have not heard much from dtrump lately to see how it is working out

urc-3680

Posted: Mon Dec 26, 2022 9:14 am
by HamburgerHelper1
I stand corrected I manually created timed macro on remote and downloaded it macro is 9 sec hold but RMIR lists it as 0.13 and also changed button label to xshift it does seem to appear though that anything above 6 second is when it screws up
And the codes where changed from 71 to 74

I just tested the 3660 the same way and and the same error occurs on that one as well.
Graham perhaps you could try your 3660 and see if you get similar results

Posted: Mon Dec 26, 2022 1:29 pm
by mathdon
HamburgerHelper1 wrote:I manually created timed macro on remote and downloaded it macro is 9 sec hold but RMIR lists it as 0.13
Did you try using the macro with a 9 sec hold, to see if the remote really does support it? RMIR cannot support such a value, as my understanding of the way the remote stores hold values is that the maximum is 6.4 seconds.

urc-3680

Posted: Mon Dec 26, 2022 1:57 pm
by HamburgerHelper1
on the 3660 i manually did a 16 sec hold macro and it works and RMIR displays wrong keys again
Yes anything above 6 if i make a macro in RMIR it displays overflow error for every key in the macro that is over 6 seconds. key's 6 sec and under in the macro do not display error
If same macro made manually on remote it will display wrong keys and it seems to always show time as 0.13

urc-3680

Posted: Mon Dec 26, 2022 3:23 pm
by HamburgerHelper1
From Testing Manually on the remote i can make a 24 sec hold macro.
It times out at 25 and then the macro will not work

urc-3680

Posted: Mon Dec 26, 2022 3:47 pm
by HamburgerHelper1
I just noticed one other thing about timed macros
According to the manual the dedicated app buttons are device specific timed macros and when manually made on the remote RMIR reflects this but a person would have to know to add that INFO in the macro if they make it in RMIR

Posted: Mon Dec 26, 2022 4:54 pm
by The Robman
Here's my suggestion, unless Graham has any better thoughts. Try creating macros on the remote with different delay intervals (maybe go up 1 second at a time) and then do a raw download (as this will prevent RMIR from interfering) and save the *.ir files. This should give us a good indication of exactly how the remote stores the macro delay times.

urc-3680

Posted: Tue Dec 27, 2022 8:14 am
by HamburgerHelper1
Here is raw downloads of time macros made on the urc3660 using the app buttons per suggestion
I think this will help

Randy

https://www.hifi-remote.com/forums/dload ... e_id=26653

Posted: Tue Dec 27, 2022 9:29 am
by mathdon
Please try development build RMIR v2.14.17 in the RMIR Development folder.

I found the original codes for Real-Time Macro hold times by doing exactly as Rob suggests, but it never occurred to me that anyone would want to hold a button for more than 6 seconds, so I never tried that. I have now done so and found that the URC3660 does indeed use three different codes for three different ranges of duration. These values are 74, 75 and 76. The development version adds support for 76 and its corresponding value range. In this range, durations are stored in units of 100ms, and as they are stored in a single byte, the maximum duration is 25.5sec corresponding to a value $FF.

I have also checked the button codes for FastFwd, FastFwd (Held), Rewind and Rewind (Held) and confirmed that the values 71 and 72 for the held buttons, as in the RDF, are correct.

I would be grateful if Randy can test this version with his URC3680 as well as URC3660. If there are differences in behaviour then it would suggest to me that there are differences in firmware, despite the common signature. Remember that you can load a saved raw download (a .ir file) into RMIR just as you can a .rmir file, and it will ask you to select the remote (in this case URC3660 and URC3680) concerned. In this way you can load the same setup into both remotes for testing.

urc-3680

Posted: Tue Dec 27, 2022 1:25 pm
by HamburgerHelper1
All test's demonstrate that the URC3660 and URC3680
behave the same loading a raw download from one remote into the other.
Macros made manually on the remote and in RMIR behave the same
loaded into either remote.
The timing also appears to be accurate

urc-3680

Posted: Wed Dec 28, 2022 8:36 am
by HamburgerHelper1
Setting a hold of 5 seconds and using a stop watch i get about 5.4 seconds but it could be human error pushing buttons. Maybe others would have different results

Posted: Wed Dec 28, 2022 9:07 am
by The Robman
When you set a delay, do you program the delay by entering a number, or does the remote time you?

urc-3680

Posted: Wed Dec 28, 2022 9:15 am
by HamburgerHelper1
I set delay at 2.3 sec and stopwatch displays 2.29 sec +/- human error

Posted: Wed Dec 28, 2022 10:17 am
by The Robman
So the remote times you, rather than you enter 2.3 somewhere in the process, right?