JP1 Remotes

I managed to make this work and I think it is fairly clean from a UI perspective. I couldn't get the RC5Initializer() to work with this setup. However, the choice in the check box (selecting the upper or lower possible sub-device numbers) on the setup tab while it works does not appear in the pull down choice in the functions tab.

It works fine the way I have it set up, but if someone wants to modify the RC5Initializer, this is what I think needs to be done:

Be able to accept and entry of "RC5" in the first command parameter (RC5x Device :0|2|4|6|RC5). That sets the bottom bit of the second variable byte which changes between RC5 and RC5x. It also needs to have the text for "Sub-Device>64"appear rather than "OBC>64".

To clarify, as written it works and it is fully functional. AFAIK, it also works every feature that the $0073 protocol can do.


[RC-5/5x Combo]
PID=00 73
DevParms=RC5x Device 1:5=0,Sub-Device>63=0:bool,RC5x Device 2:5=[0],Sub-Device>63:bool=[1],RC5x Device 3:5=[2],Sub-Device>63:bool=[3],RC5x Device 4:5=[4],Sub-Device>63:bool=[5]
DeviceImporter=RC5Importer()
DeviceTranslator=Translator(comp,0,5,3) Translator(comp,2,5,11) Translator(comp,4,5,19) Translator(7,1,25) Translator(comp,6,5,27) Rc5FlagTranslator()
FixedData=00 00 00 00

CmdParms=RC5x Device :0|2|4|6|RC5,RC5x Sub-Device:7=127,RC5x OBC:6=63,RC5 Device:5,RC5 OBC:7
CmdTranslator=Translator(comp,1,6,0) Translator(comp,2,6,6) Translator(0,2,13) Translator(comp,1,1,12,6) Translator(comp,0,1,15,2) Translator(comp,3,5,3) Translator(4,1,1,6) Translator(comp,4,6,8)
#CmdParmInit=RC5Initializer()
CmdParmInit=PickInitializer(0,n0,n2,n4,n6,,)

DefaultCmd=00 00
CmdIndex=1

Notes=This Protocol can do either RC5 or RC5x mostly used in McIntosh and Philips equipment. It can do all 128 OBC's for any device in RC5. \
In the Setup tabou can select any four devices in RC5x and pick between subdevices 0-63 or 64-127 by marking the checkbox by the respective device. In \
the functions tab you can select any of the four RC5x Devices in the RC5x Device column OR RC5. If you pick RC5x use the columns for RC5x \
Sub-Device and RC5x OBC. If you select RC5, then use the columns further right for RC5 Device and RC5 OBC. Note: Since the variable data \
mapping is different between RC5x and RC5, values will appear in RC5x columns\
as you enter data in the RC5 columns and vice-versa. Just ignore the ones you aren't using.

Code.S3C80=40 9A 42 8B 17 C8 81 10 00 08 01 C2 01 A4 01 C2 01 A4 DE 2C 00 00 06 C2 94 01 06 00 28 08 37 21 18 E4 07 03 E4 08 04 E6 10 00 28 03 76 00 01 6B 45 B6 C2 20 29 03 8D 01 49 E6 25 09 E6 24 04 E6 28 89 E6 12 08 E4 22 1C E4 23 1D 28 08 37 22 08 37 24 0D E4 06 03 8B 0B 37 24 08 E4 05 03 8B 03 E4 04 03 E4 07 04 E4 08 05 76 00 01 6B 03 B6 03 20 77 77 E6 10 01 8D 01 49
Code.740=0C 1C 42 80 11 E9 C0 20 20 08 08 02 07 02 06 02 C9 6F 20 00 00 04 17 62 38 3C 01 69 A5 62 4A 29 03 AA B5 5D 85 5D A5 61 85 5E A5 62 85 5F 17 5A 06 A5 5D 49 20 85 5D 3C 04 77 2F 5C 3C C0 7E 22 00 3C A8 7E 22 00 A2 78 A0 5D 22 44 22 06 90 EC 60 3C 06 6C 3C E1 7E 3C 81 7F 3C 21 80 3C 01 69 A5 73 85 71 A5 74 85 72 A5 62 85 5E A5 61 17 5A 02 49 20 85 5D 4C 00 FF 60
Code.6805-RC16/18=10 27 42 20 15 87 81 10 08 04 00 DE E1 00 DE E1 4A 0A 6E F9 00 00 03 00 84 09 01 5F 22 B6 5F 44 A4 03 97 E6 5A B7 5A 01 57 04 A8 20 B7 5A 3F 58 B6 5E B7 5B B6 5F B7 5C A6 02 B7_66 CC 01 C4 A6 06 B7_68 B6 5E B7 5A B6 5F B7 5B A6 01 B7_66 A6 C5 B7_7B B6_71 B7_6F B6_72 B7_70 01 57 06 B6 5A A8 20 B7 5A CC 01 B2

From what you have done here, I think I have all the information I need to write custom initializers and translators.

I think there might be a better way to present this to the user, however.

