JP1 Remotes

The protocol I happen to be using is "NEC1 Combo", because TEAC chose a different subdevice for the tuner. The other one I was likely to test the RDF on was "Sony 12/15", another multi-byte protocol, I think.

I had already decided to simplify things a bit and make an upgrade that leaves out the tuner, so I can use straightforward NEC1. I'll try that later this evening when I get back on the case.

Also I only just realised how to manually program keymoves (that's 994, right ?) so I also planned to try that and see how it gets stored.

Got it !! You were spot on, Greg (twice in a row, it turns out).

First I made an upgrade just using the NEC1 protocol. No shifted keys worked.

Then I added back the line "AdvCodeFormat=EFC" that you suggested. That got the keymoves working. So it must be the new format.

So, when I sober up I'll post a new RDF file. As I understand it this will :

• 1. Only work for simple protocols until RM is enhanced (and thereafter require IR v6.0 or later).
  
  2. Still benefit from manually pulling out keymoves that duplicate upgraded keys with UE defined keycodes above 0x7F (to save a bit of advanced code memory) until RM gets a further enhancement.

I did try the restrictions stuff you recommended, Greg, and got a bit confused. IR seemed to complain about the way you recommended, so I tried it the other way about, placing specific restrictions (ShiftMoveBind, XShiftMoveBind) on the keys that have predefined shifted functions. But both RM and IR seemed to totally ignore these. Please don't take this as a complaint until I check it out further (I think I mean "until I understand what the heck I'm doing").

Thanks for all your help, Rob and Greg.

Well here goes ! Since yesterday's minor triumph I tried every "spare" button code from $30 to $3F as "Phantom" buttons in Macros, and all of them work except $30 and $34. So I put the others into the RDF as 14 "Phantom" buttons.

The result is posted here. For me it seems to work in every way (subject to the caveats mentioned in the previous post).

I hope it works for you too !

Give RM v1.12 a try. I think it should have fixed all the problems you were having with it.

As you've come up with this so quickly, the least I can do is try it out.
But I'm struggling to know when, this side of the New Year !

Thanks

Andy

Hi Greg

IR (6.00rc3) reports an <Error> against "Hex Cmd" and "EFC or Key Name" when I make keymoves in RM v1.12. Could be an IR problem, of course.

I could post some big upgrade files, but something really simple serves to illustrate. Make a minimal upgrade as follows :

• Remote: URC-6131 PVR Remote
  Device Type: Misc Audio
  Protocol: NEC1 Combo
  Device Code: 133
  Just one function, we'll call it "power on"
  EFC: 130
  Sub Device: 106
  Put this function onto the shifted power button.

Paste the output into IR 6.00 rc 3. The single keymove shows errors as if IR didn't understand the output.

Actually, I'm surprised that these keys come up as three (rather than 2) byte commands on the "Devices" Tab of IR (i.e if put on unshifted keys). RM shows fixed data of 5E, but by the time it gets to IR the fixed data is blank and the first of three hex bytes per key is 5E.

Unfortunately I'll be away from my bagful of remotes (and my broadband connection, but not my PC!) for the next week. I'll try to take a look over Christmas to see if there are any questions. But of course you may be otherwise occupied yourself !

Have a good one !

Add to the [General] section of the 6131 RDF. That'll tell IR how to decode the keymoves correctly. Note that IR will now display the keymove as EFC5, which won't match the EFC(3) of 130 you entered in RM (or KM). That's because the EFC5 format encodes both bytes of the hex command, while the EFC entered in KM/RM only encodes the OBC byte.

The URC-6131 uses 3 digit EFCs.

Is it just that the URC-6131 only allows entry of three digit EFCs, or that it actually can't support 5 digit EFCs for keymoves created with IR/RM/KM?

We know that the non-extended URC-6131 uses EFCs instead of Hex for keymoves. If it doesn't support 5 digit EFCs, there is no way for IR/RM/KM to create valid keymoves for protocols that use 2-byte commands.

All I know for sure is that by setting EFCDigits=5, IR600RC3 can actually interpret the keymoves correctly. Andy will have to test for us to see if the keymove actually produces the correct output.

The URC-6131 and the similar Atlas remote are both "hybrids". While they use the new keymove format, they only support 3 digit keymoves, both inside and out. In other words, if you program the remote manually, you must use 3 digit EFCs (or EFC3s), and if you program keymoves using IR/KM/RM the first byte must always be zeroes. Well, it doesn't really need to be zeroes, but whatever value is there will be ignored. These 2 remotes don't support EFC5s in any shape or form. They don't support 2-byte keymoves in any shape of form.

I'll be back with my 6131 (and 7562) on Jan 1. I'll try to contribute more then.

I'm back on the case now. I must have been in a hurry on Christmas Eve, because I failed to save all the files I made, and now I cannot reproduce one problem I complained of, namely getting three byte upgrade code rather than two plus one byte of fixed data. I can only assume that, as I was making my "very simple" upgrade by editing a much bigger/different upgrade, there remained some rubbish in the RMDU file. Now (for non-shifted keys) I get a sensible one byte of fixed data, two bytes of key data (NEC1 combo protocol).

All the following is using the published 6131 RDF or my posted 7562 RDF, but with Greg's line: added in the [General] section.

Yes, Greg, that line certainly does stop IR from complaining about the keymoves. But on loading the upgrade to a 6131 the shifted buttons don't work.

Thinking I may have misunderstood how to get the shift effect on a 6131, I tried a similar upgrade on a 7562. It worked. This is the first time I have seen reliable keymoves using the NEC1 combo protocol on my 7562.

So now I was even more convinced that I had misunderstood how to get a shift on the 6131, reinforced perhaps by the fact that the "magic" key on the European models I'm used to is at the very top, but the "set" key I believed got a shift on the 6131 is at the bottom.

So I took a look at the output from the 6131 with a learning remote. Sure enough the shift was working fine, it's just the wrong codes coming out. For instance, expected output:

NEC1, Device 133, Sub-Device 106, Hex Cmd $74

actual output:

NEC1, Device 133, Sub-Device 193, Hex Cmd $55

I note that KM is not yet ready for KeyMoves on the 6131, so maybe it's common knowledge there's still a way to go on that one. But the good news is that whatever is in there so far for the 6131 actually seems to work nicely on the 7562 !

Let me know if there's anything I can do to debug the 6131 problem (or point me to the thread if there's already one running). Could be that it's just the NEC1 combo protocol that shows the problem ?

In the meantime I'll put some bigger upgrades into the 7562 to se if it really is as good as it looks. But I'll not change the posted RDF, as I get the impression from Rob's post that the extra line is not going to be the final preferred solution.

... and a Happy New Year !

I now have a big upgrade on the 7562, with all the shifted keys I could wish for. They all work fine.

Rob (if you are there - sometimes I think you read every single posting on these boards, but how could you ever find the time ?!),
is it possible that is actually perfectly correct for the 7562 (B01 version) ? Even though it's wrong for the 6131.

Thanks

Andy

There is no problem with the URC-6131, it just doesn't support keymoves for 2-byte protocols, plain and simple, which is why I said the EFCDigits=5 setting was wrong for the 6131. The only way to setup keymoves with an un-extended 6131 for 2-byte protocols is to create a dummy upgrade that includes all the functions that you want to use in keymoves, then use "key copies" against this upgrade.

As for the 7562, I just checked all the IR dumps that I have for this remote and none of them have keymoves in them, so I can't say what the correct format is, but if by adding that parm to the 7562 RDF you have made the keymoves work, it would certainly imply that it's the correct thing to do.

Thanks for this, Rob.

I've updated the posted RDF to add the required line. It looks like a good 'un !

Andy