delay in button presses

petehouk · Post by **petehouk** » Sun Mar 15, 2015 1:34 pm

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 ... e_id=13252

jeajea · Post by **jeajea** » Sun Mar 15, 2015 2:19 pm

If your JP1.2/3 cable is working try using RMIR to load and use my MCE
remote upgrade.

http://www.hifi-remote.com/forums/dload ... e_id=12315

3FG · Post by **3FG** » Sun Mar 15, 2015 3:45 pm

Jim,
In spite of the name, OrtekMCE is a completely different IR protocol from MCE.

Post by **vickyg2003** » Sun Mar 15, 2015 3:54 pm

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.

jeajea · Post by **jeajea** » Sun Mar 15, 2015 4:00 pm

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)

3FG · Post by **3FG** » Sun Mar 15, 2015 4:22 pm

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

petehouk · Post by **petehouk** » Sun Mar 15, 2015 5:46 pm

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?

3FG · Post by **3FG** » Sun Mar 15, 2015 6:40 pm

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

mdavej · Post by **mdavej** » Mon Mar 16, 2015 7:25 am

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?

3FG · Post by **3FG** » Mon Mar 16, 2015 10:42 am

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.

petehouk · Post by **petehouk** » Tue Mar 24, 2015 5:55 pm

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?

3FG · Post by **3FG** » Tue Mar 24, 2015 9:24 pm

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.