IRK! Infrared Remote USB Keyboard / Blog: Recent posts

v3.02 of the IRK! software works on the SMT version of the PCB.

My prototype runs at 48 MHz instead of 24 MHz - but only because the mikroProg Suite software that I use to program the PIC18F25K50 has a bug at the moment which causes it to set incorrect configuration bits. If you use a different programmer then you can run it at 24 MHz or 48 MHz.

Well, the SMT prototype is almost working. There's some sort of bug (maybe) with the mikroProg programmer I'm using which seems to be ignoring the CPUDIV configuration fuse that I need. As a result the MCU clock runs at 48 MHz instead of 24 MHz...not good. The LCD shows that it is trying to establish a USB connection but not quite making it.

I put an OnSemi MC14066B Quad Bilateral Switch on the prototype (instead of the Maxim MAX4066 that I originally intended). The MAX4066 has a lower "on" resistance (around 45 Ω compared to about 100 Ω for the MC14066B at 5V) but it's probably more important that the "off" resistance is high - otherwise you could see weird behaviour. Still not tested yet, but in theory it should work.

A major change justifying a new version number is addition of a Surface Mount Technology (SMT) version of IRK!. I haven't completed assembling the SMT version, so it may have bugs that need fixing (and it might not actually work!).

The original Through Hole Technology (THT) version is unchanged as of v2.11 and all its files have been moved to a directory called /tht. A new directory called /smt has been created to house all the new SMT files.... read more

I skipped 2.10 because it was a "nothing really changed" update. Come to think of it, 2.11 is kinda the same. This version:

• Supports USB Full Speed interface - but it's not really needed because, as you can imagine, a keyboard driven by an IR remote control doesn't need a lot of bandwidth. But you never know, one day Low Speed USB may not be available.

• Checks to see if any buttons are pressed when it powers up and, if so, displays a "Release Buttons!" message. This is really just to remind me to remove the PIC programmer before trying to use it - as the programmer loads some of the inputs so that it is the same as the user pressing and holding buttons. ... read more

• Fixed a bug in the menu navigation where pressing and holding the SHIFT panel button when adjusting the backlight delay causes the LCD to lock up.
• Reserved RAM bank 4 (by defining a dummy variable at that location) to prevent the compiler allocating variables to it. Bank 4 is used by the USB hardware module when it is enabled (which it always is in this application). The data sheet also warns against using RAM banks 5 to 7 but that shouldn't affect this app.
• Added support for the GUI key. The GUI key is a generic name for the button known as the Windows key on some keyboards, the Command or Apple key on MAC keyboards, and the Super key in Linux-land. For my MythTV system, I've used this to map GUI+F to start the mythfrontend program. Prior to that I had to use a real keyboard or mouse to restart the frontend - now I just use my remote control :) ... read more

I've learned something new about programming in MikroC for PIC after all these years...you can force the compiler to use ROM instead of RAM for string literals by coding "const" either on the string definition:

:::C
const char CRLF[] = "\r\n"; 

or by coding "const" on a function that returns a string:

:::C
const * char getSomeString()
{
  return "any string literal";
}

When I did this in IRK! v2.08, RAM usage dropped from 991 bytes (49% of the maximum) to just 271 (13% of max) and ROM usage increased accordingly from 15722 bytes (48% of max) to 18338 bytes (56% of max). Obviously, we have way more ROM than RAM to play with, so this is a really good outcome.... read more

I've added the following Consumer Device code descriptions:

• Menu
• Menu OK (pick)
• Menu Up
• Menu Down
• Menu Left
• Menu Right
• Menu Escape
• Channel Up
• Channel Down
• Play
• Pause
• Record
• Fast Forward
• Rewind

Note that this is a cosmetic change only, because IRK! has always allowed you to map these codes onto your remote control buttons...you just had to know what hex code to select. For example, in the USB Consumer Device usage page, the hex code for the "Channel Increment" usage (function) is 0x09C. You can find out the hex codes by reading the USB HID Usage Tables specification (specifically, Chapter 15 "Consumer Page") at usb.org... read more

Well, it's finally been fixed - IRK! now works reliably at long distances.

The problem wasn't that the duty cycle not being high enough, it was the error margin I coded for deciding whether a pulse was too long or too short.

The shortest pulse width I use is 600 microseconds, and I'd coded the receiver logic to tolerate a variation of +/- 100 microseconds. Strangely, this only worked reliably at close (< 4m) range. At longer ranges there must have been some pulses appearing outside this margin, and that caused many IR transmissions to be ignored.... read more

I've been trying for a few months now to figure out why IRK! works fine at close range (less than 3m) but struggles when you're sitting further away from the IR receiver than that. What is really weird is that if I bounce the IR signal off a wall then it works just fine when I'm sitting more than 4m away (100% of commands recognised) - but pointing directly at the IR receiver at over 3m away I get about a 1 in 3 hit rate. ... read more

Fixed a bug with the extended pulse width checking introduced in 2.04, which would have made 2.04 pretty much unusable.

• I've become a git convert. So I've deleted the SVN repository and started using git from 2.04 onwards.

• The big change in 2.04 is to reduce the AGC "training" burst at the start of each IR transmission to be just 1000 us (instead of 9000 us) with a silence of just 600 us (instead of 4500 us). Doing that has some ramifications:

  1. IR codes that you have "learned" onto your remote control will need to be re-learned. Sorry.
  2. The TSOP4838 IR receiver will not go into "noise suppression" mode and reduce sensitivity. That means it should be able to receive IR signals over longer distances.
  3. You should be able to transmit more key presses per second. Yippee...(seriously, if you need this because you play games using your remote, then get an xbox or anything)... read more