JP1 Remotes

[jeajea]

RMIR problem(s) loading pause upgrade for Charter URC-1060BC2(3)
RMIR v2.03 Alpha 28 build 13 (and 11)
Windows 7 PRO 64bit
Java 8 update 31 (and 25)
RMIR identifies the remote as URC-1060BC2
Sticker in battery compartment indicates
URC-1060BC3-0780-002-R

[mdavej]

Can you also post a raw download?

[jeajea]

the raw download (has three other device upgrades

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13201
_________________
Jim Anderson

[mathdon]

Nothing you have described suggests to me a problem with the RMIR program.

[ruidosobruce]

[jeajea]

Thanks for explaining how things actually work.
My choice of using the record button for testing was bad.
My only remaining issue is pause durations that are correct when
assigned to a device slot become 25+ seconds when a key move is use
to assign the function to a button on a different device.

It appears to be using a duration value of 255 or maybe 0.

Is this a known key move limitation?
_________________
Jim Anderson

[3FG]

BC2 versus BC3: As near as I can tell, the only difference in these remotes is the sticker in the battery compartment. They have the same signature, and separate RDF files would contain identical information except for the name. I'm quite confident that internally the two remotes are identical. From my point of view I would rather rename the RDF to 202608 (Charter OCAP C4000 URC-1060BC2_BC3) (or whatever doesn't break the RDF naming rules) and not oblige users to make a meaningless selection of BC2 or BC3.

I'm also comfortable that the Pause executor works, at least on an Atlas 1056B03. Jim, as I mentioned in your other thread, the next version of protocols.ini will handle the duration in units of 1/16th of a second, so the maximum pause time will be about 16 seconds. Here's the new entry:

[mathdon]

[3FG]

After thinking some more about the BC2/BC3 issue, I don't think we need to change anything. I'll compare this situation to Comcast remotes. The JP1.3 remote has signature 30393039 and our RDF file identifies these as URC-1067BX3. I have 4 of these remotes, all from 2009, but the battery compartment stickers say variously 1067BC3-0001-R, RC1475505/02MB, and RC1475505/03MB. Later, we saw "platinum" colored remotes with stickers which say 1167BC0-0001-R, and others which are RC1475505/04SB. There is also a RC1475507 series. BTW, the more recent cosmetically identical remotes are JP2 with signature 255602. Stickers include RC1475511/01B and 1067CBC4-0004-R.

The point is that the sticker probably tells us more about the manufacturing facility used to make the remote than the firmware. And mostly users don't even think about the sticker numbers. Perhaps the question about BC2/BC3 arose now because we have only had the ability to add upgrades for the last couple of weeks--from a JP1 standpoint, these are new remotes. One thing we can do easily is to change the Name field in the RDF from Name=URC-1060BC2 to Name=URC-1060BC2/BC3, so that a little investigation will reassure a user that the RDF is supposed to work with either BC2 or BC3.

The issue with the keymoves is not limited to Pause upgrades, and I think we should investigate to see if RMIR can be modified to add a check. I made an upgrade using the Dish IR protocol, and gave it setup code 2121. I assigned functions to shifted buttons and uploaded to the remote in two configurations: 1) setup code 2121 assigned to a device button and 2) 2121 not assigned to a device button. Then I downloaded from the remote and for case 1 changed the assignment from 2121 to a built in setup code. RMIR asked if I wanted to keep the keymoves (good!). For 2) I deleted the Dish upgrade--so setup code 2121 no longer existed, but RMIR said nothing about the now-orphaned keymoves. After uploading to the remote, the buttons associated with the orphaned keymoves do nothing.
So I think RMIR should check each time an upgrade is deleted to see if keymoves are orphaned, and ask the user if it is desired to keep the keymoves-- which the user may want to do if the purpose of deleting the upgrade was to replace it.

[ElizabethD]

3FG, Graham,
Just about Pause, in case my notes might be helpful and doesn't derail your Charter discussion:
Based on my JP1 remotes (see sig) my pause keymoves aren't deleted when the pause device is deleted because RMIR asks whether to retain the protocol and I say yes. I just tried it, since normally I leave it alone, so that I can try various numbers, which will be gone when pause device is zapped.
Perhaps I build differently. I don't assign any pauses to any buttons in the upgrade, so they are not in the grey area. I just make functions in the pause device for 1,2,3,4,5 seconds. Then I make a keymove in RMIR and select Function option and then the duration function.
(I've given up on various built-in pauses with their weird timings such as 2sec setting running for 20sec. I use the simple looping one from KM. It's really universal because doesn't need any JMP addresses so you can move it from remote to remote. Just change the PID to something like 01EB since RMIR hates duplicate PIDs. 2sec function will not be exactly 2sec - depends on remote speed exhausting its counters, but it's close.)
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

[jeajea]

To clarify my pause duration problem

If the pause upgrade is assigned to a device slot such as TV and buttons for that device are used (either assigned in the upgrade or by key move) the correct pause duration is used.

If you assign the pause to a button on a different device via key move the duration becomes maximum (255 or maybe 0) when that device and buttons are use.

If you change the setup code to a real TV type the duration becomes maximum (255 or maybe 0).
_________________
Jim Anderson

[jeajea]

I tried the same combinations on an Atlas 1056B01 and the pause durations were correct.
_________________
Jim Anderson

[mathdon]

[mathdon]

[3FG]

Graham,
I tried out Build 15 with deleting a device upgrade which has keymoves. It does exactly what I had hoped. Thank you.