GPS detected as serial mouse

Question

I'm not sure if this question is in the right stackexchange site because it's a mix of programming and hardware. Admin, feel free to move it to another stackexchange site.

Here is the problem:

I've programmed a small application (C++ MFC) that read the output of a GPS (Garmin that output NMEA) via a serial port (COM 1). Everything is working great so far but for field testing, we needed to use it on a laptop that didn't have a COM port.

So we purchased a SABRENT USB to serial cable for the testing phase. I installed the driver of the cable and everything was ok. But each time we unplug/replug the cable OR each time the computer is restarted, the GPS is detected as a serial mouse. When the GPS is detected as a serial mouse, the mouse start to move everywhere, clicking and double-clicking randomly causing a major problem.

This never happened using the physical COM port on my computer.

Here are the solution that I've read and tried that doesn't work:

1. Only plug the USB cable after the boot of the computer is complete: It seems to work only if the user doesn't unplug and replug the USB cable. Since pluging and unpluging the GPS while troubleshooting is very common thing, this solution can not be used. Also, pluging after rebooting can not be a stable solution since this GPS will be permanently installed to a computer in a truck used by technician that know little about computers, I don't want them to mess with waiting the reboot of the computer before connecting GPS.
2. Adding the key SkipEnumerations to the registry for the COM port causing the error: This can't be done because each time the USB is plugged, a virtual COM port is created and the number is pretty random (COM6, COM7, etc). Also, virtual COM port are not in the registry.
3. Disable the detected serial mouse: This is impossible to do because when the mouse is detected, I can't control my normal mouse anymore and it's a total mayhem. As soon as I unplug the usb cable, the mouse dissapear from the device manager so it's too late.

Answer 1

Since people are going to find this using Google WWWW, here's a slightly generalized answer.

Serial ports can be connected to many different things. They don't just talk to modems. They could also talk to mice, for example, or graphics tablets. There's a whole specification, the Plug and Play External COM Device Specification, dealing with how Plug&Play enumeration works over serial ports. Unfortunately, your GPS receiver isn't a proper Plug&Play serial device and the continuous data stream that it sends to the host confuses the serial port Plug&Play enumeration protocol.

Your USB adapter cable itself could be doing the Plug&Play autodetection.

USB devices have types, so called device classes, that they report to the host. An adapted device might be, in the USB world view, a serial port device type (a Communications Device Class device class) or a mouse device type (a Human Interface Device device class). Several USB↔RS-232 adapter cables are known to decide what USB device class they report themselves as to the host based upon what they detect connected to their RS-232 interface. They will attempt to communicate with the device, auto-detect what kind of serial device it is, and change their own device class accordingly. If a GPS receiver looks like a mouse to them, they'll report themselves as a USB HID device.

In which case, your correct first course of action is to replace the adapter cable with one that doesn't do this autodetection. You can see whether this is what is happening by looking at the USB device in the Windows Device Manager, and seeing whether it is a USB HID or a USB CDC device.

From what I can see from the vendor's manual, the Sabrent USB↔RS-232 adapters aren't this intelligent; although it is unclear what the difference between the "K" and "M" flavours is, and this might be a factor. In which case, however, you are not out of the woods, because there's a second round of autodetection:

Windows could be doing the Plug&Play autodetection.

Windows, when it discovers that it has a serial port, attempts to find out what's connected to the port; handshaking with the device and determining its type. It then invokes the appropriate device driver.

There are two ironies here. First: This means that a "smart" USB↔RS-232 adapter, that has already itself done the handshaking and determined that it is a CDC device and not a HID device, can go through a second round of handshaking, as Windows itself attempts to determine what this serial port is connected to. Second: Even in machines that don't have their RS-232 motherboard logic in their Super I/O chip wired up to an I/O connector, the Windows serial port device driver is gamely trying to check what's physically connected to the port.

There are several ways to address this:

• Disable the sermouse driver entirely. This is a simple matter of changing its start class, wither by tweaking the registry directly or using the Windows service manager, from Automatic to Manual. The sermouse driver is invoked when the serenum bus driver detects a mouse connected to a serial port. If the sermouse driver is set to Manual, it won't start up automatically, and it won't create a "mouse" device object for the new "mouse" that has been (erroneously) autodetected. The autodetection, done by serenum will still occur; and Device Manager may report that the inability to drive the device since the driver does not start. Also, the port will of course not be fully recognized and listed as a communications device. The system, after all, thinks that it's a mouse.

• Do what Microsoft has been saying to do since the days of Windows NT 5. Microsoft KnowledgeBase article 283063 describes exactly this situation, and points out that Microsoft updated its serenum driver ten years ago, all of the way back in 2001, to include a bypass facility. One needs to locate, in the registry, the device parameters information for that particular instance of the serial device, and add a SkipEnumerations value to it, to stop serenum from trying to enumerate it. Full details, including where to look in the registry for serial devices on systems with different HALs, are in the KnowledgeBase article.

  Yes, these things are in the registry, and are not "virtual". if you are looking for "virtual COM ports" you are looking for the wrong things. Read the article and follow the instructions.

• Use the tool that Microsoft has been providing to fix this since the days of Windows NT 5.2. This tool is the slightly misleadingly named COMDisable, and instructions for obtaining and using it are in Microsoft KnowledgeBase article 819036. It essentially does the same registry modification as above, to change the behaviour of the serenum device driver, without one having to laboriously locate where the device parameters are in the registry.

Answer 2

Found this site that might be useful. Read the 2nd post from Antipodean:

The CDC class as programmed by Microchip will handle 255 bytes - but you have to be careful. If you start sending characters before the device has finished enumerating the host (especially if a Windows host) will enumerate the port as a mouse. If this happens the cursor will continously jump all over the screen as the host treats the GPS data as mouse data. To stop this you need to wait for the charaters the host sends to attempt to recognise a mouse, and wait several seconds before allowing any data to be transmitted.