New RDF and Maps/Image Release 1.31

[mr_d_p_gumby]

I find this kind completely uncomprehendable, although sitting here staring at it, do I start counting from 0, and then skip counting for anything that has a comma in it?

If so then I could also count the numbers then I could point the errors where there are more setup types than = signs in the device setups section. As you note, I reported there were 6 device types in the remote by counting those = signs.

For the device type number, think of it like this: Start by initializing a variable to -1. Then read & parse each line. If no device type number is present (no comma), add 1 to the previous value in the variable and use that as the device number. If a device type number is present, use it and update it to the variable.

It might help to always print the device type number in your report. That way you'd see the way the entries would be interpreted by IR/RMIR.

The more complicated case is where you find device type numbers such as $0202. In this case, split the high and low bytes into two values. Treat them as separate values (use two separate variables, both initialized to -1; use the same logic independently for each). The low byte is the device type number. The high byte is a secondary device type number used only in older remotes.

[vickyg2003]

I find this kind completely uncomprehendable, although sitting here staring at it, do I start counting from 0, and then skip counting for anything that has a comma in it?

If so then I could also count the numbers then I could point the errors where there are more setup types than = signs in the device setups section. As you note, I reported there were 6 device types in the remote by counting those = signs.

It might help to always print the device type number in your report. That way you'd see the way the entries would be interpreted by IR/RMIR.

Yes, I think if I find it this confusing, the report user would find it difficult too, so I think this is a good idea

For the device type number, think of it like this: Start by initializing a variable to -1. Then read & parse each line. If no device type number is present (no comma), add 1 to the previous value in the variable and use that as the device number. If a device type number is present, use it and update it to the variable.

If I'm reading this correctly,

0 implied 0
0,2 specific 2
1 implied 3?

Is that correct?

The more complicated case is where you find device type numbers such as $0202. In this case, split the high and low bytes into two values. Treat them as separate values (use two separate variables, both initialized to -1; use the same logic independently for each). The low byte is the device type number. The high byte is a secondary device type number used only in older remotes.

Which is high, which is low?

[mr_d_p_gumby]

If I'm reading this correctly,

0 implied 0
0,2 specific 2
1 implied 3?

Is that correct?

Yes.

Which is high, which is low?

If the entry is $0102, then $01 is the high byte (secondary device type number) and $02 is the low byte (primary device type number).

[mathdon]

I'm not sure if the issue of missing blank lines between sections is supposed to have been sorted in the v1.31 release, but the following RDFs are currently failing to open due to missing blank lines:

RS00RS00 (RS 15-1935_1934 7-in-1).rdf
10261026 (URC-8203 Kameleon).rdf
10751075 (URC-7555 OFA5).rdf

[3FG]

I believe that there is an error in the RDF file 30273027 (Vizio VUR8 6100 JP1.3), which has the effect of messing up the Code Selector in IR, and breaking it in RMIR.

The file includes the following:
[DeviceTypes]
CBL/SAT = 0
TV = 1
VCR/DVD = 2
CD = 3
CBL/SAT = 0 <<<<<<<<<<<<<<<
VCR/DVD = 2,2
VCR/DVD = 2,2
CD = 3,3

Based on earlier posts in this thread, I think it should be
[DeviceTypes]
CBL/SAT = 0
TV = 1
VCR/DVD = 2
CD = 3
CBL/SAT = 0,0 <<<<<<<<<<<<
VCR/DVD = 2,2
VCR/DVD = 2,2
CD = 3,3

Here's a separate issue, and just a speculation. I don't own one of these remotes, so I can't check this, but it seems odd to me that apparently the Audio button is factory set up to be a Video device type, since AUDIO is the 3rd item in this list:

[DeviceButtons]
CABLE = $00A $00B
TV = $00C $00D
AUDIO = $00E $00F
dev4 = $010 $011
dev5 = $012 $013
DVD = $014 $015
dev7 = $016 $017
dev8 = $018 $019

Perhaps the order should be:
[DeviceTypes]
CBL/SAT = 0
TV = 1
CD = 3
VCR/DVD = 2
CBL/SAT = 0,0
VCR/DVD = 2,2
VCR/DVD = 2,2
CD = 3,3
or
[DeviceButtons]
CABLE = $00A $00B
TV = $00C $00D
dev4 = $010 $011
AUDIO = $00E $00F
dev5 = $012 $013
DVD = $014 $015
dev7 = $016 $017
dev8 = $018 $019

[vickyg2003]

Hmm, I wonder how I missed this post!

