Linux Infrared HOWTO

Werner Heuser

v3.3, 2001-04-22


Table of Contents
Preface
1. About the Document and the Author
2. Status of the Document
I. IrDA
1. About the Linux/IrDA Project
2. Getting Started
3. Specific Connections and IrDA - Protocols
4. Hardware Supported by Linux/IrDA
5. Advanced Topics
II. Infrared Remote Control
6. Introduction
7. Linux Infrared Remote Control - LIRC
8. Lego Mindstorm
9. Serial Infrared Remote Controller
10. Infrared Tools for the COREL Netwinder PC
11. ir
12. irmctl
13. IRManager
14. irXxD
15. gmd
16. Infrared Remote Control - IrDA
III. Appendix
A. Credits
B. Revision History
C. Serial Infrared Port Sniffers
D. Infrared Light and Eye Safety
E. Copyrights, Disclaimer, Trademarks
List of Figures
5-1. IrDA Stack

Preface

1. About the Document and the Author

 

Better red, than dead.

  Unknown AuthorEss

This document is based on the How to use part of the Linux/IrDA project homepage and the Linux/IrDA Tutorial by Jean Tourillhes. I have also included material provided by the Linux/IrDA core team, the Linux/IrDA mailing list and other sources.

The document is included in the LINUX DOCUMENTATION PROJECT - LDP .

The latest version of this document is available at MobiliX-HOWTOs. You may find my Linux-Mobile-Guide (the former Laptop-HOWTO), the Linux-Ecology-HOWTO and the Linux-Medicine-HOWTO there also.

Mathieu Arnold provides an earlier version of the IR-HOWTO in French.

Please feel free to contact me for comments or questions about the HOWTO. I know this material is not finished or perfect, but I hope you find it useful anyway. For other questions and current information about Linux/IrDA please ask in the Linux/IrDA mailing list as explained below.

<Werner Heuser>


Chapter 2. Getting Started

2.1. Software

The commands provided by the irda-utils package are the basic set of tools to get a working IrDA connection. The other tools (e-Squirt, IrNET, ..) are optional. The programms don't have manpages yet. You may use my man pages instead, see MobiliX - Software.


2.1.1. IrDA-Utils


2.1.1.3. Contents of Linux/IrDA-Utils


2.1.1.3.2. irdadump

A program that displays all the frames sent, and received on the infrared link.

One advantage of implementing IrDA device drivers as network device drivers is that you should be able to attach sniffers to the device (or actually the packet type). That way, it is possible to use a really handy utility called irdadump (instead of tcpdump). This will make debugging MUCH easier. Linux-2.2 implements the BPF (Berkeley Packet Filter), so its possible to filter out exactly the frames you want to see.

Note: You probably have to be root for using irdadump . CONFIG_PACKET has to be enabled in the kernel. If compiled as a module you might load the module manually. irdadump has been converted into a library, so it can be used from GUI applications as well.

Here is a sample output of a small session between Linux and a Palm III. This log shows that the local irobex layer is not responding, so the Palm III sends a disc frame.
dagbnb /home/dagb/linux/irda-utils/irdadump/ # ./irdadump

20:18:15.305711 xid:cmd:saddr=0x05c589 > daddr=0xffffffff,S=6,s=0
20:18:15.385597 xid:cmd:saddr=0x05c589 > daddr=0xffffffff,S=6,s=1
20:18:15.465568 xid:cmd:saddr=0x05c589 > daddr=0xffffffff,S=6,s=2
20:18:15.545953 xid:cmd:saddr=0x05c589 > daddr=0xffffffff,S=6,s=3
20:18:15.625574 xid:cmd:saddr=0x05c589 > daddr=0xffffffff,S=6,s=4
20:18:15.705575 xid:cmd:saddr=0x05c589 > daddr=0xffffffff,S=6,s=5
20:18:15.785601 xid:cmd:saddr=0x05c589 > daddr=0xffffffff,S=6,s=255,info=Linux
20:18:18.075526 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=0
20:18:18.225498 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=1
20:18:18.375495 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=2
20:18:18.526355 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=3
20:18:18.675614 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=4
20:18:18.676364 xid:rsp:saddr=0x05c589 > daddr=0xb50c14b,S=6,s=4
20:18:18.765506 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=5
20:18:18.927221 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=255,info=Palm III
20:18:18.975796 snrm:cmd,ca=0xfe,pf=1
20:18:18.976534 ua:rsp,ca=0x58,pf=1
20:18:18.977145 ua:rsp,ca=0x58,pf=1
20:18:19.585627 rr:rsp,ca=0x58,nr=0,pf=1
20:18:19.585810 rr:rsp,ca=0x58,nr=0,pf=1
20:18:19.606413 i:cmd,ca=0x58,nr=0,ns=0,pf=1
20:18:19.606582 rr:rsp,ca=0x58,nr=1,pf=1
20:18:19.627708 rr:cmd,ca=0x58,nr=0,pf=1
20:18:19.627871 i:rsp,ca=0x58,nr=1,ns=0,pf=1
20:18:19.650571 disc:cmd,ca=0x58,pf=1
20:18:19.650736 ua:rsp,ca=0x58,pf=1
20:18:21.165524 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=0
20:18:21.315608 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=1
20:18:21.315793 xid:rsp:saddr=0x05c589 > daddr=0xb50c14b,S=6,s=1
20:18:21.395499 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=2
20:18:21.545516 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=3
20:18:21.695500 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=4
20:18:21.845840 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=5
20:18:22.007222 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=255,info=Palm
III
20:18:22.056143 snrm:cmd,ca=0xfe,pf=1
20:18:22.056310 ua:rsp,ca=0xc8,pf=1
20:18:22.056381 ua:rsp,ca=0xc8,pf=1

37 pacckets received by filter


2.1.2. openobex

The overall goal of the OpenOBEX project is to make an open source implementation of the Object Exchange (OBEX) protocol. OBEX is a session protocol and can best be described as a binary HTTP protocol. A typical application is the "beam" function of PalmOS.


2.1.3. e-squirt

e-Squirt is a simple protocol for sending URLs over the IrDA medium. This allows for interaction with CoolTown enabled devices.


2.1.4. IrNET for Linux-IrDA

IrNET is a protocol allowing to carry TCP/IP traffic between two IrDA peers in an efficient fashion. It is a thin layer, passing PPP packets in a IrTTP socket. It uses PPP in synchronous mode for efficiency, and offers lots of flexibility and various features. The main part of IrNET in included in kernel 2.4.x, and a user-space daemon (to automate connections) is available on the web page.


2.1.5. Java - IrDA Interface

This Java Infrared Socket API provides a way of communicating through infrared medium on a linux machine using Java. Thus, Java application developers can develop applications involving infrared access much easily. The API is very similar to java.net.Socket API and has been implemented using the Linux infrared stack. Both connection oriented streams (IrSocket and IrServerSocket) and connectionless Ultra (UltraSocket, UltraPacket) interfaces are available.


2.2. Kernel

2.2.1. Preface

Please read the Kernel-HOWTO to get more information about the compilation process. Get the latest patches from http://irda.sourceforge.net or the Linux/IrDA mailing list archiv.

You'll find the Linux/IrDA code in:

/usr/src/linux/net/irda (protocol stuff)

/usr/src/linux/drivers/net/irda (device drivers)

/usr/src/linux/include/net/irda (header files)

General Parameters Make sure you use kernel 2.4.x sources. If unsure about your kernel version try uname -r.

Get the latest kernel patch from the Linux/IrDA project . Or from the Alan Cox kernel series . Put it into /usr/src or where else your kernel sources live and apply something like (replace patch-2_2.0-irdaXXX with the actual file name):
cd /usr/src
tar xvzf patch-2_2.0-irdaXXX.tar.gz
cd linux
patch -p1 -l < ../patch-2_2.0-irdaXXX
For latest drivers maybe experimental support has to be enabled CONFIG_EXPERIMENTAL.

Enable sysctl in "General Setup" CONFIG_SYSCTL.

You should have proc file system support CONFIG_PROC_FS.

Also serial support for the SIR features CONFIG_SERIAL.

I am not sure whether there has to be printer support for using a printer with Linux/IrDA CONFIG_PRINTER. But I assume this feature is not necessary.

Networking support _must_ be enabled CONFIG_NET.

Make sure you have module support CONFIG_MODULES in your kernel! Test it e.g. with lsmod.

Also kerneld support CONFIG_KERNELD. But kmod (CONFIG_KMOD) also works. A monolithic kernel seems to work, too. But modules are highly recommended!

To use irdadump you probably have to set CONFIG_PACKET.

If you only apply the Linux/IrDA patch, you should not have to do a make clean, so that should save you some time. I suggest you do something like this:

make dep && make all && make modules && make install && make modules_install If you get really strange errors, then try to rebuild from scratch after a make clean.


