JP1 Remotes

I took John Fine's suggestion to add the Streamzap protocol to RM.

Streamzap is like RC5 but has an additional device bit. I modified the protocol to be 3-bits and 6-bits of fixed data and 6-bits of variable data. No commands were >63

I added the following to Protocol.ini:

[Streamzap]
PID=01 24
DevParms=Device Code:6=35
DeviceTranslator=Translator(comp,0,6,2)
FixedData=ff 73
CmdTranslator=Translator(comp,0,6,2)
DefaultCmd=ff
CmdParms=OBC:6=0
Notes=This protocol is similar to RC5 but has an extra device bit
Code.S3C80=43 8C 21 8B 14 86 81 10 03 06 01 A6 01 92 01 A6 01 92 A3 34 FF FF FF FF 06 08 00 27 0B 03 8D 01 46


Saved the file but Streamzap doesn't show up in the drop down list of protocols when I open RM. I tried all possibilities including rebooting my computer in case Java was running in the backround, deleting the old and renamed protocol.ini file.

I'm sure it's something simple and I am showing my admitted and utter lack of knowledge about Java and RM. Also, does anythuing in my entry look out of place?

It looks nearly right, so I tried adding it to my protocols.ini and it DOES show up in the drop down.

My one long-shot guess for why it didn't show up for you is that you didn't have a remote selected that RM knew was S3C80 (since the entry indicates only S3C80 support). If you don't use RM much, maybe you don't even have it configured to find the RDF files.

But there is also an error. Those ",2" values in your translator indicate that the top bit of the field belongs two bits below the top of the data, as the device field does in Rob's version. But, if I understand your version right, the (top of) device is 8 bits below the top of fixed data and the OBC is zero bits below the top of the hex cmd.

I prefer Rob's PB version (if I missed a flaw in that, please comment). I think Protocols.ini for that would be

[Streamzap]
PID=01 24
DevParms=Device Code:6=35
DeviceTranslator=Translator(comp,0,6,2)
FixedData=ff
CmdTranslator=Translator(comp,0,6)
DefaultCmd=ff
CmdParms=OBC:6=0
Notes=This protocol is similar to RC5 but has an extra device bit
Code.S3C80=43 8C 11 8B 13 85 85 10 08 06 01 A6 01 92 01 A6 01 92 A3 34 01 A6 00 00 08 00 27 0D 03 8D 01 46

BTW, I hope the difficulty you had this time doesn't discourage you from trying next time (and if it still doesn't work this time after you make sure it can find RDF files, I hope Greg can help you, because I don't have another guess).

jon_armstrong wrote: deleting the old and renamed protocol.ini file.

Maybe I do have a guess. Was that a typo in the post or did you drop the s in the actual file name when edit/renaming protocols.ini?

John,

Thanks for the response, I have been away all day and I never did figure out why it couldn't see the protocols.ini (I did have a 1994 selected, the the software asked me to find the RDF on install so they were available.)

I even tried a second machine -- same problem. I then copied your version of Rob's snapstream, pasted it and it worked. I then re-pasted my old version and then it worked -- go figure!

As far as the offset for the bits I understand now. And although, I haven't looked at what Rob did, I assume he must have put the lead in to simulate the first bit, and do it in one byte of fixed data -- Very good thinking!

As far as being difficult, I admit to starting with the RC5 protocol section as a model and being pretty confused. I still don't see why the RC5 devices are 6-bits. Maybe it has something to do with those fancy check boxes:

DevParms=Device 1:6=0,OBC>63=1:bool,Device 2:6=[0],OBC>63:bool=[1],Device 3:6=[2],OBC>63:bool=[3]

Or what the device importer is or where that is defined:

DeviceImporter=RC5Importer()

It might be worth commenting that one as an example but now that I've broken the ice, I'll figure it out. I may not tackle the RC5/5x combo as my first task though!

DeviceImporter is something I've added recently. Most protocols don't need anything for the DeviceImporter.
It is there to handle importing KM upgrades when the KM device parameters don't match up exactly with the RM device parameters.

