JP1 Remotes

Thanks Bill. That will be great to have extenders for more JP1.3 remotes. May I ask if URC-7950 will be suitable?

Above, you refer to 'T_dev' (which could be a minor typo) as being permanent, or is there a T_dev command as well?

I am still a bit confused, perhaps because the RCA readme which I obtained might be outdated. It has a heading Temporary Device Selection: "You often want to issue a key...without disturbing that previous device selection. Dev_xxx commands will do this. When the macro finishes, the device is automatically cancelled."

Regards
Chris

tranx wrote:May I ask if URC-7950 will be suitable?

Chris, that's a European remote, you might want to PM NBoater, and see if he's got anything in the works for that. He's released 2 European extenders so far.

Re. your earlier advice about the need for an activity mindwarp, haven't got much further but see in the Extender readme's there is a change of emphasis Atlas vs. RCA in respect of temporary assignments:

e.g. Atlas:
'X_TV', which I undertood to include all the temporary TV device buttons.

cf. RCRP05B:
'Dev_Tv', which seems also to require precise button-group assignment, in which case the following 'set_C';'set_O', etc. would (exceptionally) be temporary just within that macro.

Both Unclemilitie and I went to this new setup style with our extenders at about the same time, although the urc-8910 extender had been written that way many years ago. The new style requires a few more bytes of keymove/macro space to do a standard device assignement macro, But it allows us to have more keycodes for phantoms and key_groups.


X_TV = Dev_TV
Both are temporyary setup codes that effect all keys until the a cancel or the end of the macros.

Below are examples that show the new style takes a few more bites

Macro:= TV_P, AUD_V, 1,2,3
just became
Macro:= Dev_TV, Set_P, Dev_Aud, Set_V, Dev_Cancel, 1,2,3

It took 3 more bytes of keymove macro space to do the same thing.

For remotes with more than 5 devices, we run out of key codes, so this new method really improves things. On remotes with tiny E2 areas, the old TV_P type system might still be preferrable, even with 8 devices, but with the bigger E2 area in these flash remotes, the extra keycodes and extra device groupings made it a good tradeoff.

If you can't visualize what running out of key codes look like, open up my extender zip files for the 8820N and 8820B00 remotes. Each contains a keyset sheet that shows the keycodes for the remote. You can see how efficient this new method is for conserving keycodes, so we can have more groups.

Thanks Vicky.

As I said, the RCA extender readme which came with the "RCA RCRP05B Extender V1.05" download, has a paragraph headed 'Temporary Device Selection', with the (truncated) text which I quoted.

Forgive my ignorance but, as a newcomer I am still confused. It now seems more evident that the Extender came about by collaboration, but are there really several versions, by different authors, available separately or in a series?

And now that you have added Dev_TV, Set_P, Dev_Aud, Set_Aud, Dev_Cancel, 1,2,3, I think I understand that the ... Dev_Cancel... part is needed to cancel the Dev_Aud part so 1,2,3 can be done within the presumed still earlier Dev_TV;Set_C assignments which were established in another macro, which I think unclemiltie clarified as being otherwise 'permanent'.

In contrast, my RCA Extender readme clearly stated that any Dev_xxx would have only remained in force, like the (Atlas-type) X_TV, until the macro had been executed, so that it did not need to be cancelled!!!

So, I can't help but ask whether the readme account which accompanied my RCA Extender Download V1.05 does not apply to it, and/or whether there is a later version of the readme or of the RCA Extender, please?

Chris

tranx wrote:Thanks Vicky.

As I said, the RCA extender readme which came with the "RCA RCRP05B Extender V1.05" download, has a paragraph headed 'Temporary Device Selection', with the (truncated) text which I quoted.

Forgive my ignorance but, as a newcomer I am still confused. It now seems more evident that the Extender came about by collaboration, but are there really several versions, by different authors, available separately or in a series?

All the extender versions are posted in the files area. Some have different authors. For example the URC-7800. I worked on the latest, and I might add greatest, , extender. But there were other authors on this prior to me and all our files are in the extender area of the files section.

