Solidtek Ack-571 keyboard A,Q,S,space & esc keys

[Teks]

I am using the Solidtek ACK-571 IR Keyboard_KM.txt file
with RM, IR and a URC8910. All is good except a few keys that are not working for me and or missing. I was able edit and replace the old hex value for the <ESC> key. I also added the missing <SPACE> key and hex value.. both are working now. The 6C 90 Space, 60 60 Escape hex settings where found in this great thread. Three keys remain that I know of that are not working (they are also mentioned in the same post) the A, S and the missing Q key. It would be nice to have all the keys working and the Solidtek ACK-571 IR Keyboard_KM.txt updated. I'd hate to see Jon's great work fall by the wayside.

Is this the best and most current file for the solidtek ack-571 keyboard? Maybe the final slipped through the cracks.. member Nad might know.

Anyway...

After updating decode_ir.dll RM is able to decode my learned A Q S keys and give me a OBC value. Tried these values as is but they don't seem right.. no luck. Here is my learned AQSKeys IR file maybe someone can take a look.

[xaust]

OK, I finally had to break out the Johnny Quest secret decoder ring on this one. I actually had to reverse engineer some of the existing keys that were working correctly. Also I figured out that you use the "Misc" values from DecodeIR.

Here are the OBC codes that are working for me:

A = 04 40
Q = 08 80
S = 84 C0

I will tell you the secret decoding trick for this device but then you have to promise you will erase it from your memory and disavow any knowledge of it. You take the last three of the four "Misc" chars of subdevice 0 for the learned key and you flip the bit order for each one. The "Misc" chars are output from the DecodeIR.dll in IR on the "Learned Signals" tab. You must be using the latest dll for this keyboard (figured that out on trial number 6237).

So for example, using the "S" key.
DecodeIR spits out this "Misc" value for this learned key:

0 1 2 3

Throw away the 0.
The 1 (0001) flips to 8 (1000).
The 2 (0010) flips to 4 (0100).
The 3 (0011) flips to C (1100).

This yields an OBC code of "84 C0".

Who/how do we update the KM.txt file?

[xaust]

I have uploaded an updated KM file for this keyboard here.

The changes for this version are:

Added Q and Space keys.
Fixed the A, S and Esc keys.
Updated the Protocol def to v3.11.

[The Robman]

Do the following buttons really work in this upgrade:
F2,
left alt,
left shift

I ask because the 2nd byte doesn't look right. I just took a look at the hex codes used for this upgrade as you got me curious with your post. First off, as you seem to already have figured out, this is an LSB protocol (which means you have to read the binary backwards).

Only 4 bits appear to be used in the 2nd byte, the remaining bits are all zeroes. You can calculate the first 4 bits by adding the left and right nibbles of the 1st byte together (keeping in mind that this is LSB, so you would need to reverse the bits in order to do the addition, then reverse the result).

I have created a spreadsheet that demonstrates this...
http://www.hifi-remote.com/forums/dload ... le_id=2388

Looking at the spreadsheet, you'll see that it kicked out those three buttons as not following the formula.

I think the correct hex codes for those buttons are:
10 10 F2
FA 20 left alt
70 70 left shift

So, if the buttons don't work, try replacing the hex codes with those values and see if that fixes it.

[xaust]

Great feedback Rob - thanks. I will take a look, test, and create a new KM file. It will take me a day or so to get to this.

Anyone know of any other misses for this keyboard?

[xaust]

I just updated the KM file here.

What I found is that the correct OBC codes are the following for these keys:

F2 = 11 00
Left Shft = 71 60
Left Alt = FB 30

It appears that there was a transcription error in the first pass of the KM file.
These three key code updates are the only change from V2 to V3 of the KM file.[/url]

[xaust]

Well my bad. The codes I used for the F2, L-shft and L-alt keys worked but were not reliable. I changed them to Rob's recommendation above and they are better. What tipped me off is that my OBC's had an odd first byte, e.g. 71 as opposed to 70 for the L-shft. No one had downloaded my V3 rev of the KM file yet so I simply replaced it with my updated version.

The V3 version of the KM file (here) now has these key defs:

F2 = 10 10
Left Shft = 70 70
Left Alt = FA 20

That's it - I'm done unless someone finds some other problems.

[The Robman]

If I get the time (and I remember) I'll re-write the protocol for this so you won't need to specify the 2nd byte. I'll mean a slightly larger protocol upgrade, but a much smaller device upgrade.

When I do it, will you be up for testing it?

[xaust]

Yep - I would be happy to give it a try.

One thing though - once in awhile a key press on the remote will cause the key to get "stuck" on the receiver and it will repeat until I press another key. This is tolerable but it would be nice if it did not do that. The actual keyboard does not do this, only the remote. I suspect it has something to do with the timing in the protocol. I would be interested if anyone else is seeing a similar problem with this keyboard.

[The Robman]

Can you do me a favor, can you learn some short presses of the keyboard buttons and post the results. In other words, don't hold the keyboard button down as you would normally do when learning a button.

[xaust]

I only have a URC-6131.

Hopefully someone else with the Solidtek ACK-571 keyboard and a learning remote can reply.

Perhaps some of the IR files in this post and one other in this forum will suffice?

[The Robman]

I have created a PB file based on the protocol that's in your KM file here:
http://www.hifi-remote.com/forums/dload ... le_id=2400

I then modified it so that it should calculate the 2nd byte and that version is here:
http://www.hifi-remote.com/forums/dload ... le_id=2401

I then went a stage further and had it recalculate the break code:
http://www.hifi-remote.com/forums/dload ... le_id=2402

So, to use the V2 or V3 versions, you need to strip the 2nd byte of the code out of your KM file. I have done that in the following KM file:
http://www.hifi-remote.com/forums/dload ... le_id=2403

So, if you use the V4 KM file with the V2 protocol code, the signals generated should be the same as what you currently get.

If you use the V4 KM file with the V3 protocol code (which is the code in the KM file) the BREAK signal might be different on occassion, which might fix the problem you experienced where you need to press another button to stop the device responding.

[xaust]

I tested the V4 KM file with the built-in V3 protocol code. The keys are working fine. The key repeat problem still remains though. Thanks for the attention to this device Rob!

[The Robman]

Is the key-repeat problem limited to certain buttons? And if so, which ones? The implication there would be that the BREAK signal is not being calculated correctly for those buttons, while it is being calculated correctly for all the others.

Armed with that info, the next step would be to search through all of those other threads and see if anyone has included learns for those buttons, and more importantly, see if they've included short-tap learns. Could you do this?

Alternatively, once you've identified the buttons, we could try pinging Teks to see if we could get him to learn them.

In the meantime, you could just program macros for those buttons where you follow the problem button with another button that doesn't do anything important, just to cancel it out.

[Teks]

Hey guys, thanks for all the effort.. I like to think this is a big part of what the JP1 forum is all about.

As for keys repeating I'll have to check into it a bit more. If you need any ack-571 learned keys I'm your man.