Microsoft MCE Keyboard Remote

[The Robman]

The way you do it is, copy the whole comma row to a new row, then edit the final byte to be all zeroes (you may need to add a quote at the beginning to stop Excel changing it to a number) and the red digits will reveal the answer. In this case, it should be "00000".

[vickyg2003]

Comma works!!!!!!!!!!!!!!!!!!

I also added the missing pageup, pagedown, and the directional arrows to the keymap file. They are working too.

This is so much easier now that I have a nuc IR sensor working.

I also as a test tried creating a shift-F10 by changing the last byte to 00000010, and then used the new checksum and made the appropriate changes to my data ORing 001 00000 with the checksum for the secondbyte and adding 128 to the obc. That worked as advertised, the Shift-F10 brought up the options menu...
Tried Windows+E by changing last byte to 00001000 and computing and encoding
Tried Alt+F by changing last byte to 00000100 and computing and endcoding
Tried Ctrl+A by changing last byte to 00000001 and computing and encoding

All worked, see the keymapmaster in the zip file for the examples. The spreadsheet really helps with this.


I added your MCE checksum calculator spreadsheet to the MCE keyboard zip, and uploaded it.

Rob, thanks for doing that. I certainly don't follow the math, but it works flawlessly.

https://www.hifi-remote.com/forums/dload ... e_id=14676

[vickyg2003]

Would it have been easy to compute the verification code in the executor?

[The Robman]

Would it have been easy to compute the verification code in the executor?

Yeah, that's the next step. I haven't looked at your code yet to see how you created the signal, and I haven't written anything in assembler in years, but I'll try to have a look at this tomorrow. The function that you need is called XOR, but I need to think about the best way to approach it using the least amount of code.

[vickyg2003]

I see i was editing my post above while you wete posting.
We now know thar the signals that had the last byte of 00100000 could use 00000010 if we recalculated the verification code. That could simplify my enoding scheme and allow obc's all the way to 256 and reduce the size of my protocol by a few bytes. With the checksum calculator we now have the ability to send any key plain, or combined with alt, cntl, shift or the windows modifyer key as long as the obc is less than 128. If i recalculated the verification code for those keys captued with a different shift value i could change my code to go all the way to obc 256. But that doesnt handle any keys with a combination of modifier codes. But would you really need them on a remote anyway. What do people use a remote for? Kodi? Plex? Media center? Simple home automation?

If you read on the internet, you'll find numerous references to using a logitech with the Windows MCE Keyboard device. No mention that the comma doesn't work, nor that the learns are so dirty that it is very difficult to recapture them for analysis.

[The Robman]

Do you have any idea what the 2nd byte value of 00100000 means? Especially given as the regular shift value works.

If you want to include my spreadsheet in the zip file, you should modify it so that it calculates the 2nd byte for your KM upgrades.

If we were to build the checksum calculator into the executor, we would still need at least 7 bits for the OBC and 4 more bits for the CTRL, Shift, alt, Windows indicators, which means we'd still need 2 variable bytes. We could keep it to one if we just supported SHIFT.

Do you have a commented PB file for your executor?

Here's the formula for the checksum:

Code: Select all

1 = a:12345 b:
2 = a:678   b:1234
3 = a:12678 b:1567
4 = a:3467  b:23568
5 = a:13568 b:24578

Where
a = OBC
b = Modifier (ie, shift, alt, etc)

The numbers refer to the bits in the byte, counting from left to right, numbered from 1 to 8 (ie, the way Excel does it).

So, to calculate bit2 of the checksum, you would XOR bits 6,7,8 from the OBC byte and bits 3,4 from the Modifier byte.

[vickyg2003]

Do you have any idea what the 2nd byte value of 00100000 means? Especially given as the regular shift value works.

When I was writing my excutor I was cluless. Now I'm thinking way, way back to Windows 3.1 or maybe DOS when I was using Alt - 0162 to add ¢ and sometimes it would work and sometimes it wouldn't, and it depended on which ALT key I was using. The ALT on the right or the ALT on the left. Now I'm thinking that the 0010 0000 might mean the one on the shift on the left and 0000 0010 might mean the shift on the right. I haven't actually tested those to see if they will work with 0000 0010 but the comma worked that way.

Its really helpful having the equipment here to test on. Its even in the same room, so I'm not climbing out of the dungeon to something on the main or second floor!

If you want to include my spreadsheet in the zip file, you should modify it so that it calculates the 2nd byte for your KM upgrades.

Ewww

If we were to build the checksum calculator into the executor, we would still need at least 7 bits for the OBC and 4 more bits for the CTRL, Shift, alt, Windows indicators, which means we'd still need 2 variable bytes. We could keep it to one if we just supported SHIFT.

Right now you are thinking with your JP1 hat on, I'm thinking NEVO. My NEVO has 59000 bytes free, while my JP1 remote has 2 bytes free. With a Nevo, you could put EVERYTHING in an upgrade, and just use the keys in macros, without having to assign them to buttons on a device. So you could start your Nevo, Enter your password as a macro.... And set up a few combinations of keys to do other things.....

Do you have a commented PB file for your executor?

More or less, its in the Protocol Builders file section. The mouse and keyboards were zipped together.

[The Robman]

Do you have a commented PB file for your executor?

More or less, its in the Protocol Builders file section. The mouse and keyboards were zipped together.

You're gonna make me go search for it, eh? What do we tell the newbies about posting links to files?
https://www.hifi-remote.com/forums/dload ... e_id=14678

[vickyg2003]

[The Robman]

I downloaded ur "PB" file but it just contains the KM files.

[vickyg2003]

Hmm, upload time was just a few minutes after I created it and it was a in the morning. I guess I'm getting worse at this stuff.

I updated the link, and then downloaded and tested, the files in there are definately PB files now.
https://www.hifi-remote.com/forums/dload ... e_id=14678

[The Robman]

I was thinking that I could calculate the checksum in a similar way to how I did the 4DTV protocol but it would take too many bytes of executor code. So I'm thinking that it would be better to have RM calculate the checksum and feed it into the executor.

As for the executor, I haven't studied yours yet, but here's how I think it could work. We could have 3 fixed bytes but in the executor data block, set it for one fixed byte of 8 bits and one fixed byte of 5 bits. Set it for 2 variable bytes of 8 bits each. Then in the logic, change it from 3-2 to 2-3 (fixed/variable).

I would use the low bit of the OBC byte to hold the high bit of the checksum.

For the 2nd byte, I'd use the first 4 bits for the low bits of the checksum and the next 4 bits for the 4 flags (windows, alt, shift, cntl).

Then in the logic, we can copy variable2 over to fixed 2, then mask out the right nibble. Then mask out the left nibble on variable2.

For the OBC byte, we can clear the CARRY then use RRC (Rotate Right thru Carry) to (a) put the OBC back into position, (b) clear out the high bit and (c) capture the missing checksum bit. Then we can use RRC on fixed2 to rotate the missing bit into position.

I'll take a crack at writing that either today or tomorrow, unless you want to try first. Then we need a volunteer to write the protocols.ini code.

[The Robman]

here's what I came up with, sorry don't have time to do a write up as we're going out, but I wanted to get it loaded for you to look at

https://www.hifi-remote.com/forums/dload ... e_id=14693

[vickyg2003]

Hi rob, the PB sure is smaller, but it doesn't work. The device is not responding. It is sending out 37 bits as expected. Not sure if its the checksum or the obc that is incorrect.

[The Robman]

Are you able to capture the signals so I can take a look? I didn't do any testing on it myself.