Remote control via infrared is not the aim of the Linux/IrDA project but is included in this HOWTO to cover "Linux and Infrared" more completely. I found three projects which worked on this topic. You may find some links to current information at http:// www.snafu.de/~wehe/index_li.html.
LIRC is a package that supports receiving and sending IR signals of the most common IR remote controls. It contains a device driver for hardware connected to the serial port, a daemon that decodes and sends IR signals using this device driver, a mouse daemon that translates IR signals to mouse movements and a couple of user programs that allow to control your computer with a remote control. Takahide Higuchi wrote about LIRC: "It's great, and it seems almost complete solution, but it seems there is almost nothing supporting hardware on the market (or need to solder some special circuit ... it is hard work for many people to do so). I believe that LIRC will be more popular if consumer IR support is implemented in FastIR drivers and some common API (for example, a raw IrSocket and common ioctls) is made!". You may find LIRC at http://fsinfo.cs.uni-sb.de/~columbus/lirc/
To subscribe to the LIRC mailing list send an email to <lirc-request@xmission.com> with the word "subscribe" in the body of the message. There is also a mailing list archive at http://www.wh9.tu-dresden.de/~heinrich/lirc/list-archive/
This is a simple, cheap device that can be connected to any serial port to control most components that have infrared remote controls. It was designed and built on a solderless breadboard and is finally designed as a PC board. You may find this package at http://www.armory.com/~spcecdt/remote/remote.html
Ryan Shillington wrote some tools to control the COREL Netwinder via infrared, for example:
Server Side for the Corel Palm Administrator (deamon). It depends on having ir-simple installed and up and running. With this you can check and change IP addresses, Gateway addresses, setup eth1, etc. You can also run simple commands AND you can check the Temperature, Memory, Load averages, etc.
Client Side for the Corel Palm Administrator. You can also run simple commands AND you can check the Temperature, Memory, Load averages, etc.
A very basic Infra Red device driver. This does not support IrDA (only unreliable transfers). It looks specifically for Remote Control signals (and Keyboard, etc.). It blocks and passes data up very differently.
You may find the tools at http://www.netwinder.org/~ryansh/
ir is an interface program to Chris Dodge's RedRat 2 infrared controller to send and receive infrared signals to/from consumer devices like TV's, VCR's, cable boxes, and stereos. It is written in Perl. It uses only the basic Perl constructs and no external packages, so it should work on any platform that supports Perl and serial communications. It can be accessed via the command line or cron, as an email handler (through aliases), or as a cgi script which will automatically generate a form with all possible codes. It has macro capability so one command can send a series of IR signals. With an X-10's IR543, it can be used to control X10 devices, too.
Two of the above mentioned projects use some kind of selfmade dongle for infrared remote control. There is also a description to build a serial IrDA dongle by yourself in the german ELEKTOR 5/97 p. 28 magazine. Maybe someone can merge these two kind of dongles together.
For a discussion of the relation between Infrared Remote Control and IrDA I quote from the Linux/IrDA mailing list (shortend and modified by wh):
Ryan Shillington wrote: "Remote IR and ASK-IR are very different from FIR or MIR or SIR.
Remote IR and ASK-IR are very low speed and low frequency (but very long range) uses for IR. They operate around 2400 baud.
SIR operates at higher rates, and is meant for long range transmission where you need more than a few characters pass through (unlike a remote control).
MIR is a little faster (less range), but with speeds up to 1.15 Mbps, and FIR (where the devices have to be practically touching) is 4Mbps. The range is inversely proportional to the speed you can send data at.
I'm working on drivers for Remote-IR, but you should know that your IR stuff has to support it. Look for protocols like NEC, RC-5 or RC-0 (those are the most common ones).
You can use SIR to receive Remote Control signals. Set your baud rate nice and low and data will come through. BUT, from my experience, it's not the RIGHT data. It's not being analyzed in the right way, and as such, you can't compute the checksums or check it with its complement.
I have managed to get data in (using SIR) with remote controls. I have been told that SIR will read the remote control stuff differently depending on temperature (although I have never had that experience). "
Lichen Wang <lwang1@ix.netcom.com> wrote in response: "The so-called ASKIR in most laptops etc. is not meant for remote IR devices. ASKIR is meant for Sharp Wizard and Zauaus PDAs and some of Sharp's notebook PCs. Sharp stated this long before IrDA was established and is still supporting it to maintain backward compatibility. Apple's Newton had this capability at one time, too.
Briefly, ASKIR uses 9.6 Kbps (19.2 and 38.4 Kbps are also possible) asynchronous data format of 8 data bits, 1 stop bit, and odd parity. The start bit as well as all 0 bit in data/parity are transmitted as IR square wave at 500 KHz (DASK sub-carrier). The stop bit as well as all 1 bit in data/parity are represented by the absence of any IR transmission.
As you can see, this is totally incompatible with existing IR remote control.
[..]
True. Not only can you use SIR hardware to receive, you can transmit, too. Of course, there are some limitations.
Most IR remote controls use 38 KHz sub-carrier. 3 times 38 is 114, very close to 115.2. You can set the UART to operate at 115.2 Kbps, 7 data bits, no parity, and 1 stop bit - a total of 9 bits. Each 3 cycles of the 38 KHz sub-carrier can be received or transmitted as a byte of 0x5B.
There are some physical limitations in addition to the fact that the sub-carrier must be 38 KHz. The SIR receiver is not as sensitive to 38 KHz as the IR remote receiver designed for that. The SIR transmitter has a much lower duty cycle and thus can not emit a strong sub-carrier either.
IR remote encodes the control signal by turning on and off the sub-carrier at certain specific patterns. Now that you can transmit and receive the sub-carrier, what remains is all in timing.
For transmit, you have to know how many consecutive bytes of 0x5B to send for each burst of the sub-carrier, and how long to be quiet between the bursts.
For receive, you have to know how many of the 0x5Bs you received are consecutive, and how long the gaps were between these groups of consecutive bytes.
[..]
My experience with the IrDA link distance of SIR, MIR and FIR is somewhat different from what Ryan said.
[..]
SIR, MIR and FIR should all work from 0 to 100 cm but in practice:
(a) Some devices may have problems at LONG distances.
When possible, place the two communicating devices no more than 50 cm apart. Low power devices, such as pagers, phones, etc. may have even shorter ranges despite the fact that they use SIR instead of MIR or FIR.
(b) Some devices may have problems at SHORT distances.
Place the two devices at least a few cm apart. Putting the two devices too close to each other can cause troubles.
It is somewhat intuitive that when the link is not reliable we put the two devices closer together. But it is counterintuitive that too close is not good either. The reason is that the light intensity at 1 cm is 10.000 times brighter than that at 100 cm. At 0.5 cm, it is 40.000 times, etc. The IR receiver manufacturers have difficulties to cover this huge dynamic range. We all have problems reading under a 10 W light bulb, but imagine how it feels under a 100.000 W light!
[..]
The IrDA Physical Layer is totally incompatible with the DASK modulation used in IR remote controls. Thus it is not possible to use the same controller function for both FIR and remote control. However, practically all FIR controller chips do include some additional functions to support remote control. National, SMC, and Winbond (just to name a few) all have such I/O chips.
The IR transmitter for FIR and remote control are very similar. I have tried a standard FIR transmitter. It can reach 10 meters for remote control purpose. Thus it performs just as good as transmitters designed for remote control.
The IR receiver for FIR and remote control are somewhat different. A FIR receiver can receive remote control signals but can reach only 1 meter whereas receivers designed for remote control typically can reach 10 meters.
I have an ISA bus adapter with a National I/O chip that supports both FIR and remote control. I also have IR Dongles that include both FIR and remote control receivers. (Plus a transmitter for both modes.) I cannot find any software to support remote control functions. I did my own experiments in DOS (I cannot run Linux yet.) Anybody interest in this? "
Benny Amorsen wrote: "I have a laptop that is supposed to support ASKIR. The mode of the infrared port can be switched to ASKIR in the BIOS. Having to reboot to switch the mode in the BIOS makes it useless, though, so someone would have to find a way to switch on the fly. "
Dag Brattli wrote: It should be possible to use IrControl (formerly IrBus) for IrDA compliant remote controls. I currently don't know about any remote controls using IrControl standard, but there should be some out there (anyone else who knows better?). You should go to the IrDA site (http://www.irda.org) and get the physical layer standard (which includes IrControl I think).
"Normal" IrDA (using IrLAP) is _not_ well suited for remote control because of the connection oriented nature (and just supports 9600bps for connectionless use). The reason for the limited range is eye-safety they say (but I currently don't know why CIR works better using the same power). I have however seen laptops connect at 4-5 meters (but I don't think that any high speed communication would be possible).
Most IrDA chipsets are capable of CIR operation, and it is quite easy to modify the drivers so they talk CIR. Takahide Higuchi has started to look at IrSockets and it would be great if we could open a "raw" Ir(DA) socket which then could send and receive CIR packets. Then all the CIR applications could live in userspace.
I know that Corel is interested in using CIR for controlling the NetWinder (and they actually have running code). Take a look at http://www.slashdot.org/articles/98/12/05/0916216.shtml or http://www.netwinder.org/~ryansh
From the "IrDA Data Link Design Guide" p. 21 by Hewlett-Packard http://www.hp.com/go/ir : " It is possible to transmit and receive signals other than IrDA signals with Hewlett-Packard IR transceivers. For implementation details, please refer to the Application Note, Transceiver Performance with ASK and TV Remote Signals."
From the IR-MAN page http://www.usuarios.com/ib308564/irda.html :
Fortunately, many IrDA devices are compatible with the 38-kbps ASK modulation used in TV remotes. This means that they can work with such kind of infrared type signals. ... However, it seems that there are still many portable computers that can't receive TV infrared stuff.
For desktop computers, there exist two options, depending on the motherboard you have. Usually a Pentium MoBo has an I/O chipset ready for infrared communication. There is a special connector where you can connect the transducer. The other option is buying a serial type transceiver that connects to the standard serial port (RS-232) of the computer. ... PC Remote Control has been tested with success using both type of IrDA devices:
1) IRmate IR-210 Serial Port Infrared Adapter. ... The serial port speed at wich the device sends recognizable data values is 2400 bps. I don't know if this speed will be the same for all the adapters of this type or is an unique characteristic of this model.
Look at the examples of data values received to see how similar are them. There are some infrared commands that change a lot every time, difficulting the recognition. In such cases, a great tolerance in the comparison could be used, but the risk of confusion between different commands will be increased. An apropiate tolerance value for almost all cases is 20.
2) Actisys IR2000L connected to an Asus P2B motherboard. ... There are several serial port speeds that work well, although 4800 bps seems to be the best one. Other adapters of this same type work also well using this speed. Take a look at the samples of data sequences received using this device. Some remote buttons send exactly the same sequence and it's impossible to distinguish between them at all.
3) Asus IR-eye connected to the same MoBo as above. It works as well as the Actisys device.
TV remotes send commands only one way, in a low-speed burst for distances of up to 30 feet. They use directed IR with LEDs that have a moderate cone angle to improve ease-of-use characteristics. Cordless connectivity via IrDA transfers files, point-to-point and bidirectionally, in a high-speed burst for short distances using directed IR with LEDs having a narrow cone angle. IrDA transmissions require relatively careful aiming, and they're easy to block. For this reason, don't expect a great distance while working with the remote unit.
Alessio Massaro <Alessio.Massaro@cern.ch>: wrote: " IrDA doesn't talk to tv-remotes, but it does have the IrCOMM layer to emulate a serial i/f. My guess is that to get LIRC working with it, you should just need ... to read from the IrCOMM virtual serial device (as you would with a /dev/cua or whatever) and use a remote that can be seen by your dongle+IrDAheader pair."
Answer by Dag Brattli: "You are talking about being normal serial ports, but that is something at least I have choosen IrDA not to be. I have implemented all the device drivers as network device drivers, so things are a bit different (more frame oriented). The device drivers deliver IrDA frames and currently nothing else.
But I don't think that we must have a tty interface to the IrDA device drivers in order to support more RAW reads and writes. And btw. forget about IrCOMM, it has nothing to do with this issue.
I have actually already implemented support for raw reads and writes for the device drivers, since some of the dongles require this."