JP1 Remotes

Fact: discrete on and off can be made to work in at least one version of this receiver (mine) . With the Panasonic Combo2 protocol, it needs byte 2 to be zero, not 4. It works great in the power on/off macros in spite of all our complaints in several threads here. Consequently, I updated Rob’s CompositeSpreadsheet. At the tail end, I fell out of yahoo, so I can’t tell whether file really got through. I’ll check later.

Speculation: Multiple codes for Power function made me revisit this issue. While I don’t know how to reconstruct what may have gone into the Combo2 protocol, my guess is that the first device is 128.0. I haven’t yet played with KM’s device combiner which, I suspect, would clarify. [These discretes just cost me 12 bytes! Keymove space is about shot , and I don’t know yet how to rebalance other than by extender]

I've forgotten which JP1 remote you have, and I don't have time now to check for built-in setup codes anyway, but usually there is a built-in setup code that can be used for the KeyMoves instead of using the combo.

The reason for using a combo may be that you have too many functions outside the main subdevice for Keymoves, or that no setup code is built in for some subdevice. But even if it's best to use a combo for the upgrade, it is likely not best to use it for any KeyMoves associated with the upgrade.

This is one reason RM has an external functions tab (and KM has something similar, which I've never used). Once you decide that a given function will need a KeyMove anyway (such as if it's on a shifted key) then you are usually better off redefining it as a one byte hex command based on some built-in setup code.

TV/0250 is Panasonic:128.0 aka Panasonic:128

Elizabeth, that's great news! Can't wait to try it on mine.

Thanks,
Tom

Forgot to ask...how did you figure out that you needed to change the byte 2 setting?

Thanks,
Tom

Jon,

TV/0250 is Panasonic:128.0 aka Panasonic:128

Ouch! Thanks for spotting this. The receiver is 160 not 128. At least that's how I understand it.


tbsmith,

how did you figure out that you needed to change the byte 2 setting?

I've been staring at Rob's composite. Followed the Power function (as in 'follow the money'). Just tried things. In IR I changed second byte to the subdevice numbers in his list, and $FF worked after they flipped the bits. So that confirmed it. No logic, really.


John,
We're off the main subject and the Site Owner may complain

I've forgotten which JP1 remote you have

I didn't think it was relevant. Remote is 8910 with B02 at the end.
You give me the greatest answers, but this question is rough on me...

The reason for using a combo may be that you have too many functions outside the main subdevice for Keymoves

I'm not sure I follow what you're saying. I used combo2 because what was built in was dreadful and the file I found is great. Not knowing any better, that's the path I followed. I have some within-upgrade keymoves (shifts, phantoms) and a bunch which span different devices, meaning types in JP1-speak, I think. Receiver is the central unit in my design so a bunch of things have to get connected. In fact I've been contemplating that perhaps I should make me a combo-combo to include some of those keymoves, not that I know how. I have to go back and read more readMe files.

This is one reason RM has an external functions tab (and KM has something similar, which I've never used). Once you decide that a given function will need a KeyMove anyway (such as if it's on a shifted key) then you are usually better off redefining it as a one byte hex command based on some built-in setup code.

I know about KM's external function, it works very well, but I thought it was for something else. And I didn't think of actually using something out of the remote while I've already commited myself to the upgrade for the receiver. I'm sure I'm missing something from what you wrote. Can you explain just a bit simpler? So are you saying that instead of coding something on a shifted key which is so costly, I can just pop =RCVR/<Terrible BuiltIn Code number that does what I need> into KM and use that instead?

BTW, one reason I ever got 8910 because Panasonic remote that came with the receiver was designed to be really user-hostile (unlike their TV remote). Then, I followed 8910 instructions to setup this receiver, and most keys didn't even work. And that's how I found myself in this amazing JP1 land .

ElizabethD wrote:So are you saying that instead of coding something on a shifted key which is so costly, I can just pop =RCVR/<Terrible BuiltIn Code number that does what I need> into KM and use that instead?

The only "savings" you'll see (assuming you can create the external function from a 1-byte setup code) is 1 byte. A key move from a 1-byte protocol uses 5 bytes of EEPROM, while a 2-byte command uses 6. If you replace enough 2-byte key moves with 1-byte equivalents, you might see modest gains (perhaps enough for an extra key move or two).

That one byte per KeyMove was all I was talking about. Somewhere in there I got the idea that Elizabeth's setup was so tight on KeyMove capactity that a few extra bytes really mattered.

We still haven't fully explained how to do it, since it depends on a built in one byte setup code matching device 160 and the subdevice of the desired function. Jon's answer (and my original guess) were based on the apparently erroneous 128.

I'll check later if no one else does.

johnsfine wrote:it depends on a built in one byte setup code matching device 160 and the subdevice of the desired function

Audio/0303 = 160.10
Audio/0308 = 160.0
Audio/0309 = 160.4
Audio/0367 = 160.194
Audio/0518 = 160.28

Only Audio/0303 (as CD/0303 160.10) appears to be in the 8910.

