Am I missing something obvious??

chameleon_789 · Post by **chameleon_789** » Sun Dec 11, 2005 12:13 am

I've just bought an IRdA keyboard to play around, and possibly write drivers for the PSP..

I couldn't get the IRdA keyboard program that was posted here to work, so I tried Vanya Sergeev's IRdA raw input prog (modifed to press O after every keypress which added some 0's to the file making it easier to read)... but, I can't see any sort of pattern which I'd be able to use to work out what key is being pressed.

Seems like there's 4 apparently random hex digits, followed by C1FFFF, repeated 3 or 4 times depending on how long the key's held. These are the results I got from repeatedly pressing A:

Code: Select all

858D C1FFFF AF1F C1FFFF 3468 C1FFFF
AD27 C1FFFF 83C9 C1FFFF 8C3A C1FFFF 9915 C1FFFF 2638 C1FFFF
BB9E C1FFFF 906E C1FFFF 0F87 C1FFFF
B8F1 C1FFFF 97D1 C1FFFF 2AC8 C1FFFF
B76E C1FFFF 9EAA C1FFFF 089B C1FFFF
AA40 C1FFFF 8C3A C1FFFF 1806 C1FFFF
8879 C1FFFF ACE0 C1FFFF BEEA C1FFFF 036C C1FFFF
B8F1 C1FFFF B9C5 C1FFFF 2D27 C1FFFF

And for B:

Code: Select all

A66B C1FFFF A386 C1FFFF 0E15 C1FFFF
9121 C1FFFF 80C6 C1FFFF 221E C1FFFF
901A C1FFFF AF1F C1FFFF 0909 C1FFFF
9FE5 C1FFFF 83C9 C1FFFF B9C5 C1FFFF 9B65 C1FFFF
A994 C1FFFF 906E C1FFFF 80C6 C1FFFF 221E C1FFFF
BA6C C1FFFF AF1F C1FFFF 0909 C1FFFF

Not much difference between them. The only thing I've noticed is that the last group of 4 hex digits before C1FFFF are usually a much lower value than the first 2 groups. I have a few ideas, alot of the 'randomness' could be down to timing, but I still can't work out a connection between the key pressed and the hex values.

Can anyone can see a pattern or think of anything I might be doing wrong? I've also got some pda drivers, they're in .prc and .sis format, I'd be grateful if anyone in the know could take a look at them and see how they interpret the signals.

http://www.adesso.com/drivers/SK-6688.zip

seventoes · Post by **seventoes** » Sun Dec 11, 2005 9:02 am

Theres a serial port echo program included with luaplayer, try that out maybe? I dont know anything about Ir, but i dont see a patern in those numbers either.

chameleon_789 · Post by **chameleon_789** » Sun Dec 11, 2005 9:21 am

ty, could help a lot.. i'm taking a look now. So far, no luck.. i've seen BA6C C1FFFF AF1F C1FFFF 0909 C1FFFF for B quite a few times, but I've had the same code showing up using S.. not sure what's going on there..

Dr. Vegetable · Post by **Dr. Vegetable** » Sun Dec 11, 2005 9:31 am

Out of curiosity, what keyboard are you using? I ask because I have a Belkin IR PDA keyboard that I had been thinking of doing this with. I had spent about 15 minutes playing with AgoIn's keyboard sample, but got flaky results. I never bothered to try to decode the Belkin output, but have meant to circle back at some point. (Too many projects going on at once!)

Make sure the keyboard is close to the IR port on the PSP, with straight line-of-sight. My IRda keyboard had to be very carefully positioned in order to get anything at all. I think most low-power IRda devices have a range of about 12 inches.

Shine · Post by **Shine** » Sun Dec 11, 2005 10:14 am

Perhaps it is the IrDA Control protocol. You can search Google for the specification.

chameleon_789 · Post by **chameleon_789** » Sun Dec 11, 2005 10:20 am

I'm using this keyboard (although the one I got was branded under a different name, and came with more drivers than the online .zip). It's got two IR ports, one which is adjustable so positioning isn't a problem, the only problem is the cradle doesn't like the PSP :)

Adesso SK-6688