2.2.2. IrDA Specific Parameters

The following is from ../linux-2.4.3/Documentation/Configure.help Please consult the latest available kernel documentation for current information and new drivers.


2.2.2.1. IrDA subsystem support

CONFIG_IRDA Say Y here if you want to build support for the IrDA (TM) protocols. The Infrared Data Associations (tm) specifies standards for wireless infrared communication and is supported by most laptops and PDA's.

To use Linux support for the IrDA (tm) protocols, you will also need some user-space utilities like the irmanager and probably irattach as well. For more information, see the file Documentation/networking/irda.txt. You also want to read the IR-HOWTO, available at http://www.linuxdoc.org/docs.html#howto .

This support is also available as a module called irda.o. If you want to compile it as a module, say M here and read Documentation/modules.txt.

IrDA Cache last LSAP

CONFIG_IRDA_CACHE_LAST_LSAP Say Y here if you want IrLMP to cache the last LSAP used. This makes sense since most frames will be sent/received on the same connection. Enabling this option will save a hash-lookup per frame.

If unsure, say Y.

IrDA Fast RR's

CONFIG_IRDA_FAST_RR Say Y here is you want IrLAP to send fast RR (Receive Ready) frames when acting as a primary station. This will make IrLAP send out a RR frame immediately when receiving a frame if its own transmit queue is currently empty. This will give a lot of speed improvement when receiving much data since the secondary station will not have to wait the max. turn around time before it is allowed to transmit the next time. If the transmit queue of the secondary is also empty the primary will back off waiting longer for sending out the RR frame until the timeout reaches the normal value. Enabling this option will make the IR-diode burn more power and thus reduce your battery life.

If unsure, say N.

IrDA Debug

CONFIG_IRDA_DEBUG Say Y here if you want the IrDA subsystem to write debug information to your syslog. You can change the debug level in /proc/sys/net/irda/debug

If unsure, say Y (since it makes it easier to find the bugs).

IrLAP Compression support

CONFIG_IRDA_COMPRESSION Compression is _not_ part of the IrDA(tm) protocol specification, but it's working great! Linux is the first to try out compression support at the IrLAP layer. This means that you will only benefit from compression if you are running a Linux <-> Linux configuration.

If you say Y here, you also need to say Y or M to a compression protocol below.

IrLAP Deflate Compression Protocol (EXPERIMENTAL)

CONFIG_IRDA_DEFLATE Say Y here if you want to build support for the Deflate compression protocol. The deflate compression (GZIP) is exactly the same as the one used by the PPP protocol.

If you want to compile this compression support as a module, say M here and read Documentation/modules.txt. The module will be called irda_deflate.o.

IrLAN Protocol

CONFIG_IRLAN Say Y here if you want to build support for the IrLAN protocol. If you want to compile it as a module (irlan.o), say M here and read Documentation/modules.txt. IrLAN emulates an Ethernet and makes it possible to put up a wireless LAN using infrared beams.

The IrLAN protocol can be used to talk with infrared access points like the HP NetbeamIR, or the ESI JetEye NET. You can also connect to another Linux machine running the IrLAN protocol for ad-hoc networking!

IrCOMM Protocol

CONFIG_IRCOMM Say Y here if you want to build support for the IrCOMM protocol. If you want to compile it as a module (you will get ircomm.o and ircomm-tty.o), say M here and read Documentation/modules.txt. IrCOMM implements serial port emulation, and makes it possible to use all existing applications that understands TTY's with an infrared link. Thus you should be able to use application like PPP, minicom and others. Enabling this option will create two modules called ircomm and ircomm-tty.


2.2.2.2. Device Drivers

IrTTY IrDA Device Driver

CONFIG_IRTTY_SIR Say Y here if you want to build support for the IrTTY line discipline. If you want to compile it as a module (irtty.o), say M here and read Documentation/modules.txt. IrTTY makes it possible to use Linux's own serial driver for all IrDA ports that are 16550 compatible. Most IrDA chips are 16550 compatible so you should probably say Y to this option. Using IrTTY will however limit the speed of the connection to 115200 bps (IrDA SIR mode)

If unsure, say Y.

IrPORT IrDA Device Driver

CONFIG_IRPORT_SIR Say Y here if you want to build support for the IrPORT IrDA device driver. If you want to compile it as a module (irport.o), say M here and read Documentation/modules.txt. IrPORT can be used instead of IrTTY and sometimes this can be better. One example is if your IrDA port does not have echo-canceling, which will work OK with IrPORT since this driver is working in half-duplex mode only. You don't need to use irattach with IrPORT, but you just insert it the same way as FIR drivers (insmod irport io=0x3e8 irq=11). Notice that IrPORT is a SIR device driver which means that speed is limited to 115200 bps.

If unsure, say Y.

Winbond W83977AF IrDA Device Driver

CONFIG_WINBOND_FIR Say Y here if you want to build IrDA support for the Winbond W83977AF super-io chipset. This driver should be used for the IrDA chipset in the Corel NetWinder. The driver supports SIR, MIR and FIR (4Mbps) speeds.

If you want to compile it as a module, say M here and read Documentation/modules.txt. The module will be called w83977af_ir.o.

NSC PC87108 IrDA Device Driver

CONFIG_NSC_FIR Say Y here if you want to build support for the NSC PC87108 and PC87338 IrDA chipsets. This driver supports SIR, MIR and FIR (4Mbps) speeds.

If you want to compile it as a module, say M here and read Documentation/modules.txt. The module will be called nsc-ircc.o.

Toshiba Type-O IR Port Device Driver

CONFIG_TOSHIBA_FIR Say Y here if you want to build support for the Toshiba Type-O IR chipset. This chipset is used by the Toshiba Libretto 100CT, and many more laptops. If you want to compile it as a module, say M here and read Documentation/modules.txt. The module will be called toshoboe.o.

SMC IrCC (Experimental)

CONFIG_SMC_IRCC_FIR Say Y here if you want to build support for the SMC Infrared Communications Controller. It is used in the Fujitsu Lifebook 635t and Sony PCG-505TX. If you want to compile it as a module, say M here and read Documentation/modules.txt. The module will be called smc-ircc.o.

ALi M5123 FIR Controller Driver (Experimental)

CONFIG_ALI_FIR Say Y here if you want to build support for the ALi M5123 FIR Controller. The ALi M5123 FIR Controller is embedded in ALi M1543C, M1535, M1535D, M1535+, M1535D Sourth Bridge. This driver supports SIR, MIR and FIR (4Mbps) speeds.

If you want to compile it as a module, say M here and read Documentation/modules.txt. The module will be called ali-ircc.o.

Serial dongle support

CONFIG_DONGLE Say Y here if you have an infrared device that connects to your computer's serial port. These devices are called dongles. Then say Y or M to the driver for your particular dongle below.

Note that the answer to this question won't directly affect the kernel: saying N will just cause this configure script to skip all

ESI JetEye PC Dongle

CONFIG_ESI_DONGLE Say Y here if you want to build support for the Extended Systems JetEye PC dongle. If you want to compile it as a module, say M here and read Documentation/modules.txt. The ESI dongle attaches to the normal 9-pin serial port connector, and can currently only be used by IrTTY. To activate support for ESI dongles you will have to start irattach like this: irattach -d esi.

ACTiSYS IR-220L and IR220L+ dongle

CONFIG_ACTISYS_DONGLE Say Y here if you want to build support for the ACTiSYS IR-220L and IR220L+ dongles. If you want to compile it as a module, say M here and read Documentation/modules.txt. The ACTiSYS dongles attaches to the normal 9-pin serial port connector, and can currently only be used by IrTTY. To activate support for ACTiSYS dongles you will have to start irattach like this: irattach -d actisys or irattach -d actisys+.

Tekram IrMate 210B dongle

CONFIG_TEKRAM_DONGLE Say Y here if you want to build support for the Tekram IrMate 210B dongle. If you want to compile it as a module, say M here and read Documentation/modules.txt. The Tekram dongle attaches to the normal 9-pin serial port connector, and can currently only be used by IrTTY. To activate support for Tekram dongles you will have to start irattach like this: irattach -d tekram.

Greenwich GIrBIL dongle

CONFIG_GIRBIL_DONGLE Say Y here if you want to build support for the Greenwich GIrBIL dongle. If you want to compile it as a module, say M here and read Documentation/modules.txt. The Greenwich dongle attaches to the normal 9-pin serial port connector, and can currently only be used by IrTTY. To activate support for Greenwich dongles you will have to insert irattach -d girbil in the /etc/irda/drivers script.

Parallax Litelink dongle

CONFIG_LITELINK_DONGLE Say Y here if you want to build support for the Parallax Litelink dongle. If you want to compile it as a module, say M here and read Documentation/modules.txt. The Parallax dongle attaches to the normal 9-pin serial port connector, and can currently only be used by IrTTY. To activate support for Parallax dongles you will have to start irattach like this irattach -d litelink.

