I would like to introduce you briefly to my current effort to develop version 2.0 of IrCOMM2k and the
enhancements, which will come with it. I will also update this page whenever an important milestone was
reached and will announce the start of alpha- and beta-test phases. I am still contemplating a few ideas
regarding the new architecture of IrCOMM2k and what possibilities might come with it.
The combination of two new system drivers enabled me already to hook into the data stream between the
IR-adapter driver installed on my system and Microsoft's IrDA protocol driver. By doing that I have full
access to the raw IrDA data, sent and received by the adapter. If I constantly monitor the IrDA data
stream, it should be possible to forward incoming requests for the virtual COM-port to it within the
kernel. If necessary I could also initiate a connection, by generating the required raw data for the
IR-adapter and sending it off. The below improvements are possible because of that:
Full support of all IrCOMM functionality, all (virtual) status lines could be transmitted
between the devices
Special requirements of devices or applications could be accommodated, so that they may become
compatible with IrCOMM2k (e.g. Psion-Handhelds)
Improved latency through a direct connection between the IR-adapter and the virtual COM-port.
Depending on the type of data this could improve also the throughput.
IR debugger interface to monitor data will allow better problem analysis
Unfortunately there is still some effort required to provide the first fully functioning version. In
essence: I have to implement a limited version of the IrDA-protocol, and this protocol is relatively
Or use a simple, existing, very robust IrDA-stack, available at no cost - and port it to Windows. But where
could one get something like that? From the Linux Kernel of course! That's the approach I choose to pursue.
Initially, I am planning for a console-type prototype, which addresses a serial IR-adapter. Should that
work, I will migrate the code into the Windows driver - which probably means, that Linux will invade the
holy Windows system-kernel for the first time!
- The driver kernel is close to containing the functionality desired for this release.
- Microsoft's IrDA and IrCOMM2k can be used in parallel now! A forward-driver, which must be
installed as infrared adapter (one each for each physically existing adapter) routes the traffic, as
long as the virtual COM port is closed. Once it is opened, IrCOMM2k takes over as before.
- Eliminated error, which could have disturbed communication with certain IR devices (there were
reports of hanging PSION's).
- Additional memory leaks in Linux IrDA searched for and identified (nobody is perfect).
- This should have been the last alpha version. The next milestone is the realization of the setup
program. I might write a small tool to visualize the IR connections, which IrCOMM2k established. That
will be called Beta1 and introduces the phase, in which only remaining errors are repaired.
- A late Christmas gift: alpha version 3 and there are also
a few errors eliminated:
- Root cause of the crashes with "MULTIPLE_IRP_COMPLETE_REQUESTS" message repaired.
- Workaround for problems with Hummingbird Exceed found (the 1.x-Versionen already concerned!).
Programs writing without timeout and without flow control to the COM port were blocked, when no IR
connection was established.
- Linux kernel implemented (2.4.20) and partially examined for memory leaks (a patch for Linux is in
- IrDA advertises now to other devices with the system name and no longer with "Linux IrDA".
- In alpha version 4 I will focus on binding the Microsoft IrDA stack, so that its functions could be
used if necessary. To me, this sentence sounds somehow familiar?
- With the alpha version 2 released today (see download area)
a few more Psion/Communicator users should be able to sync via IR! Early testing leads me to believe
that. Changes in this version:
- Status lines are supported bidirectional. Up to the established IR connection, the input lines are
considered "set" (Resolves PSION problem).
- Completion of the IOCTL functions of the virtual COM port.
- Errors with Windows XP resolved, they to an immediate crash with some IR adapters.
- Eliminated error, which led to aborts during transmission of large data sets.
- In alpha version 3 I will focus on binding the Microsoft IrDA stack, so that its functions could be
used if necessary.
- Here it is now, the long promised alpha version! In the
download area you will the executables and -of course- the
source codes. Please read the readme.txt for installation instructions!
- What works already (for me): Hotsync with a PalmOS-4.0-device (it is faster than the infrared
support of Hotsync!), full accesses to a S35i with S25@once, ViSie, PEP2000 and Sx35CZ, in particular
the logo upload works problem-free, which it did not, in the past.
- What does not work yet (according to a alpha-tester): Synchronization with Psions. I am however
optimistic to solve this sooner or later by utilizing the embedded diagnostic means, even "from the
- Still missing: some IOCTL control instructions of the virtual COM port (e.g. to set status lines on
the target device), (partial) parallel use of the Microsoft IrDA stack to use other IrDA services than
IrCOMM, the setup program, a GUI to configure and diagnose and much more.
In regards to feedback: please send error reports via eMail to me. I need a description how to
reproduce the error behind or the output of irda2kdump.exe and Portmon. But anything that already works
(now) and did not in the past: please post in the forum!
- A little anecdote: while working intensively with the Linux IrDA stack from Kernel 2.4.19, a memory
leak was uncovered (nobody is perfect...). The Linux developers knew about the problem but not the
accurate lines in the code. One of the causes of this problem, which was critical for IrCOMM2k, was
uncovered and eliminated. A Patch will also be part of the Linux-2.5 kernel. That is Open Source!
- It is almost done: The IrDA stack is implemented as protocol driver and the virtual COM port was
bound to it. Today for the first time I transmitted data from a terminal program via infrared to my
mobile phone, the other direction (back to the terminal program), however, is not yet completed (but
the answer from the mobile already appeared on the debug console!).
- The protocol-driver directly uses all IR adapters supported by Windows. It either handles the data
or passes it on to the Windows IrDA driver. Additionally it can address several adapters (tested with a
serial ACTiSYS IR220L+ and a Tekram IRmate 410U, USB).
- All works well and very stably, I am confident to release a first alpha version soon.
- The following is still in the works: receiving data by the COM port, setting and reading status
lines, flow control of the virtual port. I estimate 2 more weeks.
- PS: The PSION test with irdalnx was not successful. Thanks to all, who tried it.
- The Linux-IrDA-stack works! IrCOMM is integrated and the application was enhanced to address the
- Early testing with a mobile phone and a Palm Pilot look very promising, but the lack of addressable
status lines is noticeable. However, this will be available with the final version of this release (a
few essential changes within the driver are necessary to achieve this)
- Alpha-tester's needed: If you would like to test the current release, feel free
to download the program and make sure you read the
contents of the readme.txt. The source code is
certainly available too. If you happen to be the owner of a Psion handheld and you
have the ACTiSYS-dongle - please test this driver!
- Partial porting of the Linux-IrDA-stack into a Win32-console-type application was successful! A
serial dongle (ACTiSYS IR220L+) can be addressed; IrLAP, IrLMP and IAS work fine.
- Only a few changes to the Linux source were required, most will be caught by header-files, which
substitute the Linux-Includes.
- Here is a snapshot of communications
between the application and my S35i mobile phone. The device attempts to send a phone book entry (the
required service is missing at the recipients end, therefore the IAS request failed).
- Next Steps: TTP and IrCOMM porting, then establish a connection between IrCOMM and the virtual
COM-port. That way support for PsiWin (PSION synchronization-software) could be achieved, limited to
the ACTiSYS-dongle, though.
- Succeeded with proof of concept. Data traffic between the IR-adapter and the IrDA-protocol can be
routed through own drivers, without limiting the functionality of the IR-interface.
- A simple IrDA-sniffer was implemented which produces raw data in a console window (data can be
stored in a file).
- Hardcoded names for my IR-adapter unfortunately prevent installing this prototype on other systems.
That is one of my next goals.
- A few samples of the sniffer-output ("<==": sent, "==>": received):
PEP2000 sending cellphone-logo (fail),
also s25@once via IrCOMM2k (fail)
and finally s25@once via IR-file transfer
By accessing the IrDA-traffic directly it is now possible to implement analytical and monitoring
functionality while running on Windows 2000/XP, in a similar fashion as we know it from the IR-Monitor in
Windows 98 (that one was written by HP and not by Microsoft, by the way...). Devices and their services
could be depicted or visually display the transmission rate and quality.
Some discussions in the forum were related to the possibility of offering a number of virtual COM-ports,
which could be associated with specific IR-devices (for instance, by using a name). That way a number of
synchronization programs for different PDA's could run simultaneously, without interfering with each other
(as an example...). A user front end is needed therefore to allow these associations, which would be
handled within the IrCOMM2k-kernel-driver.
There are no limits to imagination, as far as possible functionality is concerned, but I am the only one
working on this driver and haven't found a way to clone myself. I am quite busy with the work on these
drivers. Should one of you have the desire to write such a user front-end application with the
functionality described - go for it! Some basic knowledge about IrDA would be helpful, but having some
enthusiasm is more relevant. I am sure we could agree on the interface between the kernel-driver and the