Unclemiltie gave me a great deal of help getting started, but for the most part extender writing is a pretty solitary persuit. 100's of hours of dinking around with a remote, in our own little JP1 world before we go public asking for testers. Currently there are 4 "active" extender developers, unclemiltie, me, NBoater and mathdon. We rarely collaborate. We dig in and do our own thing. This Dev_Tv thing was out there for a long time, one of my testers (Nils) actually mentioned it to me, but it went over my head until I "discovered" it on my own a year or so later. Likewise, I tried to sway the group with an exciting new development in my last extender, that let you have "multiplex" the keymoves when you did your regular multiplexing, giving you "almost phantom devices", but that never became mainstream.

tranx wrote: And now that you have added Dev_TV, Set_P, Dev_Aud, Set_Aud, Dev_Cancel, 1,2,3, I think I understand that the ... Dev_Cancel... part is needed to cancel the Dev_Aud part so 1,2,3 can be done within the presumed still earlier Dev_TV;Set_C assignments which were established in another macro, which I think unclemiltie clarified as being otherwise 'permanent'.

Yes, A dev_TV will stay active until :
* another temporrary device is set
* dev_cancel is issued
* you exit macro mode

tranx wrote: In contrast, my RCA Extender readme clearly stated that any Dev_xxx would have only remained in force, like the (Atlas-type) X_TV, until the macro had been executed, so that it did not need to be cancelled!!!

Yep, they do not NEED to be canceled, they will self terminate when you have finished the last step of the macro chain.

tranx wrote: So, I can't help but ask whether the readme account which accompanied my RCA Extender Download V1.05 does not apply to it, and/or whether there is a later version of the readme or of the RCA Extender, please?

Perhaps you can suggest unclemiltie reword that section

RCA Readme wrote:Temporary Device Selection:
---------------------------

Within a macro, you often want to issue a key to a specific device
regardless of the previous device selection and without disturbing that
previous device selection. Dev_xxx commands will do this. When the macro
finishes, the device is automatically cancelled.

This is what I said in my 8820N Documentation

I can't take credit for the wording. I probably plagerized that, since documentation is not my strong suit. That just doesn't sound like me. It sounds like capn_trips or I might have picked that up from another extenders documentation. But i digress, I think the above passage might clarify the situation for you now.

That has cleared the fog!

I was reaching for the potential for obscure problems if the chain stretched out into the distance before completing the outermost macro, but could not grasp it. Nor had I heard of the Dev_cancel command until you mentioned it, but the text explains it all.

Will certainly contact NBoater to see if an extender is in the works for the EU JP1.3 URC-7950, thanks.

By Royal Commision have been redoing Her 5-device-limited Harmony which lacked the ability to properly learn the obscure G20 commands which have been used by the JP1s to control a couple of IR mains plugs which are rather choosy.

Neither remote could learn the precise IR from the other and I had to revert to an old higher capacity harmony H655 model to be able to add the 2nd G20 command to the newer fancier but meaner H650, so they could be shared.

It is certainly being a pain to do compared to JP1

To add some more clarity to this, or everything you didn't want to know about how HT device selection works in an extender....


In the remote there is a table of setup codes, it is organized by device ID. For example, the CBL could be ID 0, TV ID1, VCR ID2, etc.

In this table is stored the setup code that you enter when you are setting up your remote. So when you set the TV to 0560, you store 0560 in entry number 1 (the second entry) in the table.

Now, when you introduce Home Theater mode (this is what the extenders do, and some of the remotes did this natively as well) you have to tell the remote what to do when a key is pressed. To do this, the extender keeps a table of device ID's that are stored for each key set. Again for example, say that the remote has 5 key sets (T, V, C, M and O). To tell the remote what to do when it processes a "Channel" Key you store the device Id into Channel the entry in that table.

The remote also stores tables of keys that are checked after every key press to see which set the current key is pressed. These lists are sometimes stored in the remote when shipped from the factory and are sometimes stored in the extenders if we can't find a list that we like when we're writing the extender.

So, when a key is pressed, the extender code does this:

• First, get the key value and look it up in the key lists. Find the key list ID
  Second, use that key list ID to look up the device Id for that key set from key set table
  Third, use the device ID to go look up the setup code for the device
  Fourth, load the setup code and process the key that was pressed using that setup code

