How to use your RS232 or IRDA port for Remote Control

Update History - skip to Introduction if this is your first visit

FAQ page added

FAQ No.2 updated to include extra information on component selection

Theory updated
Hardware schematic and text updated
Software Section text and code updated (winsamp now version 1.3)
FAQ updated
***** This was a big update - please let me know if I've broken anything (that used to work!) *****

Software section updated to include new (experimental) VB TX version of MANYBUTT

Minor update to Software section to add (experimental) VB TX version with support for COM5-8

Since then . .
Only tweaks.


Firstly, an apology. There is a lot to read on this page and I'm struggling to make it even slightly visually appealing. If you feel that the subject is worthy of your attention, then I suggest you grab a printout of this page, arrange yourself comfortably with a nice cup of tea or whatever floats your boat, and settle down for as long as it takes.

Unlike some of my other stuff, this one is fairly serious. It is intended to introduce a concept and demonstrate its application rather than present the definitive finished product, but having said that, everything needed to get it working properly on a PC is included, with enough information and flexibility to enable the software as supplied to be incorporated into much more elaborate Windows front-ends if desired. The idea is not limited to PC platforms, however - most devices with serial or IRDA ports are possible candidates for the technique as described, and samples made on one platform should transfer easily to other platforms.

A number of people have done good work in the field of turning a PC into a 'learning' universal infrared remote control, for various appliances such as TVs, video recorders, satellite decoders etc. The common methods appear to use either an IR detector and transmitter circuit attached to the parallel port, or an 'intelligent' device accepting high-level commands attached to a serial port. A quick online search will turn up schematics, construction details, driver software and some very attractive Windows front-ends for this purpose.

Following on from my Furby experiments (
), I set out to prove that it is possible to control the TV etc using either an IRDA port or a standard RS232 port with extremely minimalist hardware. The reasons were threefold. First, the challenge. Second, the convenience or geek value - many PCs, PDAs and other devices already come with IRDA as standard, wouldn't it be nice to use it for something different. Third, DEVICE INDEPENDENCE AND PORTABILITY OF SAMPLES - serial ports of one type or another are fairly ubiquitous, more so than parallel ports anyway, and a drawback with sampling and playback through the parallel port is the heavy dependence on processor speed and environment - samples made on one speed of machine may not work reliably on a different speed of machine (no criticism intended, but this is what I found when I tried it), so to have a good probability of success you have to sample your remotes on the machine you intend to use for playing them back - consequently, you can't simply sample your Sony CD remote and send the file off to your pal in Greenland when he loses his [ahaaa - until now :-) ]. Also, most systems have more than one COM port, so it's no great hardship tying one of them up permanently for remote control. The next bit is a disclaimer of sorts, then we'll get on with the theory.

Disclaimer - Please read this - Important

What I am about to describe is my own original idea, my own software, my own project. As far as I am aware, nobody else does it, or has done it, this way, but if they have, what can I say? Great minds think alike? I am not intentionally ripping off anyone else's work, and have worked long and hard to get it into its present state, for my own amusement, with no prior knowledge that it can or cannot be done or indeed that it has been attempted in this fashion. The ideas and software have been put here because I thought you might be interested in how I did it. It all works as far as I'm concerned, but I'm not asking or telling you to use it in any way, shape or form. The software (should you choose to try it) can write small text and binary files containing sample information to your disk, or whatever you run it from. Also, the Windows demo application keeps a couple of settings in the Registry to enable it to remember preferences from one session to the next. None of this should cause you any distress, but as with all things, it could always go horribly wrong, so you have been warned. If you don't want to risk using my software, you should be able to write your own using the information in the theory section. Also be advised that there is a class of IR remote control (so-called 'flash' controls) which is not supported by the software in its present form, but the project is still in a state of flux and I may add support later - the issue here is one of trying to keep it simple enough for anyone to use when they don't have the use of a proper 'scope - I'm sure you don't wish to become an expert on remotes (not that I am, but a certain amount of it inevitably rubs off).

