rdf for OneForAll 7562 chipcode B01 sig EM60EM60 help

[The Robman]

We have a new RDF for this remote, that is very close to being complete:

EM60EM60 (URC-7562-B01 One for All).rdf

[rem]

Thanks for the new RDF. Much appreciated. I haven't repaired my cable so I haven't used it yet!
With regards to your earlier question regarding the file full of upgrades.
Yes the upgrades were there when I purchased the remote as I haven't performed any upgrade for this remote.
I assume they were there from the factory but I can't say for sure because there weren't any seals on the packaging. There's a chance the remote may have been a returned item - but it's unlikely because it did look brand new when I got it.
Thanks for the help.

[Andy]

Hello rem

Good to see you back in circulation. Sorry you are still short of a cable. Are you in the UK ? It sounds like you are not someone who gets out a soldering iron at the drop of a hat, so would it help if I sent a cable that's hard to break ? (I don't use ribbon cable - I'm lucky to have a few 0.1" pitch crimp connectors lying about).

Don't be overly grateful for the .RDF file, it isn't usable to make upgrades yet (RM chokes on it, and of course KM will not know about it yet).

I worked out (or confirmed) the stuff in the [Settings], [DeviceTypes] and [DeviceButtons] sections. Rob (with info I learned from my remote) did the really clever stuff (of course !), especially concluding that the [ButtonMaps] section should look the way it does (i.e. way more complicated than the previous revision of URC-7562). Also Mike England has contributed a more polished [Protocols] section which isn't in the version I posted yet, but probably should be.

At the moment I think Rob is waiting for me to give names to the buttons that appear in the [ButtonMaps] section but are absent from the [Buttons] section (namely $83 to $87, $C8, $D8), but I have no idea how to move from a guess to confirmation without making an upgrade - which I can't do yet (it's a sort of chicken and egg situation).

From reading messages on the boards about related remotes, button codes from $80 to $BF seem to be "shifted" by use of the menu key, so here are my guesses for unexplained keys in this area :

$83 POWER button after MENU pressed
$84 LEFT button after MENU pressed
$85 RIGHT button after MENU pressed
$86 UP button after MENU pressed
$87 DOWN button after MENU pressed

Now having a different function for the four direction keys after MENU is pressed makes a whole lot of sense, especially as EXIT and SELECT seem to work this way. But I have no idea why the POWER key would get a new meaning in the MENU context.

Button codes from $C0 to $FF seem to be regular shifts using the MAGIC key, so here are my guesses for unexplained keys in this area:

$C8 MUTE key shifted by MAGIC key
$D8 AV key shifted by the MAGIC key

I don't know if you can comment on any of the above. The manual does not seem to boast about any modification of functions after pressing the MENU key.

[The Robman]

I should also point out that Andy has very kindly sent me a URC-7562 to play with (thanks Andy), so if I get some time I can help out finishing up this RDF too.

[Andy]

My 7562 has been gathering dust for a while (I had been playing with my old 7544 and learning lots), but prodded by rem's new posting I just took another look. I added the "missing" buttons to the [Buttons] section of the RDF with totally meaningless names. This at least stops RM from choking on it, and it produces an output which (at first sight) works !

So (maybe not this evening) I should be able to program functions to the "missing" keys and see what keypresses actually cause the remote to issue that function. Now it does feel as though it's getting closer.

In my last post my "guesses" came from notes I made a couple of weeks ago. Looking at this again I cannot see why I guessed shifts of the direction keys for buttons $84 to $87, as these are the codes for volume and channel up/down with the top bit added. Never mind, let's see what happens !

