IrDA uses (brief)
DRAFT 5th May 2004 — First version.
16th August 2004
16th October 2004 — Format changes[b].
22nd August 2005 — More on OBEX/IrReady for printers.
15th October 2005 — Note in IrMC that modem access is by IrCOMM.
8th December 2005 — Note “IrTranPv1” and OBEX over v25.ter.
Copyright © 2004 – 2005 Alan J. McFarlane
Peer-to-Peer and Peer-to-Access-point Networking (IrNet)
Direct / Raw IR (SIR / HP-SIR)
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.
My IrDA FAQ, two documents on the history of IrCOMM in Windows 2000 etc, Window 2000 with Mobile phones (lack of Virtual COM port support) and Microsoft IrCOMM in Windows XP and 2000, and finally my reference document on programming IrDA on Windows 2000 etc, Microsoft Windows IrDA programming. All are available from my homepage, http://www.alanjmcf.me.uk/
The IrDA’s standards documents can be found on their website, http://www.irda.org
Alvin Mok has a very useful and extensive set of profiles for IrDA devices, showing what services they each support, see his site at http://homepage.mac.com/alvinmok/
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.
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 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.
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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.
Uses IrCOMM; the desktop PC application accepts connections from the PalmOS side and thus conflicts.
Uses IrCOMM; the desktop application listens on IrCOMM and thus conflicts.
Uses IrCOMM; the desktop application listens on IrCOMM and thus conflicts.
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. |
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.
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 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.
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.
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… |
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. |
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. |
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. |
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 |
Copyright © 2004 – 2005 Alan J. McFarlane