johnsfine wrote:That's the keyboard one, right? And it assumes there is no carry from adding the device nibble to the first keycode nibble (which is reasonable because that "device" nibble seems to be zero for all keyboard samples).
I'm pretty sure the generic check byte logic of RM cannot do the correct wrap around carry. RM is designed to make it easy to add extra Java modules that do things like that. I should write a Java module to do the check nibble calculation with wrap around carry.
I probably wrongly assumed it could

I did go back and check all the regular KB keys using the wrap around carry and (as I'm sure you already knew), it is also consistent with them. So I suspect the wrap around carry is the true check nibble logic for all commands but the simpler sum of the nibbles works so far for all keys that have been decoded. So we can start with that until we find a command that won't work.
In thinking about the mouse commands, even though we now could emulate any direction and velocity, as a practical matter with only four arrow keys on OFA remotes (are there any with more?), we probably just want to pick a moderate speed in the four cardinal directions plus the right and left mouse buttons and create an upgrade. Then have users key move those six keys to their regular KB upgrade device. We should be able to do that in a double byte protocol, so we can just calculate those two bytes manually and I'll document the process.
I created an Excel spreadsheet that can calculate the commands and check nibbles for every 15 degrees of bearing at any constant velocity and I'll just add the calculation of the two variable bytes (lsb first.) We could also create the left or right mouse button plus the four direction keys and those could be moved to the shifted (or x-shifted) arrow keys and get a pretty cool emulation of the mouse in order to drag the mouse. Does that sound reasonable?