Old Belkin dongle

CONFIG_OLD_BELKIN_DONGLE Say Y here if you want to build support for the Adaptec Airport 1000 and 2000 dongles. If you want to compile it as a module, say M here and read Documentation/modules.txt. The module will be called old_belkin.o. Some information is contained in the comments at the top of drivers/net/irda/old_belkin.c.


2.3. Kernel Module Options

This survey of module options was generated with the modinfo command.

actisys.o
Dag Brattli <dagb@cs.uit.no> - Jean Tourrilhes <jt@hpl.hp.com>
ACTiSYS IR-220L and IR-220L+ dongle driver

ali-ircc.o
Benjamin Kong <benjamin_kong@ali.com.tw>
ALi FIR Controller Driver
io int array (min = 1, max = 4), description "Base I/O addresses"
irq int array (min = 1, max = 4), description "IRQ lines"
dma int array (min = 1, max = 4), description "DMA channels"

esi.o
Dag Brattli <dagb@cs.uit.no>
Extended Systems JetEye PC dongle driver

girbil.o
Dag Brattli <dagb@cs.uit.no>
Greenwich GIrBIL dongle driver

irport.o
Dag Brattli <dagb@cs.uit.no>
Half duplex serial driver for IrDA SIR mode
io int array (min = 1, max = 4), description "Base I/O adresses"
irq int array (min = 1, max = 4), description "IRQ lines"

irtty.o
Dag Brattli <dagb@cs.uit.no>
IrDA TTY device driver
qos_mtt_bits int, description "Minimum Turn Time"

litelink.o
Dag Brattli <dagb@cs.uit.no>
Parallax Litelink dongle driver

nsc-ircc.o
Dag Brattli <dagb@cs.uit.no>
NSC IrDA Device Driver
qos_mtt_bits int, description "Minimum Turn Time"
io int array (min = 1, max = 4), description "Base I/O addresses"
irq int array (min = 1, max = 4), description "IRQ lines"
dma int array (min = 1, max = 4), description "DMA channels"
dongle_id int, description "Type-id of used dongle"

old_belkin.o
Jean Tourrilhes <jt@hpl.hp.com>
Belkin (old) SmartBeam dongle driver

smc-ircc.o
Thomas Davis <tadavis@jps.net>
SMC IrCC controller driver
ircc_dma int, description "DMA channel"
ircc_irq int, description "IRQ line"

tekram.o
Dag Brattli <dagb@cs.uit.no>
Tekram IrMate IR-210B dongle driver

toshoboe.o
James McKenzie <james@fishsoup.dhs.org>
Toshiba OBOE IrDA Device Driver
max_baud int

w83977af_ir.o
Dag Brattli <dagb@cs.uit.no>
Winbond W83977AF IrDA Device Driver
qos_mtt_bits int, description "Mimimum Turn Time"
io int array (min = 1, max = 4), description "Base I/O addresses"
irq int array (min = 1, max = 4), description "IRQ lines"

irda.o
Dag Brattli <dagb@cs.uit.no>
The Linux IrDA Protocol Subsystem
irda_debug_R07c03e02 long

irlan.o
Dag Brattli <dagb@cs.uit.no>
The Linux IrDA LAN protocol
eth int, description "Name devices ethX (0) or irlanX (1)"
access int, description "Access type DIRECT=1, PEER=2, HOSTED=3"

ircomm-tty.o
Dag Brattli <dagb@cs.uit.no>
IrCOMM serial TTY driver

ircomm.o
Dag Brattli <dag@brattli.net>
IrCOMM protocol

irnet.o
<none>
<none>


2.4. Configuration


Chapter 3. Specific Connections and IrDA - Protocols

3.1. Stating the IrDA Stack

There are three sorts of low level drivers: SIR, dongle and FIR. If the right driver is detected by the kernel you get a message like:


3.1.1. SIR


3.1.2. Dongle Connection - Infrared Adapters for the Serial Port

The currently supported dongles are the Extended Systems Inc. ESI-9680 JetEye, the Tekram IRmate 210B, the ACTiSYS IR220L and 220L+, the Greenwich GIrBIL. dongle.

Dag Brattli wrote (modified by wh): "To use dongles you have to do something like this:
modprobe tekram         # or esi or actisys
irattach -d tekram      # or -d esi or -d actisys
modprobe is not necessary, if /etc/modules.conf is correct. As you can see, you must still use the -d option with irattach since it is possible to have two serial ports using different dongles at the same time (so the tty you are binding must know which dongle it is supposed to use). So if you have two dongles and two serial ports, you could do something like this:
modprobe tekram
modprobe esi
irattach /dev/ttyS0 -d esi &
irattach /dev/ttyS1 -d tekram &
PS: I would not try to turn the two dongles against each other, since I really don't know how the stack would react :-) ... Since I don't have any of these new ACTiSYS 220L+ dongles, I'm not able to test it. Since the new dongle has support for one extra speed (38400bps), you must specify the dongles differently with irattach so that the kernel knows which dongle you are using (and what QoS can be used):
irattach /dev/ttyS0 -d actisys     # for the 220L dongle
irattach /dev/ttyS0 -d actisys+    # for the 220L+ dongle
The current implementation of dongle support does not have any state associated with it, so its not possible to use both ACTiSYS dongles (220L and 220L+) at the same time (connected to two serial ports) for now. If someone needs to be able to do so, please mail me (Dag Brattli) and I will think about it!"

Note: When I tried to use an infrared modem (Swissmod 56Ki, manufactured by Telelink AG) connected to my laptop (IrDA works with Window$95 only, due to non standard hardware) I had to remove the infrared support in the BIOS to get it working!

Dag Brattli: "It is now possible to use irport instead of irtty! I have moved all the dongle stuff out of irtty and into irda_device, so it will also be possible to attach dongles to irport. Need however to make a small user-space utility dongle_attach that can be used to attach dongles to a specific driver instance. BTW: irattach is still working as before, and you will not notice the difference even when attaching dongles to irtty (I've just redirected the dongle ioctl to irda_device). Irport may be interesting since you avoid one software interrupt (bh) level, and it's also forced to work in half duplex mode so you don't get any echo if the irda port itself don't have echo-cancellation (girbil dongle and HP-4000 etc) ... To use it, you must supply the parameters to modprobe like this: modprobe irport io=0x3f8 irq=4, or whichever values you use. You can also add these parameters to /etc/conf.modules like this: options irport io=0x3f8 irq=4, but then you must remember to do a depmod -a and use modprobe irport instead of modprobe."

Alvin Loh: "Anyone with a ESI 9680C can use both parallax's and ESI's signalling scheme, meaning they can use Parallax's driver with ESI9680C to work. "


3.2. Printer Connection - IrLPT, IrTTP, IrCOMM?

IrLPT seems to be replaced by IrCOMM. Sorry I don't have tested this yet. So this is only the remaining part from former IrLPT support. Please see mailing list archive for further information.

Takahide Higuchi reported: " I have been debugging IrCOMM with a printer ( Canon BJC-80v ) with IrDA port and IrCOMM protocol (not IrLPT). I can print a short e-mail text though, it easily causes dead lock when I try to print a postscript with gs."

From the page of Thomas Davis http://www.jps.net/tadavis/irda : To use the IrLPT server, you need to perform the following steps:
/sbin/modprobe irlpt_server
/sbin/mknod /dev/irlptd c 10 `grep irlptd /proc/misc|cut -f 1`
At this point, the IrLPT server is ready to recieve print jobs; now; all you need is this simple shell script
#/bin/sh
#
while (true)
do
cat /dev/irlptd | lpr
done
Dag Brattli: I hope that this will make it easier for all you that prefer to live in user-space, to make your own IrDA applications and try it out. Some printers actually use IrTTP (because of the limitations of IrLPT), so now you can write your own small user-space printer client so you can talk to it:
int discover_devices(int fd)
{
    struct irda_device_list *list;
    unsigned char buf[sizeof(struct irda_device_list) +
          sizeof(struct irda_device_info) * MAX_DEVICES];
    int len;
    int daddr;
    int i;

    len = sizeof(struct irda_device_list) +
      sizeof(struct irda_device_info) * MAX_DEVICES;
    list = (struct irda_device_list *) buf;

    if (getsockopt(sfd, SOL_IRLMP, IRLMP_ENUMDEVICES, buf, &len)) {
    perror("getsockopt");
    exit(-1);
    }
    if (len > 0) {
    /*

Just pick the first one, but we should really ask the user
     */
    daddr = list->dev[0].daddr;

    printf("Discovered: (list len=%d)\n", list->len);

    for (i=0;i<list->len;i++) {
        printf("  name:  %s\n", list->dev[i].info);
        printf("  daddr: %08x\n", list->dev[i].daddr);
        printf("  saddr: %08x\n", list->dev[i].saddr);
        printf("\n");
    }
    }
    return daddr;
}

