IrDA uses (brief)

DRAFT 5^th May 2004 — First version.

16th August 2004

16^th October 2004 — Format changes[b].

22^nd August 2005 — More on OBEX/IrReady for printers.

15^th October 2005 — Note in IrMC that modem access is by IrCOMM.

8^th December 2005 — Note “IrTranPv1” and OBEX over v25.ter.

Introduction

This document contains a list of the most common uses of IrDA and for each includes a brief description of that usage, including how the user will uses that service, what devices support it and some brief technical notes on the IrDA connection types used.

It does not include detailed information on the technical details of the protocol used. Nor does it include information on the lower layers in the IrDA protocol stack, nor on IAS Classes used by internal services only e.g. “PnP”.

BTW, a possible better term for “uses” may be “applications”, “services” or “profiles”, however those words have multiple other meanings and may not thus be any clearer. The Bluetooth standards body uses the last when defining such services, what I describe here may in fact be IrDA profiles.

General uses

These are uses defined by standards bodies or for use on devices from multiple vendors.

Unless noted, the connections use TinyTP; those using IrLMP alone are marked as such.

Object Exchange (OBEX)

Sending address book entries, business cards, calendar entries etc. It is very widely supported on Mobile Phones, PDAs and PCs. It is PalmOS’s Beaming, Nokia’s “Send … via IR“, Windows 2000’s Wireless Link File Transfer (irftp.exe), Linux’s OpenObex etc.

It is also a very convenient means for printers to accept jobs; the peer device does not need to support any printer control language e.g. PCL or PostScript etc, but can print common OBEX object types simply by beaming them to the printer, see below.

In advanced usages it supports fetching (‘GET) as well as the usual sending (‘PUT’) mode, arbitrary object/file types and even browsing the peer’s file system.

Name:	OBEX
Specification:	IrDA, i.e. “IrOBEX12.pdf” etc.
Service Name:	“OBEX”—“default OBEX servers, and in particular have some provision for dealing with multiple object types and services.” “OBEX:IrXfer”—“…subset of object exchange…strictly for file exchange.” Both quotes from IrOBEX12.pdf, section 6 “IrDA OBEX IAS entries, service hint bit and TCP Port number”.
Client devices:	PCs, PDAs, Mobile Phones, etc.
Server devices:	PCs, PDAs, Mobile Phones, Printers, etc.

OBEX is also available over a ‘serial cable’ connection to certain mobile phone models, to enable it one uses the standard’s “AT +CPROT=0”, or Sony Ericsson’s “AT *EOBEX”. Of course the serial connection can be any v25.ter-like connection e.g. an IrCOMM connection or USB connection etc. See ETSI TS 127 007 (etc) for more information.

Dial-up Networking

Dial-up networking here includes making a dial-up connection for data networking, making other dial-up connection types and accessing a (modem type) device for access to its other features. In Mobile Phones, access to their address book, (SMS) message store, and other features such as setting dial-tones and screensavers is generally available via the AT command set.

This use is generally done through IrCOMM (9-Wire); see below.

IrModem is also sometimes available; see below.

Peer-to-Peer and Peer-to-Access-point Networking (IrNet)

Make TCP/IP (or others) connections between a pair of end-user devices or between an end-host and an LAN Access-point, i.e.

The link uses PPP encapsulation, which negotiates link settings, network protocol configuration and authentication.

This usage can instead use IrCOMM, again creating a PPP encapsulated link. Windows 95 and 98 used that configuration, Windows 2000 and later supports only IrNet. Linux supports both. Using IrCOMM again of course adds to the multiple conflicts over it.

Name:	IrNet, part of the IrDial suite.
Specification:	“IrDial”, from Microsoft, Nokia and Ericsson.
Service Name:	“IrNetv1”
Client devices:	PCs, PDAs, etc.
Server devices:	PCs, PDAs, Access-points, etc.

IrModem

This is the other half of the IrDial suite, this time for dial-up connections. It is largely historic though, IrCOMM being used instead. It is specified to be for dial-up leading to PPP use only, it does not provide for general v.250, i.e. Hayes/AT command support. However, I would be somewhat surprised if modem suppliers implement this restricted usage.

