MCE Remote learned codes

[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]

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)+

I would be happy with that. I had forgotten the detail Rob mentioned that this irp definition causes the executor to be comp. But even reminded of it, it doesn't bother me much.

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)+

I'm glad you don't like that. I don't either. I don't want to even try to figure out what the "comp" is accomplishing there.

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.

I haven't looked at the range of OBCs. If I understood Rob's point correctly, this third form is what Rob wants based on the logic that the set of OBCs does not guide the choice of polarity so we should let the executor default guide that choice.

If the set of OBCs really doesn't guide the polarity choice, then I would tend to agree with Rob (based on the fact that Rob is usually right).

But there is nothing seriously wrong with the IRP notation being opposite from the executor. That is what "comp" (a feature of the executor description, not a feature of the irp notation) tells you.

I don't think any of us want to fight over which polarity is chosen. We're each just explaining why we lean one way or the other in a fairly arbitrary decision.

[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.