void client()
{
    struct sockaddr_irda peer;
    int addrlen = sizeof(struct sockaddr_irda);
    int daddr, actual;
    char buf[1024];

    fd = socket(AF_IRDA, SOCK_STREAM, 0);

    daddr = discover_devices(fd);

    peer.sir_family = AF_IRDA;
    strcpy(peer.sir_name, "P1284");
    peer.sir_addr = daddr;

    connect(fd, (struct sockaddr *) &daddr, sizeof(struct sockaddr_irda));

    /* Try to send something */
    actual = send(fd, "Testing", 8, 0);

    /* Try to read reply */
    actual = recv(fd, buf, 1024, 0);
}


3.3. LAN Connection - IrLAN


3.5. Palm III Connection - IrCOMM

Wessel de Roode wrote: The Palmpilot is default locked on 57k. You can however if you write your own software for the Pilot, use the 115k line settings. I quote a part from the irlib.h:
---------- irlib.h from the SDK 3.0 from palmpilot -----
// Options values for IrOpen
#define irOpenOptBackground     0x80000000   // Unsupported background task use
#define irOpenOptSpeed115200    0x0000003F   // sets max negotiated baud rate
#define irOpenOptSpeed57600     0x0000001F   // default is 57600
#define irOpenOptSpeed9600      0x00000003
Peter Pregler reported: If the Palm enters the range of the irda-device a popup appears with the text "Transmission: waiting for sender"

Ron Choy answered: There is a software called ShutupIR that is supposed to help with this problem of annoying popup http://hp.vector.co.jp/authors/VA005810/irda/shutup10.zip I haven't tried it but it looks like it would fix your problem.


3.6. Linux Terminal on Palm (Handspring Visor) via IR

by Chris Morris on Linux/IrDA list: In addidtion to using IR to hotsync my Handspring Visor I got my Handspring visor to work as a linux text terminal via infrared last night. My computer is a Dell Inspiron 3800 (BTW I wracked my brains for weeks trying to get IR to work under the 2.4.0 kernel. The whole problem was caused by Linux looking at the wrong IRQ for ttyS3 . Maybe the IR HOWTO should mention that at some point.). I am using Beam Sync for Visor V1.0b2 by Hacker Dude-san. N.N. and MTerm by Shigeyuki Seko (seko@.jps.net). On the laptop I have IR set to SIR mode and COM 3 via BIOS. I have to set /dev/ttyS3 to IRQ3 via setserial /dev/ttyS3 irq 3 on boot up. After boot up I do a:
/sbin/modprobe irda
/sbin/modprobe irtty
/sbin/modprobe ircomm
/sbin/ircomm-tty
/usr/sbin/irattach /dev/ttyS3 -s
cat /proc/net/irda/discovery shows the visor as IrComm Now /etc/mgetty+fax/mgetty.conf has to have these options: port ttyS3 direct y speed 9600 , faster maybe possible but only 9600 worked for me so far toggle-dtr n Then in /etc/inittab: palm:235:respawn: /sbin/mgetty ircomm0 After all of this I can start MTerm, issue a '/sbin/init q' then send a few <CR> from the Visor and I get a text termianl login. While composing this email I found a previously undiscovered website that seems most helpful: http://abgruen.de/palm/palm-ppp-mini.txt


3.8. Connecting from Linux to WinCE

Submitted by Arthur Tyde and Bryan Abshier of Linuxcare Inc.

This will tell you how to set up a masqueraded PPP connection via. IrDA from WinCE to a Linux based notebook computer. Once you are IP connected, the rest is up to you. We put this together as a guide for Sony notebook users with Casio E-100/105 PDA's, though the procedure should work for any WinCE 2.11 device with infrared capabilities talking to any notebook. Do all the Linux side testing signed on as root, standard warnings apply.

Configure WinCE Configure a network connection for your WinCE device. Go into "Connections" and create a "Direct Connection" Name it something meaningful, for device select "Infrared Port". Go into settings and change the baud rate to 115200, this is the max for WinCE. Go to TCP/IP settings and check "Use server-assigned IP address," and "Use software compression," and "Use IP header compression" Make sure "Use Slip," is unchecked. For Name Servers, make sure "Use server-assigned addresses" is checked. Go to Start, Settings, Communications, Identification and enter something for the Device Name. (I used "cetoy") You most likely already have these values set if you have synced with a Win9x desktop using Activesynch.

Configure Linux/IrDA Set up IrDA support on your notebook (described elsewhere) and get to the point where your notebook will discover an IrDA compliant device. A good sign is the irda0 device will show up when you execute ifconfig. It will not have an IP address, this is ok.

Setup the Connection Test the discovery by setting an IrDA device in range of your IR port, wait 5 seconds, and;

cat /proc/net/irda/discovery

For example, the Ericsson I888 World Phone with IR port enabled should immediately show something like this;

"name:I 888 WORLD   ,hint:0x9104,saddr:0x838470e5,daddr:0x152dceaa"
Your WinCE machine will not be discovered unless it's actively looking for a connection. So, if you want to test with WinCE position your device and double tap on the network icon you created in step 2, you should see something like this:

"name:mytoy,hint:0x8204,saddr:0x838470e5,daddr:0x00000b72"
The name displayed will be whatever value you have entered into the Start, Settings, Communications, Identification as the Device Name. At this point, with basic IrDA functioning- we can move on to establishing a PPP connection for WinCE. These scripts can also be used for serial cable connects. Create the following files and copy them into the directory indicated.

/usr/sbin/cebox.sh - make it executable
#!/bin/sh
pppd call cebox
Because Microsoft likes to break standards, you need the following chat script. This will feed WinCE the proper ASCII keywords it wants before allowing a PPP connection.

/etc/ppp/cebox.chat
TIMEOUT 3600
"CLIENT"    "CLIENT\c"
""      "SERVER\c"
The following file will allow you to specify the IP addresses, IR (or serial port if using a cable) device, DNS and so forth. I do not recommend you change the 192.IP addresses below. WinCE really has an affection for 192.168.55.100 because all the MS synch tools seem to have it hardcoded. DNS can be whatever you normally use.

/etc/ppp/peers/cebox
/dev/ircomm0 115200 crtscts
connect '/usr/sbin/chat -v -f /etc/ppp/cebox.chat'
noauth
local
192.168.55.101:192.168.55.100
ms-dns 10.2.0.1

Testing the connection Ok, now you can test the connection to make sure it all works. Reboot your machine, run irattach /dev/ttyS2 -s 1 (/dev/ttyS2 being the serial port your BIOS sees the IR device as, if irattach is not running, start it) Align the IR ports, at the Linux command prompt type /usr/sbin/cebox.sh, and simultaneously press return to start cebox and double tap your connection icon in WinCE. You should get a happy message from WinCE reporting Connecting to Host, Device Connected, Authenticating User, User Authenticated and finally Connected. You should see something like this when you are connected:
irda0     Link encap:IrLAP  HWaddr 06:89:d0:58
      UP RUNNING NOARP  MTU:2048  Metric:1
      RX packets:246 errors:0 dropped:0 overruns:0 frame:0
      TX packets:251 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:8

ppp0      Link encap:Point-to-Point Protocol
      inet addr:192.168.55.101 P-t-P:192.168.55.100 Mask:255.255.255.255
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
      RX packets:10 errors:0 dropped:0 overruns:0 frame:0
      TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:10
The following script sets up IrDA, establishes a ppp connection with WinCE, and then sets up IP masquerading. It is provided as an example of how you can tie this all together. This is more or less a manual approach. You can get creative, start irattach at boot and stick a line in inittab to constantly look for a WinCE connection on the IR port. This will however, run down your batteries and limit your ability to access other IR gadgets. I just use the script below. Position the device, run wince and start communications on your PDA when the script tells you to.

/usr/local/bin/wince - make this executable
#!/usr/bin/perl
use strict;
#
# Enable IrDA, start ppp0 and set up WinCE masquerading
# A. Tyde - Linuxcare Inc.
#
print "\n-> Setting up IR infrastructure...\n";
system("killall irattach 2>/dev/null");
sleep 1;
system("/usr/sbin/cebox.sh");
print "   Start WinCE Serial or IR networking now!\n";
open(ECHO,">/proc/sys/net/ipv4/ip_forward") or die "Can not open /proc/sys/net/
ipv4/ip_forward";
print ECHO "1";
close (ECHO);
print "   Serving 192.168.55.100 to WinCE device...\n\n";
system("ipchains -F");
sleep 5;
system("ipchains -P forward DENY");
system("ipchains -A forward -s 192.168.55.100/32 -j MASQ");
exit 0;