p.s. Did the 7562 actually arrive yet, Rob ? I did get that spare 6541 via ebay, but have not thought about sending it yet, mainly because my old 6541 died (only a button contact problem, I'm sure) about the same time. I now have the recommended button contact repair kit and am plucking up the courage to open the 6541. However, a few moments ago I opened a 7544 for the first time and it was much easier than the 7562, so maybe I'll get my old 6541 fixed at the weekend and send one to you.

[The Robman]

Yes the 7562 did arrive and I verified that the EEPROM is loaded with codes from the factory (which is unusual). Tell ya what, rather than mess with the old 6541, why not keep the new one for yourself and send me the old one, I can fix remotes pretty easily.

Would you like a US model in return perhaps? How about a URC-8811 or a URC-6131?

[Andy]

Well, I am a bit slow on the uptake ! I was staring at the trees and not seeing the wood.

The [Buttons] section of the RDF I posted on 19th November has "been around a bit" but seems to be derived from (or have a common ancestry with) the RDF for the older 7562. I had to print it out and go through it with a highlighter pen before I noticed that (to go with the seven "missing" keys referenced in the [ButtonMaps] section) there are seven "shifted" keys mentioned in the [Buttons] section that do not appear in the [ButtonMaps] section. Is there any correlation between these two sets of seven button codes ? You bet there is !

Generally it's about the status of the next to top bit, it's the only difference in the set. Or to put it another way, if I take the "extra" shifted keys in [Buttons] and do an exclusive-OR against $40, then in each case I get a code that satisfies a missing code in [ButtonMaps].

So :

Code: Select all

  SLEEP=$83   (magic > power)
  EXIT=$D8    (menu > AV)
  BRIGHT+=$86 (magic > CH+)
  BRIGHT-=$87 (magic > CH-)
  COLOR+=$84  (magic > VOL+)
  COLOR-=$85  (magic > VOL-)
  Select=$C8  (menu > MUTE)

i.e. keys shifted by adding $C0 are reached by pressing the MENU key, those shifted by adding $80 are reached by pressing the MAGIC key. This seems straightforward enough, except that the RDF for the older URC-7562-B00 has these the other way about.

At this point I thought I must have the problem licked. But there are still some wrinkles left.

If I make an upgrade using RM, and calling up no shifted buttons (except these that have built-in button codes), then the output from RM includes some keymoves which appear to duplicate the effect of these shifted keys (which are already included satisfactorily in the "devices" part of the upgrade). If I leave these keymoves in place, these keys don't work as intended. If I rip out these keymoves, it works nicely. I could blame RM for this, but it seems much more likely that something remains in the RDF that is telling RM to add these unwanted keymoves.

So I've posted an RDF (EM60EM60 (URC-7562-B01 One for All)v01.rdf) that actually seems to make good upgrades, as long as one takes the trouble to manually remove keymoves that relate to the keys mentioned above. I also put Mike England's [Protocols] section in this one.

for comparison purposes, the RDF posted earlier is still showing at EM60EM60 (URC-7562-B01 One for All)v00.rdf.

[gfb107]

I think it might help if you add the line

Code: Select all

XShift=$C0

to the General section of the RDF. This tells RM and IR than XShifting (in this case invoked using the Menu key), is enabled, and that the XShift mask is $C0.
You could even try

Code: Select all

XShift=$C0,Menu

which has the added effect of using the work "Menu" instead of "XShift" in RM and IR.

[gfb107]

After further investigation I've fouind that there are problems in RM when a shifted/xShifted button is in the button map and is assigned a function. I'll work on making a fix for that.
In the mean time, you might want to also add the line

Code: Select all

DefaultRestrictions=XShift

to the General Section, which means that unless otherwise specified, buttons can't be xShifted. You'll also want to add a :None after the keycode for the buttons that can be xShifted, like this:

Code: Select all

AV{Exit_20}=$18:None

to indicate there are no restrictions on the use of those buttons (in this case they can be xShifted). See https://www.hifi-remote.com/forums/viewt ... ?p=798#p798 for a description of the valid values for restrictions.

As a matter of style, I prefer RDFs that include named shifted/xShifted buttons to not include the shifted/xShifted name in the name of the base (unshifted) button. So, instead of

Code: Select all

AV{Exit_20}=$18:None, Exit=$D8

I would prefer to see

Code: Select all

AV=$18:None,  20=$98, Exit=$D8

That's just my personal preference.

The other choice would be to not name the shifted/xShifted buttons at all.
If the case of the AV/Exit button, that would look like

Code: Select all

AV{Exit_20}=$18:None

instead of

Code: Select all

AV=$18:None, 20=$98, Exit:$D8

Of course, I should warn you that changing the name of a button in the RDF requires a matching change to the associated .MAP file.

[Andy]

Thanks for these tips, Greg. And on a more general level, many thanks for RM !

Unfortunately it will be the weekend before I can try this out, and learn more about button restrictions.

[Andy]

I unexpectedly got a chance to take a look at this again this evening, and I noticed something really weird. This with or without the mods that Greg suggested, so I posted no new RDF.

Now I am making upgrades that simply don't use the shifted keys that have key numbers assigned. But I am using shifted versions of some other keys. None of them work.

I did a doublecheck that the remote really does refer to a shifted key with an offset of $80, by putting a macro on (for instance) magic>FFWD. This also confirmed AdvCodeAddr as $022, in case I hadn't done that before.

Then I noticed that IR was "editing" the Keymoves as presented by RM. Here's RM's output :

Code: Select all

KeyMoves
 83 f4 07 ff a9 16«power on: also recognised by T-H300DAB tuner»¦
 a9 f4 07 ff a6 72«DAB tuner function / FM mode»¦
 8b f4 07 ff a9 2c«tape<<»¦
 94 f4 07 ff a6 52«DAB tuner info / RDS»¦
 8e f4 07 ff a9 1c«tape stop»¦
 90 f4 07 ff a9 5c«tape record»¦
 93 f4 07 ff a6 92«DAB tuner auto tuning»¦
 8d f4 07 ff a9 ec«tape>>»¦
 8f f4 07 ff a9 9c«tape pause»
End

and here is the Raw Data that ends up in the remote :

Code: Select all

0020:  00  00  83  A4  07  FF  A9  16  A9  A4  07  FF  A6  72  8B  A4
0030:  07  FF  A9  2C  94  A4  07  FF  A6  52  8E  A4  07  FF  A9  1C
0040:  90  A4  07  FF  A9  5C  93  A4  07  FF  A6  92  8D  A4  07  FF
0050:  A9  EC  8F  A4  07  FF  A9  9C  00  FF  FF  FF  FF  FF  FF  FF

Note that all those "F4"s got changed to "A4". If I manually edit the Raw Data to show "F4" then as soon as I hit the "Apply" button then they jump back to "A4". As if IR knows best. But presumably RM showed F4 for a reason ?

Am I onto something, or is this a red herring ?

[gfb107]

The "F" in "F4" is a special case. In IR, that nibble is used to indicate the device index of the keymove. Since RM and KM don't know which device index the upgrade will be assigned to, they use F to tell IR to use the device index to which the upgrade is assigned by the user. In this case, the upgrade is assigned to device index A (which I think from reading the RDF is the TV device?). So, yes, this is a red herring.

Is it possible that the URC-7562 uses the new format for keymoves, like the URC-6131? If so, you might try adding

Code: Select all

AdvCodeFormat=EFC

to the [General] section of the RDF.

[Andy]

Thanks, Greg

Nice explanation of the red herring !

I tried the "AdvCodeFormat=EFC" line you suggested. The output of RM does not change, but IR produces a different pattern in the Raw Data, is that right ?

However, the keymoves still do not work, so I guess that was not the solution

Thanks anyway

[gfb107]

Oh, if I'm not mistaken, you're using a protocol that uses 2-byte commands.

We haven't figured out the new format for keymoves that use 2-byte commands. As a result I think RM defaults to generating these keymoves in the old format.

I suggest you try creating some keymoves manually on the remote and look at how they are stored using IR. That'll help us figure out if we're on the right track, or chasing another red herring.

Also, could you post information about the protocol, and any protocol parameters you are using to generate this upgrade? Maybe a link to a .rmdu file?

[The Robman]

We haven't figured out the new format for keymoves that use 2-byte commands. As a result I think RM defaults to generating these keymoves in the old format.

Actually, we just figured that out recently and the new 6.00 version of IR handles it. I guess I forgot to pass the info along to you Greg, which is my mistake, I will do so soon.