JP1 Remotes

Just forget it, Rob. I was just wondering why when I learned some of the Comcast cable functions on the 15-133 the EFCs were different from the original codes used for the Comcast remote. Doesn't have anything to do with the upgrade I'm trying to do.

I'll try Vicky's protocol suggestion.

I think you're missing the fact that your learns replaced those old functions entirely. If the new CH+ matched the old 0476 CH+, that means your learns didn't work. The fact that they don't match is a good thing in this case. The important thing is that everything shown in Rob's post matches, which it does. The original codes are irrelevant since they were all effectively overwritten (technically they're still there, but learns take precedence).

Anyway, we should be in the home stretch now.

I put in Vicky's protocol and now the remote does work!

However, there are some issues. For many buttons, a single press sends the same command more than once. I think some may even be 4 presses (like OK).

The buttons that do that are:
- Cursor movement (2,4,6,8)
- Enter (5)
- Backspace (last)
- Mute
- Pg Up/Pg Dn (Ch+/CH-)
- Left Mouse button (OK)
- Right Mouse button (info)
- Mouse movement Down/Left (guide)
- Next (Live)
- Close (exit)
- Numlock (PIP_SWAP)

Also, the D button (REC) seems to be working slowly and inconsistently.

Finally, is there a way to "speed up" the mouse movement keys:
- left (left arrow)
- up (up arrow)
- right (right arrow)
- down (down arrow)
- up/left (page up)
- up/right (page down)
- down/left (guide)
- down/right (menu)

Thanks Vicky and Dave for all the help. You have done more than anyone could ask. Any ideas on what I can do to fix the problems?

Sounds like Vicki needs to increase the leadout time.

As for the REC button, it sounds like you're getting tripped up by the UEI functionality which requires you to hit the REC button twice. Test it again to see if that's the case (ie, first press is ignored, second press works). The way to override this is to re-program the button using an EFC keymove.

Rob:

I'm glad you guys know what you're talking about, because I don't!

It looks like you're right about the REC button. Hitting it twice appears to work. I may just use a different button instead. Not really that important anyway.

Thanks.

If you want to stick with the REC button, you just need to re-program it using a keymove. Do you know how to do that?

Rob - I think I do. I just stuck it on another button and now it works fine. Now I just need to figure out the multi-press issue.

Thanks.

Plomaris wrote:I put in Vicky's protocol and now the remote does work!

Cool!

However, there are some issues. For many buttons, a single press sends the same command more than once. I think some may even be 4 presses (like OK).

The buttons that do that are:
- Cursor movement (2,4,6,8)
- Enter (5)
- Backspace (last)
- Mute
- Pg Up/Pg Dn (Ch+/CH-)
- Left Mouse button (OK)
- Right Mouse button (info)
- Mouse movement Down/Left (guide)
- Next (Live)
- Close (exit)
- Numlock (PIP_SWAP)

There are two possible culprits, the lead-out time or the minimum number of repeats. Is the OEM remote this sensitive too? If not, then the minimum repeat might be the culprit.

Try editing the protocol upgrade and replace it with this one. This one has no minimum and I recalculated the lead-out time like Rob suggested.

Upgrade protocol 0 = 00 14 (S3C8+) Noname PC like Mitsubishi (PB v4.01)
3D 90 11 8B 0E C5 41 08 08 00 82 01 7C 00 82 03
95 5B 04 8D 01 46
End

Finally, is there a way to "speed up" the mouse movement keys:
- left (left arrow)
- up (up arrow)
- right (right arrow)
- down (down arrow)
- up/left (page up)
- up/right (page down)
- down/left (guide)
- down/right (menu)

Does this function better on the OEM remote?
If the OEM remote is too slow also, then edit the protocol upgrade and replace it with this one, just to see if it is actually possible for the mouse to be speeded up.

Upgrade protocol 0 = 00 14 (S3C8+) Noname PC like Mitsubishi (PB v4.01)
3D 90 11 8B 0E C5 41 08 08 00 82 01 7C 00 82 03
95 4C 5E 8D 01 46
End


Does that speed up the repeating?




EDIT: I CHANGED BOTH UPGRADES ABOVE AFTER I REALIZED I HAD ADDED INSTEAD OF SUBTRACTED THE TIMING DIFFERENCE TO THE LEAD-OUT TIME.

Tom, I corrected my last post and wanted to make sure saw it.

Vicky:

The OEM remote works well, so all my comparisons are against that. It is not sensitive like the 1067. The mouse movements are fast and smooth, which is what I want for the 1067.

I'll try the protocol upgrades when I get home later.

Thanks again for all your work!

I just took a closer look at the original learns and I see now that the leadout time is dependent on the overall time, which complicates things a little. Vicky, how did you determine what time to enter into PB? I've always had to use trial and error to get the "OFF as total" leadouts right.

It occurs to me also that a too long leadout might also cause the symptoms that Tom is seeing. If the leadout is too long, it's possible that the device might interpret it as multiple button presses rather than a held button.

If you want to test the leadout times, here are two buttons from either end of the spectrum. The INPUT button should have the shortest leadout at 20040 uS and the CH+ should have the longest leadout at 25400 uS.

The Robman wrote:I just took a closer look at the original learns and I see now that the leadout time is dependent on the overall time, which complicates things a little. Vicky, how did you determine what time to enter into PB? I've always had to use trial and error to get the "OFF as total" leadouts right.

I just took the two CH+ keys timing data, dumped them into Excel and then did the ABS, of all the times the two rows, and added them up and subtracted the difference between what the Mitsubishi and the OEM were, and adjusted the lead-out time by the units of time. Unfortunately I had ADD on the mind, and then added when I should have subtracted.

It occurs to me also that a too long leadout might also cause the symptoms that Tom is seeing. If the leadout is too long, it's possible that the device might interpret it as multiple button presses rather than a held button.

Yes that is what I came away with too.

If you want to test the leadout times, here are two buttons from either end of the spectrum. The INPUT button should have the shortest leadout at 20040 uS and the CH+ should have the longest leadout at 25400 uS.

Thanks for doing the calculations. If the current change doesn't work for Tom, I'll test it with IRScope.

I sure wish I knew what you guys were talking about. I'm glad I have the experts helping me out.

Hopefully, I will learn and be able to actually contribute in the future.

Plomaris wrote:I sure wish I knew what you guys were talking about.

The infrared signal is just a timed light pattern. We've just been talking about the timings and how they might be affecting your equipment.

You might want to read my Infrared Protocol Primer. It gives you a quick overview how a infrared signal looks.

vickyg2003 wrote:I just took the two CH+ keys timing data, dumped them into Excel and then did the ABS, of all the times the two rows, and added them up and subtracted the difference between what the Mitsubishi and the OEM were, and adjusted the lead-out time by the units of time.

I just tried a different approach. I calculate each ZERO to have a time of 1070 and each ONE to be 2140 (ie, double). So each 16-bit signal has a base time of 1070*16 (ie, if the signal were all zeroes) and the true total time is that total (17,120) plus the number of ONEs times 1070. I then added that number, plus 260, plus the leadout time to come up with 47,050 which I think is probably the true "OFF as total" value.