Decoding 'by ear' is more difficult than I imagined, so at the moment I'm trying to decompress the symbian drivers to see if there's any way of getting the keycodes from there.

edit: thanks shine, I read a coule of specifications but I think the irda control protocol is built in, the psp just transmits/recieves data packets from it.

Dr. Vegetable · Post by **Dr. Vegetable** » Sun Dec 11, 2005 6:01 pm

I am not familiar with Vanya Sergeev's program, but I have modified Shine's IrDA sample to operate as a simple hex display of raw IrDA data. You can download the program (with source) from here:

IrDAmon.zip

Using this program, I am getting fairly predictable results with my Belkin keyboard. I get 4 bytes per key-down and another 4 per key-up. It seems that the keyboard is sending raw scan codes, as the values sent do not seem to be affected by holding down the Shift key, etc.

Next I will map out the scan codes to see if I can make a simple text input program for this keyboard. Hopefully, we can eventually incorporate support for all of the commonly-available PDA keyboards in any driver that might get written.

As this is my first published homebrew application, I welcome any feedback.

UPDATE:
Ok, I'm on a sleepless roll. I mapped out the scan codes for the Belkin keyboard, and wrote a simple typing program. This is just a quick-and-dirty application that doesn't support backspace, delete, or arrow keys, and simply echoes keystrokes to the screen. It does track the state of the Shift and Caps Lock keys, although it doesn't handle Shifted Caps Lock combinations correctly at all. The table in this program contains the codes for all keys and buttons on the keyboard, although some are not supported (or even scanned for) by this program.

The keyboard is made by Belkin, Model No: F8U1500-E, and is available at Staples for about $60. It is a fairly decent design, the keyboard folds in half and includes a PDA stand that does a nice job holding the PSP. The stand has a metal reflector that can (and must!) be carefully positioned to mirror the IR from the keyboard into the PSP's IrDA port. Once you get it adjusted, the comms are reasonably reliable.

You can download the application (with source) at:

IrDAtype.zip

I have not yet attempted to incorporate this into AgoIn's Keyboard Demo application, although the basic concept is the same. Although I haven't looked at his source code in awhile, I wouldn't be surprised to find out that my code is very similar to his. I seem to recall that somebody made a library out of his program, so I'll see if I can find that and add what I have learned.

I did notice that at times, the PSP would start receiving a stream of random crap, depending on how I positioned the keyboard and PSP. I think there is some form of IR interference around here, either off my desk lamp, or perhaps off my laptop computer. I am pretty sure that my laptop doesn't have an IrDA port, but sometimes those things are easy to overlook!

Again, any comments or suggestions are welcome.

EDIT:
Apologies to Vanya Sergeev, who wrote the original IrDA program upon which Shine based his program, upon which I based my program...

Also not sure why I thought AgoIn wrote the keyboard demo. The demo I was referring to was actually written by Tim Underwood.

EDIT #2:
I found a stupid mistake in the original program that limited the rate of input from the IrDA serial port to one byte per vsync, which limited the program to receiving about 15 keystrokes per second, max. (Keyboard input would slowly trickle in if you typed faster.) The link above now points to the updated project that processes all available IrDA bytes, for immediate keyboard response.

chameleon_789 · Post by **chameleon_789** » Tue Dec 13, 2005 10:28 am

Nice code :) Being a beginner, I've learnt quite alot from looking through it. Using your IrDAMon, I was able to out some more about the scan codes from the SK-6688 (enough to map the A-Z 0-9 keys) :

-Each code is 2 bytes long.
-For each key, there are 16 unique keydown and 16 u.nique keyup codes, making a grand total of 32(!) unique codes for each key (the codes can be in any order, a single keydown code can be follwed by any of the keyup codes).
-While the key is held, a keyhold code is transmitted, which can be any one of 16 codes (not bound to a specific key).
-In between codes the 3 byte 'endcode' 0xC1FFFF is sent.

Code: Select all

-Keyhold &#58; > 0x8000 and < 0xC000 &#40; I have these mapped &#41;
-Keydown &#58; > 0x8000 and < 0xC000 
-Keyup   &#58; < 0x4000

Normal keypress would look something like this&#58;