I'm thinking there should be 4 columns:

• Type - RC5x or RC5
• Device - When the Type is RC5x, then provide a drop-down choice of the entries made on the Setup panel. When the Type is RC5, allow entry of a 5-bit device value.
• Sub-Device - only valid when Type is RC5x. Can accept/display values from 0-63 or 64-127, depending on the flag from the Setup panel.
• OBC - the OBC for the function (6 bits when Type is RC5x, 7 bits when Type is RC5).

The UI would be better the way Greg described it. I expect it would take a lot more new Java code to achieve that than a cruder UI, but it sounds like Greg is offering to do so.

Yes, I am offering to do it. It will take a bit more Java, but isn't a better UI the 2nd reason for having RM (the 1st being to eliminate the Excel requirement)?

I certainly agree with Greg's UI, it will make it much cleaner.

There are a few subtleties in what I did, that probably are already apparent to you two since you designed the whole protocols.ini concept which is quite powerful. (I was amazed that I could make it work even in a cruder state.)

One is trivial but I assigned the top bit of the sub-device to an unused bit in the variable data in the RC5x mode with this translator:

Translator(comp,1,1,12,6)

It's only purpose was to allow a numeral >63 into sub-device. Apparently you can't do that unless the bit has been assigned somewhere in a translator even though the bit width was specified as 7 in the parms. That may have some other purpose but if not, it might be good to relax that requirement.

The others:

Translator(comp,0,1,15,2) and Translator(0,2,13)

may be important to mention since Greg is going to change that part a little. Command Parm 0 is a "choice". When I added the RC5 choice (for a total of 5 choices) that correctly requires 3 bits. The bottom two are mapped to RC5x device selection and the top bit (that is 0 in all but RC5) is mapped (comp) to the bottom bit of the second variable byte that changes the mode from RC5x if 1 and RC5 if 0.

A couple of other questions:

How do you eliminate/hide the EFC column? In a two byte protocol, I think it confuses rather than clarifies.

I think it would be a good idea to always show the fixed data on the Setup page, do you agree? It does in this case but unless I missed something it doesn't always.

jon_armstrong wrote: It's only purpose was to allow a numeral >63 into sub-device. Apparently you can't do that unless the bit has been assigned somewhere in a translator even though the bit width was specified as 7 in the parms. That may have some other purpose but if not, it might be good to relax that requirement.

I don't really understand the issue. The design does require that the hex command translation be bidirectional (it can compute the hex command from the input and it can recompute the input from the hex command). It sounds like you found some glitch in the process of recomputing the input from the hex command and you covered it up by stuffing the problem bit redundantly into a spare bit.

I'm sure is Greg hit any problem in reversability of a translation, he can fix it in the Java code without storing any bits redundantly. Not that there is anything particularly wrong with storing a bit redundantly, but you shouldn't need to.

jon_armstrong wrote: How do you eliminate/hide the EFC column? In a two byte protocol, I think it confuses rather than clarifies.

I don't think we provided a way (but Greg may correct me). In most two byte protocols I think the EFC is worth keeping. The key factor is that the EFC in the two byte protocol is the same as the EFC for the same command in some related one byte protocol (presumably a one byte protocol that has fixed data holding the value that the two byte version has in the other hex command byte).

If there is no one byte protocol (in any model) that shares EFC numbers with the two byte protocol, then I agree that showing the EFC does more harm than good.

jon_armstrong wrote: I think it would be a good idea to always show the fixed data on the Setup page, do you agree?

I agree.

jon_armstrong wrote:It does in this case but unless I missed something it doesn't always.

I don't recall seeing that. I've seen a bunch of cases where data on the setup sheet fails to redraw as things get resized (by changing to a protocol with more fields) so things get temporarily lost from view. Greg long ago corrected the reproducible cases of that. It still happens occasionally, but I have no idea how to reproduce it, nor whether the bug might be in RM or in the GUI package or in Sun Java.

johnsfine wrote:

jon_armstrong wrote: It's only purpose was to allow a numeral >63 into sub-device. Apparently you can't do that unless the bit has been assigned somewhere in a translator even though the bit width was specified as 7 in the parms. That may have some other purpose but if not, it might be good to relax that requirement.

I don't really understand the issue. The design does require that the hex command translation be bidirectional (it can compute the hex command from the input and it can recompute the input from the hex command). It sounds like you found some glitch in the process of recomputing the input from the hex command and you covered it up by stuffing the problem bit redundantly into a spare bit.

The top bit of RC5x sub-device is really bit 6 of fixed data for what ever of the four choices is selected and that is set by the fancy little check boxes that I copied from the RC5 protocol. So we don't really want to set a bit of the fixed data from the command parms (I don't know if TranslatorFromCmd() will work either) and other than assigning the unused bit in RC5x, I couldn't see a way to do it.

This is a very unusual case and I see the reasoning for the "bi-directional" feature. I'm just explaining a little more in case I missed something. I know Greg can fix any of these little glitches, so it is only for my understanding.