Anyway, with the software and hardware described, I routinely control a Toshiba TV, JVC video recorder and Maspro satellite receiver either using a laptop irda port or a normal 232 port on my desktop PC, using samples made from the original remotes and without having to know details of the three different protocols actually employed by the devices. There is a good chance that most other appliances will work equally well ('flash' devices being known exceptions). If you can't get a device to work, the sampler software will at least provide information to help identify the problem if you wish to look deeper into it.

Finally, if you would like me to investigate the implementation of this technique on other platforms, you should send me non-returnable hardware and development software for the experiments, and if you make a fortune based on the idea, I certainly wouldn't mind you giving me a share :-)

Blank Frank 24th November, 1999.

Theory - Updated 26th August, 2002

Ok. Now to the good bit. Without getting too technical, here is an idea of what's going on and why. Though there is a mind-bogglingly large selection of remote control protocols at the bit level, based on quite a number of types of protocol at the packet level, the vast majority of ir remote controls function by sending data at relatively low rates by transmitting bursts of (carrier) pulses of various lengths with periods of silence inbetween, also of various lengths. The data is encoded in the lengths of the bursts and silences, and receivers demodulate the carrier to recover the baseband data. The carrier frequency is typically somewhere in the range 36 - 40 kHz, and receivers are designed to allow signals of this frequency range through (+/- a few kHz) while rejecting signals outwith this range in order to reject such things as strip lights.

You may wish to brush up on your serial port theory for this - lots of info online, maybe enough on the Furby page. I make the assumption that most receivers will be happy with combs of pulses at 38.4kHz, since they are designed round R-C filters and diode pumps (at least conceptually, though most use one integrated device). I can achieve this by transmitting suitable characters at 115200 baud out of any serial port, so long as there are no gaps between characters. The precise pattern for a comb is the character value 0xdb, at 115k2/8/e/2 (0x5b at 115k2/7/n/1 would also be possible but would require data to be loaded into the uart more frequently). There is sufficient tolerance in most receivers to cope with the effective 4-pulse granularity (or 3-pulse if 7/n/1) in the comb. The next assumption I make is that out-of-frequency-band pulses will be rejected by the receiver, so if I transmit 0xfe, still at 115k2/8/e/2, this will look like silence to the receiver. So that's the transmission part covered - by sending correctly-sized groups of characters with values 0xdb and 0xfe, I can effectively construct an infrared stream which looks like it came from a 'real' remote control from the receiver's point of view, so long as I keep the uart continuously stuffed with data. The timing is derived from the uart, not the raw speed of the PC or other host device, and it is fairly easy to keep up.

Sampling works as follows. Using the very simple hardware described below, (or your own equivalent - doesn't need to be a handshake line, could be a joystick or printer input, for example), I transmit a junk character (0xff as it happens, but it doesn't matter) continuously out the serial port with no gaps between characters. While waiting for each character to be transmitted, I sample the IR input as frequently as possible (in my case a handshake line) and if I ever see an 'active' condition on it (ie if IR is ever detected) I assume that there is a comb (36 - 40kHz) of data being received from a remote control during this period, and if I don't see activity I assume this is a silent period. I grab a big array, with one bucket for each character time, and the buckets will either be marked as active or silent. After a preset number of characters have been sent, I stop grabbing and process the data. What I end up with is another array of buckets which contain alternating active counts and silent counts, stored as numbers of character times, adjusted to compensate for the inherent tendency of this method to round up comb lengths and round down silence lengths. Arrays like this provide a compact method of sample storage, and are very easy to play back when I want to transmit the sample as described above, and again, the timing is absolute, based on the uart, not the processor raw speed, so it is accurate and repeatable. By understanding the actual protocol used, it would be easy to compute the packets rather than store samples as such and make the storage space requirement much smaller, but I'm trying to avoid this to keep things simple and flexible. There are a few details to do with timeouts, sample sizes, waiting for the data to start, suspending interrupts etc which will be explained elsewhere, but the basic principle is very simple and apparently rock solid.

