JP1 Remotes

[mathdon]

First my apologies to Vicky and Rob . There are too many terms associated with button presses for me to retain them all in my mind. We have OBCs, Hex Codes and EFCs. But we also have Key Codes, as in an RDF. I was confusing OBCs with Key Codes. Rob brought this home to me by pointing out that of course our UEI remotes have fixed key codes but send out all sorts of OBCs for different equipment. I think my conclusion, concerning this Ortek protocol, is that Ortek is using Key Codes (related to the key matrix) as OBCs but that in general this is not the case and the OBCs are then more closely related to their function.

Now to the next point. John and Rob, you've confused me more than I was before! What I would like to say is

OrtekMCE {38.6k,480}<1,-1|-1,1>(4,-1,D:5,P:2,F:6,C:4,^48m)+

where P is a position code:

0 for first frame of repeat sequence
1 for all repeats up to last one
2 for last repeat

and C is checksum, 3 more than the number of 1 bits in D, P, F together.

I do not want to say

OrtekMCE {38.6k,480,comp}<-1,1|1,1>(4,-1,D:5,P:2,F:6,C:4,^48m)+

with the same notes. I'm still not clear why these two are not equivalent, but I gather from John that in some way they are not. If the first is not valid and I would need to say the second then I would prefer to leave out the comp, accept the uncomped OBC and change the notes to:

"where P is a position code:

3 for first frame of repeat sequence
2 for all repeats up to last one
1 for last repeat

and C is checksum, 1 less than the number of 1 bits in D, P, F together."

But I think the latter is ugly, especially because of the range of OBC values that it gives.

Please accept that I'm still on a steep learning curve with this protocol business, so you may need to repeat the (to you) obvious before it sinks into my head!
______________
Graham

[johnsfine]

[The Robman]

John raises a good point that the IRP and the implementation of a protocol don't necessarily have to agree with each other. The writer of a protocol doesn't decide to make his protocol comp'd, in fact, he wouldn't understand what it means anyway. We only need to use the term because of the way UEI implements it's executors, and keep in mind that UEI doesn't care about OBCs, so they don't care if they get it right or not.

UEI tends to gets the 1s and 0s reversed, in fact, they seem to do it on purpose, so we need to treat those reversed executors as comp'd, but we don't need to include anything about whether it's comp'd or not in the IRP.

Look at it another way, just because UEI's executor that generates NEC signals is comp'd, doesn't mean that I can't write one myself that isn't. When I write executors, the only time I make them comp'd is if I think there's some value to keeping the EFCs consistent with a UEI version.

In this case, I don't have the flexibility to reverse the 1s and 0s in the executor due to the limitation that I mentioned earlier.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!