3.9. Cellular Phone Connection

As far as I know some cellular phones use the IrCOMM standard, e.g. Ericsson SH888 and NOKIA 6110 (I'm not sure about the NOKIA 8110). Maybe other cellular phones use the IrOBEX standard (see the Palm III section for information about setting up a connection) or IrMC.

gnokii is a Linux/Unix tool suite and soon to be modem/fax driver for Nokia (GSM) mobile phones. Phones supported include 3110, 3810, 8110, 5110, 6110 and their derivatives.


3.9.2. Ericsson

1. Configuration To start a communication session with /dev/ircomm0 , for instance, say:
dip -t
> port ircomm0
> term
Probably you may use cu or xc instead of dip, too cu -l /dev/ircomm0 or xc -l /dev/ircomm0. There are also reports about some efforts with the Ericsson GF768 and IR Modem DI 27.

Benny Amorsen wrote: The SH888 emulates an IRDA-port when you connect it using the serial cable. Why someone would think up something weird like that is beyond me, but that is the way you get it to work in Windows. Not that I ever managed to make it work in Windows, though.

Ales Dryak has send this survey (looks like a Debian/GNU Linux distribution, please modify your configuration accordingly). Mobile Ericsson SH888 ati1 = 980408 1035 PRGCXC125101:

mknod /dev/ircomm0 c 161 0
mknod /dev/ircomm1 c 161 1
2. /etc/conf.modules:
alias tty-ldisc-11 irtty
alias char-major-161 ircomm-tty
3. /etc/irda/drivers: irattach /dev/ttyS0 -s 1 # (IrDA port in SIR mode) 4. /etc/chatscripts/sh888
<ABORT stuff>
"" \d\d\d\d\d\dATZE0
OK ATD<phone number to call)
CONNECT \d\c
5. /etc/ppp/peers/sh888
noauth
connect "/usr/sbin/chat -v -f /etc/chatscripts/sh888"
/dev/ircomm
115200
defaultroute
noipdefault
user <your username> # don't forget to add your password to chap secrets or chat script

A few seconds (app. 30) after executing pppd call sh888 I get connected to our Intranet/Internet having full IP connectivity (telnet, ftp, www, icmp tested). Futhermore I can connect to /dev/ircomm using minicom and play with AT command. Great! And looks stable!


3.9.3. SH888 Phonebook Tool

Gerhard Gonter reported: Several members of the list are successfully using the Ericsson mobile phone SH888 with the Linux-IrDA software, usually to use it as a modem. The software is also quite useful to access other parts of the phone using AT commands. The built-in phonebook is an interesting target.

After A quick research on the Internet (FreshMeat, Deja, YAHOO), I did not find any phonebook tool for Linux (or another Unix). To solve that problem, I wrote a small Perl script and a related module. Since this now works acceptably well for me, I decided to wrap that up and release it at this early stage of development. The tarball can be retrieved from http://falbala.wu-wien.ac.at:8684/pub/english.cgi/0/172903 as http://falbala.wu-wien.ac.at:8684/pub/english.cgi/d172914/sh888-0.01.t ar.gz

In the mailing list gsmlib was also recommended, though ... there was no way for me to use this over infrared, no connection with my sh888. Florian Lohoff reported: Works (kind of) with the S25. I needed to change a ifdef as it seems the S25 does not respond with CR LF ...But setting a link from /dev/mobilephone -> /dev/ircomm lets me send SMS via the S25 without a problem. Phonebook backup does NOT work because the S25 does some silly responses to probably empty phonebooks.

The specifications for SMS messages and phone books can be downloaded free (of charge, not FSF free ;-) from ETSI. Search for GSM 07.07 (you might also want GSM 07.05). You have to register before downloading it. The standards are in Acrobat PDF format. The S25 supported commands are available on the Siemens websites as a PDF for free.

A survey of the AT commands for the SH888 is at http://mobileinternet.ericsson.se/emi_download/sh888/888_R1D.pdf


3.9.4. NOKIA

Carlos Vidal wrote: Correct me if I'm wrong, but it seems to me that Nokia telephones do not contain a genuine hardware modem, but something which is similar in principle to WinModems for PC. Whenever Nokia writes about modem communication, they use the name "Windows software modem" (or something similar). Which is actually backed up by the need to use special Nokia software for Windows (called Nokia Cellular Data Suite).

Joonas Lehtinen wrote: This is true with 61xx models. Models: 8810, 9000(i) and 9110 should work fine. (They have inbuilt modem). My Nokia 9000 reports IrCOMM with linux.

Some suggestion by Carlos Vidal carlos@tarkus.se : "I'm doing some tests trying to see how far can I get with my Nokia 6110 on Linux. I've just compiled gnokii-0.2.4 (gnokii is Nokia mobile phones connected via serial cable support for Linux and *BSD http://multivac.fatburen.org/gnokii/ , WH), but it doesn't work. As I have Nokia Data Suite I did the following connection:

Nokia 6110 <-- Nokia Cable --> PC/Linux <-- Null-modem cable --> PC/W95

In the PC/Linux I run the program snooper (by Jun-ichiro itojun Itoh , sorry couldn't find an URL maybe some other sniffer will do it also, e.g. sniffit, see also appendix about serial sniffers, WH) with small modifications in order to configure the serial port correctly.

Normally, if snooper has the correct baud rate, the phone and the PC/W95 should communicate as if there was no snooper in between. This worked pretty well when I cracked the protocol of my Minolta camera. The problem here is that the phone doesn't answer or hangs after a while.

It seems that the timing is quite important during the initial phase of the communication. The log I obtain is:

0>1: UUUUUUUUUUUUUUUUUUUUUUUU
line 0: LE *DTR *RTS ST SR CTS CD RI *DSR
line 1: LE *DTR *RTS ST SR CTS CD RI *DSR
0>1: UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUU\x1e\x00\x0c\x02\x00\x09\x00\x01\x00\x0d\x00\x00\x02\x01@\x00P\x
06
1>0: \x18\x00\x00\x00\xfc\x18\x00\x00\x00\x00\x00\x00\xc0\xf0
0>1: \x1e\x00\x0c\x02\x00\x09\x00\x01\x00\x0d\x00\x00\x02\x01@\x00P\x06
1>0: \x18\x00\x00\x00\x18\x00\x00\xc0\xf0\x18\x00\x00\x00\x00\x00\x00\xc0\xf0
0>1: \x1e\x00\x0cd\x00\x06\x00\x01\x00\x10\x01`\x13\x13
1>0: \x18\x00\x00\xf0\x00\x00\xfc
0>1: \x1e\x00\x0cd\x00\x06\x00\x01\x00\x10\x01`\x13\x13
0 is the PC/95 and 1 is the phone. The communication starts with a stream of 'U' (0x55) and with DSR/DTR on. The phone answers with '0x18 0x00 ...'. This dialog continues for a while as if both were deaf and finally the phone crashes and the only way to reset it is to remove the batteries!

I guess that what happens is that the phone is trying to find the correct baud-rate and fails because of the delays introduced by snooper. This probably has to do with some IrDA protocol used with also with the infrared connection."

Wessel de Roode "I managed to get the Discovery IR hint bits (with my Palm Pilot):

Discover:
0:xxxxxxxx:81.01
    01  IR_HINT_PNP     01  IR_HINT_TELEPHONY (IrMC ?)
    80  IR_HINT_EXT

Device info query:
\006Device\012DeviceName
    4e 6f 6b 69 61 20 36 31 30 30       Nokia 6100
I also managed to query the PNP device of the Nokia. It has one PNP device. It's PNPC100 which equalt a 9600 baud modem. I deleted the query, if somene can send me a hint to restore it. was somthing like IrDA:<dunno>:PNP:Comp#01 The same query with IrDA:<dunno>:PNP:CompCnt gives the number of PNP-devices are available in the Nokia. Which is here only one."

Maybe it is necessary to load the irlpt_server module for connections to a NOKIA.

There are also reports about gsmlib for sending and receiving sms messages, updating address books etc). These functions are working, except for minor charset problems.


3.10. Digital Camera Connection

Markus Schill wrote: "Great that there are also other people who are interested in using the SONY DSC-F1 IR adapter under linux. Up to now I have only toyed around with the linux-irda software and the serial IR adapter from PuMa Technologies that came with the camera. This is the status. I am using linux 2.0.33 and the latest linux-irda... If I use:
modprobe irda
modprobe irtty
irattach /dev/ircomm0
the adapter starts talking to the camera. /var/log/messages says that SONY-DSC-F1 was found, but no service is started. (Please note, this probably doesn't apply to the 2.2.x kernel versions of Linux/IrDA, [WH]).

There are two programs for linux available that can be used for the communication with the camera via cable: (1) chotplay and (2) stillgrab. They both take a tty as commandline option, so I guess that they should work if the irtty layer of the protocol stack works correctly ... I have not looked at anything in the linux-irda code, yet!). I am not sure whether I understand the stack but shouldn't the irtty make the thing look like a normal tty? What service should be started. "

