There are two basic ways in which WinLIRC won't work -- either the hardware or software is bad. This will hopefully help you track down and fix any problems you might be having.
So you've built a receiver and it doesn't work at all; that is, when you hit "raw codes" in WinLIRC, you don't see anything at all when you press buttons on your remote. Possible causes of this are:
Try a different remote, or at least take a look at the end of your remote through a CCD camera (like a home video camera or digital camera) to make sure the infrared LED is flashing. Or just make sure the remote can still control a TV or whatever. (An interesting side note: this guy can apparently see infrared rays. Look at the bottom of his page. That's cool.)
If you can get a receiver from someone else, try theirs. If theirs works and yours does not, then yours is definately broken. Check and double-check the wiring, polarity of parts, and make sure the cable you're using to connect it to the computer is good (with no crossed wires or other tricky stuff going on). Double-check the schematics at http://www.lirc.org/receivers.html. If you're not using one of the IR modules shown on the list, maybe you should be. Measure voltages and make sure the IR module is getting enough (according to the datasheet for your particular module); also make sure that the levels at the serial port are high enough ("high enough" depends on your computer).
Try your receiver on a different computer. If it works there, maybe your serial port is broken or misconfigured or has strange voltages. Or, try booting a different flavor of Windows, if you can. Or try using LIRC under Linux. If it doesn't work under a different Windows or Linux, then it's probably not the fault of WinLIRC. I've gotten a report that upgrading the BIOS to the latest version on a Dell laptop fixed computer problems for one user, so that's probably worth a try.
You'll probably get an error if this is the case, but I had at least one report of some low-level VxD that was using the serial port in ways unknown to Windows; WinLIRC didn't (and couldn't) realize that the port was in use and so it just didn't work at all.
You see raw codes but learning doesn't work. I'm not surprised. The learn function in WinLIRC is pretty bad, and only works well on a handful of the various protocols used by remotes out there. Some ways to fix this:
My personal favorite. I just give up on a remote and grab another if it's being particularly problematic. Remotes are cheap, and they're easy to find. Similarly, if you have a programmable remote, you can try programming it differently. For example, I recently got up a remote that worked best when programmed it to work with Sony TVs.
For whatever reason, you might be having problems recording the config file on your own system, possibly due to speed or driver issues (which usually affect signal reception and which I'll address later). Try recording a config file for your remote on a different system. Since WinLIRC is compatible with LIRC (exceptq for new features recently added to LIRC), you can also get a Linux machine, record a config file with LIRC's superior "irrecord", and then transfer that generated file back to Windows.
The LIRC project maintains a database of config files for various remotes at http://www.lirc.org/remotes/. You might be able to find a config file for your remote there, or at least one that's close.
Not easy, but certainly possible. I've never actually done this, but you could get out an oscilloscope (or just look at the "raw codes" output), decode the signal by hand, and build a config file from that. You might find some people on the LIRC mailing list that can help you with this; the LIRC site can also help you figure out the proper format of the config file.
By the way, if learning works but analyzing doesn't, that's no big deal. WinLIRC should still be able to receive and decode signals.
Either decoding is unreliable (works one time, fails the next), or it becomes unreliable or stops working completely depending on the programs you run and what you do. Maybe you see problems with you go to play a DVD, or an MP3, or CD audio, or a DivX movie, or whatever.
This is by far the most common problem I get e-mailed about. The culprit is just the way that things work from within Windows. In Linux, the lirc_serial module gets loaded into the kernel and chains directly to the serial port's interrupt handler. There isn't much you can do to knock it from its throne. Windows isn't nearly as nice. WinLIRC runs as a user-space process, and it's at the mercy of Windows to get scheduling time whenever it can. It runs at the highest priority, but anything in kernel space (such as any VxDs or device drivers) can easily take precedence over it, and WinLIRC can end up missing or misreading signals from the receiver. I've heard a lot of different problems, and each one seems to have its own solution.
If your computer is slow (say, 200MHz or less), it's possible you just don't have enough spare CPU time left over from Windows to accurately decode signals. Try it on a faster computer and see if you have more luck. If you do, the next suggestion may help.
A description of how to do this can be found here. Commercial programs like FireDaemon could also be used. This could be combined with the next tip.
Daron L. Olesch-Williams points out that you can run any program in it's own memory space with any priority, and that this helps his reception greatly. Read his note here.
If you're seeing intermittent problems (sometimes works, sometimes doesn't, seems random), it's possible that WinLIRC is just being too strict when trying to match the signals. You can make it less strict by editing the configuration file and increasing the allowable margin of error, or 'eps'. It's entered as a percentage, and is usually around 25. Try changing it; for example, from:
to:eps 25
eps 75
If that helps but doesn't completely solve the problem, you could push it up even higher, but if it gets too high, WinLIRC can no longer differentiate between long and short pulses and it just won't work at all.
It's possible that your remote is hard to interpret because of short pulses, too much similarity between codes, or some other reason. A different remote may help.
If possible, use the Analyze feature after you learn the remote. An analyzed remote takes slightly less CPU time to decode, which might just buy you enough extra cycles to improve reliability.
A few people have seen intermittent problems and eventually traced it back to the hardware. It's possible that your IR module isn't getting enough power to provide a consistent signal, or maybe your serial port isn't providing a clean source of power. You could try adding an external power supply, or adding bigger capacitors on the power lines, or just using one of the more advanced circuits from http://www.lirc.org/receivers.html.
If you can successfully decode one signal but then need to wait a few seconds before any further signals can get decoded, it's possible that the auto-sense code is misdetecting the receiver's polarity. Try manually setting the sense to "high" or "low" instead of "autodetect". Just try them both and see which one works.
Other processes running in the background can affect decoding. Try killing them all and see if things work better. If possible, you can also reduce their priority; programs like Winamp have the option to do this. Note that WinLIRC already runs at the highest priority possible for a standard Windows process.
Try reducing the priority of Winamp (under Preferences) or whatever MP3 player you happen to be using. With Winamp in particular, I've also had numerous reports that switching the output plugin to "DirectSound" (instead of the default "WaveOut") solves this problem. You may find that upgrading your sound card drivers can fix the problem, or that going into the driver preferences and disabling extra features on newer cards may help. Try reducing the sound quality if Winamp and/or your driver gives you that option. Disable visualizations and other plugins that could be slowing down the system. Playing songs with a lower bitrate can also help, especially on slower CPUs. If you're playing MP3s off of a CD-ROM or over the network, try copying them to the local hard drive first instead. Finally, you can always try one of the other MP3 players; there's a ton of them out there.
Another case where latency in the low-level drivers preempts WinLIRC's ability to accurately receive signals. In this particular case, the problem is that the digital audio extraction was tying up the system. Going into the CD-ROM drive's preferences and disabling "Digital Sound" solved the problem.
Getting a proper MPEG decoder card (instead of using software decoding) can take a large load off of the CPU and leave more time for WinLIRC, but poorly written decoder card drivers can also have the opposite effect and completely block the system while waiting for the card to deliver video frames. The best suggestion I can give for this, then, is to just try to change something. Upgrade your video and sound drivers. If you're using a hardware decoder card, try switching to software decoding. If you're using software decoding, try borrowing someone's DVD decoder card to see if it works any better. Playing a DVD is a very CPU-intensive thing, and it's really hard for WinLIRC to squeeze enough priority out of Windows to be able to decode signals reliably.
Video capture, like playback, can cause long delays on the system bus depending on how well the card's drivers were written and the quality of the card. If WinLIRC doesn't work when you're watching TV, upgrading drivers for the capture card (and also your video drivers and sound drivers, while you're at it) may help. You might also want to try borrowing someone else's capture card to see if that helps at all. I had one report that using older VFW (Video For Windows) drivers instead of the newer WDM (Windows Driver Model) drivers was the key to getting WinLIRC working, which is unfortunate because everyone's moving to WDM. Still, that's dependent on your particular card and system. Configuring your video capture card to use a lower resolution, or capture fewer frames per second, or display a smaller window on the screen, can also help.
I had one report where WinLIRC simply wouldn't work if the guy turned on dual monitor support or when he used his video card's TV out feature. Again, the only thing I can suggest here would be to try to change stuff around; try upgrading drivers, switching video cards, etc.
You probably have a Winmodem. They're junk. Basically, they tore out everything except the physical interface to the phone line, and rely on the CPU to do all of the necessary digital signal processing to send data over the line. In other words, your CPU load just shot up considerably, and since it's driver causing the load, it has priority over WinLIRC and you can no longer reliably receive signals. Your best bet is to get a real modem, or, if that's not possible, the standard drill of upgrading drivers may help. Or maybe even connecting at a lower speed could help.
Well, there you have it. That's just about everything I know regarding getting WinLIRC to actually work on all of the systems out there. If you've gotten this far and still have trouble, you may be out of luck. What we really need is a good microcontroller-based circuit that handles all of the low-level decoding on a dedicated processor, so that none of this stuff regarding system load and drivers actually matters at all. I'm currently working on a nice USB transmitter/receiver to do just this, but I don't know if or when that will ever get finished. Subscribe to the WinLIRC mailing list or just keep an eye on the main WinLIRC page and you'll be sure to know if such a project ever gets finished.
Copyright (C) 2002 Jim Paris <jim@jtan.com>
Last update: Thursday, June 13, 2013 at 08:28 PM
Hits (since May 21,2001):