In KM for RC5, the device parms are Device 1, Device 2, and Device 3, and we've indicating that OBCs greater than 63 are supported by adding 100 to the device values.

In RM, we've added specific flags to indicate that we want to support OBCs greater than 63, which means the device parms are not consistent between KM and RM. The DeviceImporter takes care of that.

jon_armstrong wrote: As far as being difficult, I admit to starting with the RC5 protocol section as a model and being pretty confused. I still don't see why the RC5 devices are 6-bits. Maybe it has something to do with those fancy check boxes:

That one sure is confusing. I'd need more review than I have time for now to understand it. I also don't know why the device fields are 6-bits, and I'm probably the one responsible.

I know it's NOT because of those fancy check boxes. I remember how those work. Greg and I went to significant effort to replace the "add 100 to the device number" process in KM with something that I think is more understandable (and connects automatically with the OBC fields in the functions page).

I tend to leave in handles for features that don't need handles (features that never need to be changed) as long as there is no extra cost to doing so. Thus I suspect the extra device bit is somehow a handle to the never-changed lead-in bit, and as such will give strange results if you use a bigger device number than rc-5 actually supports. But then, any wrong device number gives equally useless results so far as the end user is concerned, so there isn't even a cost in user confusion if this guess is correct.

OK, I'm hooked!

Here is RC5x (fixed I believe) even with the fancy check box from gross copying from the RC5 example. The only thing it doesn't do is allow you to enter 78 in the Sub-device field when the check box is set for sub-device greater than 64. It converts it to 12 and the command is correct. So I figure I did something wrong.

[RC-5x]
PID=00 F2
DevParms=Device Code:5=16,Sub Dev<63=1:bool
DeviceTranslator=Translator(comp,0,5,3) Translator(comp,1,1,1)
FixedData=0f
CmdTranslator=TranslatorFromDev(comp,1,1,1) Translator(comp,0,6) Translator(comp,1,6,6)
CmdParms= Sub Device:7=0,OBC:6=0
DefaultCmd=ff f0
CmdIndex=1
Notes=
Code.S3C80=40 9A 12 8B 17 89 81 10 08 08 01 BB 01 A8 01 BB 01 A8 94 01 00 00 06 7D 00 00 04 09 76 00 01 6B 03 B6 03 20 77 77 8D 01 46
Code.740=0C 1C 12 80 0C E9 C0 20 20 08 08 02 07 02 06 03 78 17 5A 02 AF 5D 3C 04 77 2F 5C 3C C0 7E 22 00 3C A8 7E 22 00 A2 78 A0 5D 22 44 4C 03 FF
Code.6805-C9=0C 1D 12 20 11 C0 C0 20 20 08 08 02 13 02 0A 03 F9 00 00 00 00 04 01 57 06 B6 5A A8 20 B7 5A A6 02 B7 59 A6 C0 B7 7B CD 01 83 A6 A8 B7 7B CD 01 83 A6 5D AE 08 CD 01 9E CD 01 8C 24 E2 81
Code.6805-RC16/18=10 27 12 20 15 87 81 10 08 04 00 D9 E1 00 D9 E1 49 27 00 00 00 CD 03 00 78 09 01 57 06 B6 5A A8 20 B7 5A 3C_66 CC 01 C4

Your CmdTranslator extracts 6 bits from the command to get the Sub Device. The maximum possible value is 63. Sub-device larger that 63 are represented by adding 64 to those 6 bits when the SubDev>63 flag is set. You need a custom CmdTranslator to disaply that correctly.
This isn't the only protocol that does something like that, so I may be able to reuse another Translator for that purpose, with a tweak or two.

Greg,

Is the custom CmdTranslator something that can be done outside of the program?

My next adventure was to do the RC5/RC5x combo, but I have no clue how to define two different sets of device/command translators based on the setting of the bottom bit of the two bytes of variable data.