* keydown|endcode|&#40;keyhold|endcode&#41;xN|keyup|endcode *
* 99B3   |C1FFFF |A386    |C1FFFF    |0F87 |C1FFFF   *
&#40;N is the length of time you hold down the key&#41;

each code is 5 bytes long, each keypress is a minimum of 15 bytes and a multiple of 5.

My plan is to map all of the 16 keydown/keyup codes to one 1 byte code. This would make it much, much easier to map the keys. (there's 63 keys on the keyboard, one byte should be more than enough). Once the 'typing' program is done, I should be able to ignore the keycodes inbetween.

I'll updatate progress at a later date, as I don't have much time on my hands for programming. For now the major hurdle is mapping the actual keycodes.. all 2016 of them :|

chameleon_789 · Post by **chameleon_789** » Tue Dec 13, 2005 10:46 am

On another note... I actually emailed the makers of the keyboard asking for the specifications of the data transmissions. I got a reply saying they are "the most secret & important property" and "We are not allowed to release them as we need to protect our software"... ironic I worked it out like 2 hours before I got their reply :D

If a beginner can work it out in the time it takes to send that reply (literally a couple of hours of my spare time over two days), why not just send the codes? lol..

Dr. Vegetable · Post by **Dr. Vegetable** » Tue Dec 13, 2005 10:50 am

Great! Glad to hear things are starting to make sense.

That is kinda messed up that they use 16 different codes for each keydown. I suspect that there is some obscure pattern to the set of codes used for a key, and if you can decode it, you'll save a lot of brute-force effort. If you have a chance to post some examples of all sixteen codes for a few keys, I'll take a stab at figuring it out.

I made this post in the PSPSDK forum to ask if anyone has thought about creating a standard library to easily add IrDA keyboard support to homebrew apps, but no response so far. I am thinking that it might make sense to see if we can add keyboard support to the p-sprint keyboard emulator library. Maybe the library could check for a keymap.dat file in a standard location on the memory stick, and use the specified IrDA keyboard, if any, instead of (or in addition to) the PSP button combinations.

Anyway, keep on plugging, and good luck!

dot_blank · Post by **dot_blank** » Tue Dec 13, 2005 11:46 am

this is becoming interesting ;)
i look forward to see if people
around the world can get this list
of irda keyboards and what they signals
are ....and making a keyboard driver
is very much needed and very interesting work

Dr.V: great source :) ...i have similar keyboard :D
you can find great prices for some wireless
keyboards at this link http://wireless-keyboard.com/c/1497/Hom ... index.html
works just fine and i like the legos!!
especially this silly guy right here
http://drvegetable.com/images/throttle.jpg

;) cheers

Dr. Vegetable · Post by **Dr. Vegetable** » Tue Dec 13, 2005 1:25 pm

Good links! (I assume these all lead to eBay listings?)

These links appear to be the same keyboard that I am using:
Belkin Wireless Infrared Keyboard ($18.99 starting bid)
BELKIN Wireless PDA Keyboard F8U1500 Works w/Most PDAs ($9.99 starting bid)
Belkin Wireless PDA Keyboard ($15.95, reserve met)

I actually got mine on sale at Staples for $35, but the normal price is just under $60. There are a few other IrDA keyboards on this list that would be nice to support as well.

One thing that would need to be thought out a bit is support for international character sets. My sample program only handles 7-bit ASCII. With a little bit of work, it should really be able to read a configuration file to map scan codes into unicode characters for true worldwide appeal.

Glad you noticed my LEGO stuff. The same things that draw me to hacking the PSP were what originally attracted me to the LEGO hobby. I am hoping at some point to do a few projects that incorporate both interests.

EDIT:
Actual price for the Belkin keyboard at Staples is just under $60, not $70 as originally reported.

chameleon_789 · Post by **chameleon_789** » Wed Dec 14, 2005 1:59 pm

As requested, here are the hex codes for a couple of keys.

I couldn't see a connection betweeen them myself, but there must be some sort of pattern, it doesn't make sense that they'd store multiple codes for each key. There are also some anomalies to the normal formula, B seems to only have 15 codes for keydown, and some keyup codes are >0x8000.

