Step 6: How It Works


The basic idea is that there is a one-to-one mapping between pressing a button on your remote control and a key combination sent to your PC. IRK! simply teaches your learning remote a code that represents a particular key combination. Once you have programmed that code onto one of your remote buttons, pressing that button will transmit the code back to IRK! which will, of course, recognise it then send it to the PC as a USB keystroke.

Because IRK! generated the IR code, it can't possibly not recognise it - so IRK! does not need to support a zillion different IR remote control models!

USB Keystrokes

USB keystrokes are sent to the PC using codes defined in the USB Human Interface Device (HID) Usage Tables specification. That specification defines, for example, that code 0x04 means the letter "a". For a keyboard device, like IRK!, additional "modifier" codes can be sent to the PC to indicate whether the GUI (aka Windows key, Apple key, Super key), Control, Alt and Shift keys are also "pressed". For example, to send an uppercase "a", IRK! sends 0x02 (meaning Shift is pressed) and 0x04 (meaning "a" is pressed). The computer interprets that sequence as meaning uppercase "A". Immediately after sending that sequence, IRK! will send a "null" sequence of 0x00 and 0x00 to indicate that no key or key modifiers are currently being pressed. This is required by the USB protocol otherwise the PC will think you are holding down the Shift and "A" keys until it receives the next USB key code.

So, you can see that IRK! only has to be able to "teach" a learning remote control a sequence of 0x02 followed by 0x04 to represent the letter "A". When the user presses that button on the remote, IRK! will receive it using its infrared receiver and then send the 0x02 0x04 sequence to the PC which will be interpreted as the user pressing Shift+A on a USB keyboard.

Infrared Command Format

IRK! only recognises infrared signals that are addressed to a particular IRK! unit. To achieve this, an address byte is also sent/received on the infrared path. Each infrared command is a sequence of six (6) bytes as follows:

AA, AA', UX, UX', YY, YY'


AA is the address byte from 0x00 to 0xFF
AA' is the inverted address byte (all the ones converted to zeroes and vice versa)
UX is the usage page (U = 0x0 to 0xF) and, for the Keyboard usage, modifier nybble X (Control, Alt, Shift)
UX' is the inverted UX byte
YY is the command byte (for Keyboard usage, the USB key code)
YY' is the inverted command byte

The reason for transmitting an inverted copy of each byte is to reduce the chance that interference has caused an invalid command to be received. For example, you wouldn't want your request to "play this recording" to be interpreted as "delete this recording" just because a fly interrupted the infrared signal path in that instant!

To validate each command as it is received, IRK! checks that AA (inverted) equals AA', and that UX (inverted) equals UX', and that YY (inverted) equals YY', and that either AA equals this IRK!'s device address or AA equals 0xFF (the broadcast address). If all of the above is true, then IRK! can be fairly sure that it is a valid command and will act upon it.

Infrared Transmission Technique

IRK! uses Pulse Width Modulation (PWM) to encode the series of 1's and 0's that constitute each command. You could reprogram the microcontroller to use a different technique such as Manchester Encoding but PWM works just fine. For example, the USB '1' key when encoded using PWM looks like the image above.

Whenever the signal is "low", an IR burst of pulses at 38 kHz is being transmitted. Conversely, when the signal is "high" it represents a period of silence.

There is a leading burst for 1000 μs then silence for 600 μs (in versions of IRK! prior to 2.04, it was 9400 μs and 4500 μs respectively). This leading burst was required by older infrared receiver modules to "train" their Automatic Gain Control (AGC) circuits so that they could determine what a normal signal level was. Today's IR receivers don't usually have this requirement, but your learning remote may be old so IRK! still supports it.

Thereafter, a '1' is encoded as a short burst followed by a long silence, and a '0' is encoded as a short burst followed by a short silence.

Broadcast Address

An address byte of 0xFF is recognised by all IRK! devices that you may have built. So it is possible for a single remote control to send a command to ALL IRK! devices simultaneously.

System Control Commands

IRK! also supports the USB-defined "System Control" commands called "Sleep", "Wake" and "Power Off". Some USB keyboards have keys for these functions, but they are not intrinsically keyboard functions. Any suitably programmed USB device, such as IRK!, can send USB System Control commands to your PC to request it to go into "Sleep" mode, for example. The following is a summary of the results of the System Control commands on my PC (your mileage may vary):

Power Off = CPU off, Disk off, Monitor off, USB off
Sleep = CPU on, Disk off, Monitor off, USB on
Wake = Does not work!
Power Switch Pressed = CPU off, Disk off, Monitor off, USB on

