JP1 Remotes

I have a URC-8910 and I'm trying to create a code for Handan CV-7700 PVR cable box (sold in many European countries).

I've downloaded the learned signals from the remote to IR. The remote uses StreamZap protocol, but here's the problem: it uses device code 36 for some of the functions, and device code 37 for some. However, Keymap Master only allows me to enter one device code for the whole remote.

Is there any way around this?

Several ways. If you're not short of KeyMove space the easiest way is:

1) Create an upgrade for whichever of 36 or 37 has fewer ordinary buttons. In that upgrade don't assign any buttons (it doesn't matter whether you define any functions).

2) Install upgrade 1 from KM or RM into IR.EXE, but don't assign it to any device key.

3) Create a second upgrade for whichever of 36 or 37 has more ordinary buttons. Give it a different setup code number than you gave 1. Define its functions the usual way and define the other device number's functions as "external functions" (see KM or RM documentation) using the setup code number of the first upgrade.

4) Assign buttons normally in that second upgrade, including both ordinary and external functions.

5) Install the second upgrade into IR.EXE, which should require you to assign it to a device key (so IR knows how to interpret the external function KeyMoves that RM or KM created).

By "ordinary buttons" I mean buttons of the original remote that logically correspond to whatever 8910 buttons are in the key set for whatever upgrade type you're creating. Non ordinary buttons are those that would need a KeyMove anyway, and thus don't count when deciding which device number to use in which upgrade in order to reduce the number of extra KeyMoves KM must create.

Two possible solutions:
(1) Use the Device Combiner protocol; or
(2) Make two separate upgrades and keymove in the functions from one of them.

The Device Combiner protocol (selectable in KM like any other protocol)would require you to do the setup page from BOTH StreamZap device number upgrades in order to get the fixed data you require to fill in the setup page of the DC upgrade. Further, you would be required to get the PROTOCOL upgrade from a dummy StreamZap upgrade, since the DC upgrade would call upon that protocol (which is NOT resident in your remote).

Pros and Cons
Device Combiner Pros:
(1) All of the functions are defined in a single KM upgrade.

DC Cons:
(1) The DC protocol upgrade is quite LARGE PLUS you still need to add the StreamZap PROTOCOL upgrade.
(2) Building it would take quite a bit of work (as I point out above)

TWO upgrade PROs:
(1) Much simpler work in KM;
(2) Only one PROTOCOL upgrade would be required (the two device upgrades would both use the SAME protocol upgrade)

TWO upgrade CONs:
(1) You would not have all of the functions defined in a SINGLE KM file;
(2) You would have to create KEYMOVES for EVERY FUNCTION in ONE of the two upgrades to carry it over into the other.

The TWO upgrades option is really a preferred one if there is only a small number of functions that use the "less-common" device number. [EDIT: as John pointed out above while I was typing ] As that number rises, and the number of Keymoves required grows, (and depending on how much of "Keymove/Macro" memory you have vs. "Upgrade" memory) you lose efficiency and at some point using Device Combiner becomes more economical.

Capn Trips wrote: TWO upgrade CONs:
(1) You would not have all of the functions defined in a SINGLE KM file;

I always use RM, where Greg built the UI for "external functions" the way I asked him to, so of course I think it is intuitive and easy to use.

I think KM's support for external functions can also get the job done. BUT I find it less intuitive and never use it, so I'm not sure it really does all that RM's does.

I think Capn Trips's CON, quoted above, assumes you won't use "external functions" in KM but will do something that gets the same results into the remote by defining the required KeyMoves using IR's UI rather than KM's UI.

That approach is just as easy (as the external functions method) when you first define the upgrade. But would be harder to deal with when you want to modify or share the upgrade later (because of exactly the CON he mentioned).

Has that amusing little StreamZap glitch been corrected yet? That's the one where the wrong fixed data got generated by KM and RM and you either have to add Dec192 (or HexC0 or Bin11000000 if you like) to the device number or manually change the resulting upgrade generated :

https://www.hifi-remote.com/forums/viewtopic.php?t=4469

https://www.hifi-remote.com/forums/viewtopic.php?t=5123

Hmmm... interesting catch, uq. I just generated dummy upgrades side-by-side in KM and RM and they:
(1) use different NUMBERED protocols (0123 in KM and 0124 in RM), although both are StreamZap and are IDENTICAL in content (so probably no big deal);
(2) and RM has a OBC>63 selection which RM does not, resulting in;
(3) KM generates fixed data=DB, whilst RM generates fixed data=5B UNLESS the OBC>63 is selected (which from the reading would be the exception rather than the rule).

I guess that means it's REALLY recommended for peterelk to use RM rather than KM for this(these) upgrades.

The correct PID for the Streamzap protocol is $0123. The $0124 protocol is a very seldom used protocol, in fact I am only aware of one code in one remote that uses it, that being the AMP/1099 code in the 15-2133 remote, which is listed as being for a Proceed amp.

Thanks a lot guys! I used keymoves to create the code, works great!

Actually, I wrote a new exec for the Streamzap that lets you use the complete range of OBC codes, and both KM and RM have been updated to use it.