Serial IR receiver problem

Can you give us some design details about the IR receiver? Is it one of those shown on the Winlirc web page?

My guess is the AU-600 is putt>Hello all

Thanks for yor reply.

Yes it's a circuit from the winlirc web page:

I tried to use a longer cable to the skype adapter, separating them with about 3 meters - no change.

I also tried to move the skype adapter to an externaly powered USB hub, but nothing changed.

I also moved the skype adapter to another computer (a laptop) to rule out EMI interference. I put it close to the computer with the IR device and close to the IR device itself. This didn't affect the IR device at all, so it's some "internal" mayham with the com-port and USB.

The error is very consistent in itself. Connect the skype adatper and the IR will only recognize one signal out of about 20 or so. Disconnect the skype adapter and the IR device will recognize all signals transmitted from the remote.

I'm puzzled...

I've never heard of true USB interfering with a COM port. Is the Skype device a true USB device or does it use a virtual comm port? Even with a virtual port I can't see the driver messing with the COM port DCD line.

You can use your soundcard to see the IR signal but you'll need to attenuate the signal since you're pulling the output up to DCD which I think is

10-12V. For a 5V signal see...

There's free soundcard oscilloscope software at...

I would not entirely rule out EMI. You may need both devices using the same ground and power to see it.

Let me start out by saying I have no direct experience with Skype. I'm assuming you have an interference problem, and it's probably stray IR light. Do you have a electronic camera? First thing to do is to darken the room or wait until nighttime and check the IR again. Is it better in the dark? If not, look around the room through the electronic viewfinder. If anything's continuously emitting IR, it will be flashing bright blue. Use a handheld remote aimed at the camera to be certain it's IR sensitive.

Although, again, I am unfamiliar with their equipment, the symptoms you describe sound like the Skype unit may be emitting IR that's "stepping on" the IR signals. Are there any dark red plastic windows on the device anywhere? I get the same sort of "1 in 20" response when one of my powermids is getting direct sunlight and/or IR from somewhere. When the IR receiver powermid sees stray light, it then relays that "light noise" to the powermid facing the equipment stack and it really reduces the range and effectiveness of the local remote control. I can get the local remote to work, but only once in 10 tries or by getting right up on the receiver. Does your remote work if you hold it right up against the IR receiver? The stray light problem can be severe. It's why I have all my powermids on appliance modules, so that I can switch them off when I am in the "equipment" room operating the AV stuff locally and not via powermid.

Get a black plastic garbage back and first cover the Skype completely with it still on. Any better? If not, put your remote and your receiver in the bag and try them. If the reception is noticeably better, you've got stray IR exiting from somewhere.

You can try the same two tests with aluminum foil or a metal trashbasket big enough to shield the Skype unit and then your remote and receiver, in turn to check for radio interference but it sounds like you've tried that step.

-- Bobby G.

It may be that the Skype software is taking control of the PC's hardware timer and that WinLirc also needs the timer.

Bobby, thanks for your reply. I don't however think this has to do with stray IR light emitted from the skype adapter or som other source. The adapter doesn't have any IR transmitters and the behavior of the IR receiver doesn't change with the distance of the remote control either.

Dave, I'm not to good with electronics, so I don't really know what you're aiming at with the oscilloscope approach. I guess it would be of interest to "see" the IR signal from the receiver... It sounds very cool though :-)

That the problem should stem from a sharing problem of some resource like a hardware timer sounds very possible to me due to the "feel" of things. I'm not sure what a hardware timer is or what I should do to confirm that this is the problem though. I guess it comes down to how the skype and winlirc softwares are designed and therefore there is not much to do if you're right?

One idea I have to solve this is to buy or build an USB based IR receiver hoping that the skype adapter won't affect it. I can't really assess the risk with this approach.

I thought he said he had moved the Skype adapter to another computer - a laptop IIRC, and that the problems still continued. That tends to rule out USB device contention issues if the LIRC is on one PC and the Skype adapter on another but it's very likely I didn't read him correctly.

-- Bobby G.

It's fairly simple and would definitely tell us whether the signal is being corrupted. Connect a 100K resistor to your DCD line in the adapter with the other end going to the TIP of a 3.5mm stereo cable. Put a 10K resistor between TIP and GND (attach GND to your adapter GND also). You can then record the signal as a .WAV file.