Consumer Device Commands

IRK! supports the USB-defined "Consumer Device" commands such as "Mute", "Vol+", "Vol-", "Calculator", "Browser Home", You can use these commands to control your Media Player (play/pause, stop, skip back, skip forward etc) or start applications (Calculator, Browser, Media Player etc).

For a complete list of the Consumer Device commands that you can use, just download the USB Human Interface Device Usage Tables document. That sounds complicated, but the specification is not that hard to read. Specifically, look at Table 17 "Consumer Usage Page". It does not matter that IRK! does not display the names of all these commands as you scroll through them, you can still ask IRK! to send them to your USB host (e.g. Linux, Windows, MythTV etc) - and the USB host should execute the corresponding function.

Power Switch and Reset Switch Commands (experimental)

Astute readers will have noticed that there is a problem with trying to get IRK! to "Power On" your PC - because not all PCs supply power to USB devices all the time when the system power is off and IRK! depends on power being provided by the USB interface of the system it is connected to.

A way around this is to power the IRK! circuitry from the "Standby" voltage (Vsb) from the PC power supply. Vsb on older computers supplies +5V at around 10 mA even though you have powered your PC off. More recent ATX power supplies can deliver Vsb at 2A. This means that, if powered from Vsb, IRK! can stay awake listening for IR commands as long as the PC is plugged into the wall power outlet. The IRK! circuit caters for pressing the Power and Reset buttons on your PC, but you will have to somehow tap into the Vsb output from your PC's power supply to get it to work. I don't know of any motherboards that have a readily accessible header pin for Vsb. This means that if you want this function, then you may have to physically break the Vsb wire from the PC power supply. The Vsb wire should be the purple wire.

Note that powering IRK! from Vsb has not been tested at the moment, but should work in principle. The Power Switch and Reset Switch functions do work as long as IRK! is powered from USB though.

