JP1 Remotes

A built in 1-byte Panasonic protocol, which I just picked to replace 2-byte protocol (combo2 or MIX), has 5-8 keys in unexpected places. So I can make me an additional tiny upgrade to improve those bad keys. I’ve done it before. No problem here (other than finding a setup code that sticks, but that’s another story).

But here is the catch: I need to connect built-in protocol to device button since the remaining 30 or so functions are fine. I want to do some sort of a reverse keymove to my 5-8 button definitions. I wonder if my upgrade can in fact override that part of the built-in setup.

I’m not even sure how to ask this question, it’s something like this:
Bound device/Old key = small replacement setup code + new function key code.
Problem is, source isn’t a device, I’m not assigning it to device button. So is this too backwards to contemplate? Is there another way? Would something in protocol builder spreadsheet be appropriate? I haven’t used it, looked at it once.

I suspect my idea is looney. Then again, a solution might be simple, done before, and I’ve read about it and miss the connection. Bottom line: it being Bastille day today, I expect a revolution at home against bad button assignments , so please help.

ElizabethD wrote: But here is the catch: I need to connect built-in protocol to device button since the remaining 30 or so functions are fine. I want to do some sort of a reverse keymove to my 5-8 button definitions. I wonder if my upgrade can in fact override that part of the built-in setup.

That's just ordinary KeyMoves, nothing "reverse" about it. KeyMoves override keys defined in setup codes. It isn't a matter of an upgrade overriding a setup code.

ElizabethD wrote: I’m not even sure how to ask this question, it’s something like this:
Bound device/Old key = small replacement setup code + new function key code.

Right. But it's not a key code, it's an EFC or a hex command. If you need a two byte protocol, it must be a hex command.

ElizabethD wrote: Problem is, source isn’t a device,

No problem. The source is never really a device. The source is a setup code. You can use a device key as a way of identifying a setup code, but that's the only connection it would have to the KeyMove source. Or you can just specify the source setup code directly and skip the source device key.

ElizabethD wrote: Then again, a solution might be simple, done before, and I’ve read about it and miss the connection.

Unless I totally misunderstand what you're trying to do, that's right.

It is very common to use a second (or even more) setup code to fill in (via KeyMoves) functions that have the "wrong" subdevice when you choose a built-in or new one_byte setup code instead of a big combo.

If you are creating an upgrade for that extra setup code, you can save space by not assigning any functions to buttons. Use the functions tab in KM or RM to document the intended functions and if necessary to translate to EFC or hex command, but the functions aren't needed for the actual upgrade. The hex command of each function goes into the KeyMove and the upgrade provides only the protocol ID and the fixed data.

If you have three or more subdevices, you may want that upgrade to be a combo and the KeyMoves to use 2 byte hex. But with just two subdevices, the main setup code can be non combo for one subdevice and the second setup code can be non combo for the other.

johnsfine wrote: ... Or you can just specify the source setup code directly and skip the source device key.

Of course! That's what I missed in this context. 'All you need is setup and hex code' to paraphrase what you answered me to some previous problems. So the absence of device assignment is no longer a showstopper ! In other instances, when all upgrades were in front of my face in KM, the meaning of external functions was more obvious. Trying, now, to correct a built in thing seemed different.

johnsfine wrote: If you are creating an upgrade for that extra setup code, you can save space by not assigning any functions to buttons.

That's what I intended to do in the first place. Just keymoves in IR.

johnsfine wrote:
Unless I totally misunderstand what you're trying to do ...

No misunderstanding at all. And I now understand the anwers. I took a quick trip to IR which confirmed that you can skip entering device which results in <N/A>, precisely what I was aiming at. This will work. Many, many thanks for fast response, clear explanation and ,of course, a brilliant system making all this fun possible .

John,
I don't think it took more than 20 minutes to uncombine and tighten up a perfectly good 155-byte upgrade. It's now 60 bytes, including 9 keymoves . 10 more bytes will likely fall off due to some codes working with two subdevices. Don't ask why, because I don't know.

Many thanks for help!

ElizabethD wrote: some codes working with two subdevices. Don't ask why, because I don't know.

I won't ask why, I'll ask whether you're sure.

I don't remember exact details, but I remember there is a command in subdevice 5 that displays some information, and the same OBC number in a different subdevice displays similar information, but not the same (so someone was fooled into thinking he didn't need subdevice 5 for full support of the device). The information from the subdevice 5 command was more useful than the other version.

johnsfine wrote: I won't ask why, I'll ask whether you're sure.

... I remember there is a command in subdevice 5 that displays some information ...

Thanks for not asking.
Before I reply that of course I am sure and risk having my head chopped off I intend to compile the little list. Just the action of doing so may reveal I'm wrong. I may have to enable learning again to be sure. I'll keep you posted if you're interested.

I haven't zapped the 10 bytes for 144.5 and 144.1 yet for the very reason of having some doubts about it also. It appears to me at this point that 144.0 is sufficient from the changes I initially made in the combo upgrade.

Device 5 has on my receiver has one and only one function: Tape position. I don't recall using it and I believe that it is only available on power up. VCRs and I don't see eye to eye. The old one had a blinking clock for years. This one (PV-V4620) at least knows what time it is and so it also knows where it is which isn't bad .

John,
I thought of something during real work. While I might review the VCR since byte-saving is now on my agenda, similar results about my Panasonic SA-HE100 receiver are undisputable. From a list Rob prepared, I tested all SA-HE200 codes which weren’t already in my upgrade. It was then that I saw that alternative subdevices are permitted. File is v4. I just updated it the other day with another function.

In your spare time,
> See [Dups] which caught my attention (couple are intentional, I put them in).
> On [Update*] click on receiver with ‘egd’ in name - blue column filter, select Y to see all codes which worked and/or
> Click on functions column filter and select, one at a time, power, sfc, test (maybe others, I don’t recall).
I can replicate and stand by every blue Y in that file. I remember thinking, then, that HE100 or 8910 ignored bit 2. I found it very curious (defies definitions of unique device addressing???), made the record minus esig, and dismissed the whole thing.

John,
For the VCR, the facts do not support my assertion that one code can address more than one subdevice. Thanks for asking.
>> Coding error in extender keymoves, found and fixed.
>> Another thing derailed me: I thought that some functions worked in the MIX upgrade and now they also worked for a different subdevice, but that was just not true.
>> Also confusing were couple functions which still decode as 144.0 OR 128.0 which I find odd. Receiver, which I dragged into this thread, is another story, yet seems somehow related to strange things I see. I'll figure it out eventually.

Bottom line: things are working quite nicely, I no longer need a tripod for the duration of 8910 macros , and got the big upgrade splitting under control (first build them, then take’m apart).
Many thanks, John, for help, here, and several of my previous questions. It’s all slowly sinking in.