johnsfine wrote:That one byte per KeyMove was all I was talking about. Somewhere in there I got the idea that Elizabeth's setup was so tight on KeyMove capactity that a few extra bytes really mattered.

Correct. Every byte counts. So far I’ve collected building blocks for the first round of design. Likely inefficient and due for a good cleanup. Second round of improvements depends on the tools I find, so I’m very interested in byte savers. At this point I see 19 free bytes in the keymove/macro area, and tons of space in the upgrade area and I doubt I could fiddle with the pointers. I could zap a questionable-usefuleness macro of some 9 bytes, but I still need couple macros and couple keymoves for stuff now upgraded as well as other devices.

Mark Pierson wrote:Only Audio/0303 (as CD/0303 160.10) appears to be in the 8910.

I looked at my TV job and confirmed what Mark knows: when I called an external function from a built-in one-byte VCR setup into one-byte TV/0250-type upgrade, it became a 5-byte keymove exactly.

This is really interesting. Can’t wait to see which way you’ll both point me.
And how did you find out that 160.xx is used in those built in codes? I can't see them .

Mark Pierson wrote:

johnsfine wrote:it depends on a built in one byte setup code matching device 160 and the subdevice of the desired function

Audio/0303 = 160.10
Audio/0308 = 160.0
Audio/0309 = 160.4
Audio/0367 = 160.194
Audio/0518 = 160.28

Only Audio/0303 (as CD/0303 160.10) appears to be in the 8910.

Should there also be a 160.20 in the list? It's in the Panasonic Combo2.
How did you, and how would I, go about finding where 160 is used????
I've looked at CD/0303 in advanced codes section and see no ref to 160.
What obvious piece am I missing?

I gather from some info I saw on this site that a combiner of some sort could incorporate what's now in keymoves into the upgrade area. Could you just point me in the right direction how to start? And could you explain or show me a link where I can find the differencce between device combiner and, for instance, already combined Panasonic Combo2.

BTW, once again, thanks to you all for such terrific support. Whatever simple upgrades I built up to now has been fully approved by the family.

ElizabethD wrote:How did you, and how would I, go about finding where 160 is used????
I've looked at CD/0303 in advanced codes section and see no ref to 160.
What obvious piece am I missing?

That's what "experts" are for! The only way that we know that CD/0303 uses 160.10 is because somewhere along the line, someone learned the signals from a remote using CD/0303 and made a note of it. Most experts have files compiled from such findings which we use to look up info like the stuff that mark posted.

You can get some of this info yourself from the devices.xls and devices4.xls spreadsheets.

You can get some of this info yourself from the devices.xls and devices4.xls spreadsheets.

Would it be beneficial to the group to create a devices6011.xls, devices810.xls, etc? I've been wanting to give back something to the goup but don't have much in the skills department that would be helpful. But I could probably do some brute force learning of various built-in codes.

ellen wrote:Would it be beneficial to the group to create a devices6011.xls, devices810.xls, etc?

If I interpret, what you asked, correctly – by all means, please, build/update any crossrefs you can. Perhaps all in one spreadsheet. In Devices4, for example, the history stopped at 3 universal remotes. And, likely, not all codes are in. I would think, unless you have every remote and equipment in the world, this should be a group effort with many people updating. People like me will be grateful and it might save some experts’ time looking up codes for us.

robman wrote:That's what "experts" are for!.

Trying to avoid just that, if the info just might be in front of my face someplace. But the ideas in this whole thread just make me ask more questions …

robman wrote:You can get some of this info yourself from the devices.xls and devices4.xls spreadsheets.

I saw somewhere that Devices.xls is obsolete and/or not to use. So it sits in my collection, unused.
That is a useful file! The data is there – filter for 160 reveals 4 or so device protocol rows. (List possibly missed 20. I use it for the receiver with Panasonic Combo2).
Devices4 likely has the info but you have to know first, what Mark found, that CD/0303 uses 160 (no data in Devices4 that’s useful, but advanced code list has it). Codes sheet is padlocked. I don’t do password breaking unless value added is going to be enormous.

I’m still puzzled about how to know what’s built into Panasonic Combo2 (my original question, which by now, of course we know should have asked about 160 not 128). How can I, by looking at that protocol, know which device protocols were included? How come actual subdevice numbers (not index) are used in coding?
I’m making a mental parallel (perhaps erroneously) with a file Panasonic Combo PV-D4732 which uses device combiner from KM. It clearly shows what’s been scrambled into it: there’s a list in a lower-left corner and fixed bytes are shown in the Protocol section for each part of the combination. On the Functions sheet just zero based index is used and that’s that.
Panasonic MIX seems to have mixed some/all of above, and subdevices 0,1,5 are clearly shown, and on the Functions sheet, subdevice is always 1 (plus delay byte). So how come I don’t see such a clear connection to protocols in Combo2 or PanasonicMIX as I see in the combiner and how can that be unscrambled? Would actually making an experimental combiner show me the light if I could just watch its footprints?

I imagine a situation of some unknown equipment from which you learn that it uses protocol(s) list and subdevice(s) list – how would I go about knowing which of the combo protocols might include what’s needed? Trial and error only?