Code: Select all

Key	Keydown	Keyup
A		
	858D	036C
	8682	0470
	8879	0F87
	8B76	0F97
	920C	15FD
	9777	16F2
	99B3	1806
	9CC8	1B09
	A1BE	21D7
	A6D9	2638
	AA40	2AC8
	AD27	2D27
	B401	3468
	B76E	3701
	B8F1	39F6
	BB9E	3A9F

S		
	84E0	01EA
	87EF	06F6
	8810	0E15
	8B1F	0E15
	901A	117E
	9121	1271
	9EDE	1E81
	9FE5	2111
	A50D	2DE1
	A66B	2EEE
	A994	302B
	AAF2	3514
	B593	3514
	B69C	3AEB
	B963	85E1?
	BA6C	9B65?

D		
	8420	01C8
	872F	06D4
	88DF	0B23
	8BD0	0C3F
	91E2	11BB
	94DD	12B4
	9A19	1D44
	9F26	1E4B
	A5EC	21ED
	A60B	2212
	A975	2D1D
	AA92	2EE2
	B14C	30A6
	B283	33CF
	BDBC	3D51
	BE73	3E38

B		
	851D	05A3
	8612	0B4C
	89E4	0C50
	8AEB	114E
	9001	1241
	977E	1DBD
	99BA	1EB2
	9EC5	25FE
	A06E	2631
	A799	290E
	ACF7	369F
	B56F	3A69
	B690	841C
	B99F	88E5
	BA60	9D3A?
	----	BED0?

Also it's probably worth mentioning the way the codes are ordered. In the table I've sorted them in numerical order, but the actual codes are outputted in sequential order if the key is held for the same amount of time, like this :

Code: Select all


A Keypress &#58;

|keydown| keyhold |keyup|
8879	ACE0	15FD	
A6D9	8F35	1B09	
8B76	A079	16F2	
920C	B21A	0470	
99B3	B535	21D7	
9CC8	BEEA	036C	
9777	B9C5	2D27	
8682	A386	3701	
A1BE	80C6	39F6	
858D	AF1F	3468	
AD27	83C9	3A9F	
B401	9915	2638	
BB9E	906E	0F87	
B8F1	97D1	2AC8	
B76E	9EAA	089B	
AA40	8C3A	1806	
8879	ACE0	15FD	-repeats here
A6D9	8F35	1B09	
8B76	A079	16F2	
920C	B21A	0470	
99B3	B535	21D7	
9CC8	BEEA	83C9	3A9F	-sequential order is messed up here
8B76	9915	2638	
920C	906E	0F87	
99B3	97D1	2AC8	
9CC8	9EAA	089B	
9777	8C3A	9915	ACE0	906E	0F87
B8F1	97D1	2AC8	
B76E	9EAA	089B	
AA40	8C3A	B535	21D7	
BB9E	BEEA	036C	
B8F1	B9C5	2D27	
B76E	A386	B21A	80C6	B535	21D7	
9CC8	BEEA	036C	
9777	B9C5	2D27

If anyone can see some sort of connection it'd be much appreciated.

pspvideo9 · Post by **pspvideo9** » Thu Dec 15, 2005 7:39 am

We're curious, do you see any lag when printing characters to the screen from your IR Keyboard at high wpm rates?

Dr. Vegetable · Post by **Dr. Vegetable** » Thu Dec 15, 2005 8:09 am

On the Belkin keyboard, yes. If I type a bunch of keys, the data seems to trickle in. I haven't measured the maximum rate, but that could be added to my sample program pretty easily, I am sure.

Speaking of the sample program, it is possible that I am doing something foolish that would artificially limit the rate of input.

pspvideo9 · Post by **pspvideo9** » Thu Dec 15, 2005 8:22 am

We are seeing such lag on our ThinkOutside IR Keyboard as well.

The odd thing is, for us, the lag isn't in the keyboard. We can quickly type out a sentence, then move the PSP away from the IR keyboard sensor, and the _all_ the data ends up being displayed but only at a "trickle".

From our investigation, the sceIoRead is causing some unknown delay, because clearly all the IR data is getting to the PSP in near-real time.

Do you get the same such results with your keyboard?

