JP1 Remotes

ElizabethD wrote:At least in 8910, there's ONE byte where the FAV device is stored once forever. 8910 extender writer (David Vasques) did not assume that you can code FAV macros for more than one device. At least I never saw such a reference. Perhaps other extenders do.

vickyg2003 wrote:Each keymove, and macro and fav key have a header that tells you what key, what device, what type and how long the next record is. Followed by the data.

Liz, there are remotes with 2-byte headers and newer remotes with 3-byte ones. When Vicky writes that the header tells you the key, the device, the type (of Advanced Code, ie keymove, macro or fav/scan) and the length of the following data, she is speaking of 3-byte headers, which can always do that.

For both header sizes the first byte is the key code. In a two-byte header the length is in the low nibble of the second byte. That leaves one nibble, just 4 bits, for the device and type. UEI does this by assuming that keymoves are the only type that needs a device specified. If the lowest bit is 0 then it is a keymove with the upper three bits giving the device type. If the lowest bit is 1, there is no device type as the upper three bits are needed to distinguish the other types of advanced codes. In fact, only one of these three bits is used, to distinguish between macros and fav/scan, but the two bits remaining are not enough for a device type.

A fav/scan in a remote with 2-byte headers therefore stores the fav/scan device in a separate, dedicated, byte and so can accept only one device, even in an extender. But with 3-byte headers, it is possible to construct fav/scan entries for several different devices, even if an unextended remote can't interpret them. For the same reason, 3-byte headers can handle device-specific macros, even if most remotes don't have them, but 2-byte headers cannot.

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

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