Dag Brattli wrote: "I'm not sure which application level protocol the camera uses, but it is possible that it implements the IrDA(TM) Infrared Transfer Picture Specification (IrTran-P). If you take a look at http://www.irda.org/standards/pubs/IrTran-P_10.pdf, you will see that it is a protocol which is implemented above IrCOMM (not IrTTY!). IrTTY is something we use just to be able to talk to the Linux serial driver. "

The Kodak-Digital-Camera-HOWTO by David Burley now describes how to get IrDA working and implemented to get communications and to use the DigitalOS camera's with Linux and IrDA.


3.11. Window$9x/NT and Linux/IrDA

3.11.1. Introduction

Why this? Unfortunately Linux users are not always supported with the necessary hardware information. Sometimes it is possible to look at this informations in Window$95. Sometimes its even useful to connect the two. Linux could also provide occasional access point services to a Window95 laptop of a friend dropping by.

Where to get it from? At http://www.microsoft.com in the directory /Windows95/downloads/contents/WURecommended/S_WUCommunications/W95IrDA / you will find a support pack Infrared Transfer 2.0. It is a self-extracting archive W95IR.EXE with 331KB. Note: Microsoft seems to change the location of this file (and others) at random, the former URL is Microsoft Windows95 IrDA - Old

Microsoft(tm) has three versions of IrDA support for Windows95. The version number can be found in the "Software" icon in the Control Panel and the file infrared.inf.

Version 1.0 is still delivered with some hardware.

Version 2.0 is the version they currently offer at their web site. It is in the self-extracting file W95IR.EXE. The last time I looked (1999-02-21) it was 434KB and was found at http://support.microsoft.com/download/support/mslfiles/W95IR.EXE . Their website is frequently changing, so do not be surprised to find the file (also) in another location or not at all.

Version 3.0 can/could be found in their downloadable Infrared development kit IRDDK30, but is mostly useful for developers. It is internally different from 2.0, it is based on "miniport" network drivers, just like the Linux version. It exists for some time and has some support for NT, but it clearly did not make it into the mainstream NT4.0 distributions. For 95 you are probably better off with 2.0. The choice may depend on the documentation of the drivers you get with your specific hardware.

MS website also used to contain a nice utility IrXfer, contained in the archive IRXFER.EXE, This is the Infrared Transfer utility, which uses an IrOBEX variant I think, it is referenced in the IrOBEX protocol description. The utility was freely downloadable, but I could not find it the last time. It is a nice graphical utility which can be used to transfer files over IrDA between computers.

With some machines, e.g. a HP Omnibook 800 it is necessary to use a vendor specific version of this package (for the HP Omnibook 800 you may find it on the recovery CD).

Especially the ..\windows\inf\*.inf files and the device manager are of interest to look for configuration details.

As far as I know Window$NT doesn't support IrDA(TM). About Window$98 I have heard there is no IrDA(TM) support yet. Countersys on http://www.countersys.com claims to sell an IrDA solution for NT4.0 to support their JetBeam product, Microsoft refers to them for it.

AFAIK:


3.12. Linux to Linux Connection


3.12.2. Compression

Please note this feature is still quite experimental! Dag Brattli wrote: "Just wanted you to know I have just added COMPRESSION support to IrLAP! As you may know, this is _not_ part of the IrDA(TM) standard, but Linux can now negotiate with its peer and check if it has the same compression capabilities). So obviously if you are talking to Win95, Palm III or whatever, you will _not_ get compression!!! This is something which is exclusive for Linux as far as I know! The IrDA(TM) standard says that devices should ignore unknown field in the negotiation header, so we are still "compatible" with IrDA(TM) (have just borrowed an unused header value).

If you want to try using the compression code (Linux <-> Linux) you will have to insert the irda_deflate module some time before you actually make the connection. I do it before irattach.

The compression standard I have added is the deflate format used by the zlib library which is described by RFCs (Request for Comments) 1950 to 1952 in the files ftp://ds.internic.net/rfc/rfc1950.txt (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format).

The compression interface is similar to PPP, so you can add as many different compressors as you want. Currently there is only support for GZIP, but BSD compression will be added later. ... Have just tested GZIP compression at 4Mbps. It was a really bad idea! Compressing the frames takes so much time that the performance is actually worse than when not using compression at all. The conclusion is that compression should only be used for SIR speeds, ..."


3.14. Connection to Docking Station

Dag Brattli: "Connection to the Tekram IRDocking IR-660 http://www.tekram.com/Hot_Products.asp?Product=IR-660 . This device is a docking station with LAN access, printer, mouse and keyboard. You can also use them at the same time as the internal mouse and keyboard! Just fire up gpm -t ps2 /dev/irkbd and the laptop will make a keyboard/mouse connection to the IR-660. Now I just have to make gpm read both /dev/psaux and /dev/irkbd, and then make X11 read /dev/gpmdata, and I should have the thing configured!

... one problem: gpm can handle multiple mice, but Linux cannot handle multiple different keyboards. So if you have one norwegian keyboard and one remote US keyboard like I have, then things will be a little bit confusing. I got a hint from Alan Cox about a project that is implementing real support for multiple keyboards, so I'll check that out.

... OK, I sort of worked it out. By using TIOCSTI on /dev/console, you can insert scancodes directly into the tty queue. This can be a problem for virtual consoles that expect to receive some translated and cooked keycodes, but X happens to like raw scancodes, so this will work quite nice when using X but not for other virtual consoles. Anyway this is good enough for me, so I will not use a lot of time converting the scancodes to keycodes and index them with some keymap just to make it work with text only virtual consoles. As I see it the irkbd driver has now been successfully been ported to user-space :-)

... the Tekram IR-660 device can, in addition to attach a keyboard and mouse, also print using IrTTP (it can print using IrLPT, but that is not so funny since it requires exclusive use of IrLMP, and you don't wan't to stop the network, mouse and keyboard just to print a document). I'll try and see if I can get IrTTP printing working using a fifo as well.

... Tekram has added a control channel in addition to the data channel so that you can get some status information about what is going on. The name of their own protocol is P1248. It's published through the "P1248" class and "IrDA:TinyTP:LsapSel" LM-IAS entry, so you can try to find it.

... Canon is using the P1248 protocol, and their printer monitor program BrintBuddy2 (Japanese version) is using this protocol now. I don't know what they use for the data channel. Maybe they support TinyTP directly in addition to the other methods. You can try and look up the "IrLPT" class with the "IrDA:TinyTP:LsapSel" in the LM-IAS and see if you can find it."


Chapter 4. Hardware Supported by Linux/IrDA

4.1. Obtaining Information about the Infrared Port in Laptops

To get the IrDA port of your laptop working with Linux/IrDA you may use StandardInfraRed (SIR) or FastInfraRed (FIR).


4.1.2. FIR