Dr. Vegetable · Post by **Dr. Vegetable** » Thu Dec 15, 2005 8:34 am

Yes, I get the same results. I can type a bunch of stuff (or run my finger across the QWERTY... row) and then move the keyboard out of line-of-sight. The correct characters continue to trickle in.

Are you using my program, or something else? I ask because this was a quickly thrown together app, and it could be written incorrectly. It sounds like you have isolated the trickle to the firmware, though...

pspvideo9 · Post by **pspvideo9** » Thu Dec 15, 2005 10:30 am

I was hoping it wasn't the firmware, looks like thats the culprit. It seems like there is some sort of internal buffering going on, which is totally odd since the PSP reads the IR data in real time.

Nope, I'm not using your program. I'm using my own code to read in characters from my ThinkOutside IR keyboard.

Dr. Vegetable · Post by **Dr. Vegetable** » Thu Dec 15, 2005 8:54 pm

Ok, thanks for the added info. I'm usually more relieved to find that the bug is not in my code. :) Are you planning to publish the keycodes so that we can incorporate them into the upcoming library?

chameleon_789: I haven't had a chance to play with the keycodes you posted yet, but will try to do that today. But I am surprised that any hardware manufacturer would guard their protocol so closely. After all, getting people to support their hardware on other platforms can only help their sales. Why they would think any of their competitors would want to copy such an overly complicated protocol is beyond me. Maybe if you explain to them what you are doing and how it could benefit them, they might loosen up a little? If that doesn't work, ask to speak to a manager until you get someone who doesn't have their head up their ass...

Shatterdome · Post by **Shatterdome** » Tue Dec 20, 2005 10:03 am

I'm not sure if the is an sceIoPeak function ?

I know when reading keys from the psp if you use sceCtrlRead it is slow, but if you use sceCtrlPeak it reads keypresses real time...

dot_blank · Post by **dot_blank** » Tue Dec 20, 2005 12:24 pm

sceCtrlPeekBufferPositve is best for use
in inputs that require realtime input ...ie..at the
rate of 60hz ....i think thats pretty fast enough ;)

Dr. Vegetable · Post by **Dr. Vegetable** » Tue Dec 20, 2005 10:23 pm

Good tips! I will try this out when I have a moment.

I haven't had much time to work on this project the past several days, but (as previously mentioned) I would like to incorporate this into p-sprint. I will try to support any keymaps that are documented, and hope to help chamaleon_789 decode that oddball keymap as well.

I'll have more time to work on this next week.

user303 · Post by **user303** » Wed Dec 21, 2005 4:14 am

I have converted the codes to binary and tried to see if I could discover some sort of pattern but all I came up with was the obvious.

Code: Select all

KD	 KP	   KR		    KD			              KP			     KR
8879	ACE0	15FD		1000100001111001	1010110011100000	0001010111111101
A6D9	8F35	1B09		1010011011011001	1000111100110101	0001101100001001
8B76	A079	16F2		1000101101110110	1010000001111001	0001011011110010
920C	B21A	0470		1001001000001100	1011001000011010	0000010001110000
99B3	B535	21D7		1001100110110011	1011010100110101	0010000111010111
9CC8	BEEA	036C		1001110011001000	1011111011101010	0000001101101100
9777	B9C5	2D27		1001011101110111	1011100111000101	0010110100100111
8682	A386	3701		1000011010000010	1010001110000110	0011011100000001
A1BE	80C6	39F6		1010000110111110	1000000011000110	0011100111110110
858D	AF1F	3468		1000010110001101	1010111100011111	0011010001101000
AD27	83C9	3A9F		1010110100100111	1000001111001001	0011101010011111
B401	9915	2638		1011010000000001	1001100100010101	0010011000111000
BB9E	906E	0F87		1011101110011110	1001000001101110	0000111110000111
B8F1	97D1	2AC8		1011100011110001	1001011111010001	0010101011001000
B76E	9EAA	089B		1011011101101110	1001111010101010	0000100010011011
AA40	8C3A	1806		1010101001000000	1000110000111010	0001100000000110

Maybe someone else can make some sense of it.