Yes, many of the RDF's have a problem with this. I couldn't actually diagnose the problems, but I did prepare an informational report on this for Chris.

http://www.hifi-remote.com/forums/dload ... le_id=9112

Here is the section regarding the 30273027

Code: Select all

[30273027 (Vizio VUR8 6100 JP1.3).RDF                                       
[DEVBUTTONS]         [DEVTYPES]              [MAP, DEVTYPE NUMBER] [Implied Setup]               

CABLE                 CBL/SAT                    0           0 
TV                    TV                         1                  1 
AUDIO                 VCR/DVD                    2                  2 
dev4                  CD                         3                  3 
dev5                  CBL/SAT                    0                  4 
DVD                   VCR/DVD                    2,2                2 
dev7                  VCR/DVD                    2,2               2 
dev8                  CD                         3,3               3 
Remote contains unknown number of setup code types.

The Report helps me to read the RDF's, but someone needs to go through and make sense of the RDF's.

There was a lot of talk about this earlier in this thread.

If memory serves me right about 50% of the RDFS have screwy devicetype devicebutton associations because the rules were not understood.

I can make changes to the report if anyone can give me rules. However, trust me, you don't want ME to try to correct the RDF's!!!!!! I know Chris was extremely busy, and if memory serves me right there was something else we were waiting on before Chris was going to spend time on this, but for the life of me I can't remember the details.

Edit: Oh yeah we were going to wait until the master list properly identified 0046 variants.

[3FG]

Improved RDF for 31793179 RCA RCRP05B
Revised version.

1) In IR and RMIR, it is possible to generate a new remote image without first downloading from an actual remote. With the released version of 31793179 (RCA RCRP05B black), the new image does not work when uploaded into the remote. The culprit is memory location $22 ($622) which should be set to $0F. Other values give a variety of bizarre behaviors, summarized below. I've added an entry in [Settings] so that a new image will have $22 set to $0F. This is visible on the General tab as an entry labeled Byte22 with a value of 15. In RMIR, the value is not user editable on the General tab by design, but is editable in the Raw tab. IR.exe seems to ignore the StartReadOnlySettings directive and so the value is editable in both tabs.

2) The remote is capable of sending the Power signal for Cable and TV modes whenever the respective device button is pressed. This is manually programmed with the 972 command, and location $1B stores the information. At reset, $1B contains $0C, and if sending the Power signal is enabled, $1B instead contains $1C. I've aded an entry into [Settings] to allow this to be user selectable on the General tab. There is also an entry labeled Byte1B which sets the less significant nibble to $0C. Editability is similar to 1) above.

The 972 command accepts Ch+ to turn on the sending Power feature (2 blinks), and CH- to turn it off (4 blinks)

$22 values and behaviors (quite possibly incomplete or just plain wrong.)
In general, device buttons and Setup always respond with a blink. In the description below "all" means all buttons except Devices and Setup. I haven't checked to see if actual IR signals are sent, except for $0F.

0F: Normal
1F, 2F, 9F, AF, BF: Channel group buttons are sent to Cbl device; all others don't respond.
3F, 4F, 5F, DF, EF: No buttons respond.
6F: Any Channel group button press results in alternately the CBL or TV LED lighting; all others don't respond.
7F: The DVD device lights, regardless of selected device mode, for Ch group; all others don't respond.
FF: Ch group is sent to TV; all others don't respond.

The released RDF sets $22 to $FF, which is why I've tried to improve the RDF.

[xnappo]

I can make changes to the report if anyone can give me rules. However, trust me, you don't want ME to try to correct the RDF's!!!!!! I know Chris was extremely busy, and if memory serves me right there was something else we were waiting on before Chris was going to spend time on this, but for the life of me I can't remember the details.
.

Yep - we had a ton of discussion on this in the RDF thread... However it became quite confusing and I thought the result was that it needed to be left as-is.

I am perfectly willing to make changes - but I am nervous of fixing one thing only to break another as has already happened a couple of times.

xnappo

[3FG]

31793179 RCRP05B: Added Setup code locks in [Settings]. These are at $1A-- the same location as the 15-133/134/135 remotes.

Individual locks can be Set/Cleared by tapping the device button before issuing a 982 command, which is typically referred to as a Cable Lock command, but actually works for all devices.

[Daniel_Eble]

The 12 bytes from $3D to $48 appear to store the result of setup command 985 (cable device multiplexor). The format is one byte for the button code and two bytes for the setup code, repeated four times.

I'm not sure how useful this is because the 985 command does not seem to make my remote operate as the wiki describes.