Devices that include the server-side support are mobile phones from Ericsson e.g. the R250m and Nokia e.g. the 6800. Windows 2000 originally had no IrCOMM Modem support providing only IrModem. This went down like a lead balloon with consumers, and IrCOMM Modem support was later provided (in a patch and service pack). Later OSs, i.e. XP, have this support by default.

Programmers who want to access Mobile Phones but find that their programming environment does not allow them to use IrCOMM should try using IrModem; it won’t be supported by all phones but it may be enough.

Name:	IrModem, part of the IrDial suite.
Specification:	“IrDial”, from Microsoft, Nokia and Ericsson.
Service Name:	“IrModem”
Client devices:	PCs, PDAs, etc.
Server devices:	Mobile Phones, modems in general etc.

Printing (IrLPT)

IrLPT is a protocol from the IrCOMM suite, see below. It replaces a parallel or serial link to the printer; all other things remain unchanged. The peer must thus understand the control languages used by the printer e.g. PCL, PostScript etc.

OBEX (see above) provides a convenient replacement for this usage for known object types. Printers that are IrReady (Point and Shoot) are required to support the following types: text, JPEG (EXIF), vCard, and vCal; and optionally: PCL3, PCL5, Postscript, vNote, vMsg, and ESC/P.

Other members of the IrCOMM suite can be used also, e.g. Centronics or 9-Wire.

Name:	IrLPT
Specification:	IrDA, i.e. In IrCOMM specification.
Service Name:	“IrLPT” over IrLMP.
Client devices:	PCs, PDAs, Mobile Phones etc.
Server devices:	Printers.

IrMC—“Mobile Communications”

To quote from the specification,

2. IrMC Framework

The IrDA IrMC specification defines the rules for utilization of IR in wireless communications equipment, e.g., in mobile handsets, PDAs, PCs, notebook computers and pagers.

2.1 IrMC Applications

The IrMC specification enables IrMC Object exchange between a variety of applications. For instance, the IrMC specification enables easy exchange of:

· business cards between Phone Book Applications

· text messages between Messaging Applications

· calendar and todo items between Calendar Applications

· short notes between Note applications

The IrMC Call Control specification enables call control of mobile handsets. The IrMC Audio Specification enables real time audio transmission respectively.

When accessing the phone as a modem the cable replacement protocol IrCOMM is used, see below.

Name:	IrMC
Specification:	IrDA, i.e. “IrMC_v1p1.pdf”.
Service Name:	“IrDA:TELECOM” (“IrDA:IrMC” is not a valid service/class name)
Client devices:	PCs, PDAs, etc.
Server devices:	Mobile Phones etc.

LAN Access (IrLAN)

This protocol is largely historic now, being replaced by IrNet or PPP over IrCOMM.

It required the end devices create frames as if they were directly connected to a LAN: thus on Ethernet, Ethernet II/802.3 frames and on Token-Ring, 802.5 frames. Authentication etc wasn’t supported. For devices that already have PPP support, IrNet is much easier to implement.

Name:	IrLAN
Specification:	IrDA i.e. “IrLAN.PDF”.
Service Name:	“IrLAN”
Client devices:	PCs.
Server devices:	PCs, Access-points, etc.

Image Transfer (IrTran-P)

Transferring images from digital cameras. To quote from the specification,

1.1. Foreword

IrTran-P(Infrared Transfer Picture) is an image communication scheme for a digital camera based on the Infrared Communication Standard specification created by IrDA. The IrTran-P specification is to be largely used together with the IrDA standard specifications.”

This protocol is somewhat historic now. It runs over IrCOMM—this is a major source of conflict; particular as the server-side application runs on PCs, which need to support other applications that listen on IrCOMM.

The specification (at section 3.4.1) explicitly excludes the use of IrCOMM’s control information, and states that TinyTP flow control facilities should be used instead. The decision to use IrCOMM is thus even more perplexing.

Microsoft notes in document “IrDAConf-06-01.ppt” that their IrTran-P implementation in Windows XP also listens on TinyTP Service name “IrTranPv1”.

