Rogan's IR Keyboard!
This project started a few years ago while in South Africa, at the SensePost offices in Pertoria. Rogan had brought in a box of "Stuff" and wanted to know if anybody had a want or need with any of the items in it, so as you do, you poke around and see whats available.
There was all sorts of things ranging from RF gate openers to random bits of hardware that Rogan had collected over time. I however, spotted a small soft touch keyboard that i liked the look of, and wondered what i could do with it.
So we come to the now and ive got an itch to see whats going on with it...
The History:
This is a InfraRed Keyboard from a little PC based Phone called "TuxScreen", they were built in 1998 and originally sold for $650 USD.
There is some incredible history related to these devices. More can be read here:
http://tuxscreen.sourceforge.net/wiki/view/SomeHistory
The Hardware:
So lets have a look at the hardware and what info we have.
Opening the keyboard we can see the PCB and components used:
So the Electronics tell us this is a SWK-8630N From Sejin Electronics (http://www.sejin.com)
Having a good ganders around the internet really didnt give me much information about this keyboard, or anything assosciated! However, We can tell what certain bits are because there labelled and silly big!
Lets go through each part
SKP-0103Z - Keyboard Controller
40 Pin DIP package Keyboard Controller with PS/2
I couldnt find any info about it but pretty much it would look something like this:
Philips 74HC393N - Dual 4-bit binary ripple counter:
I really dont have a clue what this does, however i "think" it helps translate the P/S2 codes to the IR delivery.
IR:
Infrared radiation is a form of light similar to the light we see all around us. The only difference between IR light and visible light is the frequency and wavelength. Infrared radiation lies outside the range of visible light, so humans can’t see it:
Because IR is a type of light, IR communication requires a direct line of sight from the receiver to the transmitter. It can’t transmit through walls or other materials like WiFi or Bluetooth.
The IR Data:
Because the IR sensor is generally pulled high when active and dropped to low when transmitting we can set a trigger on Saleae Logic to capture the data.
The Logic capture shows just random key presses on the keyboard. Lets see what the data actually looks like.
And here are some details about the signal
So what we are actually capturing is the full data waveform of the Diode while transmitting data.
Next, i wanted to see if the data was the same for each Key Press.
Here are 5 "Enter" Keys pressed with simular time on the down press and up lift of the key.
Lets look at each "Enter" Key press.
We can dig a little deeper here and see each data set in detail.
And this "Could" be something like this.
NOTE: This may be incorrect here, it may be reversed, or it may be wrong all together!
Now, im not 100% sure if this is the truth, but looking at the width of the blank spaces, they are consistent with the width of other data bits. i.e. the width of a "0" bit is 0.794ms, and this width fits perfectly in to the width of the "1" too.
But first, why were there 3 parts to one keypress? Not sure, lets go see...
So what i did here was cut up the 3 key presses and layered them to see if the same sequences were present on each keypress and the same timing. well yes infact they are they same, however depending on the human factor and the fat finger, depends on how long the data stream is!
So where are there THREE transmissions per keypress?
Doing further analysis, i worked out that, the first Data part is the Key down, the second, is Key up and the third i think, is transmission end... im still undecided
If you keep a key pressed, it resends the first data part over and over again.
Now i want to see what i key down on two different keys looks like!
Differentiating Keys:
In this instance i have chosen something simple, the Number "1" Key and the Number "2" Key.
Again each key has 3 parts to it, lets see if we can see a difference
Lets look at the Key Down data transmissions of each key and try to work out what the bits are.
As you can see the first half (12 bits) is exactly the same and the last 12 is different. Now, im not totally sure that it is even a 24 bit stream, im sure ill work it out as i go, but for now, that would make sense (to me at least)
I now want to see if the Key Up is a similar sytle.
And they are, so here is a break down of both key number 1 and 2 key presses!
We can now start to see some simularities between the data each key press has.
For me, right now, the first 12 bits contain key state (key up or key down) and the 2nd 12 bits contain the key code... again i might be wrong here!
Now lets look at the End part of each transmission!
Again we will compare the ending parts of the number 1 and 2 keypresses just to be consistent.
These are exactly the same. Now i dont know if these just signal the end of transmission but they are part of every key press from the keyboard. so for now we will keep that asumption.
So the end of transmission code is:
Key State Key Code
111010100001 111111100000 EOT
Adding Additional Hardware:
Now that we have worked out that the IR is working, what the transmissions look like, we need some way of using the keyboard, else its just another paperweight...
I knew i needed some bits i didnt have in my draws of magic, so i ordered this:
https://www.amazon.co.uk/gp/product/B07BFNGF53
It contains both a IR transmitter and Reciever!
These will be connected to a Arduino Uno for ease
First thing, i wanted to see how and what the IR reciever was taking in and in what format
By hooking the Logic analyser up to the reciever diode i was able to see a decoded IR signal.
A nicer squarewave for sure, and its the same as the "1" Key down press data from the transmitter (without the carrier wave)
In this example i have counted the binary "1" when the signal is pulled low, as i did before.
At this point, i thought, this was going to be easy peasy with the Arduino and the IR libs that are available, however this was not the case..
All the IR Libs i tried, didnt come close to what i was seeing, infact, most saw the same result, no matter what key was pressed!
Using a nice and simple HEX output dump of what is being recieved, each key press has three parts (as we have seen before), however, each keypress data is exactly the same, but... on the Logic view, they are different as we already know.. Something is a miss here!
Looking around, a resource here: https://www.vishay.com/docs/80071/dataform.pdf tells us that there are generally 3 ways of coding data in IR (probably more), does our signal fit any of these?
BI Phase Coding, Pulse Distance Coding and Pulse Length Coding...
One of the signals fits in with "BI Phase Coding", but not all do...
This one doesnt make sense to me.. Back to the drawing board!
My thought process right now is, get the arduino to print out the binary data being recieved from the IR sensor. See if we can get it to match the signal from Logic.
1101010100100110 Key 1 Down
1101010000010011 Key 1 Up
1100100011111110 End TX
So does this make sense to me, no it doesnt at all! These are 16 bit, and they vary all the time with the same keypress, not by alot but they dont repeat every time!
So what we know is:
There are 3 data transmissions per key press!
The IR transmissions are not your generic (widey used) protocols in use.
The IR length of each transmission is 15.6ms long each!
The Last transmission of each key is the same!
24bit IR Encoding methods do exist, But this is non of them!
Continuing the WORK!
After taking a few weeks break on this, i decided to come back to it. One thing that was playing on my mind was the way the Keyboard IR pulses were different to the normal IR encoding methods used.
With this i used Adafruits IR_RAW arduino sketch to see if it could pick up some interesting info. (https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/IR_Sensor/Arduino/Raw_IR/Raw_IR.ino)
With a few tweaks this allowed me to see how many pulses were for each Low and High transition on the decoded IR signal
In the picture above, we can see where the transmission started and how long the PIN was pulled either HIGH or LOW.
Now we know from the Saleae graphs from before that the "Key Down" starts with THREE LOW pulses. So i got to thinking that the first value of 2440ms is equal to the length of "three" LOW pulses, equating to three binary 1's
I confirmed this by looking at the timing of a single LOW pulse (between 820ms and 840ms)
By doing a bit of simple math, 2440 / 820 = 2.97ish (nearly three)
The next thing i noticed was that the HIGH single pulse was quicker than the LOW single pulse. only by about 50ms, so not a great deal.
after messing about with the code (rounded some numbers to the nearest 10, did some division etc) i was able to get a decent and consistent readout of the IR encoding method
This let me print out each key press in binary and see the IR signal as i saw it on the probe!
There are a few additional 0's due to noise (ambiant light)
As the above picture shows, the keypresses are picked up and displayed as per the IR decoding seen earlier.
This is a sucess, with a fair bit of tweaking to the code and defining some structures, i was able to get a clear reading of each key press
The next step is to take each value available from the keyboard and get IR sensor to HID funcationality to be able to use the Keyboard as a Keyboard on ANY computer!
This has been a great Adventure and coding exercise
I have uploaded the project file to Github here:
NoobieDog
Enjoy