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 Plan

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 complex.

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!

Current Progress

01.04.2003: 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.

12.27.2002: 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 preparation). 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?

15.12.2002: 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.

01.12.2002: 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 distance". 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!

04.11.2002: 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.

09.22.2002: The Linux-IrDA-stack works! IrCOMM is integrated and the application was enhanced to address the virtual COM-port. 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!

09.08.2002: 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.

07.23.2002: 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 (success).

New Functionality

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 monitor.