USB-UIRT with JP1 codes

[emptythoughts]

Hello all, Hopefully you can help me because I've been trying to figure this one out for a little while now with no luck. I have a USB-UIRT and i'm trying to get it to send the keys for my SolidTek (ACK-571U) keyboard. I noticed that someone had written the protocol for it on these boards and was wondering if there's any way to use that with the usbuirt instead of a remote.

I was able to learn some pronto codes using some software from their site, but when i send them it types 4 of the letter ( ie// I send x and xxxx shows up) instead of just once.


TIA,

[vickyg2003]

Hello all, Hopefully you can help me because I've been trying to figure this one out for a little while now with no luck. I have a USB-UIRT and i'm trying to get it to send the keys for my SolidTek (ACK-571U) keyboard. I noticed that someone had written the protocol for it on these boards and was wondering if there's any way to use that with the usbuirt instead of a remote.

I'm a little unclear, was it the USB-UIRT that you found a protocol for, or was it the SolidTek keyboard?

I was able to learn some pronto codes using some software from their site, but when i send them it types 4 of the letter ( ie// I send x and xxxx shows up) instead of just once.

So you have some pronto codes from "their" site, that is sending 4 repeats where you want to have only 1.

Who are they?

We can tweak the number of repeats in the pronto hex.

We can generate pronto hex for you.

Exactly what are you asking for?

[emptythoughts]

lol, sorry for being unclear i'm a little tired and wasn't really sure how to word my question.

the protocol i found was for the solidtek keyboard.

they and their site are are the usbuirt homepage and the developers section.

yes the problem is that it's repeating 4 times when i want it to only repeat once.

If I understood how to tweak the pronto hex to only repeat once or generate proper hex with the same result that would be exactly what i'm looking for.

Thanks for the quick reply, I really appreciate it. hopefully i'm a bit more clear time.

[The Robman]

could you post the pronto hex that repeats 4 times, or post a link to the site where you found it.

[emptythoughts]

here's the hex i'm sending:

0000 006B 0000 000E 0044 002E 0010 0018 0010 0018 0010 0018 0010 0018 0022 0018 0010 0030 0010 0018 0010 0018 0022 0030 0010 0018 0022 0030 0022 0030 0022 0107

i'm using the program on this site to learn the code:
http://sourceforge.net/projects/uirt-j/

[vickyg2003]

Rob, would this would be the sent once version of that hex?
0000 006B 000E 0000 0044 002E 0010 0018 0010 0018 0010 0018 0010 0018 0022 0018 0010 0030 0010 0018 0010 0018 0022 0030 0010 0018 0022 0030 0022 0030 0022 0107

[emptythoughts]

just tried it, repeated 4 times still

[vickyg2003]

Hmm, The hex I posted should be sending one frame instead of continuously while held.

I looked at that source forge tool, but of course I have no USB-UIRT so it does't like that, but what value are you putting in for the repeat?

Or is there a control like a LIRC file being produced?

[emptythoughts]

i've tried putting 1 & 2 in the repeat same result with both. I tried a couple of different wait times as well. repeat has to be at least 1 or it doesn't send.

Not sure exactly what you mean by the LIRC file, but no files are modified/created when I send.

[vickyg2003]

When I play with the pronto hex its decoding as SolidTek16. Rob has often written about how keyboard protocols have a release frame and your mention of a reading about a custom protocol for the keyboard seems to indicate that this might be the problem. There is no release frame in this pronto hex. I am wondering if the tool that you were using to capture the pronto hex isn't capturing the release frame, so the SolidTek is thinking the key is being held even if its not being held.

I went and found our upgrade. The v6 version said it had a fix for the "sticky key problem".

When I captured the signal from the upgrade, it showed 1 frame like yours, and then 2 release frames.

Our tools want to break this into two pieces of pronto hex. I'm not sure how to combine these by hand, but some of our pronto experts will know.

I think the missing release frame is causing a "sticky key problem".

If someone can show me how to combine these I'd do the rest of them.

Protocol=Solidtek16 Device=0.0 OBC=1 (Pronto from signal)
0000 006D 0010 0000 0045 002C 0012 0017 0012 0017 0012 0017 0012 0017 0024 002F 0012 0017 0012 0017 0012 0017 0012 0017 0012 0017 0012 0017 0024 002F 0012 0017 0012 0017 0024 15EF
Protocol=Solidtek16 Device=0.1 OBC=1 (Pronto from signal)
0000 006D 0000 0010 0045 002D 0012 0017 0012 0017 0012 0017 0012 0017 0024 002E 0012 0017 0012 0017 0012 0017 0012 0017 0012 0017 0024 0018 0012 002E 0012 0017 0024 0018 0012 0139

[3FG]

Vicky,
I think we can make use of Barf's IrpMaster here.

If you put the following into a batch file e.g. solidtek.bat, and put this batch file into the IrpDirectory, and run it, it should write all 127 possible OBCs into a file imaginatively called foo.bar.

Here for example is obc 32 "A"

Code: Select all

0000 006D 002E 0000 0045 002E 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0024 002F 0012 0018 0012 0018 0024 002F 0012 0018 0024 1552 0045 002E 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0024 002F 0024 002F 0024 002F 0024 0018 0012 1552 0045 002E 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0024 002F 0024 002F 0024 002F 0024 0018 0012 1552

I used a lead out similar to the one you learned.

java -jar IrpMaster.jar -p -d 1 -o foo.bar -i "{38k}<-624,468|468,-624>(S=0,(1820,-590,0:1,D:4,F:7,S:1,C:4,1:1,-143m,S=1)3) {C= F:4:0 + F:3:4 + 8*S } [D:0..15, F:0..127, C:0..15]" D=0, F=*
BTW, this should only work for device 0, if I read the DecodeIR source code correctly. Other device numbres won't have the check sum calculated correctly.

[vickyg2003]

Vicky,
I think we can make use of Barf's IrpMaster here.

Thanks Dave it looks pretty good. In the learns I got from the upgrade, the 2 release frames didn't have that large gap. They looked more like this

0000 006D 002E 0000 0045 002E 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0024 002F 0012 0018 0012 0018 0024 002F 0012 0018 0024 1552 0045 002E 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0024 002F 0024 002F 0024 002F 0024 0018 0012 0139 0045 002E 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0012 0018 0024 002F 0024 002F 0024 002F 0024 0018 0012 1552

Hopefully we'll hear from emptythoughts that this hex fixes the repeating problem.

I know I said I'd do the rest, but I'm afraid of IRPMaster..... Maybe I'll drop out of this thread and let you take care of it. Thanks again.

[emptythoughts]

that hex works! I was able to generate the rest with irpmaster as instructed and those ones seem to work as well. Thanks for all the help guys/gals, you're the best!!!

[vickyg2003]

Now I'm embarrassed for being afraid of Irpmaster, when a newbie could follow the directions and get it working. What is even worse is that I'm still frightened.

Congratualtions

[3FG]

The leadout of all three frames is 143 mSec, so the total time per command is close to a half second. If that's too slow, you could try reducing it.

Vicky's learns have only 2 mSec following the terminating frames, and this suggests that a shorter time may work. 2 mSec is very short compare to most IR signal leadout times, so I wonder if it will work with all keyboards.