JP1 Remotes

[Barf]

Continuation from http://www.hifi-remote.com/forums/viewtopic.php?t=15146, since I did not want to treadnap a beginners question.

It strikes me that RM on one hand and DecodeIR + IrpMaster (thus programs using IrpMaster, like IrScrutinizer and IrMaster) on the other uses different and incompatible definitions. First it is the names: "GI Cable" vs. "G.I.Cable". Then RM has no D parameter, while DecodeIR/IrpMaster has a four bit D:

{38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*){C = -(D + F:4 + F:4:4)} [D:0..15,F:0..255]

Anyone would like to comment?

[3FG]

Well, I don't remember ever seeing an "official" description of the GI IR protocol, but it is reasonable to believe that it does have 4 bits of device data. So I think the description of the IR protocol given by DecodeIR is correct.

RM provides various protocol executors, which need not provide a way to send all possible bit combinations given in the IRP description. The official executor written by UEI only sends device 0 and consequently takes no D parameter in the fixed data. I think they did this because it saves space in the executor and seems to fully serves the need--we only ever see device 0.

It is important to distinguish between IR protocols and protocol executors. The latter can be written to implement only a subset of a protocol, or in some cases several protocols may be implemented. We also provide executors which allows more than one modulation frequency.

I don't see a conflict here.

[Barf]

Thank you for your answer. The difference between protocol executors and protocols is absolutely clear to me. Interestingly, however, is that RM consequently calls executor for "protocol"...

So, the different names is possibly even a Good Thing.

The reason why I care is that I will consider smart import into RM, which will require to map protocols to executors. Having a lot of special cases is no fun...