If you want to use up to 4Mbps, your machine has to be equipped with a certain FIR chip. You need a certain Linux/IrDA driver to support this chip. Therefore you need exact information about the FIR chip. You may get this information in one of the following ways:

  1. Read the specification of the machine, though it is very rare that you will find enough and reliable information there.

  2. Try to find out whether the FIR chip is a PCI device. Do a cat /proc/pci . The appropriate files for 2.2.x kernels are in /proc/bus/pci . Though often the PCI information is incomplete. You may find the latest information about PCI devices and vendor numbers in the kernel documentation usually in /usr/src/linux/Documentation or at the page of Craig Hart http://members.hyperlink.net.au/~chart . From kernel 2.1.82 on, you may use lspci from the pci-utils package, too.

  3. Use the DOS tool CTPCI330.EXE provided in ZIP format by the German computer magazine CT ftp://www.heise.de/pub/ct/ctsi/ctpci330.zip. The information provided by this program is sometimes better than that provided by the Linux tools.

  4. Try to get information about Plug-and-Play (PnP) devices. Though I didn't use them for this purpose yet, the isapnp tools, could be useful.

  5. If you have installed the Linux/IrDA® software load the FIR modules and watch the output of dmesg, whether FIR is detected or not.

  6. Another way how to figure it out explained by Thomas Davis (modified by WH): "Dig through the FTP site of the vendor, find the Windows9x FIR drivers, and they have (for a SMC chip):
    -rw-rw-r--   1 ratbert  ratbert       743 Apr  3  1997 smcirlap.inf 
    -rw-rw-r--   1 ratbert  ratbert     17021 Mar 24  1997 smcirlap.vxd 
    -rw-rw-r--   1 ratbert  ratbert      1903 Jul 18  1997 smcser.inf 
    -rw-rw-r--   1 ratbert  ratbert     31350 Jun  7  1997 smcser.vxd 
    If in doubt, always look for the .inf/.vxd drivers for Windows95. Windows95 doesn't ship with _ANY_ FIR drivers. (they are all third party, mostly from Counterpoint, who was assimilated by ESI)."

  7. Also Thomas Davis found a package of small DOS utilities made by SMC. Look at http://www.smsc.com/ftppub/chips/appnote/ir_utils.zip . The package contains FINDCHIP.EXE. And includes a FIRSETUP.EXE utility that is supposed to be able to set all values except the chip address. Furthermore it contains BIOSDUMP.EXE, which produces this output:

    Example 1 (from a COMPAQ Armada 1592DT)

    In current devNode:
               Size      = 78
               Handle    = 14
               ID        = 0x1105D041 = 'PNP0511' -- Generic IrDA SIR
    Types:  Base = 0x07, Sub = 0x00,  Interface = 0x02
    Comm. Device, RS-232, 16550-compatible
    Attribute = 0x80
                    CAN be disabled
                    CAN be configured
    BOTH Static & Dynamic configuration
    Allocated Resource Descriptor Block TAG's:
    TAG=0x47, Length=7 I/O Tag, 16-bit Decode
    Min=0x03E8, Max=0x03E8
    Align=0x00, Range=0x08
    TAG=0x22, Length=2 IRQ Tag, Mask=0x0010
    TAG=0x79, Length=1 END Tag, Data=0x2F

    Result 1:

    Irq Tag, Mask (bit mapped - ) = 0x0010 = 0000 0000 0000 0001 0000 so, it's IRQ 4. (start at 0, count up ..), so this is a SIR only device, at IRQ=4, IO=x03e8.

    Example 2 (from an unknown machine)

    In current devNode:
              Size      = 529
              Handle    = 14
              ID        = 0x10F0A34D = 'SMCF010' -- SMC IrCC
    Types:  Base = 0x07, Sub = 0x00,  Interface = 0x02
    Comm. Device, RS-232, 16550-compatible
    Attribute = 0x80
                   CAN be disabled
                   CAN be configured
    BOTH Static & Dynamic configuration 
    
    Allocated Resource Descriptor Block TAG's:
    TAG=0x47, Length=7 I/O Tag, 16-bit Decode
    Min=0x02F8, Max=0x02F8
    Align=0x00, Range=0x08
    TAG=0x22, Length=2 IRQ Tag, Mask=0x0008
    TAG=0x47, Length=7 I/O Tag, 16-bit Decode
    Min=0x02E8, Max=0x02E8
    Align=0x00, Range=0x08
    TAG=0x2A, Length=2 DMA Tag, Mask=0x02, Info=0x08
    TAG=0x79, Length=1 END Tag, Data=0x00

    Result 2:

    a) it's a SMC IrCC chip

    b) one portion is at 0x02f8, has an io-extent of 8 bytes; irq = 3

    c) another portion is at 0x02e8, io-extent of 8 bytes; dma = 1 (0x02 =0000 0010)

    Thomas Davis has placed some device information at http://www.jps.net/tadavis/irda/devids.txt .

    Warning

    The package is not intended for the end user, and some of the utilities could be harmful. The only documentation in the package is in Microsoft Word format. Linux users may read this with catdoc, available at http://www.fe.msk.ru/~vitus/catdoc/ .

  8. Use the Device Manager of the MicroSoft Windows9x/NT operating system.

  9. You may also use the hardware surveys mentioned below.

  10. And as a last ressort, you may even open the laptop and look at the writings at the chipsets itselfs. Here is an probably incomplete list of manufacturers: Chrystal, Hewlett Packard (HP, chipsets are marked HSDL), Hitachi, IBM, National Semi Conductor (NSC), NEC, Philips, Sharp, Standard Micro Systems Corporation (SMC/SMSC), Texas Instruments (TI), VLSI, Winbond. As an example of application circuits the HSDL-7001 (from a HP brochure, modified by WH):
        LEDs    Encode/Decode    SIR/FIR
    
       HSDL-1001    HSDL-7001      UART 16550/
                      MicroController
       ______      ______________      ____________
      |      |    |              |    |            |
    (||   TXD|<---|IR_TXD     TXD|<---|SOUT        |
      |      |    |              |    |            |
      |      |    |           RCV|--->|SIN        |
      |      |    |              |    |            |
    (||   RCV|--->|IR_RCV  16XCLK|<---|BAUDOUT     |
      |      |    |          NRST|-+  |            |
       ------      --------------  |   ------------
                                   V


4.2. Hardware Surveys

There are some surveys about Linux and infrared capable devices in the WWW:


Chapter 5. Advanced Topics

5.1. Troubleshooting


5.1.2. Troubleshooting Techniques

Although I'm not much of a hacker I collected some tricks to track errors or bugs in the Linux/IrDA software.

For some ThinkPad models you have to reboot to the preinstalled M$ OS and activate the IrDA port using the Thinkpad tools. There is currently no Linux tool to achieve that. This will disable your internal serial port (ttyS0)!. The DOS tool is PS2.EXE, as far as I know tpctl doesn't achieve this. It is really important to use this DOS program (ps2.exe) to enable IR. Using the windows tools does not work. Without that the driver loads correctly and everythings seems OK, but the LED does not light bright enough.


5.5. Beyond IrDA

5.5.1. Extending Transmission Distance

According to the IrDA specification the range is up to 1 meter. From the "IrDA Data Link Design Guide" p. 20 by Hewlett-Packard http://www.hp.com/go/ir : " In some cases it may be desired to increase link distance beyond the 1 meter guaranteed by IrDA. The two ways to do this are to increase transmitted light intensity, or to increase receiver sensitivity. In order to extend the link distance, both sensitivity and intensity must be increased for both ends of the IR link. If it is desired to communicate with a standard IrDA device that may have minimum transmitter intensity, the receiver intensity must be increased. The standard IrDA device may also have minimum receiver sensitivity, so transmitter intensity must also be increased."

Andreas Butz wrote: "This might be a silly question, but has anyone an idea whether the whole IrDA stack really relies on a two-way connection, or whether there are some parts of it that could be abused for a one-way connection, ideally for unreliable data? We're trying to modify some IR dongles to broadcast information to palm pilots over several meters distance (cover a whole room), and since we don't want to modify the pilots themselves, and increasing the sensitivity on the receiver side seems unlikely to work, we're stuck with a one way link.". Please see the mailing list archive for details of the discussion.

Sent by Marc Bury " .. just heard about some Philips new scheme for remote controls: they call it IRDA - Control. This is supposed to be bi-directional, 75 kbps data rate, multiple simultaneous devices (up to 8) and with a minimum 6 meter range!" More information at http://www.irda.org/ .

The german magazine ELEKTOR issued a guide to build a Long Distance IrDA Dongle (20m, RS232, IrDA 1.0), ELEKTOR 5/97 p. http://www.elektor.de .

"The main problem is that you generally have to make the receiver more sensitive. Basic physics has the inverse square law: the intensity drops with the SQUARE of the distance, so going from 1 to 5 meters requires 25x the power (and battery drain on a portable device), or 25x the sensitivity (and dynamic range - it still has to be able to work at 3 inches). And if you want to do it on the other end, it doesn't simply have to be 25x more sensitive, it must pick up the tiny IrDA pulse needle in a haystack of florescent lights, screen savers, moving shadows ..."

Someone tried it with a Palm III upgrade board http://home.t-online.de/home/PSPilot/ppppiii.htm .

Also laser diodes (pulsable) were recommended by K-H.Eischer: But they are more expensive. And the laser diodes are also dangerous if they have more than 1 mW. A better solution would be to use lenses to focus the beam. There is a minimum of absorbtion in the air (I don't know the right frequency) and you should use IR diodes with this frequency.

James wrote: " Who ever it was wanting to do long distance with IrDA, we've tried this before. The best approaches are:

Whatever you choose IrDA might very well be a good choice for a protocol, given it's one of the few that sensibly copes with simplex."


5.6. IrDA Network Neighborhood

Laptop-Printer-PDA You can take a little peek at http://irda.sourceforge.net Drag-n-drop stuff, so you will be able to drop files to your PDA (uses IrOBEX) or drop files to your printer (uses IrLPT) etc.

Bridging/Routing James wrote: " ... there is a much better way of doing the briding which is routing. This is entirely user land and requires no kernel patches.

It's in two parts (you may only need one your milage may vary...) the first called irdaipcfg does the following:

1) First part is executed as irdaipcfg ifeth ifirlan daemonizes, then looks for ARP packets on ifirlan, checks that the arp was not generated by the machine on which it is running. The arp contains the ip address of the machine on the other end of the irlan (it was generated by the gratuatous arp in the irlan code). The program then sets up a host route to this ip address via ifirlan, adds a proxy arp to ifeth for it and generates a gratuatous arp on ifeth. It writes the ip address of the client in /var/run/host.ifirlan so you can easily undo all of this from a script.

2) Second part is executed as gratarp ifirlan. Sometimes the gratuatous arp seems to get lost in the pipe work, gratarp deamonizes and spits out a whole stream of the things...

I use them as follows: (you can use them to do whatever you like)

On my host (the machine bolted to my local net) irlanx is brought up as 10.192.0.1 with a netmask of 255.255.255.255 and a broadcast of 10.192.0.1 by my ifup script from /etc/irda/network by irattach. /etc/irda/network then runs irdaipcfg eth0 irlanx and this does the routing.

From /etc/irda/network
"start")
    echo 1 >/proc/sys/net/ipv4/conf/all/forwarding
    ./ifup ifcfg-${device}
    /sbin/irdaipcfg ${localnet} ${device}
    ;;
