JP1 Remotes

[johnsfine]

I believe this is a very flexible combo protocol and I'm wondering how RM should present the choices to users in order to preserve a good fraction of the flexibility without being incomprehensible.

I also may need to ask for some testing help, since I don't have either remote, so my theory of how these work is not certain to be correct and will need some confirmation.

The first two bytes of fixed data would normally be used as the manufacturer numbers (2 and 32 for Panasonic, encoded LSB comp as BF and FB). The protocol could be flexible enough to use those other ways, but not in any comprensible manner.

I think the next six values can be used as device and subdevice numbers according to the following rules:
1) The device number can be any of the six values.
2) The subdevice number can be the second of the six values or it can be any value later in the list than the device number.

Imagine the user chose the values 1,2,3,4,5 and 6. Then he can pick device and subdevice for each function. If a function used device 1 it could use subdevice 2,3,4,5 or 6. If a function used device 6 it could only use subdevice 2. If it used device 3 it could used subdevice 2,4,5 or 6. I hope that makes the rules clear.

A less confusing way to use this protocol might be to pretend there are two device numbers and four subdevice numbers and you can combine them in the eight obvious ways. For example:
144,128,0,1,4,5 lets you have
144.0 144.1 144.4, 144.5 128.0, 128.1, 128.4 and 128.5

In fact you could also have 144.128, 128.128, 0.128, 0.1, 4.5 and a variety of other combinations, but telling the user that might be too confusing and add nothing that would actually be useful.

There is also the question of whether RM and KM should support a special subset of this new 001F to duplicate the old VCR combo (take a single device and subdevice and support the four choices combining the specified device or specified device minus 16 with the specified subdevice or specified subdevice plus 1).

[johnsfine]

I did a little more investigation, including creating a "Panasonic VCR Combo" entry in Protocols.ini for this new version of 001F. I'll post that Protocols.ini shortly.

Mainly for Mark, but for any other epert who is currious, I'll describe here how to use the new 001F to create VCR combo upgrades:

The first byte of fixed data is the 8-bit LSB comp of the OEM dev1 value, just as in the older 001F. (default 2 encodes as BF).

The second byte of fixed data is the 8-bit LSB comp of the OEM dev2 value, just as in the older 001F. (default 32 encodes as FB).

The third byte of fixed data is the 8-bit LSB comp of the primary dev value. In RM (for compatibility with the older 001F) I force the hidden "primary dev" to have its bit 4 set so that the dev the user picked will be either the primary or the alternate depending on its bit4, for example RM uses 144 as the primary and 128 as the alternate whether the user picked 128 or 144 as the specified dev. That default 144 encodes as F6.

The fourth byte of fixed data is the 8-bit LSB comp of the alternate dev value. Having internally selected the primary dev with bit4 set, the alternate will be that number minus 16 (just as in the old 001F) but unlike the old 001F this one actually has the alternate in fixed data. The default 128 encodes as FE.

The fifth and sixth bytes of fixed data encode the primary and aternate subdevice. Similar to dev (above) I force the primary to be even and the alternate odd. The defaults 0 an 1 encode as FF and 7F.

The seventh and eighth bytes are unused (assuming the second byte of the hex command is encoded as described below) but must be present. RM will use 00 00.

The second byte of the hex command is E8, E4, D8 or D4. The E vs. D selects the primary or alternate dev. The 8 vs. 4 selects the primary or alternate subdevice. The E8, E4, D8 and D4 correspond (in sequence) to the 00, 40, 80 and C0 of the older 001F.

Anyone want to cram that all into KM?

[The Robman]

I agree with John's original analysis of the protocol, and I have posted a disassembly of the protocol here: new-001F-explained.txt.

Basically, the 2nd variable byte is a bitmap which controls which fixed bytes will be used in the signal. The first 4 bits that are set determine which fixed bytes will be used.

For example, 11110000 means use the first 4 bytes, 00001111 means use the last 4 bytes and 11000011 means use the first 2 bytes and the last 2 bytes.

However, I don't necessarily agree with John's suggested way of implementing it.

Some Panasonic VCRs need EFCs from 128.0, 144.0 and several other 144.??? codes. If we were to use the 3rd and 4th bytes as dev1 and dev2, and bytes 5 thru 8 as sub-devices, the 128.0 and 144.0 codes could use the same sub-device byte.

Of course, the ideal solution would be to come up with a more generic way of implementing this where the user can decide how to use the fixed data. Software limitations aside, the trick here would be to do it in such a way that it causes the least confusion for the user.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[johnsfine]

[The Robman]

OK, I see what you mean. In that case, yes I do agree with both the objective and how you want to achieve it.

As for the generic version, I figure that the user has two device selector numbers that they have to enter: the first number (in the range 1 thru 5) selects the main device code to be used for this signal, the second number (in the range 2 thru 6) selects the sub-device to be used for the signal. KM and RM would obviously hard code the values for the OEM codes and the user would have 6 "device codes" that they could enter.

This method would be the most flexible but also the most confusing because the "device codes" would be user defined and could be either device codes or sub-device codes.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[johnsfine]

I think you need to use RM a little more. We don't do "device selector numbers" on the functions sheet to index into tables on the setup sheet. If an entry on the functions sheet is supposed to be a selection from a list on the setup sheet, we create a pull down in each such cell on the functions sheet. Programs, not users, should keep track of indexing into lists.

You can see that in action for either version of the VCR combo in RM already (second version requires the protocols.ini I uploaded earlier).

Soon you can try the more flexible "Mixed Combo". I'm testing just a little more before I upload that. (I requires a new .jar file as well as the new protocols.ini. I already commited at sourceforge the new .java code thats in the new .jar, but any official release will need to wait for Greg).