It is not possible to sample remotes through the IRDA port - at least with my software, but probably not at all on a PC - due to the design of the port hardware. Samples have to be made using a 232 port using the hardware described below, or equivalent, but this should not be a problem. Playback through the IRDA port works fine so long as you are aware of the potential pitfalls (again covered to some extent on my Furby page, and in particular relating to operation under Windows).

I have run the same software on an 8MHz 286 (yes, I managed to find one that still works) and a K6-2 333 and got the same results. Samples made on both extremes of machine look the same and can be exchanged without problems. This suggests that the technique will work well on a wide range of devices with serial ports, not just PCs. The actual sample-grabbing process is designed to scream along, even on a slow machine, though the post-grab processing can take as much time as it needs since it is not real-time critical.

Update 26th August, 2002
Things move on. Since writing the above section, PCs have got considerably faster. I am happy to report that the system has now beem tested unchanged on Athlon 1000 boxes and above, without problems, under Windows 95 / 98SE, and, from the feedback I've had, the project has been constructed and run on a variety of PCs, and implemented on and some other platforms, in various parts of the world.

Now the interesting news. I have figured out a way of retaining all the uart-derived timing properties of transmission described above while achieving 'real' silence during the silent periods rather than the combs of out-of-frequency-band pulses which have been used up to now. It works on all the PCs I can get my hands on. The latest version of the DOS program (version 1.3) implements this and no longer has the option to switch in software timing loops to achieve (with some calibration effort) the same effect. It takes advantage of some particular features of the PC uart hardware, so I wouldn't class it as a new method, rather as an optimisation aimed at PCs. Since the vast majority of users are PC users, this new version should be of general interest, though I stand by the original method as described above as the more general solution. I have to say that I personally don't have a problem using the original silence method with the receivers I'm controlling, but this reworked version may be of some help with borderline cases, and this is now the 'official version' - I've moved over to it anyway, because it has a couple of other features I wanted, which are described elsewhere in the docs.

If you are a first-time user of this project, don't worry, just use the latest version of the software.

If you are an existing user of the system, there are several reasons why you might wish to install the latest version. Firstly, real silence rather than silence combs should work with a larger selection of equipment - the original silence combs might somewhat saturate the IR receiver or indeed totally confuse some poorly-filtered equipment (always one of the known drawbacks of the method), so the new method will hopefully improve the IR on/off contrast ratio and thus improve the operating range or make it work properly with your target equipment for the first time. Secondly, the data stream will be much easier to observe on a proper oscilloscope than it used to be. Thirdly, you can do fun things like transmit a sample from one PC to another and get a close match (I know, you could do it more easily using a floppy or whatever). Fourthly, the new software has some helpful features in DOS-screen mode which make it easier to experiment, diagnose problems and manipulate data sets. Fifthly, the average power consumption of transmission is reduced, prolonging your battery life, saving the planet and so on. The main thing here is I can see no downside. All you need to do is replace the DOS program - the change is invisible to the Windows program, and any samples you already have remain totally compatible. At worst, you get the benefit of the new features; at best you may also get better performance.

Hardware - Section updated 26th August, 2002

Here is a schematic for the hardware I use. This has been updated on 26th August, 2002 to include the diode explained below. If you built yours before this date, and you think your LED might be glowing slightly (in an IR sense) when it should be off, you should consider adding the diode even if everything seems to work fine. It may give you improved performance. You can check to see if you have the problem using a video camera or by measuring the current through the LED in the idle state - don't bother changing it if you don't see the problem. Having said that, it only hit me when I started playing with substitute transistors which were intended to be near-equivalents.

schematic for serial port remote control hardware used in this project

There are really two separate circuits, and it would be ok just to build the receiver section for sampling and use the IRDA port for transmission. The receiver section takes the power it needs from handshake lines (so no external source required in this configuration). The receiver range is only a couple of cm, so the remote has to be close to work, but there is no particular reason why a proper circuit shouldn't be built which would operate over several metres, and indeed software could be written to let the PC decode the signal properly, though it would be a non-starter as a mouse substitute under Windows or whatever. There are additional notes about the driver transistor (2N7000) on my Furby page (here).

