Atlas OCAP (URC-1056) 30333033 rdf, map and image files

[Capn Trips]

I have created map and image files for the Atlas PVR OCAP remote (URC-1056). Also made some minor edits to the rdf for clarity/simplicity. Here they are.

I hope they work I haven't broken them yet.

A few mysteries and questions, however. In RM, the buttons display lists all of the buttons defined in the rdf (presumably):

Question 1: How can one adjust the ORDER in which the buttons appear on the list on the buttons page. They are not in the order listed in the rdf, nor are they in the order of the keys' hex codes, either, so how can one get the list to list the buttons in an order I prefer?

Question 2 (Mystery): If you open RM and select this rdf, the buttons list includes a mystery button undefined in the rdf. "ButtonF1" appears on the list between "phantom4" and "F1", but is nowhere in the rdf AFAIK. How do I make it go away?

Question 3: How does the rdf reflect which buttons are in which device button map. Specifically, this mysterious "buttonF1" and "phantom4" are included in the button map for CBL, but "phantom2" is not.

Question4: Is it safe to simply rename phantom4 to phantom1 to reduce future confusion (People asking "Why is there no phantom1 and 3, but only phantom 2 and 4?")

[kupakai]

Capn Trips, see if these revised files are acceptable. I've only included the map and jpg files in that zip. I've re-imported the image of the remote to remove the lines around the buttons and resized it to 150x500 pixels as suggested in the instruction for making map files. Most labels are difficult to make out at that size, but lot of the images of other remotes are like that, and there is still the popup that names the keys.

Also, as binky123 suggested in another thread, I would think having a single RDF for both URC-1055 with 30333033 signature and the OCAP Atlas would be better in the long run, if possible. I think combining the two RDF would also require slight revision in the URC-1055 map file as well.

[Capn Trips]

Personally, I don't like the smaller image, but your polygons are definitely prettier. I'll let the distribubtion zip file manager (Nils?) decide.

I think that the differences between the remotes are such that sharing an rdf will lead to more confusion than clarity. Where in the 1055 you have "Phantom 1" and "Phantom 3", in the 1056 OCAP you have "D" and "SETTINGS". There are other instances in which multiple rdfs share the same signature and I believe that this is one of those cases in which that is the more user-friendly way to go.

But ultimately, I don't make the distribution zip files for any of the tools for the long term, so it doesn't really matter what I think.

P.S. I'm still anxious to hear the answers to my questions above from somebody knowledgeable.

P.P.S. I really question the [ButtonMaps] and [Protocols] section of the rdf.

For example, this remote has a built-in SKY setup code, which we know uses RC6-M-20n protocol, yet the PID for any of those executors (00FF or 0020) is not listed in the rdf.

Also, the sheer number of buttons included in each ButtonMap seems staggeringly large. Device buttons in a ButtonMap? Phantoms? Mini-Macro buttons? How does one determine this? I'm happy to do whatever testing needed to confirm/deny these data.

How can I verify, and/or correct them?

[kupakai]

Question 1: How can one adjust the ORDER in which the buttons appear on the list on the buttons page. They are not in the order listed in the rdf, nor are they in the order of the keys' hex codes, either, so how can one get the list to list the buttons in an order I prefer?

I believe they are in the order of the buttonmaps section, and then, any other keys left over not in the buttonmap are listed in the order in the RDF.

Question 2 (Mystery): If you open RM and select this rdf, the buttons list includes a mystery button undefined in the rdf. "ButtonF1" appears on the list between "phantom4" and "F1", but is nowhere in the rdf AFAIK. How do I make it go away?

"ButtonF1" is from the the buttonmap for device 0. There's an $F1 key between $40 (phantom4) and $34 (F1). When there is a key hex in the buttonmaps section that is not named in the Buttons section, RM makes up a name "button"+hex. I don't know if that $F1 is a mistake or not.

Question4: Is it safe to simply rename phantom4 to phantom1 to reduce future confusion (People asking "Why is there no phantom1 and 3, but only phantom 2 and 4?")

I think you can name it whatever you want. Didn't that originally come from the RDF of the other Atlas remote where MENU and "D" were phantom keys?

If you prefer the larger image for the remote try using this one with your map file:

It is the same size and position as the one you used except the lines around the buttons are gone.

[Capn Trips]

Thanks. Through trial and error I was sort of figuring that out, but you've certainly clarified some of it. Reading the rdf spec is difficult to glean understanding from.

Still wondering how one determines the buttons map "membership," if you will, and the list of included protocols. Any idea? If there's testing to do, I'm happy to to do it.