"stop")
    host=`cat /var/run/host.${device}`
    if [ .$host != . ]; then
      /sbin/arp -d ${host} dev ${localnet}
      /sbin/route delete ${host} dev ${device}
    fi
    ./ifdown ifcfg-${device}
    /sbin/ifconfig ${device} down
    ;;
on the client I set up irlan to use an address on my normal subnet 10.32.32.51 but with netmask 255.255.255.255 (not my usual netmask) I have some static routes which are host 10.192.0.1 dev irlan, and net default gw 10.192.0.1 dev irlan. I run gratarp from the /etc/irda/network, and I can wander arround my house and not lose telnet and ssh sessions ... they are sitting in ftp://bullard.esc.cam.ac.uk/pub/irda "

IPv6 AFAIK IPv6 has neighbor discovery mechanismem, but I don't have information about Linux/IrDA used with IPv6. Please see the mailing list archive for a discussion of this topic under the subject :"patch-2.2.7-ac1-irda4" .

DHCP I have got reports that it is possible to use dhcpcd with IrLAN. Please use latest DHCP software.


5.11. FAQ


Chapter 8. Lego Mindstorm

Quoting the Lego Mindstorm with Linux Mini-HOWTO by Luis Villa:" In case you don't know, the Lego Mindstorms Kit is a robotics kit from The Lego Group that retails for about 200 US dollars. For that, you get a lot of Lego pieces, a large brick containing a CPU, an LCD, and some connectors (known as the RCX), a couple of motors, and some light and touch sensors that allow you to interact with the outside world. ..."

"All communication to the RCX is done via the IR tower, which is connected to the machine via a serial port. As a result, if you have no serial port connection, you will be unable to use the RCX unless you can buy an adapter. Furthermore, under certain circumstances, there may be problems with IRQs or serial port conflicts. This is particularly likely if your modem uses /dev/ttyS0."


Chapter 13. IRManager

IRManager is a Linux daemon to make advanced use of an IRMan infrared receiver. It forwards IR signals to (multiple) native IRMan applications, and can be used with your own scripts and applications. It also has a mapping system and its advanced configuration options make it the most flexible and easy way to remote control your computer.


Chapter 16. Infrared Remote Control - IrDA

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 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 Linux/IrDA site 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 : 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."


Appendix B. Revision History


Appendix C. Serial Infrared Port Sniffers

C.1. Sniffer by Gerd Knorr

This programm is a courtesy by Gerd Knorr. You may use it to sniff the traffic which is going trough your IrDA port for details of the protocol (change the default ttyS1 in the source if necessary):

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <termios.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/ioctl.h>

#define BUFSIZE 1024

int
read_and_print(int fd, int sec, int usec)
{
    int         rc,l,i;
    char        buf[BUFSIZE+1];
    fd_set      set;
    struct timeval  tv;
    
    if (sec || usec) {
    FD_ZERO(&set);
    FD_SET(fd,&set);
    tv.tv_sec  = sec;

    tv.tv_usec = usec;
    if (0 == select(fd+1,&set,NULL,NULL,&tv))
        return -1;
    }
    
    switch (rc = read(fd,buf,BUFSIZE)) {
    case 0:
    printf("EOF");
    exit(0);
    break;
    case -1:
    perror("read");
    exit(1);
    default:
    for (l = 0; l < rc; l+= 16) {
        printf("%04x  ",l);
        for (i = l; i < l+16; i++) {
        if (i < rc)
            printf("%02x ",buf[i]);
        else
            printf("-- ");
        if ((i%4) == 3)
            printf(" ");
        }
        for (i = l; i < l+16; i++) {

        if (i < rc)
            printf("%c",isalnum(buf[i]) ? buf[i] : '.');
        }
        printf("\n");
    }
    break;
    }
    return rc;
}

void
setlines(int fd, int rts, int dtr)
{
    int lines = 0;

    if (rts) lines |= TIOCM_RTS;
    if (dtr) lines |= TIOCM_DTR;
    
    ioctl(fd,TIOCMSET,&lines);
}

int main(int argc, char *argv[])
{
    int         ser,i;
    struct termios      saved_attributes,tattr;
    struct winsize      win;
    char        buf[16];
    
    if (-1 == (ser = open("/dev/ttyS1",O_RDWR))) {
    perror("open /dev/ttyS1");
    exit(1);
    }
    
    /* Set the terminal mode */
    tcgetattr (ser, &tattr);
    cfmakeraw (&tattr);
    cfsetospeed (&tattr,B9600);
    cfsetispeed (&tattr,B9600);
    tcsetattr (ser, 0, &tattr);
    
    setlines(ser,0,0);
#if 0
    tcsendbreak(ser,0);
#endif

    /* main loop */
    fprintf(stderr,"setup done\n");
    while (-1 != read_and_print(ser,30,0)) {
    usleep(100000);
    }
    
    return 0;
}


C.2. sersniff

Written by Jonathan McDowell sersniff is a simple program to tunnel/sniff between 2 serial ports. The program was written to aid with the decoding of the protocol used by the Nokia 9000i Communicator to talk to the NServer software Nokia provides, which only runs under Windows.


Appendix D. Infrared Light and Eye Safety

This section summarizes some ideas and thoughts that were exchanged on the Linux/IrDA mailing list. It is not medically wellfounded, and whoever has better evidence or some more wellfounded source of information is encouraged to contribute it to this HOWTO.

The IrDA spec says that the range of IrDA devices has been limited to 1m for reasons of eye safety. Another plausible assumption is that power consumption and IR pollution/crosstalk were reasons for this limitation. In principle there could be danger for the eye, because infrared light is not registered by the eye, and thus the pupil won't close in order to protect the retina from bright IR light sources. This is the same situation as with UV light, which will cause snow blindness eventually, but in contrast to UV light, IR light contains much less harmful energy due to its longer wavelength.

The only legal restrictions and medical advices we were able to find on the web were concerned with infrared emissions of heat lamps or in the welding process and IEC 825-1 (CENELEC EN60825-1). This suggests that IR light as emitted by IrDA devices will be harmless, since even the peak power emitted by strong IR LEDs (ca. 300mW) is several orders of magnitude below the power emitted by medical IR heat lamps (up to 500W). For these, however, you are supposed to wear protective goggles, so maybe if you are looking straight into 1.000 infrared LEDs flashing at once, you should do so, too. The effect of infrared light is mostly heat, though, and not an alteration or destruction of the biological cell structure, such as caused by UV light. Though in the specs for the HP OmniBook 800 Hewlett-Packard recommends not to look directly into the IR LED.

As stated above, this discussion is only based on guesswork and common sense assumptions about the data found in IR LED and heat lamp specs. If anybody with a better medical knowledge can comment on this, please do so!!!


Appendix E. Copyrights, Disclaimer, Trademarks

E.1. Disclaimer and Trademarks

This is free documentation. It is distributed in the hope that it will be useful, but without any warranty. The information in this document is correct to the best of my knowledge, but there's a always a chance I've made some mistakes, so don't follow everything too blindly, especially if it seems wrong. Nothing here should have a detrimental effect on your computer, but just in case I take no responsibility for any damages incurred from the use of the information contained herein.

Though I hope trademarks will be superfluous sometimes (you may see what I mean at Open Source Definition ), I declare: If certain words are trademarks, the context should make it clear to whom they belong. For example "MS Windows NT" implies that "Windows NT" belongs to Microsoft (MS). "Mac" is a trademark by Apple Computer. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and I was aware of a trademark claim, the designations have been printed in caps or initial caps. All trademarks belong to their respective owners.


E.3. GNU Free Documentation License - GFDL

Version 1.1, March 2000

Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.


E.3.2. 1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.


E.3.4. 3. COPYING IN QUANTITY

If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.


E.3.5. 4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).

C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

H. Include an unaltered copy of this License.

I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.

N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.