http://www.hifi-remote.com/wiki/index.p ... fficial.29

[3FG]

The Wiki isn't quite correct. To change the cable code to one of the 4 stored setup codes, tap Cable and then simultaneously press/hold Setup and one of the 4 buttons previously programmed via 985. With both buttons held down, wait until the remote blinks twice. The associated setup code will be written into 0A/0B.

After a 981 reset, the 4 colored A, B, C, and D buttons are associated with the following setup codes:

1376 A "yellow"
1877 B "blue",
1377 C "red",
1982 D "green

I think you can associate a setup code with any button except device buttons, Power, and Setup.

[Daniel_Eble]

Thanks, 3FG. I updated the wiki. (Hope it's clear and accurate.)

[Daniel_Eble]

I notice that the key called "phantom1" in the RDF actually transmits a code in the default CBL 1376, if you create a macro containing it. EFC=00030 OBC=65 if I read it right. I've done a web search to see if I could find any information that would help choose a more meaningful name than phantom1; so far, nothing. I haven't tried any other device codes to see if they also have a use for this hidden button.

[3FG]

"phantom1" is used in a list of buttons and the associated keyboard scan codes. Since there is no physical button with scan code $3E, we use phantom1 as the name of the "button". Some remotes have several phantom buttons. As you have seen, a phantom can be called from a macro, just as dev4, dev5, and dev6 can be used in a macro to get access to the 3 device modes which have no physical button.

So phantom1 is a perfectly good name, because it is describing a virtual button. We usually assign functions to correspondingly labeled buttons--e.g. we try to arrange things so that the IR signal which makes the volume go up is assigned to the Vol+ button. However, phantom1 has no label, 'cause there is no actual button.

So far as I know, OBC 65 does nothing. At least it doesn't on the Motorola cable boxes we have at our house. I think that it is just a mistake made by UEI, when they were assembling the tables of hex data associated with the button maps.

[Daniel_Eble]

$22 values and behaviors (quite possibly incomplete or just plain wrong.)
In general, device buttons and Setup always respond with a blink. In the description below "all" means all buttons except Devices and Setup. I haven't checked to see if actual IR signals are sent, except for $0F.

The meaning of the high nibble of $22 has me stumped, but while trying to figure it out, I found that it is possible to configure a punch-through of any normal button.

The low nibble of $22 is the number of the device that is operated by punched-through buttons.

The byte at $2B holds the enabling flags for allowing punch-through in each device mode.

The bytes at $23 to $2A hold the enabling flags to punch through each button.

Code: Select all

Byte $23 bit 0: Power
         bit 1: Ch+
         bit 2: Ch-
         bit 3: Vol+
         bit 4: Vol-
         bit 5: Mute
         bit 6: Last
         bit 7: Fav
Byte $24 bit 0: Info
         bit 1: Exit
         bit 2: Up
         bit 3: Down
         bit 4: Left
         bit 5: Right
         bit 6: OK
         bit 7: Guide
Byte $25 bit 0: Pg+
         bit 1: Pg-
         bit 2: A (yellow)
         bit 3: B (blue)
         bit 4: C (red)
         bit 5: D (green)
         bit 6: Macro1
         bit 7: On Demand
Byte $26 bit 0: Macro2
         bit 1: Menu
         bit 2: (phantom1)
         bit 3: Day+
         bit 4: Day-
         bit 5: 1 
         bit 6: 2-9 or 0 (didn't narrow down)
         bit 7: 2-9 or 0 (didn't narrow down)
Byte $27 bit 0: 2-9 or 0 (didn't narrow down)
         bit 1: 2-9 or 0 (didn't narrow down)
         bit 2: 2-9 or 0 (didn't narrow down)
         bit 3: 2-9 or 0 (didn't narrow down)
         bit 4: 2-9 or 0 (didn't narrow down)
         bit 5: 2-9 or 0 (didn't narrow down)
         bit 6: 2-9 or 0 (didn't narrow down)
         bit 7: (dash)
Byte $28 bit 0: Aspect
         bit 1: (skip forward)
         bit 2: (skip back)
         bit 3: List
         bit 4: Live
         bit 5: (rewind)
         bit 6: (play)
         bit 7: (fast forward)
Byte $29 bit 0: (pause)
         bit 1: (stop)
         bit 2: (record)
         bit 3: PIP
         bit 4: Swap
         bit 5: Move
         bit 6: PIP Ch+
         bit 7: PIP Ch-
Byte $2A bit 0: Input
         bits 1-7: (?) (unknown, but definitely not buttonF1 or buttonF2)