(Oh yeah, by the way, there are some severe problems with this remote (I can't tell whether it's th rdf, or IR os something else). When I program it from IR with a bunch of device upgrades, NOTHING works, but I have yet to narrow down specifics. Will start a new thread when I'm ready)

[Capn Trips]

OK, now I'm looking at THIS remote and am getting scrambled buttons, as well. In this case, I downloaded from the remote, added a single device upgrade CBL/1053 (built-in JVC combo protocol).

The numeric, Ch and Vol keys are all good, but all of the others are scrambled. Red is on Replay, Menu is on REC, SETTINGS is on SOURCE, and so on.

I added that KeyMap entry (suggested in the other thread about the 102251025 remote) to the [Settings] section of the rdf and regardless of whether I chose Standard or Alternate on the General page in IR, the scrambling was the same.

When I included Sharp DVD and VCR upgrades, the entire remote would lock up, e.g. ANY button press would have FOUR DEVICE BUTTONS (all but AUD) light up simultaneously, and send no signal. (It's too late to track down what item specifically broke it right now - maybe tomorrow)

Man, this is frustrating! ..and it would probably be much easier to troubleshoot if I wasn't drinking so darned much, too!

[binky123]

This remote doesn't have the alternate keymap available so you should remove that entry from your RDF.

I'd need a copy of your .IR file to see if I can spot anything.

[Capn Trips]

OK, I removed that line from the rdf, but nothing has changed.

Here is a zip with all (I hope) relevant files:

The rdf I'm using - since I've been tweaking things like button names and sequencing in ButtonMap lists, as well as DeviceType and DeviceType Alias lists, to make the RM and IR displays more user-friendly, so I may have screwed something else up - although I was careful to make one change at a time and then verify the intended result in RM and IR before proceeding.

The three device upgrades in question:
JVC Combo TV uprgade;
SharpDVD DVD upgrade;
Sharp VCR upgrade

Two IR file:
(1) with JUST the JVC Combo TV upgrade - the "scrambled buttons" remote image.

Code: Select all

Many buttons are scrambled

NOT scrambled are: Numerics, Vol keys, CH+/-, and INFO

MOST others are wrong, like:
Replay sends C[RED]
LIST (which has nothing assigned) sends B[BLUE]
F2 sends nothing
TV (assigned nothing) sends PIP Ch-

and
(2) with all three upgrades - the "lock-up" image.

Code: Select all

NO buttons work.  

Some buttons result in 4 device buttons illuminating (VCR, DVD, TV, and CBL) for the duration of the buttons press, the rest result in no reaction.  In either case, no signal of any kind is sent 

[Capn Trips]

Bump?!

[binky123]

You should not be editing the [ButtonsMaps] section of the RDF as that is how the button KeyMap is layed out in the remote. IR/RM use this info to encode in the device upgrade which buttons are used and in which position those buttons are at.

I've updated the 3033 RDF to include in the [Checksums] section
^$200:$202..$3FF

Your OCAP+Sharp+JVC.IR file has FF FF at 0800:0801 which is incorrect.

[Capn Trips]

Ramble follows, but actual questions are at the end.

Just for my clarity - the [ButtonMaps] section of the RDF defines which buttons are in which buttonmap, correct?

I managed to figure out that the ORDER of the buttons in the [ButtonMaps] "0" section determines the ORDER in which buttons appear in RM's Buttons page, so I re-oredered some of them that to make the display more "logical". I did not add nor delete any buttons except ....

... the RM Buttons page displayed a "ButtonF1" entry that corresponds to NO BUTTON, either real or phantom. It is apparently there because of an "$F1" entry in the ButtonMap list, but because there is no such button defined in the [Buttons] section. So I deleted that $F1 entry.

Are you saying that my deleting the (AFAIK) incorrect/stray/extra $F1 entry from the [ButtonMaps] list is the cause of my scrambled buttons?
..or is the re-ordering of buttons in the [ButtonMaps] list causing this?
..or both?

I will try my setup this evening again using the RDF as distributed, but I seek understanding of these two concepts:
(1) Why do I need to have a confusion-inducing $F1 "non-button" listed on my RM Buttons display?; and
(2) How can I (without re-ordering the [ButtonMaps] section) get RM to display the Buttons in a logical, user-friendly order, as opposed to having Device Buttons scattered all about rather than grouped together (ditto for phantoms, and others)?

Thanks

[binky123]

The [ButtonMaps] section defines which buttons are in which buttonmap as well as the position of each button. You can't reorder or add/delete items.

I think you might be able to assign $F1 to a button in the [Buttons] section but I'm not certain. I'm not entirely sure about how it is treated(i.e. like shifted-$71 where $80 is added to it when shift is pressed).

By the way, I was able to modify IR7 to remove the duplicate [DeviceTypes] entries from the drop-down lists in the KeyMoves and Devices Tabsheets. I haven't released this version yet.

[Capn Trips]

OK, thanks for the update,

I'm not trying to be contrary, and I will leave the rdf alone, but I also like to point out areas where user-friendliness may be at risk. My heartburn appears to be with RM rather than with the rdf's, I suppose, but what good is it to have an entry in RM's button list that has no meaning? (I refer again to "buttonF1", which appears in RM) ... and why can't I (or HOW CAN I) re-order the buttons displayed in RM's Buttons page? Greg?

I "created" this rdf from the extant 30333033 rdf for the URC-1055 version of the Atlas PVR remote and just kept that [ButtonMaps] listing for starters, and IT has the F1 in that spot.

When I get home tonight, I'll revisit this and re-build the rdf from the original one and only change the handful of button names but nothing else. Then I'll introduce "my" changes one at a time until I see what breaks it.

By the way, I was able to modify IR7 to remove the duplicate [DeviceTypes] entries from the drop-down lists in the KeyMoves and Devices Tabsheets. I haven't released this version yet.

Does that mean my OTHER standard tweak of RDF's will become unnecessary?
I usually take

Code: Select all

[DeviceTypes]
Cable    = 0
TV       = 1
VCR/DVD  = 2
CD/Audio = 3
VCR/DVD  = 2,2

[DeviceTypeAliases]
Cable    = Cable,SAT,Video Acc
TV       = TV
VCR/DVD  = VCR,DVD,Tape,Laserdisc,DAT
CD/Audio = CD,Tuner,Home Auto,Misc Audio,Phono,Amp

and alter it as

Code: Select all

[DeviceTypes]
Cable    = 0
TV       = 1
DVD      = 2
CD/Audio = 3
VCR      = 2,2

[DeviceTypeAliases]
Cable    = Cable,SAT,Video Acc
TV       = TV
DVD      = VCR,DVD,Tape,Laserdisc,DAT
CD/Audio = CD,Tuner,Home Auto,Misc Audio,Phono,Amp

to achieve the result you discuss above.

Thanks for the explanantions (although I still don't quite understand a lot of what goes on in those rdfs )

[gfb107]

As an RDF developer, you have very limited control over the order in which RM displays buttons.

Button Maps are a representation of how the remote interprets device upgrades, and determines the order in which hex commands are placed in the device upgrade. The device upgrade itself does not include any button codes, so commands are assigned to buttons positionally. Any changes (reordering, removing, or adding entries) to the Button Maps section of the RDF will most definitely result in scrambling. The true JP1 experts extract the buttons maps from the remote through some magical process I don't know, but I know what they are used for, and that they must not be changed.

RM shows the buttons in the button map (in the order defined by the button map) for the selected device type first, then the buttons that aren't in the button map (in the order defined in the Buttons section). This creates a grouping so that the buttons at the top of the list don't generate keymoves, while the ones at the bottom do. This system has worked well so far, and to my recollection that haven't been any complaints.

I'll consider changing the manner in which RM handles this, but I make no promises that this will change. I see 2 possible approaches

1. Always use the order buttons are defined in the Buttons section, ignoring the device type and it's button map
2. Use the button map only to group buttons that are in the map first, followed by buttons that are not, but within each group keep the order defined in the Buttons section

As stated, the $F1 button is auto-generated by RM because it is a button code that shows up in one of the button maps but is not defined in the Buttons section. This is meant to help the RDF developer by exposing this fact that might otherwise be overlooked. The RDF developer is expected to create a button definition for the $F1 button code with a more meaningful name. If there is no physical button corresponding to the $F1 button code, then it reasonable to give it a phantom name. Since $F1 has the $80 bit set, it appears that it is the shifted version of the $71 button code, which must also not be defined in the RDF, or RM would pick up on that.

[Capn Trips]

Thanks for the details, Greg.

So now I got it.

"Do not mess with BOTH the order AND contents of [ButtonMaps]!"

Important safety tip.

(I'll add that to the list just below "Don't cross the streams." I still think total protonic reversal at the speed of light is slilghtly worse than scrambled buttons on a remote)

So NOW I have to figure out who (and why) put the $F1 in the [ButtonMaps] 0 section in the original 30333033 RDF.

Nils, as the RDF guru, do you know where that came from?

(I'm beginning to feel like I'm writing to Emily Litella! "Boy, you sure ask a lotta questions!")