<p>Hello!<br>Thank you so much for your work on creating IPK!. This device is very interesting to me. I'm doing a media player with OpenELEC + XBMC and his management want to use IPK!.<br>But there were some questions:<br>1. How many buttons on the remote control can be trained in IPK! ?<br>2. After a complete setup for a specific remote possible to exploit IPK! without LCD and keyboard?</p>
<p>IRK! does not have an internal table of USB button codes. Each USB &quot;usage&quot; is represented (in the USB specification) by a 16-bit &quot;usage page&quot; and a 16-bit &quot;usage&quot; code. IRK! knows about the usage page codes for Keyboard and Consumer Device. Within those pages, IRK! can teach a learning remote the low-order 12-bits of any Consumer Device &quot;usage&quot; code or the low-order 8-bits of any Keyboard usage code. Sure, it tries to display the popular usage names on the LCD display, but even the ones that it doesn't display can still be programmed on a remote. When a remote IR signal is received, IRK! simply pulls the 8-bit or 12-bit usage code out of the packet and sends it unchanged to the host's USB interface.<br><br>As for whether IRK! can be used without an LCD and front panel buttons, I think it would be difficult to operate without those user interfaces, but I guess if you could program IRK!'s IR command pattern directly into your remote then you wouldn't need an LCD or front panel buttons. I think the Philips Pronto remote control (for example) has a way of defining IR codes using PC software and loading them directly into the remote - but I've never used that remote. </p>
<p>Hello , Simplicio!<br>Thank you for your prompt response .Since English is not my native , I probably wrongly brought to you the meaning of your first question. I wanted to learn about what the maximum number of different buttons on the remote control can be mapped to keyboard shortcuts ? Or say differently. Every control XBMC I need 37-39 buttons on the remote control . I have a TV remote Cameron, which transmits the IR signal in NEC protocol and has 40 buttons. And I made the front panel with 11 buttons that are connected to the chip SAA3010 ( transmits infrared signal protocol RC- 5 (Philips)). These 11 buttons duplicate main function XBMC. So, will there be enough memory IPK! Programming compliance of all these buttons with shortcuts transmitted interface USB? And is it possible to assign the same key code USB two different IR code from different remotes ?<br>In my computer already installed LCD 20x4 (analog HD44780), which I use to display information from XBMC, so second place is impractical.</p>
<p>Sorry, I still do not quite understand what you are asking :( ...<br><br>To be clear on one thing though: IRK! knows nothing about NEC or RC5 protocols - it does not need to. Instead, it uses its own IR signalling protocol, which is why you must have a remote control that can learn IRK!'s IR signal patterns. If you have a learning remote control that can store 100 IR signal patterns, then you can program 100 IRK! IR signal patterns on it (for example, Keyboard:A, Keyboard:B, ConsumerDevice:Play etc). If you have two learning remote controls then you can also program the same (or different) IRK! IR signal patterns on each of them. IRK! can only recognise its own signal patterns when they are transmitted from a learning remote control that has already learned IRK!'s IR signal patterns. <br><br>If your remote transmits NEC or RC5 signal patterns, then IRK! will completely ignore those patterns. That is a good thing, because you can control your TV or AV system using NEC or RC5 (or whatever) protocols, and you can also control your PC using IRK! - with a single learning remote control.<br><br>The mapping of remote control buttons to IR signal patterns is done by your learning remote control and the maximum number possible depends on your remote control's capacity. IRK! does not have a table that maps IRK! IR signal pattern &quot;x&quot; to USB function &quot;y&quot; because IRK! has been designed so that part of the IRK!'s IR signal pattern can be sent directly to the USB interface. As a result, more IR signal patterns does not mean more IRK! memory is required.</p>
<p>Hello, Simplicio!<br>Thanks for the detailed and extensive explanations. Without your response, I would not have coped.<br>I gathered IPK!. Did not find the chip PIC18F25K50, had to do on the PIC18F2550. Used firmware v.2.11 for PIC18F2550. Trained key codes necessary USB Universal Learning Remote Remote Control. In Windows XP IPK! works perfectly. In Linux (OpenELEC v3.2.4) for some time IPK! works fine, then the transmission of any (no matter how trained IR commands) IPK! freezes. In this activity LED is lit constantly, and key codes in Linux is not transmitted. It is treated just reboot the system. What could be the reason?</p><p>And one more question. For PIC18F25K50 (v.3.04) F0 command list was expanded . Added command F0 0A, F0 0B, F0 0D, F0 0E. Can I add these commands into the firmware for PIC18F2550 and even add command switches the output BACKLIGHT from one state to another?</p>
<p>You can buy a PIC18F25K50 directly from Microchip Direct.<br><br>I've had a few problems with Linux in the past but they were solved by upgrading Linux to a later version. I have been using the THT version on my MythTV HTPC running Arch Linux without issue for a few years now. I suspect some sort of Linux USB glitch because the normal flow is: turn on activity LED, then send the keystroke to the USB Interface, then after a short delay turn off the activity LED. What you can do is use wireshark to trace the USB activity (don't forget to &quot;sudo modprobe usbmon&quot; first to load the USB packet trace drivers). Look at the Linux message log for any related error messages. Try a different USB port on your motherboard.<br><br>You can retrofit the SMT code to the THT code if you want - that is one of the good things about open source projects. Note that the THT version supports only two external MOSFET switches - and I still haven't tested that functionality so I still can't guarantee that it actually works (but it seemed like a good idea at the time). Toggling the BACKLIGHT state should be possible if you want that. Personally, I find the backlight distracting and leave it off.</p>
Hi! I just wanted to say that this is by far, the best instructable I&acute;ve seen. For about a year I&acute;ve been an entuisiast with the &quot;learning by doing&quot;- principle, and the tricky side is to understand the instructions in this new and great hobby. This instructble has no such bieffects.. absoluteley fantastic. This is probably my first comment as well.. Thanx a 1000 times for a wonderful work. Now lets see if I can do some work on the actual content in your instructable. / Loony
Heh Loonytech,<br> <br> Glad you're having fun with it! (sorry about the delay in responding, but I only got notified about your comment after 5 days - must be some anti-spam thing).<br> <br> I have to admit I've not put much more effort into IRK! since I bought an Android phone and installed the <a href="http://code.google.com/p/mythmote/">mythmote</a> app on it to control my MythTV system, but I sure had a lot of fun doing the whole design/build/program thing and to end up with a reasonably unique home-made gadget was worth it just for that!<br> <br> Cheers,<br> Andrew A.<br> <br> <br>
i would love to make this but i would get as far as finding the parts and by then i already would have given up. :)
What would happen if I pulled out 1random wire what would you do cause that's a lot of wires lol jk
Well, it *was* a lot of wires...but it's off breadboard now. New pic attached.
very nice and you go into detail on this so well great asset to instructables

About This Instructable


31 favorites

More by simplicio: PUB! Programmable USB Button TIC! One-button Time Lapse Camera Timer IRK! Infrared Remote Controlled USB Keyboard Without Keys
Add instructable to: