I document two issues where IrDA discovery is problematic with a Palm OS device. Firstly that certain modern notebook PCs with built-in IrDA devices fail completely to discover a Palm PDA in most situations, and secondly that the time for a Palm to be discovered by a certain other notebook PCs is great when the distance between the two devices is less that 40cm, and even sometimes at short distances fails completely.
Of course, I only describe the particular problem reports I’ve had or problems I’ve experienced myself; it could well be that these problems affect a wider range of devices. Let me know. Perhaps it’s even the reason for all those “change the transceiver type, dude” recommendations…
I’ve had a number of reports of Windows notebook PCs failing to discover Palm PDAs, thus not allowing files to be beamed from the PC to the Palm etc. One report can be seen at Palm’s forums site. The correspondents are using modern notebooks, running Windows XP, and using the notebooks’ built-in IrDA device. In both cases the “Beam Receive” option is enabled on the Palm, but the Palm isn’t detected: no Wireless Link icon appears on the desktop, etc. Also, in at least one case, the user reports that they experience no problems when using an older notebook.
However, there is no problem in the other direction; that is the Palm discovering the PC; beaming a file to the PC, and HotSync over IrDA both work without problem. In addition when those connections are in progress, the PC does realise that the Palm is in range, with the Wireless Link icon appearing on the desktop (of course, as is normal during HotSync the Palm appears named “IrCOMM” ).
Two example cases are as follows, Ken has a Palm m515 and a Palm Tungsten T3, and two notebook PCs, one with Windows ME, and the other a new Dell Inspiron 500m with Windows XP, and has tried with both Service Pack 1 and 2. He reports that the ME notebook discovers either Palm without problem, but that the XP notebook won’t discover either Palm. Ken also reports some further peculiarities with the behaviour, more of that below. Finally, he reports that the both Palms discover both PCs without problem, and that there are no issue between any of the other IrDA devices he owns.
tparnato has a Treo 650 and a Windows XP SP2 notebook, and reports that the Palm discovers the PC without problem, but that the PC discovers the Palm “less than 1% of the time”.
Given that I have don’t experience this problem between my Palm and the USB-connected IrDA device on my Windows XP desktop PC, my suspicions were with the particular built-in IrDA device. As a troubleshooting step I suggested Ken buy a USB IrDA device. With it Ken reported that discovery worked without problem. So apparently something about the built-in device is causing this problem.
However, note that Ken also reports that the PC has no problems discovering his “mobile phone, IrDA printer adapter, or any other IrDA-enabled PC”. So, it seems likely that the Palms’ IrDA software or hardware has some fault, which is highlighted by some aspect of the behaviour produced by the notebook’s built-in IrDA device. Or, it could be that the built-in device has some fault that all of the other devices are willing to tolerate.
There is apparently also some hysteresis in the behaviour. Ken has done extensive experimentation and reports that the Palm becomes discoverable by the built-in device if the Palm has recently been in range of another device. Rather than rephrase his reports, I’ll just use his words:
a) If either PDA is turned off, brought within range of the built-in transceiver and then turned on, it is never discovered.
b) If either PDA is turned off, brought within range of the [USB IrDA] dongle and then turned on, it is always discovered.
c) If either PDA is discovered by the dongle and then moved out of range, the computer reports that the link has been broken.
If the PDA is then moved within range of the built-in transceiver (but not the dongle) then it is immediately re-discovered and the link is re-established.
This only occurs if power is maintained on the PDA whilst it is moved between the transceivers.
As with the previous tests, this seems to indicate that the status of the PDA is somehow changed when it is successfully discovered. This renders it "discoverable" by the built-in transceiver. Turning off the PDA resets its status.
Ken also sees this behaviour when instead of the USB dongle he first brings the Palm into range of the Windows ME notebook. This behaviour is hard to explain…
So, with a Palm we have problems with an on-motherboard device, but not with a USB-connected device. It is recognised that USB devices have a greater latency than other types of device, so perhaps the delay added by the USB device stops the problem from occurring.
The Linux IrDA stack maintainers note that incompatibilities with some peer devices are due to their stack being so fast (aided, of course, by the great speed of a PC running Linux). During an IrLAP connection the Linux stack will send new frames before the transceiver on the peer device is ready to receive, this occurs because the peer device sends an incorrectly low value for its Minimum Turnaround Time (MinTT) parameter at connect-time.
However, I can't see how that particular problem would occur during the discovery phase. Nor do I know of any way to put a lower limit on the time Windows will wait before sending a frame to a peer device—the Minimum Turnaround Time setting common in the IrDA device’s properties sheet (in Device Manager) sets the device’s own MinTT value.
There is another possible source of this problem; perhaps instead of being too slow to accept a new frame the Palm is instead too slow to respond. During discovery, the discovering device sends out a series of ‘anyone-there?’ frames, perhaps the PC sends the next in series before the Palm has started/finished sending its response and thus the response is lost. However, if the problem is with the software taking too long to response one might expect the newer devices, e.g. Ken’s T3 to be less affected; however this is not the case.
Sadly(!) I don’t experience this problem so can’t investigate it further. Is there anyone experiencing this problem that also has a serial IrDA dongle and can thus provide a trace of the problem? Or is there a Windows driver programmer that can create me a NDIS filter driver to intercept IrDA frames and pass them to a user mode program?
The “Beam Receive” service on the Palm runs in the background, perhaps this causes a delay in the Palm responding. It would also be interesting to see if the problem occurs if a foreground application is listening on IrDA. Maybe I should knock-up a little IrDA server app for the Palm to see if having a foreground IrDA consumer has an affect…
In investigating the problems with discovery above I found, using a different notebook PC, that discovery became much slower—or even failed completely—when the two devices were close together.
[Knutson] describes a similar fault in the first Palm to support IrDA (the Palm III), where it “failed in some situations to perform gain control within the time permitted”, and “Most users in this situation would instinctively move the devices closer together […] the answer was to move the devices further apart”. This problem however occurs in recent Palm models. Testing was carried out using an IBM R30 notebook running Windows XP, along with a Palm V, a Nokia 6210, and an Extended Systems JetEye ESI-9580 Printer adaptor.
The chart below shows how long discovery takes when the two devices are at various distances apart with a number of independent timings made for each distance. It includes timings for Palm V and Nokia in range of the IBM R30 notebook running Windows XP SP2. As well as the measured times, a best fit line for each device is added.
Looking firstly at the behaviour when the mobile phone is brought in range of the notebook it can be seen that discovery is relatively prompt, generally being less that eight seconds, and that there is almost no relation between the distance and the time till discovery, the average only being slightly higher when closest than when furthest (five seconds vs. three seconds).
However when the same test is carried out with a Palm V a quite different result is found. It is clear that the time till discovery increases greatly when the two devices are closer together. At 20cm distance the discovery time averages one minute, and at 30cm is around thirty seconds. Only when the distance is increased to 40cm does the discovery time come down to the eight seconds value that was standard with the other test device.
Again it is not immediately apparent what fault causes this behaviour. Again any further reports, insights, or suggestions for further troubleshooting are welcomed.
As promised, I’ve documented two issues, and there isn’t much more to say here… Except of course to say that feedback is welcomed, whether further reports (perhaps with non-Palm[One] devices), insights, or further troubleshooting steps.
Copyright © 2005 Alan J. McFarlane
26th September 2005 Initial version.
30th September 2005 Change of title.
15th October 2005 References to related documents.
 tparnato’s report at http://forums.palm.com/pe/action/forums/displaypost?postID=20194197&returnExpertiseCode=
 The Palm IrDA API (application programming interface) requires that the programmer chooses the name the device is to appear as. The service that supports beaming, Exchange Manager, uses the device’s (HotSync) name, whereas the IrCOMM Virtual Serial Port as used by HotSync sets the name to “IrCOMM”.
 IrDA devices are generally priced unreasonably high. The cost of material for these devices is very low and in no way justify the tens of pounds/dollars/etc for which they are sold. Commonly they are even priced higher that Bluetooth devices which have higher material costs. So, look around before buying one, I got my mine for around £10 here http://www.ebuyer.com/customer/products/index.html?product_uid=47754.
 See "third type of hang" at http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/IrDA.html.
 After transmitting, a transceiver is, in a sense, blinded by its own transmission, it takes some time for it to become idle and ready to receive again.
Page 79, “The 10 XBOFs in NDM provide a remote device 10 byes of time (approximately 10.4 ms) within which to perform automatic gain control. If a device fails to adjust in time, it misses the beginning of the frame and hence fails to establish a connection.”
Footnote 7—“This situation existed in the original Palm III handheld. The controller on the original … failed in some situations to perform gain control within the time permitted by the 10 XBOFs, leading it to sometimes to fail to establish a connection.
Most users in this situation would instinctively move the devices closer together, which was exactly the opposite of what was required for a fix. In fact the answer was to move the devices further apart so that the signal appeared dimmer, and hence easier for the remote device to adjust its gain control. Fortunately, these problems were quickly fixed and were not an issue in subsequent Palm devices.”