Alan J. McFarlane
6th December 2001
Updated: 17th February 2002
Updated: 20th March 2002
Updated: 30th August 2002
Updated: 03rd November 2002
Updated: 22nd November 2002
Updated: 15th January 2003
Updated: 5th April 2003 — Small updates and a more compact HTML conversion!
Updated: 15th May 2003 — More small updates.
Updated: 2nd June 2003 — Addition of Windows Server 2003 information and more.
Updated: 2nd June 2003 — Addition of Handspring IrCOMM advice, Windows XP information and more.
Updated: 9th October 2003 — Addition of Polar HRM information.
Updated: 15th April 2004 — Minor additions, e.g. on Consumer IR and Direct IR.
Updated: 6th May 2004 — Fixed a typo in the Polar HRM section.
Updated: 16th August 2004 — Usage information on Lazy Discovery.
Updated: 25th August 2004 — Now refers to the programming reference (+).
Updated: 28th October 2004 — Information on HotSync “port is in use by” [b].
Updated: 12th January 2005 — Some less technical information on the last.
Updated: 16th January 2005 —Summary of instructions for Infrared HotSync.
Updated: 12th February 2005 —Two Treo highlighted IR HotSync issues, ircomm2k with RRAS and minor additions/typos.
Updated 20th February 2006 — Some Vista information, corrected IrTranPv1 mis-casing.
Copyright © 2001-2006 Alan J. McFarlane. All rights reserved.
Palm have added IrDA (over IrCOMM) support to HotSync Manager, this adds a “Infrared” item to the menu alongside “Local”, “Modem” etc for Windows 2000 and XP. It can be downloaded from the Palm support site at .
Figure 1—Palm HotSync Manager on Windows 2000, showing InfraRed menu option
Figure 2—PalmOS HotSync to Infrared
On the PalmOS device itself, in the HotSync application chose “Local” then “IR to a PC/Handheld” and then hit the HotSync icon. This support uses the IrDA IrCOMM protocol and exists in PalmOS version 3.3 and later, if you have an earlier version you will need to upgrade, see Question 4.
Note, on the PC one has to disable the “Image Transfer” functionality of “Wireless Link” and stop any other programs that operate in the same way e.g. “Microsoft ActiveSync”. The option in the Wireless Link Control Panel applet is shown in Figure 3; disabled is the default in Windows XP. See Question 26 for more information on this and how to do it programmatically.
Figure 3—Disabling Image Transfer in Wireless Link
If the “Image Transfer” functionality is not disabled, HotSync Manager on the PC will complain with:
Error accessing the IR Port. See the //Helpnotes//IR_Readme.txt for more information..
By the way, the file “IR_Readme.txt” does not exist! This message can also be seen however, when there is no problem with the infrared usage, this case occurs when HotSync infrared is enabled and one of the other types is toggled. This would seem to be a bug (perhaps the program attempts to re-open the infrared socket when it already has it open).
There is generally a conflict between Windows searching for IrDA devices and HotSync opening on the Palm. Initiate the HotSync process (hit the HotSync button) before bringing the PalmOS device into range of the PC. See below for more details and two other possible causes.
The message below often occurs on the PalmOS (version 4) device when an IrDA HotSync operation is initiated. The HotSync operation does not take place. This generally occurs due to an interaction between the way in which the Microsoft Windows and the PalmOS IrDA communication stacks operate.
Unable to initiate HotSync operation because the port is in use by another application.
In order to support automatic discovery of peer devices for use as printers, modems, or for beaming etc Windows 2000 etc regularly runs the IrDA discovery process. The IrDA stack on PalmOS can only be used by one application at a time and thus there is a conflict when the Beaming application activates to answer the discovery queries and, at the same time, the HotSync application attempts to make an outgoing connection.
There are two workarounds to this problem. Firstly, set “Beam Receive” to “Off” in the PalmOS “Prefs” application. However, it appears that selecting “Off” sometimes does not take immediate effect and that a (soft) reset is sometimes needed. I also have found that this option often automatically jumps to “On” (perhaps after a HotSync). Of course, having Beam Receive disabled will stop you from receiving beamed objects.
The second workaround is to initiate the HotSync operation before bringing the PalmOS device into range of the PC. This allows the HotSync application to gain sole access to the IrDA library and stops the Beam Receive functionality from interfering. As long as you get the two devices in range with 30 seconds of hitting the HotSync button, the connection will be made.
I didn’t see this message displayed on Palm OS 3.3. However the horrid “Waiting for Sender” dialog box was often displayed there—it again was displayed when a discovery query was heard and, thankfully, this behaviour was removed in later version. It is not clear whether the same “port is in use” message was possible there but hidden as the HotSync button was blocked by this dialog box.
Two other causes for this error have become apparent. Firstly, that the software for the Portable Keyboard for Treo 600 can conflict with infrared HotSync—in the PortableKB application select OFF to allow infrared HotSync. Note that driver also conflicts with other IrDA usage e.g. Beaming and other serial port usage.
Secondly the “IR to a PC/Handheld” Connection definition can become corrupted. To check whether this applies, go to the “Prefs” application, select “Connection” from the menu in the top right of the screen, and Edit the “IR to a PC/Handheld” item, and ensure it has the settings listed here. For OS 4, “Connect To:” should have “PC”, and “Via:” should have “Infrared”. For OS 3, “Connection Method:” should have “IrCOMM to PC”.
Figure 4—“ IR to a PC/Handheld” Prefs:Connection setings in PalmOS 4 and 3
On the other hand, if there are no local conflicts, but a connection can’t be made to HotSync Manager on a remote device (PC etc) then the following error is eventually displayed.
The connection between your computer and the desktop could not be established. Please check your setup and try again.
That means that either the Palm can’t find the PC hosting the infrared HotSync application, or that the HotSync application on the PC isn’t responding to the infrared HotSync requests.
More technically, this can be due to there being no IrDA peer found, or an IrDA peer is found but it is not providing the IrCOMM service, or the IrCOMM service is running on the peer but HotSync Manager is not responding on it etc.
On Windows versions prior to 2000 HotSync Manager needs to be set to listen on the IrCOMM Virtual COM port as provided by the IrDA driver e.g. COM4. This also works on Windows NT 4 with QuickBeam suite, see Question 8.
The Palm should be used in the same way as for Windows 2000/XP, see Question 1.
Note it is reported by some but I have not verified this that HotSync can also be used without the Windows IrDA software (IrDA stack, IrLMP, TinyTP, IrCOMM etc) being present. In this configuration, “HotSync Manager” should be set to use the COM port that is the Infrared device itself. This would work because the low level infrared protocol (sometimes called “HP SIR”) is like the serial cable protocol itself. See e.g. http://groups.google.co.uk/groups?q=hotsync+craigbowers&hl=en&rnum=2&selm=8bb292%24cu5%241%40nnrp1.deja.com.
I presume that this would require IrLink software on the Palm configured to use “HP SIR” for the HotSync application. As noted above in current PalmOS 3.3 and later the HotSync “IR to a PC/Handheld” mode uses IrCOMM and not raw-IrDA i.e. “HP SIR”. However, the current version of ISComplete’s (http://www.iscomplete.org) IrLink is only supported on Palm OS 3.0 to 3.1x.
I also have doubts about how well this mode of operation will work. A serial cable connection is full-duplex, that is it can transfer data in both directions at the same time. An infrared device however is half-duplex; this is because it ‘hears’ (sees) its own transmissions so will not receive anything from a peer device when it is transmitting (nor for a short time afterwards). Maybe the HotSync protocol luckily does not send and receive at the same time and thus will work (tolerably) over the raw infrared framing…
As noted above to carry out HotSync over IrDA (IrCOMM) requires OS version 3.3 or later on the Palm. There are multiple upgrade possibilities if you are running an earlier version. Firstly upgrades to later version 3 OSs are available for free on the Palm site, see:
Another route is to purchase an upgrade to version 4.1. This is available for instance at the Palm’s online store.
Some devices cannot have their OS upgraded i.e. the OS is in ROM; such devices include the Handspring Visor. The solution for them seems to be to install (parts of the) “Palm Enhanced Infrared Updater”. See the Handspring support article “What is the Palm Enhanced Infrared Updater and why would I need it?”. Be careful to only install the listed components…
Microsoft has also added IrCOMM Winsock support to their PDA’s PC synchronisation software, in ActiveSync version 3.5 at least. A difference to Palm’s is that it will automatically disable the conflicting “Image Transfer” feature during its activity period. It also finds an IrCOMM Virtual COM Port if one exists.
Note that have I do not own nor have any experience of Windows CE / Pocket PC devices, my experience is only through installing ActiveSync version 3.5 on a Windows 2000 PC and observing its behaviour.
[Out of date. Version 2 of “ircomm2k” apparently allows Psion infrared syncing].
This is one of the things that seem to remain broken by Microsoft not supplying fully functional IrCOMM Virtual COM Port functionality in Windows 2000 and XP. The PsiWin application can only communicate over COM Ports, thus in Windows 98 (for instance), it could be connected to the IrCOMM Virtual COM Port and using IrCOMM support in the Psion device synchronisation could be carried out.
Unfortunately even with the IrComm2k Virtual COM Port software (see question “Windows 2000, XP and general IrCOMM” below) being used on Windows 2000 this method does not work. It is not known why, perhaps the lack of the control signal lines being transferred or possibly that the user mode to kernel mode structure of the IrComm2k software creates longer latencies that can be handled. However it should not be difficult to add Winsock IrDA support should Psion wish to support infrared synchronisation / access.
A new version of IrComm2k is in development one of the aims of which is to support Psion usage, see its Version 2 pages. There are reports of the Alpha version proving successful.
One of the most useful protocols within the IrDA suite is object transfer (OBEX) or Beaming, as Palm would call it. All devices that support IrDA should really include it. Even some printers these days are including support. The most common use for OBEX is in transferring Address book entries between the various systems, for instance between Palms and Mobile phones. OBEX does not define any file types itself, and similar to HTTP uses MIME style file types. Commonly supported files types are vCard and vCalendar, these are recommended in the IrMC specification, which also adds vNote a plain text format.
There does seem to be some compatibility problems though. I have problems beaming between Windows 2000/XP and PalmOS 3.3 and with QuickBeam. Others seem to encounter such problems see e.g. 
Devices used include:
Other devices professing support include:
Microsoft does not provide IrDA support on Windows NT 4, but a third-party solution exists from Extended Systems (http://www.extendedsystems.com/) called “QuickBeam suite”. I have used it successfully both for Palm HotSync and for beaming.
Note the Quickbeam suite has its own API (and SDK) and does not use the same API as the Microsoft solution.
The IrDA support in XP is slightly enhanced from that in Window 2000, as discussed in presentation “IrDA and Windows XP”. The differences are as follows:
The document also notes that having HotSync use a unique Service Name e.g. “IrCOMM:HotSync” rather than pure IrCOMM would sidestep the conflicts.
Windows Server 2003 has now been released, in short, it is a new Server platform like Windows 2000 Server, and has four versions Standard, Enterprise, Datacenter and Web. It appears initially that only the Standard version includes IrDA support; all of the relevant pages in TechNet (see ) include the following statement in their notes:
In the Windows Server 2003 family, only Windows Server 2003, Standard Edition, supports infrared networking.
The Wireless Networking “Resources” page also agrees:
The Infrared Data Association (IrDA) is an international organization that sets standards for infrared data connections. The infrared support provided by Windows XP Home Edition, Windows XP Professional, and Windows Server 2003, Standard Edition is designed to meet these standards.
The support is not included in any 64-bit versions though; the TechNet page on Irftp includes the following:
This tool is not available on Windows XP 64-Bit Edition and the 64-bit versions of the Windows Server 2003 family.
Also, note that the support is removed in the 64-bit Windows XP too. An equivalent statement is also made in the “Technical Overview of Windows Server 2003 Networking and Communications” (NetworkingOver.doc) document.
The following legacy networking protocols are
removed from the 64-bit versions of the operating system:
· Infrared Data Association (IrDA).
That document however raises a point of confusion. It says in its “IrCOMM Modem Driver for IrDA” section,
This feature is only provided in Enterprise Edition and Web Edition.
Also, Knowledge base article “325867 - HOW TO: Configure Your Computer for Infrared Communication in Windows Server 2003” states:
The information in this article applies to:
· Microsoft Windows Server 2003, Standard Edition
· Microsoft Windows Server 2003, Web Edition
And finally, in an online chat on “What's new in Windows Server 2003?” a Microsoft engineer stated that he personally had used IrDA “in both Standard and Enterprise editions”.
Thus, there is a complete lack of agreement over which editions do include IrDA support. I would have thought that Standard edition is the edition most likely to be used on a user’s machine—for development testing etc—and thus where IrDA and also the modem access would be useful. Any confirmation or otherwise of the actual support would be welcome. What editions have you installed and did they include IrDA support?
I have had one report on this—thanks Mark. It was found that Standard did have IrDA support and that Enterprise and Web did not. That supports the “only in Standard” belief.
I’ve been worried for some time that Microsoft had completely lost interest in IrDA, given that there’ve not added support for IrDA in XP 64-Bit, nor included it in some of the Server 2003 versions—thought that was probably more a security “attack surface” decision. I know it’s not the today’s hot wireless connectivity technology but I know that lots of people use it; I get lots of accesses to my website, emails, and see questions in many forums online. It would thus be a bad thing if it was to be dropped from future platforms.
We’ve also seen before, with the Windows 2000 no IrCOMM for mobile phones, HotSyncing, etc debacle, that making decisions about IrDA support in the US can give a false view of user requirements —given the different technology environments that exist in the Europe, Asia, etc.
So anyway, back to IrDA support in Vista, there’s not a great amount of informaiton, however the following is in the Vista Beta 1 Release Notes document:
• Infrared (IrDA) Devices: There are known issues with IrDA devices. There are no workarounds at this time. These issues include the following:
When you transfer files using an IrDA device, they are saved in C:\Users\Default User\Desktop instead of the desktop for your account.
Certain devices can take up to 20 minutes to discover each other.
Certain IrDA device drivers cannot be uninstalled successfully.
Certain IrDA devices can cause the system to stop responding for up to 40 seconds if the infrared transmission is interrupted.
So IrDA support is apparently included; but also needing some work before release…
For Vista in particular, and for IrDA support in general it would probably be a good idea for all you who use IrDA to email Microsoft noting that you use the feature and how disappointing it would be if they stopped supporting it; a suitable email address would likely be firstname.lastname@example.org It might also be helpful to not what usage scenarios you use, any bugs you’ve found, and any other features that would be useful.
Windows XP contains all the functionality required out-of-the-box to use an IrDA enabled Mobile Phone as a modem, it’s also truly plug-and-play (plugless-and-play?!). When Windows XP discovers a Mobile Phone in front of the infrared sensor, it will automatically add a suitable Modem device, which can then be used in creating Dial-up Connections etc. Note that an IrCOMM Virtual COM Port is created for the connection to the mobile phone, see Figure 5.
I don’t know what phones work, and more importantly which don’t work, without further driver software or INF files being installed. It appears for instance that the Motorola Timeport models don’t work with the generic driver and require the “_motlser.inf” file from the CD to be installed first.
Figure 5—Windows 2000 Mobile Phone IrCOMM support
Older phones like the Nokia 6110 do not contain an IrCOMM Modem and thus will not be useable in this way, see Question 16.1.
Windows 2000 does not contain the same IrCOMM Modem support by default, however an update exists to add it. The patch can be found at http://www.microsoft.com/windows2000/downloads/security/q252795/default.asp . This patch is included in Service Pack 3 (SP3). More information on the patch can be found at  and .
Many devices use IrCOMM as their IrDA communications method, such applications include PalmOS devices and Psion PDAs for synchronisation, Mobile Phones for changing Ringtones, Icons and access to their Address Books etc. I am not a fan of this mode of operation, amongst other thing it cause a huge conflict. For instance if you want to HotSync your Palm, ActiveSync your PocketPC and transfer pictures from your digital camera then on your PC you must stop and start the respective applications. This is not user friendly. I have discussed this previously in my other documents, so I won’t discuss the wider issues further here.
There are three possible solutions to the lack of IrCOMM Virtual COM Port support in Windows 2000 and XP for these applications:
Note that for access to mobile phones for Ringtone updating etc which uses/needs an IrCOMM Virtual COM Port, then the Windows XP/2000 etc IrCOMM Modem support, as described in Question 9, provides the required Virtual COM Port (when the phone is in range).
A PalmOS device with version 3.3 or later can use an Infrared Mobile Phone as a modem. In the “Prefs” application, firstly a “Connection” called “IR to a Modem” should be created which uses the “IrCOMM to Modem” Connection Method.
Figure 6—PalmOS Prefs Connection list
Figure 7—PalmOS IrCOMM Connection
Network connections can then be created with “Connection” set to “IR to a Modem” (see Figure 7).
Figure 8—PalmOS IrCOMM Network connection
Note that for modern Mobile Phones no extra software is required, older phones e.g. the Nokia 6110 required extra software on the Palm to allow dial-up networking, see Question 16.1.
Most current Mobile Phones that include Infrared include both IrCOMM and OBEX; this means that they can be used as a modem by Windows, PalmOS etc and for ‘Beaming’. Earlier phones with infrared often included neither of these capabilities for instance the Nokia 6110, see Question 16.1.
This applies to Nokia, all of its current phones with infrared have the two capabilities i.e. 6210, 7110, 8210 etc. However, the Motorola Timeport P7389 is known to only have the IrCOMM capability and not OBEX. More information on phone capabilities can be found at e.g. , .
The IrModem protocol, which was the only way to access mobile phones in Windows 2000 originally, has been removed from Windows. Ironically, the newer Nokia phones do appear to include support for this protocol. This highlights the problems of different development and release schedules, though Microsoft was expecting too much if they really expected people to upgrade their phones to get IrModem compatible versions.
As noted above, some earlier Mobile Phones had IrDA protocol support but had neither OBEX, not IrCOMM Modem functionality. This includes the Nokia 6110, which could print Address book entries and allow multiplayer games to be run over an infrared connection though could not send Address book entries to other devices, nor be used as an IrCOMM Modem.
Software was (is) available for both Windows and PalmOS to communicate with the proprietary modem in the phone. I would recommend though that you spend the money on a new phone rather that software for one or more of your other ‘computer’ devices. That way you get the full current phone support giving full compatibility with other devices.
Printers generally have IrLPT support, this is a cable replacement protocol, it does not include a page definition language etc. The peer device must understand the printer’s language e.g. PostScript, HP’s PCL etc. In Windows 2000/XP (and possibly earlier versions) infrared printing is plug-and-play. When Windows first ‘sees’ the printer, it will add a suitable Printer driver.
For PalmOS, one needs third-party software, for instance PrintBoy from http://www.bachmannsoftware.com/. Printing support in Mobile Phones is known to exist in the Nokia 6110, as noted above, but the availability of this support in other phones is not known.
As noted above printers have recently been having OBEX (Question 4) support added. This makes printing from all devices a real possibility, for instance from Mobile Phones, PalmOS without extra software etc. Of course the printers will not be able to support all file types, however support for vCard, vCalendar and vNote will be of great benefit, providing printing support for those small devices who can’t provide full printer driver support.
To network connect directly to (or through) an NT machine you have to install RAS server along with modem type “Dial-Up Networking Serial Cable between 2 PCs” on the NT machine. This ‘modem’ type requires handshake of the form, send: “CLIENT”, receive: “CLIENTSERVER”. So on the Palm on the Network Script page enter:
Wait For: CLIENTSERVER
That’s the only ‘trick’. On NT the RAS and on the Palm the Network set-up is as normal otherwise, PPP will run great. Note since the COM Port can only have one application using it at a time you’ll have to stop HotSync Manager (or unselect “Local” from its menu) before you start RAS Server. :-(
I've connected like this with the Cradle, using Infrared should be the same, just connect the “Dial-Up Networking Serial Cable between 2 PCs” ‘modem’ to the Virtual Infrared COM Port e.g. COM4 rather than e.g. COM1.
This set-up is largely the same on Windows 2000 and Windows XP. Of course, due to the non-existence of the general IrCOMM Virtual COM Port functionality in Windows 2000 etc, the connection over infrared (IrCOMM) is not possible by default. Microsoft has replaced that function with a different method (IrNet a.k.a. IrDial, IrNetv1); however, new software would be required for the PalmOS, and it does not exist.
Fortunately, the ircomm2k software (see solution 3 in Question 11 above) can be used to create the IrCOMM Virtual COM Port on the PC; the port it creates can then be used by RRAS in a configuration similar to that on NT4. There are reports of this being used successfully, see . Remember to set-up the dial script on the Palm as below.
Serial cable connections continue to work. The null modem device in Windows 2000 that need to be used is called “Communications cable between two computers”. It appears that the script sequence on the Palm needs slight modification though. I’ve seen a recommendation that the sequence be changed to send two CLIENT prompts; this does seem to be required and does work.
The sequence is then:
Wait For: CLIENTSERVER
This is consistent with the information in Microsoft KB article 145879; it says:
“Microsoft Windows NT version 4.0 and Windows 2000 products, Remote Access Service (RAS) answers incoming calls after the first ring and Windows 2000 Routing and RAS answers on the second ring.”
My understanding is that RRAS alone is present in Windows 2000, and therefore I don’t understand the reference to Windows 2000 in the initial RAS related clause. My reading of it then is that Windows NT 4.0 (RAS) answers after one ring and Windows 2000 (RRAS) answers after two rings.
The ‘two ring’ script also works for Windows NT 4.0 with RAS, which just ignores the second instance.
Some of the Heart Rate Monitor (HRM) devices from Polar contain infrared connectivity; this allows the uploading of exercise data and configuration of the device etc. There has been much confusion as to how to use this connectivity from the various Windows OS versions. This information hopes to provide some illumination on the subject.
Not that the information here is based on the user manual and support documentation that Polar provide on their web sites and also on analysis of infrared trace information provided by users of Polar products, I have no hands-on experience with the devices. The information is believed to be correct but, as always, any comments good or bad are welcomed.
The main thing one must understand about the infrared connectivity is that there are two separate types of infrared connectivity in these devices. The type used is noted by whether the model name ends with an “i”.
The (newer?) models with the “i” suffix, the S610i, S710i, S720i, S810i, communicate using the complete IrDA protocol suite. Window’s built-in IrDA software is used along with any IrDA adapters configured for its use; this is same mode of operation (and adapter(s)) that one uses to ‘beam’ to and from PDAs and Mobile Phones etc with the “Wireless Link” application, dial the Internet through a Mobile Phone, HotSync a Palm etc. In this mode, the “Polar Precision Performance software” (PPP SW) is set to use “IrDA” on the “Hardware” tab of the “Options”->”Preferences” dialog box. This mode should work on Windows 2000 and later, and also on Windows 98.
For the technically interested, this mode appears to use a TinyTP connection with Service Name “HRM”, with the connection initiated by the PPP software on the PC. [typo! Previously it said “NRM”. The Service Name is of course “HRM”, for “Heart Rate Monitor”]
The models without an “i” suffix, the S610, S710, S810, use a form of connectivity one might call “Direct IR”, it uses the very bottom layer(s) of the IrDA protocol suite alone. Polar supplies a serial connected adapter and also a USB connected adapter for use in this mode.
This mode requires direct access to the IR adapter on your PC and thus, for internal adapters in particular, the OS’s IrDA software must be disabled to allow this. The Polar documentation notes that this mode is only available on Windows 95. I would expect this to work in much the same way on Windows 98 though, for Windows 2000 etc see below.
Access to an IrCOMM Virtual COM Port is not of any benefit in this case. The PPP SW must directly access the physical COM Port representing/attached to the IR adapter. IrComm2k, for instance, on the other hand creates a virtual serial connection over the complete IrDA stack, which is of no use here. There is also no IrCOMM support in the Polar devices themselves.
The Polar documentation is correct in noting that the “Direct IR” mode is primarily available on Windows 95, it is likely however that this mode can be enabled on other platforms too. As noted above, it requires direct (‘raw’) access to the IR adapter through the physical COM Port to which it is attached.
In Windows 2000 etc any IrDA hardware built-in to a PC is plug-and-play discovered and is made accessible to the IrDA driver software alone and is not made available as a COM Port. No way to configure the system to instead provide access to the hardware as a COM Port is immediately apparent.
This is likely the case for USB adapters too. However it is not known whether the USB adapter Polar supplies is a general IrDA adapter and is discovered by Windows 2000 etc and assigned to the IrDA software though, or whether it remains available to the PPPSW directly.
However, an external serial port connected IrDA adapter is not automatically discovered by Windows 2000 (plug-and-play does not detect such serial port connected devices) and can thus be accessed directly through the respective COM Port. It is likely that such adapters can thus be used by the PPP SW simply by setting the PPP SW to use the COM Port to which it is attached. Feedback on whether this works is welcomed. If you have previously ‘added’ your serial IrDA adapter with “Add/Remove Hardware” you can stop the IrDA software from using it by deleting or disabling the respective device in “Device Manager”.
Along with my laptop’s built-in IrDA device, I have an external serial dongle. I have failed to have successful communications through this device in Windows 2000 (SP2/SP3) if it is configured in Device Manager to be allowed to communicate at rates higher that the minimum 9600 bps. I have seen other reports of the problem and with other dongle types, for instance I have taken part on a discussion of this in the newsgroup comp.sys.palmtops.pilot.
The failure in communications occurs once a connection is requested; the initial ‘discovery’ operations are carried out successfully e.g. “Wireless Link” show peer devices in range correctly. This is interesting as 9600 bps is the rate at which the discovery process is carried out; after the discovery a connection is formed and a higher rate is agreed, so it would seem that the rate change process does not function correctly with these dongles in Windows 2000 (or at least in some installations or PCs?).
The IrDA specification can be downloaded from the IrDA web site, http://www.irda.org/.
Microsoft provides access to IrDA communications through Winsock (IrSock?). It provides TinyTP, IAS, IrCOMM and IrLMP support through various socket options. Information can be found in the MSDN Library (http://msdn.microsoft.com/library/) the URL of the start page is currently http://msdn.microsoft.com/library/en-us/irda/irda_start_2i05.asp?frame=true.
Due to omissions and errors, particularly on the advanced features, in the Microsoft documentation (and in all other sources of documentation, even hardcopy, that I have found) I have created a reference guide for this subject. All the information in has been manually verified. It is at http://www.alanjmcf.me.uk/comms/infrared/Microsoft Windows IrDA programming.html.
If you link to ws2_32.lib then you’ll receive a 10047 WSAEAFNOSUPPORT “An address incompatible with the requested protocol was used.” error in your program on opening the socket. The answer is to link instead to the Winsock library wsock32.lib. (Thanks to Vijay)
I have finally worked-out how to use Lazy Discovery! In the end, there is nothing particularly special about calling and using the feature; but instead, I discovered after many tortuous debugging sessions that the feature only works when being run as an Administrator! I can see no reason why such high privileges would be required for this feature and can only assume that this aspect of its usage is a bug.
See my Winsock IrDA programming reference for information on its usage, see Question 22.
Good information on the Microsoft support for Infrared is contained in “Hardware Development”; the Infrared section is currently at http://www.microsoft.com/hwdev/tech/network/infrared/default.asp.
As noted in Question 1 the “Image Transfer” (IrTran-P) functionality of the Wireless Link application in Windows 2000 etc conflicts with Palm HotSync Manager and any other applications that need to listen on IrCOMM. The user can disable it in the Wireless Link Control Panel applet; see Figure 9. In Windows XP, the default is ‘disabled’ so you probably won’t have to do this manually.
Figure 9—Disabling Image Transfer in Wireless Link
Investigation (thanks again to Sysinternals’ Regmon) has shown that this operation controls a Registry key. The Wireless Link application monitors this value, re-reads it on change, and enables and disables IrTran-P use of IrCOMM based on the value. The key is “HKEY_CURRENT_USER\Control Panel\Infrared\IrTranP\DisableIrCOMM”; values are 1 and 0, for true (i.e. disable) and false (i.e. enable) respectively. As noted whenever (and by whomever) this value is changed the service application reacts (likely by monitoring changes to this registry key). ActiveSync is seen to set this value when synchronisation starts and when it finishes, to remove the conflict over IrCOMM use.
Knowledge base article 278277 notes that the user interface can get out of step with the actual setting.
If one wants to replace the Wireless Link program (irmon.dll, irftp.exe) with another OBEX application, the local OBEX ‘port’ (actually IAS entry) needs to be free. Unlike with the IrCOMM equivalent “Image Transfer” as discussed in Question 1 and 26, de-selecting the apparent equivalent “Allow others to send files to your computer using infrared communications” in the Wireless Link Control Panel does not release the OBEX port (an attempt to ‘bind’ to “OBEX” fails with WSAEADDRINUSE 10048). To free the port actually the “Infrared Monitor” Service itself needs to be stopped e.g. “net stop Irmon”
GSM Mobile phones (cellular phones) have multiple features extra to dial-up that it can be useful to access over infrared, these include the phonebook (address book), the SMS message store, the ability to send SMS messages etc. Access to these features is generally available in two ways, through OBEX and through extensions to the AT command set. In the former, to transfer messages/phonebook entries to the PC requires the user to use the phone’s menus to send the object.
This latter mode is controlled by commands from the PC and same commands are used as if the connection to the mobile phone was through a (serial) cable connection. When using infrared an IrCOMM connection should be made to the phone; in Windows 2000 use the Winsock support and in Windows 98 (etc) use the IrCOMM Virtual COM Port.
The commands are described in standards published by ETSI (the “European Telecommunications Standards Institute“) and can be downloaded for free from their website (after registration). Two standards of interest are:
ETSI TS 100 916
Digital cellular telecommunications system (Phase 2+);
ETSI TS 100 585
Digital cellular telecommunications system (Phase 2+);
(Search at ETSI.org for 07.07 and 07.05 respectively).
Two example commands are AT+CPBR to read a phonebook entry and AT+CMGR to read a message.
I have no knowledge of what phone types support what subset of the defined commands.
Many people want to use IrDA hardware alone to communicate with peer devices and not use the complete IrDA protocol stack. This is using the hardware like a serial cable, simply having it send a stream of raw bytes using the HP-SIR format and not using the complete IrDA stack to do provide half-duplex turn-around, discovery, form a connection, provide flow control and retransmission etc.
Benefits to this are not needing an IrDA stack present on the two peers and it also will probably allow lower latency communications. However as noted above there is then no half-duplex turn-around, flow control, retransmissions etc.
Gaining access to the IrDA hardware for this use can be difficult. On Windows 2000 etc, as noted above, gaining direct to the hardware is only easy for serial port connected dongles. Devices connected to the motherboard or to USB are not easily accessed directly. IrComm2k is NOT for this purpose.
On the more recent Palm devices, e.g. the Tungsten T, Zire 21 etc, which run OS5 the OMAP processor they use contains the IrDA framing functionality and only will accept complete IrLAP frames. It is thus not possible to send arbitrary octets. From the FAQ at pa1mOne’s developer site (PluggedIn Program),
Raw IR mode cannot be used on OMAP-based (Tungsten|T, Tungsten|T2, Tungsten|E, Zire21, Treo600, and Zire71) products due to an OMAP processor limitation. The OMAP's UART3 automatically frames all data according to the IrDA specification. There is no way to change this setting in the processor and use raw IR in the OMAP UART.
Other devices using that processor, or processors with the same feature, will not be able to send arbitrary bytes. It would be sensible either to not use ‘direct’ IR, or to define your protocol to use IrLAP format frames to transfer all data.
It should be noted that the IrDA devices in our PCs, PDA, mobile phones etc use the IrDA-Data standard and it not the same, or even very similar, to the infrared we use to control our TVs, Hi-Fis. Just because they both use the word “infrared” does not mean that they are related. The ‘modulation’ the two use are different, IrDA send frames etc etc.
Software for 'Consumer' IR can be found on the net, it generally needs a simple IR diode etc connected to a serial port and can't work with an IrDA dongle. Often IrDA dongles contain active components that reshape the given signal and thus can’t used to send arbitrary infrared pulses.
For instance I have a Girbil serial dongle which has a 8205 or some sort of microcontroller inside the case which I presume would likely do signal re-shaping, and requires special signals to set the bit rate it uses at any particular time. As to the signal shaping this probably affect the receive function more as the received signal will not appear similar to an IrDA IrPHY signal.
The web page at http://www.veg.nildram.co.uk/remote.htm (and /furby.htm) says that you can use an IrDA device to send remote control like signals but can't receive, as far as the author can manage. This seems to be case at http://www.lirc.org/irda.html too though some may work and note that some of the dongles can be set into Consumer IR mode... Other related links: http://www.cswl.com/whiteppr/tech/pulseshaping.html
Any information on this or any other relevant information including any errors in this document would be appreciated in order to improve this document. Please send emails to mailto:email@example.com.
Copyright © 2001-2006 Alan J. McFarlane. All rights reserved.
Document for information only, no warranties blah de blah, all trademarks etc.
 “Palm, Inc. - Updater for HotSync v3.1.1 for Windows” at http://www.palm.com/support/downloads/palmhs_update.html
 Ideally Palm would have updated HotSync Manager and the PalmOS HotSync application to communicate directly over TinyTP (with an IAS Name of “PalmHotSync” perhaps) and thus remove conflicts over IrCOMM.
 PalmOne “Solution ID: 26288—Could not initialize library (when trying to beam) (Treo 600)” at http://kb.palmone.com/SRVS/CGI-BIN/WEBCGI.EXE?New,Kb=PalmSupportKB,ts=Palm_External2001,case=obj(26288).
 PalmOne “Solution ID: 29117—Can't use modem or other applications that use the Treo 600's serial port after installing the Portable Keyboard driver” at http://kb.palmone.com/SRVS/CGI-BIN/WEBCGI.EXE?New,Kb=PalmSupportKB,ts=Palm_External2001,case=obj(29117), also “Treo 600 Portable Keyboard Driver” at http://www.palmone.com/us/support/downloads/treo/treo600_kb_driver.html.
 European PalmDirect has the version 4.1 upgrade at http://www.palmdirect.com/palmeurope/dept.asp?dept%5Fid=412, the USA store has it at http://store.palm.com/category/index.jsp?categoryId=1179762.
Handspring’s “What is the Palm Enhanced Infrared Updater and why would I need
 IrComm2k (http://www.ircomm2k.de/) Version 2 pages at http://www.stud.uni-hannover.de/~kiszka/IrCOMM2k/English/version2.html or http://www.stud.uni-hannover.de/~kiszka/IrCOMM2k/version2.html depending on your language preference.
 From page “ZiLOG's Riverwave” http://www.riverwave.com/customercare/knownxcon1121_2.html “Using FileConnect Lite to transfer files between the Palm Computing Platform and PC is not always successful. Please reference the matrix shown below. …”. Note I have no experience with the Riverwave software.
 “hp LaserJet 2200 series more information, Wireless Printing” at http://www.pandi.hp.com/pandi-db/ValueAddContent?oid=27647&page=laserjet2200/technote/wireless.html
 Presentation “IrDA and Windows XP” at http://www.microsoft.com/whdc/hwdev/presents/tech/network/infrared/IrDAConf-06-01.ppt (from http://www.microsoft.com/whdc/hwdev/tech/network/infrared/default.mspx).
 Page in TechNet that note that Windows Server 2003 has IrDA support only in Standard edition include: “Understanding infrared networking” at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/entserver/understanding_IrDA_topnode.asp?frame=true, “To verify infrared support on a computer” at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/standard/verify_irda_portables.asp?frame=true and “To send files using the command line” at etc.
Note each of those pages has a version for each edition, for instance the last page above is also at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/datacenter/send_files_ir_cline.asp?frame=true.
 TechNet Windows Server 2003, Wireless Network “Resources” page: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/entserver/sag_IrDAconcepts_301.asp?frame=true.
 TechNet page on Irftp in Windows Server 2003 at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/standard/Irftp.asp?frame=true
 “Technical Overview of Windows Server 2003 Networking and Communications”, NetworkingOver.doc at http://www.microsoft.com/windowsserver2003/techinfo/overview/netcomm.mspx
 “What's New in Windows Server 2003” Chat transcript at http://www.microsoft.com/technet/itcommunity/chats/trans/windowsNET/wnet0611.asp.
 “Brown acknowledges that the U.S. market for infrared in mobile phones is "anemic," and points to the way cell phones are used as the culprit. In Asia, users tap the IR port in their handsets to exchange personal contact information, make payment transactions and exchange pictures. European users often use the IR connection as a sort of wireless modem, linking the Internet access capabilities of their handset with other devices such as laptops. Neither is the case in the U.S. market, Brown notes.” from http://www.wirelessweek.com/article/CA601564.html, Testing Infrared's Limits by Karen Brown, May 15, 2005,Wireless Week.
 “Release Notes for Windows Vista Beta 1 and Windows Server "Longhorn" Beta 1 ”http://www.microsoft.com/technet/windowsvista/relnotes.mspx
 Note digital Mobile phones e.g. GSM phones do not need nor will even contain a modem; a modem converts digital signals to pass over an analog phone system. All that Mobile phones need is support for the AT command set so that Windows can talk to them using a traditional modem driver. The ‘soft modems’ supplied for some modem phones convert the AT commands into the binary format accepted by the phone.
 “Security Update, August 19, 2001” at http://www.microsoft.com/windows2000/downloads/security/q252795/default.asp
 “Windows 2000 Does Not Support Mapping Virtual COM Ports to Infrared Ports (Q252795)” at http://support.microsoft.com/support/kb/articles/Q252/7/95.asp
 “Microsoft Security Bulletin MS01-046” at http://www.microsoft.com/technet/security/bulletin/ms01-046.asp
 The history of IrCOMM usage in Windows 2000 and later is covered in two of my documents: “Window 2000 with Mobile phones (lack of Virtual COM port support)” at http://www.alanjmcf.me.uk/comms/infrared/Window2000InfraredAndMobilePhones.html and “Microsoft IrCOMM in Windows XP and 2000” at http://www.alanjmcf.me.uk/comms/infrared/MicrosoftIrCommInXPand2000.html
 IrCOMM2k forum post “palm networking over irda” at http://sourceforge.net/forum/message.php?msg_id=2451305 However, if you use the CLIENT/CLIENTSERVER script on the Palm, the modification of the .INF file should be unnecessary.
 “Connecting a Palm Pilot to Windows 2000” at http://www.users.globalnet.co.uk/~echobase/network/win2k/
 Microsoft Knowledge base article 145879 “How to Set the Number of Rings for RAS Auto-Answer in Windows NT 4.0/Windows 2000” at http://support.microsoft.com/default.aspx?scid=kb;en-us;145879
 References from Polar user manual and support notes.
From the “Polar Precision Performance SW 4” User Guide. Page 4:
If you are using Polar S810i, Polar S720i, Polar S710i or Polar 610i via computer's internal IR port select IrDA.
Use Internal Infrared Port (Win95 only)
Polar S810, Polar S710 or Polar S610 HR monitors do not support IrDA infrared communication, but instead use so called direct infrared communication.
If you are using above mentioned monitors via computer's built-in IR port you have to select this option. Also, you need to disable the Windows Infrared Monitor in the operating system.
Note that direct infrared communication is available only with Windows 95 operating system.
Different Polar heart rate monitors use different methods for transferring exercise data to the computer.
The exercises from Polar S610i, Polar S710i, Polar S720i and Polar S810i are transferred using an infrared connection. You can use Polar IR Interfaces or other manufacturers' IrDA supported IR interfaces. Also computer's internal IR port can be used. With Polar S610, Polar S710 and Polar S810 data transmission is enabled through Polar IR Interfaces only.
With Polar S810i, Polar S720i, Polar S710i and Polar S610i the exercises are transferred using infrared communication via Polar IR Interfaces or other manufacturers' IR interfaces.
With Polar S810, Polar S710 and Polar S610 exercise data can be transferred through Polar IR Interfaces only.
From FAQ article “How to use your PC's internal infrared on Windows 95”:
You can transfer information between Polar S610 / S710 / S810 HR monitors and Polar Precision Performance SW 3.0, by the internal infrared only if you have Windows 95 installed. In Win95, the infrared works as a generic serial port. In Windows 98 / Windows Me / Windows 2000 / Windows XP a COM port is handled as a virtual port. Due to this technical difference, i.e. lack of physical serial port it is not possible to use the Polar Precision Performance SW 3.0 and Polar S610 / S710 / S810 Heart Rate Monitors with these operating systems.
 It is possible that removing the “netirsir” “.inf” and “.pnf” files from the “%windir%\inf\” directory (move them to another location e.g. “c:\backup\”) and rebooting may be enough. This file (“netirsir”) contains the definition of the Plug-and-Play identifiers (IDs) for internal IrDA adapters and thus Windows will instead use the adapters’ COM Port identifier during discovery. Again if you have previous ‘added’ an adapter, remove it in “Device Manager” before rebooting. Feedback on this please.
 Thread “Infrared Hotsync only with von 9600 Bit/s possible?” in comp.sys.palmtops.pilot e.g. at http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3D7BCB6C.8020207%40innocent.com&rnum=30&prev=/groups%3Fq%3Dalanjmcf%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26scoring%3Dd%26start%3D20%26sa%3DN
 Sysinternal’s Regmon at http://www.sysinternals.com/ntw2k/source/regmon.shtml
 Microsoft Knowledge base article 278277 “Use Wireless Link to Transfer Images” Check Box Is Cleared by Default, but the Feature Does Not Respond Correctly at http://support.microsoft.com/default.aspx?scid=kb;en-us;278277
 “Q: Why can't I use raw IR Mode on OMAP-based (Tungsten|T, Tungsten|T2, Tungsten|E and Zire71) products?” in PalmOne’s “PluggedIn: Frequently Asked Questions” http://pluggedin.palmone.com/regac/pluggedin/auth/FAQ#raw_IR