6131 2k extender RDF key translation question

[ElizabethD]

In 6131 2k extender when I use any special protocol in IR6.15 for device/shift-phantom4, it gets translated to "xshift-key0". Relevant lines in the RDF are:

Code: Select all

Phantom1=$3D, Phantom2=$3E, Phantom3=$3F, Phantom4=$40:XShiftBind,
DiscreteON=$3B, DiscreteOFF=$3C,

This is the file I used:
PVR0PVx1 (URC-6131(Old)_6131nwB00 Extender1).rdf, file date is 6/29/2005 and 7/19/2005.
There is no :XshiftBind in the 1K version, nor the extra discrete phantoms, in the 5/16/2003 file.

RDF problem or some remote limitation or I goofed?

Edited a bit later: ANother thing is that xshift-phantoms are not available to be used. They start enabled and then it gets shaded out. It's on the top of the window where you pick bound device and key.

[Nils_Ekberg]

I think it is an RDF definition problem but I will have to tinker with it. It looks like the reason the XShiftBind is there so the xshifted version isn't used but I would also bet that shift of $40 can't be used either due to a conflict.

As far as your edit goes I am able to use xshift for 1 through 3 with no problem. Did you change the RDF at all?

[ElizabethD]

As far as your edit goes I am able to use xshift for 1 through 3 with no problem. Did you change the RDF at all?

Nils, I did not touch the RDFs. AND I do not know what to expect.

I had this sort of a problem loooong ago with 8910 and Mark Pauker needed to fix IR to be able to report all key names. Unfortunately here I just don't know what's to come out.

I can use shift-phantoms 1-3 and xshift-phantoms 1-3 but, I just repeated, shift-phantom4 comes out xshift-Key0 and xshift-phantom4 is disabled. Any protocol. Any device.

[Nils_Ekberg]

Key 0 just means it is an undefined button in the RDF but is in the map somewhere. So, I suspect $40 shifted is equal to something else. I will figure it out and update the RDF to reflect that.

I didn't think you changed the RDF but I just could not understand why you were seeing something different with the phantoms 1-3 than I was but it does not sound like you actually were. Phantoms 1-3 are shifting and xshifting OK for you right?

[ElizabethD]

Nils, YES, 1-3 shift and xshift just fine.

[ElizabethD]

Nils, I may have answered a wrong question.
phantoms1-3 shift and xshift OK in IR.
I don't have the remote to be able to tell if they really shift

[Nils_Ekberg]

Nils, I may have answered a wrong question.
phantoms1-3 shift and xshift OK in IR.
I don't have the remote to be able to tell if they really shift

That's OK if they shift in IR they will shift in the remote.. So the only thing we are dealing with is the conflicting $40 key (Shift-Phantom4).

[mtakahar]

Everything in the range $40 and above will have conflicting counter part if it's shifted. Here, $C0 (Shift-Phantom4) can be considered as either $80 + $40 (Shift-Phantom4) or $C0 + $00 (XShift-Key0). There's no right or wrong in interpreting it in the rest of other cases, though, in this particular case, I don't think showing it as XShift-key0 doesn't make sense becase $00 is a no-op whereas shifted ($40, the same as Phantom4 itself) and Xshifted are not.


Hal

[ElizabethD]

Thank you.
Of course! Why didn't I see it when Nils said it up top

IR is completely correct in disabling xshift on phantom4.
It'll be interesting to see what shift-phantom4 will do. Unlikely to shift.

Boy, you guys are really pushing these poor remotes to the limits of total overflow

[Capn Trips]

I'd been following this thread with interest, as the looks "under the hood" of an extender are still somewhat beyond my ken but if I understand correctly, I can conclude that in some cases, where extensive product testing does not occur, as in all of these products that the experts create and support here, there may be unanticipated problems/conflicts.

This specific example of a key definition "conflict" in an RDF MAY explain a problem I had recently, but just found an alternative workaround, rather than asking the forum for help.

In my HTPro, running the 8910/9910/HTPro extender 1, I had tried to make a minor alteration in my setup, and tried to assign a LKP to the x-shift phantom 3 button. Other keymoves and LKPs already exist and are assigned to various Device phantom, shift-phantom, and x-shift phantom buttons, and they work fine, except I had never placed one on x-shifted phantom 3.

Well, long story short. I couldn't make it work. The button that I pressed to CALL the x-shift phantom 3 macro/LKP simply did nothing. I exhaustively searched for conflicting function assignments or anything of that ilk, but found nothing. When I simply used a DiIFFERENT button (x-shift PIP) for exactly th same LKP sequence, the invopking button calls the function just fine. So I got the functionality I wanted working and was happy.

Now I begin to suspect that perhaps the x-shift pahnyom 3 button in the 8910/9910/HTPro extender RDF uses an address that conflicts with another button and therefore wouldn't work. Does anybody with 8910 Extender experience know if this is the case?

[Nils_Ekberg]

The Phantom buttons are typically buttons that we found no other use for in the remote. ie. not assigned to a physical button. So, we take advantage of that to create extra buttons for use in macros etc. Then we use buttons values above that for extender function like X_TV etc. In the end they are usually used by something in the remote and a conflict arises. When that happens we change the RDF to lock it out or change the extender if necessary. You may just have uncovered one of those button conflicts.

I guess since we do this for fun we may not do the extensive testing that we would if it were for a paying job so sometimes the users do uncover bugs. We then try to fix them which is probably the reason for multiple versions of extenders. I should say that the newer versions of extenders is not always due to bugs but in most cases it is new functionality.

I for one have never made a coding error.

[ElizabethD]

Does anybody with 8910 Extender experience know if this is the case?

8910 sanity check for Capn Trips:
xshift-phantom3 (base $3F) should work based on math, as it becomes $FF and no other button has that number. But I just changed one macro used in device LKP to be on xshift-phantom3. When LKP runs, it does not do the job the macro is supposed to do, AND the LCD said THEA 1797, a code I do not, did not ,ever have, and it should have said DVD anyway. Do you recall a monthly puzzle of yours about THEA with some goofy setup code number coming up? This may be it, replicated. $FF might be hitting some default in the ROM routines which then picks up 1797. Hey, this madness is fun

6131 is different in a way, because it's a math problem. To xshift phantom4 (hex40), the number overflows 8 bits. And shift-phantom4 becomes $C0 which is ambiguous (are we shifting or xshifting?) as Hal and Nils said, but might work as shift.

[ElizabethD]

Since my check is slightly different than Capn Trips', here are details for the extender experts since it still might be related to how used
My normal, working code

Code: Select all

macro:  XSHIFT-M1	M3;L4
used in LKP: DVD	SHIFT-Phantom3	LKP(3)	[Short]:< Blank >  [Long]:Phantom2;XSHIFT-M1	$30 $3E $ED

When I changed xshift-M1 to xshift-phantom4 in both places, the funny stuff happens.

[ElizabethD]

Returning to the 6131 - I'm tacking this on since it's my RDF-related stuff.

I can't make Audio(CC) xshift In IR general tab I have xshift, not ordinary. Audio(CC) is in keycodes.htm included in the zip file for the 2K extender. Values are hex 37, B7, F7 - should be correct. I push Set-Audio(CC) and it works, but set-set-Audio(CC) does not. The same codes do work when reassigned someplace else. Is it me or something in the RDF? I'd like to put it in a macro, but can't till I get it working from the keyboard.

[ElizabethD]

USER ERR0R
I forgot to shift the Alt-shift button code on the General tab in IR. It now does the tri-state cycling nicely and works from macros as well.