JP1 Remotes

Posted: **Fri Dec 28, 2007 1:55 am**

I have RDFs for the PK and PL chips. I am told that I have to remap the PL functions to correspond to the PK key numbering (as there are fewer valid key numbers available on PK).

This astonishes me, can there not be a key function redefinition in one of the control files used along the way?

By the way I am using RemoteMaster 1.82.

Thanks, DL

Posted: **Sun Dec 30, 2007 12:11 pm**

Digital Larry wrote:This astonishes me, can there not be a key function redefinition in one of the control files used along the way?

The key redefinition function is actually implemented in RM, so there's no need for astonishment in this case. This is a feature that is not understood well by many RDF creators, so it often is omitted, but it is there in the Slingbox RDF files you mentioned. Perhaps you took the instruction to remap the keys too literally. We always remind users to do this, because some keys cannot be mapped (no similar button) to some remotes, and also, the mapping of functions to keys is often a personal preference.

Posted: **Wed Jan 02, 2008 7:20 pm**

Thanks Mike.

So, what you're saying is that, for a given RDMU, I should be able to select between the "UEI PK" and "UEI PL" RDFs and generate a suitable BIN file for both without further twiddling? In this case I do of course mean for key functions which are already defined for each of the chips.

Grazie,

DL

Posted: **Thu Jan 03, 2008 1:28 pm**

Digital Larry wrote:So, what you're saying is that, for a given RDMU, I should be able to select between the "UEI PK" and "UEI PL" RDFs and generate a suitable BIN file for both without further twiddling? In this case I do of course mean for key functions which are already defined for each of the chips.

Yes,what you say is true, but it is still a very good idea to just review the function assignments before proceeding. Depending on what remote you are switching from & to, you may find a few functions that are deassigned because the target remote lacks an equivalent button. Also, the user that created the upgrade file may not have assigned all the functions you might want to use because of different circumstances.

Posted: **Tue May 13, 2008 6:23 pm**

Hi Mike,

Well I'm back at it, and I notice that for these files:

BINPK (Slingbox with UEI PK Chip).rdf
- and -
BINPL (Slingbox with UEI PL Chip).rdf

the [Buttons] list is identical with 81 entries. However, I know that PL supports 81 unique codes while PK only supports 37, and the first 37 are not identically defined - in fact, none of them match (although all 37 of the PK keys are defined in the PL list).

For laughs, I created an RDF file where the [Buttons] list was correctly identified for the PK list, then I created an RDMU from the IR.EXE analysis, blah blah - the resulting BIN file code is only 10 bytes! I know they're small but is that possibly correct?

yes, I know I should just test it (sigh) - I'll have to go get some other equipment to do it.

Anyway bottom line it appears that the [Buttons] list in the PL RDF matches what I know to be correct in the spec, while the [Buttons] list for the PK RDF is NOT correct, and the guy who showed me how to do all this stuff, just said, well just remap the buttons when you enter them into RM, but I gotta tell you, that just seems stupid if it can be over-ridden some other way.

Thanks for any insight!

DL

Posted: **Wed May 14, 2008 1:45 pm**

Digital Larry wrote:For laughs, I created an RDF file where the [Buttons] list was correctly identified for the PK list...

How did you determine the "correct" button list? I know that the RDF file for the PK & JU versions don't seem to be correct in the [Buttons] and the [ButtonMaps] sections, but I don't know the correct info. Just changing the button names isn't all that is required.

Digital Larry wrote:...the resulting BIN file code is only 10 bytes! I know they're small but is that possibly correct?

Doesn't sound right.

Posted: **Wed May 14, 2008 4:06 pm**

Hi Mike,

I determined the correct button list because, as we are a customer of UEI, we do have access to their chip specifications.

I did not change the button name, I changed the key code number associated with it.

