If you ever tried to access COM port 10 or above with SerialProxy on Windows you already know it just does not work. Period. Let me tell you why it does not work and how we can fix that.

Update : this problem has been resolved as of May 4th 2009. Please check the article titled SerialProxy can now use COM ports above 9 for more details.

If you are interfacing Flash with Arduino, you surely know of the existence of serproxy.exe (aka SerialProxy). This very handy piece of software translates serial data to and from TCP/IP data which is then accessible from Flash (by opening a network socket). SerialProxy works very reliably except… if you try to use a COM port above 9.

It turns out Microsoft engineers never anticipated anybody could be using a COM port above 9 (what an outlandish idea). When they realized that some people may actually need ports above 9, they came up with a very original syntax to access them :

\\.\COM10
\\.\COM11
\\.\COM12

More information about this syntax can be found in the KB115831 knowledge base article from Microsoft.

Obviously, the programmer of SerialProxy did not anticipate that weird syntax (can we blame him ?) so any ports above 9 are simply unreachable by SerialProxy.

The obvious solution would be to patch serproxy.exe to integrate the funny syntax for ports above 9. This Arduino Forum post describes how to proceed. Unfortunately the patched version has not been made available. If anybody managed to get a hold of it please let me know so I can make the new binaries available to those who need it (including myself).

An alternative is to reinstall the FTDI Virtual COM Port drivers that are bundled with the Arduino IDE. This resets port numbering to the first available COM port. This is not a very pretty or practical solution.

Why does the FTDI VCP driver keep assigning new COM ports? The reason is that it uses the device’s serial number to uniquely identify it. For each new device (e.g. Arduino) that’s plugged in, a new virtual port is created. This happens a lot in a classrom environment with many Arduinos being used, hence my stumbling upon this problem.

A good solution to the problem, which is provided by FTDI, is to configure the driver to ignore serial numbers and instead use the “location id” (read: USB port) to create the virtual COM ports. In this scenario, there is only one virtual COM port per physical USB port.

You can read all about it in a document entitled “How To Configure VCP to Use a Specific COM Port” on FTDI’s websuite. I tried it and it does work. It makes you wonder why this isn’t the default behaviour…

Roughly, what this procedure describes is the creation of a LocIds key at this location (after the driver has been installed):

The content of the key is a list of USB ports on your machine where you want to be able to use your Arduino:

The numbers above must match the location IDs identified by using usbview as described in FTDI’s procedure.

Hope this helps.