Ok, so now that you see how this works, there are two ways to set these table entries. Let's assume that you want to set the Channel keys to use the CBL setup code that you have stored in the device table. CBL is ID=0 on your remote.

In the Atlas, you would do a C_CBL and this would store the cable device (0) into the Channel entry in the table.

On the RCA, you would need to do a Dev_CBL, Set_C. The first sets a "temporary" device to be CBL (0) and the second command tells the remote to store the temporary device in the channel.

As you have noted, both extenders have ways to set a temporary device, either the X_device commands on the Atlas or the Dev_device commands on the RCA. That temporary device is cleared either by (1) the end of a macro or (2) a Dev_Cancel or an X_Cancel command.


You may ask what is the difference and why would you choose one over the other. The issue boils down to key values.

Every key that you press is defined by an 8-bit key value, so there are 256 unique key values. Actually, there are 254 since $00 and $FF often mean something special and you really don't' want to use those. When writing an extender you need to take into consideration that you need values for every key on the remote, a shifted value for every key on the remote and an X-Shifted value for every key on the remote. The RCA has something like 65 keys so you need nearly 200 key values just for the normal, shifted and x-shifted key values.

On the Atlas style you need to define a lot of keys for the HT setup.. You need to define six keys (i.e. T_TV, V_TV, C_TV, O_TV, M_TV, P_TV) for every device, thus on an 8-device remote 8*6 and then you also need to define 6 keys for the temporary device and an X_Cancel command. This turns out to be 55 key values and in reality to make the code to detect them small they have to be contiguous. This is impossible on some remotes. This is why I switched when writing the RCA extender (i.e. lots of keys and 8 devices)

On the RCA style you need to define one set of "Set_x" keys for each key set (6 in the above example) and one set of "Dev_x" keys for each device and the Dev_Cancel command so that is 6+8+1, or only 15 keys. Much easier to find space for them in the key map.


So to answer your questions:

1: Yes, the Dev_device keys on the RCA set the temporary device, just like the X_device commands do on the Atlas.

2: The Keyset_device commands (i.e. T_TV) set the permanent table for key list device ids. The Set_keyset commands (i.e. Set_T) do this on the RCA, but it does it from the temporary device where the Atlas does it explicitly.

3: Both of the temporary device setting command sets will expire at the end of a macro (i.e. you don't need a "Cancel" on the end of your macros)





As Vicky said, some of the extenders are packaged with a key list, so you can see how little room there really is left to do what we do with extenders. I think the Atlas shipped with an EXCEL file keys.xls. I'm not sure I shipped the RCA with a keys file.[/list]

unclemiltie wrote:As Vicky said, some of the extenders are packaged with a key list, so you can see how little room there really is left to do what we do with extenders. I think the Atlas shipped with an EXCEL file keys.xls. I'm not sure I shipped the RCA with a keys file.[/list]

The only reason I suggested looking at the 8820 and 8820N keylists is that is essentionaly the same remote with both styles of keymoves and really illustrates the difference. For me, the very first step in extender writing is to create the keylist.

This is a great post Bill. The budding extender writers should find this extremely helpful. I wish I had read this before I ever started.

unclemiltie wrote: So to answer your questions:

1: Yes, the Dev_device keys on the RCA set the temporary device, just like the X_device commands do on the Atlas.

2: The Keyset_device commands (i.e. T_TV) set the permanent table for key list device ids. The Set_keyset commands (i.e. Set_T) do this on the RCA, but it does it from the temporary device where the Atlas does it explicitly.

3: Both of the temporary device setting command sets will expire at the end of a macro (i.e. you don't need a "Cancel" on the end of your macros)

Thank you very much. I must have missed something but if I wanted RCA to issue DVR 'Stop'

- would not (- Dev_DVR;Stop -) do the job?

- or would I have to do (- Dev_DVR;Set_Trans;Stop)
i.e. would 'Set_Trans' be essential to do this?

If you just wanted to issue the stop in a macro, then Dev_DVR; Stop would work

If your want the stop key to always work when using the DVR then you would issue Dev_DVR; Set_T;

Then any subsequent Stop would be sent to the DVR until another Set_T command was issued.

Think I finally got it, thank you!