View previous topic :: View next topic |
Author |
Message |
petehouk
Joined: 22 Feb 2015 Posts: 14
|
Posted: Sun Mar 15, 2015 2:34 pm Post subject: delay in button presses |
|
|
Hi everyone. I am trying to get my RCRP05B set up to work with my HTPC.
I have an Ortek VRC-1000 that I am using to teach the directional functions to my RCRP05B. I was partially successful. Some of the directions are OK but at least one of them is prone to behaving like a long button press. (If I press it two times in a row it will move 5 or 6 spaces as if I had held it down instead of doing two discrete presses.)
But some of the directions worked OK. I am guessing that this has something to do with how long I am holding the button down on the Ortek while I am teaching the RCRP05B. I have tried it several times but I have never been able to get all 4 directions right.
So I thought I would fix this by uploading the Ortek upgrade into the RCRP05B. I got that to work, but I have the opposite problem. I have to hold the buttons down too long. I know this sounds like a trivial problem but when you are using the directional buttons to navigate on-screen menus a slight delay in every button press can get really tedious.
So now that I have the upgrade loaded, I have several different options that I can compare. I taught the right and left buttons to RCRP05B and assigned them to the AUD device. I loaded an upgrade and assigned it to the DVR device. The AUD right button is is too touchy. The AUD left button is just about right. The DVR left and right buttons are both too sluggish.
I also have the Ortek for comparison. The AUD left button is almost as good as using the original Ortek in terms of responsiveness.
Is there some way to adjust this feature? Or fix them all so that they are as good as the AUD left button? What should I be looking for here?
I loaded the remote image here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13252 |
|
Back to top |
|
|
jeajea
Joined: 24 Feb 2010 Posts: 283 Location: USA |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sun Mar 15, 2015 4:45 pm Post subject: |
|
|
Jim,
In spite of the name, OrtekMCE is a completely different IR protocol from MCE. |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Sun Mar 15, 2015 4:54 pm Post subject: |
|
|
Note that the learned signal that works has a final frame, the others don't.
That would explain the double presses, there is nothing to say this is a new press. |
|
Back to top |
|
|
jeajea
Joined: 24 Feb 2010 Posts: 283 Location: USA |
Posted: Sun Mar 15, 2015 5:00 pm Post subject: |
|
|
3FG
Is his IR receiver compatible with MCE? If not Pete would need to buy MCE
receiver (or the least expensive Rosewill MCE remote he can find that
includes a reliever) _________________ Jim Anderson |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sun Mar 15, 2015 5:22 pm Post subject: |
|
|
I loaded your RMIR file into my RCRP05B and then captured the signals with a IR Widget.
The learned signal (AUD left arrow) whcih works well has a final frame and a 49mSec lead-out. The upgrade has a final frame (not surprisingly) but has a lead-out of 89mSec, which adds about 80mS to each button press.
Change the OrtekMCE executor in protocols.ini from
43 88 11 8B 16 89 84 10 07 06 00 F0 00 DC 00 F0 00 DC AD D4 03 C0 00 DC FF FF 04 1C 11 2C FF CF FB 01 2E 10 03 10 04 1A F7 29 05 00 C2 F0 C2 44 05 C2 29 05 1C 08 C0 C2 10 05 1A FA F6 01 46 46 29 01 B6 03 04 F0 05 F6 01 46 56 29 FE B6 03 06 8D 01 46
to
43 88 11 8B 16 89 84 10 07 06 00 F0 00 DC 00 F0 00 DC 5F B4 03 C0 00 DC FF FF 04 1C 11 2C FF CF FB 01 2E 10 03 10 04 1A F7 29 05 00 C2 F0 C2 44 05 C2 29 05 1C 08 C0 C2 10 05 1A FA F6 01 46 46 29 01 B6 03 04 F0 05 F6 01 46 56 29 FE B6 03 06 8D 01 46 |
|
Back to top |
|
|
petehouk
Joined: 22 Feb 2015 Posts: 14
|
Posted: Sun Mar 15, 2015 6:46 pm Post subject: |
|
|
Thanks 3FG! That worked great.
So one last question...how does AD D4 = 89ms and 5F B4 = 49ms?
And what if I want to take it down to 39ms? |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sun Mar 15, 2015 7:40 pm Post subject: |
|
|
For S3F80 processors, the lead-out time is expressed in units of 2uSec. ADD4 is hexadecimal notation; when coverted to decimal it is 44,500. 5FB4 converts to 24,500.
I didn't calculate these by hand--instead I used RMIR's facility for working with protocol executors. I used your RMIR file, went to the devices tab, and clicked in the Protocol column next to the #1 (OrtekMCE) upgrade. Then under PD Details, we see that PD0A/PD0B carry the lead-out time. I changed 89 to 49, and it gave the corresponding hexadecimal number.
39mSec? That's an exercise left to the reader Note that standard OrtekMCE uses a lead-out of 49mSec, according to DecodeIR.html |
|
Back to top |
|
|
mdavej Expert
Joined: 08 Oct 2003 Posts: 4501
|
Posted: Mon Mar 16, 2015 8:25 am Post subject: |
|
|
3FG, would you mind putting this change in the protocols.ini file that gets distributed with RM, as well as the RDF changes in the other thread? |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Mon Mar 16, 2015 11:42 am Post subject: |
|
|
I'll work on the lead-out time change. Regarding the RDF changes, I think we need to have a discussion of how to handle these PID conflicts. |
|
Back to top |
|
|
petehouk
Joined: 22 Feb 2015 Posts: 14
|
Posted: Tue Mar 24, 2015 6:55 pm Post subject: |
|
|
39mSec? That's an exercise left to the reader Note that standard OrtekMCE uses a lead-out of 49mSec, according to DecodeIR.html[/quote]
So I changed this down to 9ms and it is a lot more responsive. The RCA responds a lot more like the Ortek does. At 49ms, it is still difficult to use because it takes so long to respond.
If 49 is the "standard" setting, why does 9 work better on my RCA? |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Tue Mar 24, 2015 10:24 pm Post subject: |
|
|
Lead-outs for most IR protocols are in the 50mSec range. OrtekMCE is not a common IR protocol, and we have very few captures from which to deduce the lead-out time. Capturing signals with a learning remote is not a great way to find the details of the timing because the remote attempts to fit the captured data to a few durations. So it is possible that your learns don't closely match the lead-outs used by your OEM remote. Or perhaps they do.
Anyway, you're allowed to shoot any signals you want at a component. |
|
Back to top |
|
|
|