JP1 Remotes

Just curoius why there are only 7 potential commands on the Short Press, but 12 on the Long Press. I was thinking about reversing my LKP, but ran into that problem.

Dave

I never looked at how LKP works, but I've written a few similar protocols for KeyMoves that act as two-way macros. So I think I can explain.

There is one control byte used for several purposes, so only 3 bits in the control byte are available to indicate the split between the two lengths. The total of the two lengths is indicated elsewhere (by something outside that control byte) but only 8 ways of splitting are possible. The range from 0-12 through 7-5 was chosen because it seemed more reasonable to have the long side able to go longer.

In a ToadTog I understand why each side needs the potential to be zero keys long. I don't see that in LKP. I assume LKP would be better if the 8 splits were 1-11 through 8-4 rather than 0-12 through 7-5. But I don't know whether that would add code to the protocol, and if so whether the added code is worth it for the rare case that someone wants the 8-4 split. It still wouldn't give 9-3, 10-2 or 11-1.

Thanks jonsfine. I was wondering if it was a code problem or just a choice made in the beginning of development. Looks like a little of both.

In an LKP by definition the short side cannot be greater than 7 bytes. And the total of short + long can't be greater than 13.

Since an LKP must always have the first byte because this defines what is short vs long then you are left with a max of 6 bytes (or commands) for the short.

If you used all 7 in the short that would leave 6 available for the long. Conversely if you only had the first byte in the short then you would have 12 bytes available on the long side.

So the number of cells available in the SPB dialog when doing an LKP was my attempt to control this so users would not go over the limit.

I believe the limit of 13 has something to do with the way the extender handles these pseudo macros/km's.

One of the extender gurus will have to exlpain the ugly details.

Once again, thanks!