Just in general, I was blown away by what you guys are doing and it seems like I may be able to help on some of the UEIC protocols that I understand on a practical level.

This obviously was a incredible amount of work! I know you, John, Nils, and others have been great contributors in this endeavor.

jon_armstrong wrote:OK, I'm hooked!

That's good, but I was hoping you would enter at the shallow end of the pool.

You are the primary person creating protocols with PB, and I think the best way to release a protocol from PB is via a protocols.ini entry for RM.

You know how the bits in fixed data and the Hex command relate to the values that the user should see. For typical PB protocols (and most UEI protocols), that relationship is simple enough that the protocols.ini syntax to specify it is also simple.

As Greg mentioned, a few of the hard relationships require new Java code. Or they might be best done by noticing enough similarity to some existing special code that can be generalized a little.

It's always best to divide the task in those complex cases:

1) First make a good description of the relationship between the bits in fixed and variable data and the values that the user should manage in the UI.

2) Create the protocols.ini entry with any required Java code.

I OUGHT to be doing the complex ones because we haven't forced Greg to learn enough yet to do step 1 for the complex cases, and I might (haven't watched others' activities enough to be sure) be the only good substitute for Greg in the hard cases for task 2.

But since I haven't made much progress there, we welcome your help. I'm sure you can do the normal ones. But if you attack hard ones, I think you should just post the results of task (1). Greg sounds like he would take it from there. Otherwise I will.

I am also thrilled to get more help maintaining protocols.ini

Custom translators (actually I think they should be called protocol-specific translators) do require new Java code, but that code is generally not very complex. Here's an example you can look at: PioneerMixTranslator.java

Greg and John,

Thanks for the explanation. Don’t spend any time improving the RC5x protocol.ini entry that I did since it seems to work pretty well. I have only seen one or two sub-devices > 63 in RC5x and I've seen a lot of RC5x commands, so we can just make a note that it converts the OBC to OBC-64 but it will work. Secondly, the RC5x protocol alone isn't very useful since most RC5x commands that I have seen are in Marantz and other high-end audio gear. However, it is rarely if ever uses RC5x exclusively and generally >80% of the commands are RC5 and a few RC5x. So I don’t think it will get much use.

IMHO, the RC5/RC5x combo is a very useful protocol for three reasons:

1. I think it is in many of the newer remotes
2. You can create any RC5 command including OBC>64 and most of the equipment that uses RC5 use several different devices with OBC 63 for input commands.
3. For audio gear, like Marantz, that use a mix of RC5/5x then you don't need a combiner or key moves to get all the commands in one device upgrade.

I think I can make RC5 work and RC5x work but not together. So I can do what John called 1 and with all the code for both cases, IF, that will help.

My thinking based on playing with the RC5/5x combo, once "activated" in the ini file, is to add a fifth entry "RC5" to the pull down menu that selects among the 4 available RC5x devices on the functions tab. If that could act as the flag to set the bottom bit of the two bytes of variable data (makes the protocol RC5 or RC5x) and to trigger which of the two sets of device/command parms and translators to be used. The "custom translator” is probably better done by Greg or John since my programming skills are suspect at best.


Also, it won't hurt my feelings if that will just add work for you guys and I'll go to work on the simpler protocols that aren't yet supported but I didn't see any.

John, you have a convert for the new PB Protocols (as you suggested) since I spend more time figuring out and explaining how to deal with bytes with fewer than 8-bits, than it takes to do the protocol and test it.

Also, in thinking about this for a few days, wouldn't it be important to add a field like "irp form=" and put in the protocol in John's new format and maybe a "decodes with decodeIR.dll=yes/no". That way we would have all the protocol definitions in one place. I can take a stab at adding that.

Also, (like you need more stuff to do), how about expanding the external functions to be able to read the formatted file from decodeCCF. The ability to import a ccf file directly, maybe sort or select by protocol/dev/sub-device/OBC and then check which functions to import would really be impressive with that nice UI.