There's a timer chip on the motherboard and anything that needs to precisely time intervals can call on it. I'm sure that's how WinLirc measures the duration of the pulses and spaces from the IR receiver. If Skype also uses the timer channels it might be interfering with WinLirc.

USB-UIRT is hard to beat. It does the decoding in hardware using its own timers so it outputs the end result and there's no need to use the PC's timer chip. If I'm guessing right about the timer, it should solve your problem. There's a forum on their web page - you can ask whether others use it successfully with the Skype device. I'm sure Girder can deal with its output.

You didn't read him correctly.

If you want to try it, I've modified the schematic. Just make sure you use Line-In as Mic inputs are wired differently.

I suspect that the USB driver (or possibly the Skype application) is preventing the serial port driver from emptying the 16550A FIFO before it wraps, resulting in lost characters. At 115200, the serial port driver must service a 16550A almost once every millisecond to avoid character loss. What speed is your IR interface? Do you have any flow control? Can you run it at a lower speed to see if that helps? I'm not familiar with how Windows handles serial ports, but on Unix systems, the serial port driver's interrupt handler is normally one of the highest interrupt priority interrupt handlers, and that's for a good reason, as 16550A type ports have more taxing real-time demands than every other peripheral on a standard PC system.

Look at the schematic.

With this hardware, WinLirc treats the DCD line as a digital input - it has nothing to do with the RS232 data line nor the FIFO. It's messing with the timer and/or disabling interrupts.

Thanks for your response Andrew. I have tried different settings in winlirc, among them the speed of the com port. It didn't have any effect on my problem.

I'll have a go at it.

Btw, the link to the modified schematics reports "404 - forbidden". I think I know what to do without it though.

About USB IR receivers, I found this one:

Does this also have an internal timer function?

If you double-click it from a news reader like Agent, it works fine. If you're using an HTML based reader, paste the URL into the browser.

The versions with a microcontroller probably do but USB-UIRT is heads and shoulders above anything else you will find and I know it works with Girder.

That makes it much worse -- there's no FIFO on the modem signals. If the application monitors DCD by spinning, then it's not likely to work with anything else running on the system. What sort of bit rate is the IR signal?

I misread your reply. I assumed when you said you had moved the adapter to another machine that you also unloaded the driver software. My advice at this point would be to uninstall all your USB and serial devices and reinstall them, starting with the most necessary or quarrelsome first, and that sounds like the Skype. If that didn't work, I might pick up a $20 USB card with a different chip than what's in your machine and would trying running Skype from a totally separate USB controller. Separate USB ports on a PC usually are connected to the same USB chip so changing from one port to another usually doesn't change much.

Without cost risk, the best you can hope for is find a driver configuration that suits your hardware. You may have some luck if you can detail the problem and report the issue to the Skype people. Have you contacted them?

When debugging drivers, I've found the newest ones are usually the most buggy and I start there. But the issue here could be any piece of USB or serial driver code running on your system. It just took the Skype driver to break the camel's back.

The results of your test sound like a resource contention problem where two different programs are vying for access to the same hardware. Lots of HW makers improve the apparent performance of their devices by breaking resource sharing rules. Sometimes that can be resolved with a change in the driver load order or the driver configuration or hardware settings, but often there's nothing to do but wait for an upgrade if you're married to the underlying hardware.

I would try an inexpensive USB hub that also contained a serial port connector before I took that route. Then I might buy $20 PCI USB card and try that while waiting for a reply from Skype. I'd also check for newer drivers for all the serial and USB devices on your system. As I said, the problem could be with any one of them and their interaction with your newest device. Good luck!

-- Bobby G.

Can you try using (or adding) a different USB host controller card? It may be an issue with the driver for your current USB ports. But then again, it may also be a problem with how the driver for the Skype is written.

You may also have a problem with how the IRQs are configured on the machine. Or even with how the IRQ handler driver software is set up. Things like VIA chipsets have been notorious for driver issues (but not them alone).

As has been suggested, your best best will most likely be to switch to using a USB IR device like the USB-UIRT. The winlirc device depends on monitoring the serial port in a way that's extremely dependent on timing. Anything that disrupts the timing (like a poorly written driver on a slow machine) will cause trouble. Moving to a device designed to properly handle IR signals is a better idea.

By the time you rejigger the IRQs, drivers, PCI cards and the like buying a USB-UIRT will seem like a bargain compared to the frustration.

-Bill Kearney