JP1 Remotes

unclemiltie · Posted: Thu Jul 22, 2010 9:43 am Post subject:

Graham

A thought....

When the 6131 first came out, which I think was the first remote with the 3-byte headers, whomever did the extender made the decision to NOT do 3-byte headers and to continue with the code in the extender that does 2-byte headers.

This decision could be made in reverse for the remotes with 2-byte headers and have the extender treat the remote as if it had 3-byte headers. Sure the code would have to be a bit different, but this would solve a lot of problems.

Not only that, but I'm pretty sure that ExtInstall will deal with this when installing the extenders. When I fixed it up to deal with the JP1.x issues I allowed Extinstall to read and convert 6131 format 3-byte advance codes into 6131 extender format 2-bytes. I'm pretty sure that this will work in reverse.

-bill
_________________
this JP1 stuff is a sickness!

NBoater · Joined: 21 Mar 2009 Posts: 15 Location: United Kingdom

I am currently working on an extender and was looking at providing FAV key support for a remote that does not have a dedicated FAV key and it seems to me that there is no logical reason why it cannot have multiple FAV keys, or device specific FAV sequences.
Obviously, the extender implementation might have constraints on whether/how multiple FAV indices are required and/or handled.

To this end I would like to suggest an enhancement to the current IR/RMIR operation for handling FAV keys as follows:

Add a Target/Bound Key frame for Device and Key selections to the Add/Edit dialog boxes of the Fav/Scan tab.
For current configurations the Key selection should be populated based on the KeyCode field of the FavKey RDF entry but should be greyed out (disabled). See below for proposed change.
The Device drop-down only changing the current entry, i.e. leaving other entries unchanged, which is how, I think, Graham has coded RMIR anyway.
Add columns for Device and Key to the Tab to reflect the actual values used for each Fav sequence.

Allow a value of 0 (zero) in the first field (KeyCode) of the FavKey RDF entry.
When 0 is used then Key selection on the Add/Edit dialog box is no longer disabled but the user may decide to which key that specific Fav sequence is bound.

Only when AdvCodeBindFormat=LONG
When the “Any” choice is selected for the Device AND the FavKey RDF entry is 0 then the low nibble of the 2nd byte of the Fav data should be set to ‘F’, otherwise use the relevant device index.
I think current behaviour for “Any” is to use 0.

NBoater