Name:	IrTran-P
Specification:	IrDA, i.e. “IrTran-P_10.pdf”
Service Name:	Layered over IrCOMM (9-Wire or 3-Wire). :-( On Windows XP: also “IrTranPv1”.
Client devices:	Digital Cameras etc.
Server devices:	PCs etc.

Cable Replacement (IrCOMM)

IrCOMM provides for miscellaneous cable replacement uses. It has two “camps”, link types that use “cooked mode” and those that don’t. Cooked mode allows the transfer of link settings and control signals (e.g. DTR, RTS) between the peers.

Cooked mode over TinyTP is used by 9-Wire, 3-Wire and Centronics. Non-Cooked mode over IrLMP alone is used by 3-Wire-Raw and IrLPT. A “Parameters” IAS entry contains details of the services present.

Very many devices and applications use IrCOMM, generally in 9-Wire mode (or at least with a Cooked-mode connection). These include Palm HotSync, Microsoft ActiveSync, Psion connection, IrTran-P, printing, modem connection—notably in connecting to Mobile Phones—and others. This is a huge source of conflicts and reduces the user-friendliness of IrDA considerably.

Note that most of those applications require no support for serial cable control signals etc so there is no need to use IrCOMM for its cooked mode. Each application should instead use a basic TinyTP connection and a distinct Service Name, for instance “Palm:HotSync”, “IrDA:IrTran-P” and perhaps even “V.250” (or “IrDA:Modem” perhaps) etc.

Name:	IrCOMM.
Specification:	IrDA, i.e. “ircomm10.pdf”.
Service Name:	“IrDA:IrCOMM” “IrDA:IrCOMM” over IrLMP, and “IrLPT” over IrLMP.
Client devices:	PCs, PDAs, Mobile Phones etc etc etc.
Server devices:	PCs, Mobile Phones, Printers etc etc etc.

JetSend

The carriage of HP’s JetSend protocol over IrDA. Historic. From HP’s website,

Hewlett-Packard Company will not be initiating any new projects or project extensions relating solely to HP Jetsend. HP will continue to protect HP Jetsend intellectual property.

Name:	JetSend
Specification:	IrDA, i.e. “jetsend.pdf”
Service Name:	“JetSend”
Client devices:	misc.
Server devices:	misc.

Vendor specific uses

As noted above, for all vendor specific uses, a basic TinyTP connection should be used, with a new distinct Service Name used. Unfortunately, most vendors have fallen into using an IrCOMM 9-Wire connection.

Palm HotSync

Uses IrCOMM; the desktop PC application accepts connections from the PalmOS side and thus conflicts.

Microsoft ActiveSync

Uses IrCOMM; the desktop application listens on IrCOMM and thus conflicts.

Psion (PsiWin) connectivity

Uses IrCOMM; the desktop application listens on IrCOMM and thus conflicts.

Polar Heart Rate Monitor

The newer HRM devices from Polar use a TinyTP connection with Service Name “HRM”; the PPP SW application connects to the HRM device.

At last; an enlightened manufacturer! Congratulations.

The older devices appear to use ‘Direct IR’ alone, see my FAQ for more on this.

Name:	Polar HRM
Specification:	Polar
Service Name:	“HRM”
Client devices:	PCs etc.
Server devices:	HRM devices with names ending in “i”, e.g. the S710i.

Nokia

Service Names used on their phones include, “Nokia:PhoNet”, “Nokia:PhoNet_Games”and “Nokia:NBSrouter”.

As noted elsewhere in this document, the various phones support a variety of the generic services too, including IrCOMM, IrModem, IrMC and IrLPT.

Non-IrDA infrared

Because the term “IrDA” is well known, people often assume that all infrared is “IrDA”; in many cases, this is not the case.

‘Consumer’ IR

‘Consumer’ IR is the use of infrared to control consumer electronics products, for instance, TVs, hi-fis, DVD players etc. This usage has no link with IrDA; the protocols used by the remote controls are quite unlike the protocol used by the IrDA (IrDA-Data) protocol suite.

Most software that is available for consumer infrared control from PCs appears to need custom hardware and does not use IrDA devices, they use a simple infrared diode connected directly to a serial port. See my FAQ for some notes on this. It may be that the IrDA devices cannot send (and receive) non IrDA signal, it will also likely be that the IrDA device does not give a long enough range and only works when near the consumer device.

However, some IrDA devices can be configured to send consumer infrared types of signal instead of the IrDA type signal. See the documentation for your device.

Direct / Raw IR (SIR / HP-SIR)

The IrDA protocol suite is a layered protocol; the bottom layer—that is the “physical layer”, IrPHY—describes how bytes and bits are transmitted and how they are grouped into frames. At the slower rates (2.4kbps to 115.2kbps), a specification called SIR is used. SIR stands for “Serial Infrared” a protocol is very similar to the RS232-like serial connection type but over infrared.

SIR can be used without the rest of the IrDA protocol suite for some usages. In fact, SIR was invented by HP prior to the founding of the IrDA organisation and first used in their programmable calculators. This explains why SIR is often known as HP-SIR.

Using SIR alone has certain benefits. There is obviously greatly reduced code requirement, there will also likely be lower latency than with an IrLMP / TinyTP connection as the ‘turnaround’ features of IrDA are not necessary (the programmer must ensure that the two ends don’t send data at the same time though).

Note that this usage is generally supported in OSs by side effect only, and not really by design. In many systems, HP-SIR can be used by opening the IrDA device as a serial port. To be able to open the port, it is often necessary to disable the IrDA stack, and/or disable any built-in IrDA services—generally the OBEX service needs to be disabled.

Also, note that in some cases the IrDA hardware is itself not capable of being used in this ‘raw’ mode. For instance, many of the PalmOS 5 devices use the OMAP processor from TI. This CPU contains IrDA support in hardware and only accepts valid IrLAP SIR frames; it thus does not support sending and receiving arbitrary SIR bytes. Whenever data is to be sent, the current byte or bytes must be grouped into an IrLAP frame, with headers, checksum and trailers present.

There can be problems with this usage on desktop platforms too. It is only easy to directly access a serial port connected dongle; USB dongle and motherboard attached devices generally do not appear as a serial ports.

Particular devices’ support

PalmOS

Present since OS 3.3.

OBEX	Called “beaming”, supported by the built-in applications and by many third-party applications.
IrNet	No support.
IrLPT	Via third-party software.
IrModem Modem	No support.
IrCOMM Virtual Serial Port	This was intended solely for dial-up usage. However users realised that HotSync could be used this way if HotSync Manager on the PC was set to listen on the IrCOMM Virtual COM Port there. To support this usage on Windows 2000 etc Palm added native (Winsock) IrCOMM support to HotSync Manager.
IrTran-P	No built-in support.
Programming	For IrCOMM usage, via the IrCOMM Virtual Serial Port, or through the API below. OBEX server and client usage via the “Exchange Manager” API. General IrDA access through the “IR Library” API. The IrDA device itself can also be opened, thus allowing direct/raw SIR access, with certain major restrictions…

Windows 2000

OBEX	Via the “Wireless Link” application, “File Transfer”. Accepts any object/file type.
IrNet	Both client and server side.
IrLPT	Printers are auto-discovered, drivers installed etc.
IrModem Modem	Client-side.
IrCOMM Modem	Latterly. Client-side.
IrCOMM Virtual COM Port	Support provided by third-party “ircomm2k” software.
IrTran-P	Again via the “Wireless Link” application, “Image Transfer”. This must be disabled if any other application wishes to listen on IrCOMM.
Programming	For IrCOMM usage, via the third-part IrCOMM Virtual COM Port, or the APIs below. General IrDA access through the Winsock API or the kernel-level TDI API.

Windows XP

OBEX	As Windows 2000.
IrNet	As Windows 2000.
IrLPT	As Windows 2000.
IrModem Modem	No support.
IrCOMM Modem	As Windows 2000 patch.
IrCOMM Virtual COM Port	As Windows 2000.
IrTran-P	Disabled by default.
Programming	As Windows 2000.

Linux

OBEX	With OpenObex.
IrNet	Both client and server side.
IrLPT
IrModem Modem	No support.
IrCOMM Device	Both client and server side.
IrLAN	Both client and server side.
IrTran-P	unknown
Programming	Via the IrCOMM device for IrCOMM. General IrDA access through the sockets API. Gives TinyTP and Ultra support. IrLMP and IrCOMM access are available through a lower level API.

Nokia 6210

OBEX	Both client and server side. Menu option form, “Send … via IR”. Handles, at least, Phone book, Message note and Calendar entries.
IrNet	No support.
IrLPT	No support. (The earlier 6110 model has IrLPT client support).
IrModem Modem	No support. (Later phones do have server support).
IrCOMM Device	Server side, general cable replacement access.
IrLAN	No support.
IrTran-P	No support.
Programming	n/a