The diode marked *NOTE* between the TX pin and the gate of the FET has been added because I occasionally observed the LED to be slightly on when the TX line was low and the LED should have been off, with the result that the on/off IR contrast ratio was reduced (and consequently maybe the useful transmission range). There are a couple of possible explanations for the LED being on, which I didn't investigate further, opting rather to kill the problem once and for all by including the diode. Shame really, because the tolerance to large positive and negative Vgs values was one of the reasons I chose the FET in the first place. Anyway, the diode effectively prevents the gate from going more negative than the source and the problem is gone. If you suspect that the FET is not turning off fast enough with the 100k pulldown (due to extremely high gate / track capacitance or whatever) you could safely reduce the resistor to 10k to see if that helps, but I have no reason to think the change is needed.

The FAQ page has been updated, and now includes a couple of (untested) suggestions for increasing the output of the transmitter, and the simple change needed in order to replace the FET with a normal NPN transistor.

Software - section updated 5th April 2005

(new Windows front-end software - details at end of section, but you should read all the way down)

There are now two versions of the software package available for download, and unless you have a pressing desire to do comparisons between the original version (winsamp version 1.1) and the current one (V1.3), you should ignore REMOTE11.ZIP (37k) and go for REMOTE13.ZIP (39k). The packages contain versions of the same set of 5 files - MANYBUTT.EXE, BUTT1.BUT and BUTT18.BUT are unchanged, WINSAMP.EXE and README.TXT have been updated in the newer ( version. If you are updating your installation from 1.1 to 1.3, only the two changed files need to be replaced (obviously). Just for information, V1.2 was an intermediate version which was never published because I didn't want to have to do two page and docs revisions in quick succession, but you're not missing anything because 1.3 contains all of 1.2 plus extra features. At risk of repeating myself, the upgrade will not require you to do anything to your existing sample files, does not change the command line interface, does not modify the settings of the GUI (manybutt.exe), and only requires you to replace winsamp.exe (and the readme file, if you want to keep things in step - and then probably only if you actually want to read it). Note that the remainder of this section is virtually the same as what was here before, so there is no nead to read it again if you're already familiar with the contents.

The software here is enough to get you going both in dos and Windows95/98, but is not pretty, clever or feature-laden. It goes some way beyond proving the point that the method works, but falls well short of some of the applications which have been written around the parallel-port system. It does everything I need it to do as far as controlling multiple devices and producing platform-independent samples is concerned, so I have drawn the line there for the time being, but I hope I will have provided enough information to allow anyone with an inclination towards programming to write their own much nicer versions or to port the method to other platforms. I have in mind some particular features I might add to the VB side to address some specific future project requirements, but these are so far off the normal track that there would be little point in trying to build them in to a general app, and anyway they still depend on utilising the same dos-based core program.

How to get started

Click here to download REMOTE13.ZIP (39k) , a .zip file which contains five files - WINSAMP.EXE, MANYBUTT.EXE, README.TXT, BUTT1.BUT and BUTT18.BUT. Create a directory (wherever you want and whatever you want to call it) and put these into it. WINSAMP.EXE is the main dos app, and is all you really need to get started. MANYBUTT.EXE is my VB5 demo for Win95/98 which calls the dos program as required. The *.BUT files are example buttons used by MANYBUTT.EXE. README.TXT is all the explanation and detail I didn't want to put on this page, written in plain text, and I only suggest that it be in the same directory so it doesn't get lost or overwrite any other file of the same name - it overlaps with this file, but you would be expected to have both. This html file (REMOTE.HTM) and README.TXT are expected to evolve as I find problems, develop the idea further and hopefully if and as I get feedback. Create a shortcut to MANYBUTT.EXE on your desktop for convenience. You can also create one for WINSAMP.EXE if you prefer to access it this way rather than from dos prompt, but if you want to see what's going on, it would be best if you make sure (by tweaking properties if necessary) that it runs Full-Screen. Remember that if you want to run it on anything other than COM2, you'll need to edit the command line to WINSAMP.EXE Cx. You can actually look at and fiddle with the software without having any sample/playback hardware. If you already built the IR Thingy from the Furby page, you're half way there hardware-wise, and if you managed to get the Furby stuff working, there's a very good chance this will work too. What I suggest is you save this page or print it out, get the software and read the readme file, maybe have a look at the programs then decide whether or not you can be bothered to build the hardware. If you get that far, then go to dos prompt and run WINSAMP.EXE, using appropriate COM port selection and start trying to sample remotes. If that seems to function, then use MANYBUTT.EXE from the desktop - it's a lot more convenient in the long run. Note that only COM1 - COM4 are supported by WINSAMP.EXE, and that MANYBUTT.EXE does not touch the ports as such. MANYBUTT simply passes a string, which the dos app uses to determine the hardware addresses it hits directly.

Some more detail

The main software (winsamp.exe, 21k) is a dos application which can be run in stand-alone mode or shelled from Windows (tested with 95 and 98). It is not Windows-aware, and consequently takes more processor time when idle than it really needs, but the normal way to use it under Windows is to shell it with various command line options set, which causes it to start, do what you want (eg grab a sample or play back a sample) then exit without any keyboard / mouse / screen activity, so it's normally only loaded briefly, and the program is so small that it takes a negligible amount of time to load. Note that once a sample starts to arrive or starts to be played back, interrupts are suspended until the operation has finished. In the case of sampling, the default sample window is approx 250ms, but this can be pushed up to 500ms using command line options. For playback, this time is the duration of the stored sample, which again can be controlled from the command line but defaults to around 150ms and cannot exceed 500ms. Be aware that suspending interrupts in order to make sure there are no gaps in the data streams will inevitably result in system ticks being missed (I certainly hope so, this is one of the reasons for doing it), and the result is that your clock will gradually lose time, depending on how much you use the software. Sorry. An easy way round it would be to install one of these programs which syncs your PC to an atomic clock every time you go online if it bothers you - to some, the ability to slow down time might be seen as a bonus. A more messy way round it would be for me to attempt something clever with the real-time-clock hardware following each interrupt suspension, but it doesn't bother me that much to lose a few seconds now and again - when the battery was going flat on my PC I used to lose minutes per day and managed to cope, so this is nothing in comparison.

Because the interrupts are not suspended during sampling until the start of the IR stream from the remote is detected, there is a very small chance that a system tick or similar might happen between detection and the instruction which does the suspending. The chance of this happening is extremely small, but becomes more possible on slower machines, and the ISR would probably take longer to complete if it did happen. The effect of this would be that the recorded width of the first comb would be smaller than it actually was, which would perhaps make the sample invalid on playback for some protocols. I think I've seen this once in all the playing around during development, but of course it might be that pressing the button on the remote causes it to move into range of the receiver just at the critical time or whatever. I would suggest observing a few samples on the sillyscope screen to get a feel for what a good sample looks like, and have a quick look at the sample files to see if any are outstandingly different before burning them onto a million CD Roms or whatever. And of course test the samples.

The most usual way to operate the program in 'real' dos or dos prompt under Windows is to type 'WINSAMP' or WINSAMP Cx where x is the COM port you want to use if the default of COM2 does not suit. A 80*50 text-mode screen is presented (which might not be compatible with _very_ old graphics cards, but if your machine can run Windows it should be ok), and this has lots of things squished onto it. You need to read all the bits of writing on it because the user controls are all hinted at somewhere there. For details of command line options, type WINSAMP ? and a horrible text screen will appear, which might help. A separate README.TXT file is included explaining the command line options and controls in more detail, along with examples of how to make it work from Windows programs. I have also included a simple Windows front-end demonstration written in VB5 which uses the dos app for all the low-level stuff. This is only the actual .exe file - due to bandwidth restrictions I can't put up a full distribution - the .exe is only a few k, but all the support bits take up megs of space, so unless you already have VB5 or have acquired the support files through other software installations you've done over the years, I'm afraid you're stuck, but there is a somewhat less satisfactory but quite functional method for accessing the dos program under Windows using nothing more than program groups and shortcuts which is explained in README.TXT.

It may be possible to rewrite the whole thing as a 'proper' Windows application, but using the dos program makes it relatively simple to achieve the necessary low-level hardware access and timing. Certainly, VB or similar could be used to provide sophisticated sample management (archiving, selection, grouping, exporting, importing etc), but I have only done enough to suit my own needs for the time being.

I hope you like it.

Update 5th April 2005

Looking some more at the problem of trying to make a more 'proper' Windows program, I have now got a replacement for MANYBUTT.EXE, imaginatively called MBREV2.EXE , which might be of particular interest to people who are trying (and failing) to make the system work under (for example) XP. It should be dropped into the same directory as MANYBUTT.EXE, WINSAMP.EXE and your samples. It is completely compatible with everything that is already there. The only difference is that by default it comes with a check box checked called VB Transmit. Without labouring the point, what it attempts to do is to transmit your samples using purely VB code rather than shelling WINSAMP. If it doesn't work for you, uncheck the box and it reverts to the previous method.
The advantages are -
a) It is pure Windows (for TX only - sampling still has to be done the old way)
b) It doesn't muck about with PC hardware, make your clock run slow, fall foul of emulation, etc
c) It might work in situations and systems (notably XP) where the MANYBUTT / WINSAMP combination throws up sone kind of violation or error message, or just plain silently fails to do anything sensible
The disadvantages (some of them anyway) are -
a) You need to have VB6 runtime support installed (search for VBRUN60SP5.EXE if you need it - which you do if you see an error message about MSVBVM60.DLL) and MSCOMM32.OCX (also available by searching, if it isn't already on your system)
b) It transmits using the 'silence combs' method, which is theoretically not as good as V1.3 of WINSAMP)
c) It doesn't work very well - at least for me - I get variable results, often need to click buttons twice, and some of my devices fail to respond to samples which work fine using the WINSAMP TX method (and also with the silence-combs method of earlier WINSAMP versions) - sorry, there's nothing I can do about it because VB is in control at this point, but I reckon (no way of telling with my limited test equipment) that it has to be jitter in the spacing of characters (VB allowing the OS to stick its nose in), even on a blisteringly fast system - but if all else fails, it's worth a try