Dr. Vegetable · Post by **Dr. Vegetable** » Wed Dec 21, 2005 6:14 am

Playing with various bitwise logical operators for about 15 minutes, I am starting to see some patterns emerge from this data. The only clear pattern so far is that, if you take the keydown codes for any given letter and XOR them together, every fourth entry will result in a zero.

Code: Select all

#include <stdio.h>

int main&#40;int argc, char* argv&#91;&#93;&#41;
&#123;
   // Keypress codes for "A"
   unsigned int a&#91;&#93; =
   &#123;
      0x858D, 0x8682, 0x8879, 0x8B76,
      0x920C, 0x9777, 0x99B3, 0x9CC8,
      0xA1BE, 0xA6D9, 0xAA40, 0xAD27,
      0xB401, 0xB76E, 0xB8F1, 0xBB9E,
   &#125;;

   unsigned int x = 0;

   for &#40;int n=0; n<16; n++&#41;
   &#123;
      x = x ^ a&#91;n&#93;;
      printf&#40;"%04X\n", x&#41;;
   &#125;

   return 0;
&#125;

Results in the following output:

Code: Select all

858D
030F
8B76
0000
920C
057B
9CC8
0000
A1BE
0767
AD27
0000
B401
036F
BB9E
0000

This pattern holds true for the keydown codes for all keys that you supplied. If I apply this logic to your table for B, it seems that the last missing code should be 0xAB00.

I haven't tried any masking or bit shifting operations yet. I assume that some combination of bitwise operators applied to any given keycode will result in a constant value for each key. Just thought I'd mention this pattern in case anyone else is looking at this...

ironlung · Post by **ironlung** » Wed Dec 21, 2005 8:26 am

thanks to everyone in this thread - it seems like progress has been made in the right direction! I still have my Adesso KB in hopes of someday putting it to good use on the PSP.

btw- I'm startled at the prices going UP - I bought mine for $12 or $15 new at geeks.com - now I can't even find my KB on Froogle...

I am glad that Dr. V made a post in the dusty, cobwebbed IR Keyboard thread from 6 months ago so I could see what's goin' on.

[finds comfortable spot to lurk]

Dr. Vegetable · Post by **Dr. Vegetable** » Wed Dec 21, 2005 12:03 pm

Yeah, if I'd been paying closer attention, I would have realized that chameleon_789 posted a link to that dusty old thread in his first message of this one. While I'm cross-linking threads, here are two others that are relevant to this topic:

http://forums.ps2dev.org/viewtopic.php?t=2685
http://forums.ps2dev.org/viewtopic.php?t=2604

Anyway, I am on vacation from now into the new year, so hopefully I'll be able to devote some energy to the multitude of PSP projects that are piled on my plate.

Arwin · Post by **Arwin** » Wed Jan 04, 2006 11:50 pm

Ok, Dr. Veggie, I'm on standby when you pick this up. I'm about ready to do some more work on p-sprint, after having worked my arse off for a project at work.

Dr. Vegetable · Post by **Dr. Vegetable** » Sun Feb 12, 2006 12:58 pm

I've been working on integrating my IrDA keyboard code into Arwin's p-sprint library, and making decent progress so far. I am trying to make it easy for people to add support for other keyboards. For now this will require writing a little C code to parse the keyboard's input stream. Eventually it might be possible for a user to train the system to recognize almost any keyboard, but not yet.

In the course of doing this, I took another look at my IrDAtype sample program and realized that I made a rookie programming mistake that was causing the slow keyboard response that I reported earlier.

Dr. Vegetable wrote:Yes, I get the same results. I can type a bunch of stuff (or run my finger across the QWERTY... row) and then move the keyboard out of line-of-sight. The correct characters continue to trickle in.

Turns out I was only reading one byte from the IrDA port for every vsync! This limited my program to receiving only 60 bytes per second, which resulted in a maximum input rate of 15 keystrokes per second into the sample application. I have fixed the problem and now the onscreen echo of keystrokes is instantaneous. (The updated sample program is available at the original link.)

So, pspvideo9, I suspect something like that is to blame in your situation as well?

Am I missing something obvious??

Am I missing something obvious??

IrDA Monitor Program