JP1 Remotes

The mouse commands have been fixed and are working in version #2. Three mistakes there, 2 typing errors, and reversing the left and right click, because I don't know left from right.

The Keyboard still has some trouble, mostly with some values that I did by hand
A,C,G,

I will have a look at these next.

vickyg2003 wrote:The Keyboard still has some trouble, mostly with some values that I did by hand: A,C,G

I thought we had a good decode for "G": 00100000-11111000000000000101000000000

I never saw working signals for "A" and "C", if you can re-capture them I'll decode them for you.

It seems i packed up the wrong version of the protocol so none of the of the shifted keys are working. I was about to post it when i ran out of time. Most of the keys are working once the right protocol is included.

On a bare windows 10 machine how would you test ESC, shift and function keys?

vickyg2003 wrote:On a bare windows 10 machine how would you test shift and function keys?

This might work:
http://aalapshah.in/qipress/

Thanks Dave, that reminded me that there is the OSK built into windows. The window 10 OSK is kind of lame, but somewhere in my teaching stuff I copied off the OSK from my old XP del that has Function keys. I haven't found it yet, but I know I have it on a thumbdrive somewhere.

This morning I updated the link with the latest and greatest.
Tested all keys except F2-F12, will test those once I find my old OSK.exe.

Issue: Comma is not sending a comma, its sending a <. That is direct from harmony, so we can't do anything about that unless someone comes up with a new version.

Esc, Alt, Shift, Capslocks, Windows/Start CNTL were all verified.
1234567890 were all verified
abcdefghijklmnopqrstuvwxyz
!@#$%^&*()_+ were all verified
[]{}\|<>?/ were all verified
F1 was verified.

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

I think that's ok since comma and < are the same keycode. I wouldn't worry about it as long as you're sending hex OBC 36.

I actually use the OSK in Win 10 a lot. Here's a couple of ways to launch it.
https://www.isunshare.com/windows-10/6- ... ws-10.html

I guess the next step is to name this (these) protocol(s) and get it in protocols.ini for the various processors. I have no idea how protocols get named, but "MCE Keyboard" seems as good as any.

mdavej wrote:I think that's ok since comma and < are the same keycode. I wouldn't worry about it as long as you're sending hex OBC 36.

................

I guess the next step is to name this (these) protocol(s) and get it in protocols.ini for the various processors. I have no idea how protocols get named, but "MCE Keyboard" seems as good as any.

No the next step is to figure out how the checksum is calculated.

We have a ton of binary timing sets, which should help. The last 8 bits is some sort of shift flag. When you send !@#$%^&*() you see that the value is always "000000010" for these keys. The next to the last is the keycode which is very straight forward, we have all of those. When the byte before that is always "00000000" again. And the 5 bits before before that is some kind of verfication code. We need some mathy type to figure out how that verifcation code is calculated. We do know that the comma has a weird bit set. I'm just not sure what keycombo would yield that code, but we do have that as another example of how the last byte affects that verification code.

What my part was is to take that checksum and the OBC and incorporate the shift bit and squish it into two bytes of hex to pass as a parameter into the protocol executor.

I squished it, by adding 128 to the OBC and then used the first 3 bits of the verification code to tell me what power of 2 it needs to be.
vvvvv = verifification code
obcobcob = OBC byte for keycode
sssssssss = shiftbyte (1 bit set)

00100,000, vvvvv, 00000000, 0,obcobco, ssssssss

My current scheme doesn't work for the following codes, but really how much do you really want to type with a remote? Although Caps Lock, CTRL, Shift and Alt were all captured. Perhaps the reason that the , is sending out < with a different ssssssss value, is that the other shift key was used when sending it.

Agree, no need to add those.

Vicky, do you have a spreadsheet with all the binary that you know in it?

The Robman wrote:Vicky, do you have a spreadsheet with all the binary that you know in it?

No i have them in all sorts of formats. I have bunch of ict files that wouldn't give me all the signals inside even after padding the last leadout time.

i will put together one cohesive file tonight. Then you math/logic geniuses can have a run at the verification codes.

I relearned most of the keys and did the irscope-decode spreadsheet. I bundled it with the keyboard upgrade, so that anybody that wants to check on my work can find the data there.

The file is rawtimings.txt inside the zip file

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

I have 4 of the 5 checksum bits cracked but have run out of time to get the last one.

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

To see what I'm doing, the rec columns (P thru T) have formula to calculate the checksum and it turns red when the code is right. I'm adding bits together then using the MOD(?,2) function to replicate doing an XOR.

This certainly points out why we want a complete set of learns before we try to crack an IR code.

They didn't make this easy. You need a computer to crack it,

Nice job. It certainly is above my math/logic/eyesight skills.

OK, added the final bit. They really went to town on this checksum. This final bit required me to add 2 to the OBC and then use a bit from THAT binary.

So then can you calculate what the checksum should be for the comma when the final bit is all zeros?