Feel free to give it a whirl - you never know, it might work for you.

Minor Update 13th June 2005

Simple change to MBREV2.EXE to provide TX support for COM5-8, called MBREV3.EXE. None of my systems has those ports, so this is untested as far as I'm concerned, but it should perform almost identically to the previous version. Note, however, that the Winsamp only supports COM1-4, so if you select COM5-8 and Winsamp, Winsamp will silently default to COM2 regardless of which of 5-8 is selected. Sampling. of course, remains possible only with the correct hardware and a wired COM port in the range 1-4.

I have added a FAQ page. I welcome feedback on the project, but if you have specific questions or requests, please do me a favour and make sure they haven't already been covered by this web page, the docs or the FAQ. Your question and / or my response might be added in a generic and unattributed sort of way to the next revision of the FAQ.
Please note that - due to only having the remainder of one lifetime to spread between various activities (social, feeding, work, sleep, etc), knowing very little about anything and only having access to the same public search engines as almost everyone else, I feel it necessary to point out that I am increasingly unlikely to respond to requests for general information, help with school projects, 'Hey Frank - interesting Remote Control article, how do I repair a washing machine'- that sort of thing, so please save me from feeling guilty by not asking. Sorry to have to say that, but you'd be surprised . . . Oh, another thing, I seem to be failing quite badly in communicating my position regarding my source code, so I take this opportunity to draw your attention to Q1/A1 of the FAQ page, where I try to spell it out. Cheers.


View my other offerings
Copyright? Possibly .....