e.g. (Just showing 1 button, fair use and all y'know)

PL:
[Buttons]
Power=1,

old PK:
(which required the manual remapping)
[Buttons]
Power=1,

new PK: (which seems to be working fine on my Dish box - I imported the PL BIN, changed the RDF to the modifed PK, exported again and loaded it up to a PK device)
[Buttons]
1:num_1=1,

For this code, the PL BIN is 100 bytes and the PK bin is 93 bytes. Yes, there is a warning that some functions fell off when trying to map from PL to PK.

I don't know exactly what's up with the 10 byte BIN file I made yesterday, will check it again.

Thanks,

DL

Posted: **Thu May 15, 2008 1:57 pm**

If your PK RDF is working better than the old one, it would be nice if you would put a copy in our Tools\RDF Files area of the files section.

The way RM handles the function assignments when changing remotes works well as long as the RDF files are coded correctly. It tries to match up the button names. That works smoothly with common buttons, like 'Power', but when one remote has, for example, a 'Display' button and the other has 'Info', they won't match. The RDF syntax allows for a standard name to be used to so a match will be made. If the RDF for the remote with the 'Info' button is coded as

Code: Select all

display:Info=$33

then RM will attempt to match using 'display' instead of 'Info'.

Part of the problem with the button matching is due to lack of consistency in the set of RDF files we've created over time. Nils has put a lot of effort into cleaning this up with the latest release of the RDF files, but some RDF files for some remotes (like the Slingbox) may still need further cleanup.

Posted: **Thu May 15, 2008 2:35 pm**

Hi Mike,

The file is here:

https://www.hifi-remote.com/forums/dload ... le_id=5564

It is marked for use with the HAVA "Aeris" video placeshifting device - it is not represented as tested with Slingbox.

Thanks,

DL

Posted: **Fri May 16, 2008 6:21 pm**

Notice that the [ButtonMaps] section in this file is unchanged, so it still refers to a bunch of button codes (anything above 37) that don't actually exist on the PK chip.

The RDF spec states:

The [ButtonMaps] section is in the form:

MapNum=KeycodeList

where KeycodeList is a list of keycodes, some of which can be enclosed in parentheses to indicate that they are mapped to the same bit. Each entry (keycodes surrounded by parentheses are considered a single entry) corresponds to one mapping bit.

However, I must admit, that brilliant though I may occasionally be, I have no idea what any of this really means.

These buttons are mapped to the same bit of what?

Posted: **Fri May 16, 2008 6:42 pm**

Try replacing the [ButtonMaps] & [DigitMaps] sections with this:

Code: Select all

[ButtonMaps]
0 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11, $12, $13, $1A, $1B, $1C, $1D, $1E, $1F, $20, $21, $23, $24, $25, $14,
    $18, $15, $19, $16, $17
1 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11, $12, $13, $1A, $1B, $1C, $1D, $1E, $1F, $20, $21, $22, $16, $17
2 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11, $12, $13
3 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11, $12, $13, $1A, $1B, $1C, $1D, $1E, $1F, $20, $21, $22, $16, $17
4 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11, $12, $13, $14, $18, $17, $16, $15, $19, $1A, $1B, $1C, $1D, $1E, $1F,
    $20, $22, $21, $23, $24, $25
5 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11, $13, $14, $18, $17, $16, $15, $19, $12, $10, $11
6 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11, $13, $14, $18, $17, $16, $15, $19, $1A, $1B, $1C, $1D, $1E, $1F, $20,
    $12, $22, $23
7 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11, $13, $14, $18, $17, $16, $15, $19, $12, $10, $11
8 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11, $13, $14, $18, $17, $16, $15, $19, $12, $10, $11
9 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11, $13, $14, $18, $17, $16, $15, $19, $12, $10, $11
10 = ($0A, $01, $02, $03, $04, $05, $06, $07, $08, $09), ($0B, $0C, $0D), ($0E, $0F),
    $10, $11
[DigitMaps]
72 53 94 92 03 01 90 44 46 223 224 69 86 21 11 87 58 29 34 59 64 38 126 32 95 16
74 166 23 81 140 125 179 127 75 33 30 169 26 217 218 297 298 192 193 93 199 200 17
13 91 209 210 170 131 205 290 208 289 352

Digital Larry wrote:However, I must admit, that brilliant though I may occasionally be, I have no idea what any of this really means.
These buttons are mapped to the same bit of what?

Each button listed in the [ButtonMaps] section corresponds to a bit in the button list bytes within an upgrade. When an upgrade is created, if a function is assigned to a button, the corresponding flag bit in the upgrade is set to indicate that function data for that button is present in the upgrade.

The buttons enclosed in parenthesis are a group, and only one flag bit is used for the entire group. For example, if the flag bit for the volume buttons group is set, then data for all the buttons in the group must be present in the upgrade.

The position of the button code in this section also determines the position of the function data for that button within an upgrade. All of this must match what the remote is expecting; if not, then the remote will misinterpret the upgrade.

There are some finer details I have not mentioned here, but maybe this is enough to formulate your next question.

Posted: **Fri May 16, 2008 7:05 pm**

Thanks Mike.

I'm torn between the desire to understand this at the most fundamental level vs. just getting the end result I need, but in any case I think I get it. Like all number buttons are a group, all volume related functions are a group, beyond that, maybe not much!

Previously the DigitMaps section was just completely blank.

Good/bad/indifferent?

Cheers,

DL

JP1 Remotes

Creating BIN files for UEI PK and PL from same rdmu

Creating BIN files for UEI PK and PL from same rdmu

Re: Creating BIN files for UEI PK and PL from same rdmu