How not to be a mouse?

A device is streaming binary data to PC by COM port. Sometimes Windows mistakenly recognize such device as a mouse. So mouse pointer starts crazy jumping over the screen, pressing buttons and like. This can happen with real COM port as well as with USB to serial converter. I encounter this problem once in a while. The standard solution is disable serial mouse in the registry; however I would prefer to modify binary protocol to avoid detection. How does Windows recognize a serial mouse? In the other words, what sequences should be avoided in the binary protocol ?

Vladimir Vassilevsky DSP and Mixed Signal Consultant

formatting link

Reply to
Vladimir Vassilevsky
Loading thread data ...

I was much "amused" when I first saw this effect.

As far as I know, Windows treats /any/ incoming serial port data as a mouse during startup. So the solution is not to send any data before Windows has started.

It may be that you can avoid the problem with different baud rates - serial mice use quite low baud rates, and higher rates are unlikely to be accepted as good characters by the UART at 9600 (but as I'm sure you know, "unlikely" here does not mean it will never happen).

Reply to
David Brown

I've also experience this when a USB-serial adapter is plugged into Windows while there is active serial data. It appears a serial stream that is present while the USB device is being enumerated is the cause. First the USB-serial device/cable by itself until it enumerates as a plain old serial port and then attach the serial source.

An occasional (but never permanent) fix is to disable, not uninstall, the Microsoft Serial BallPoint entry in Device Manager. Might need to do the hack (thanks again, MS) to show un-installed devices.

I've never found an absolutely reliable way of avoiding this other than to block serial data from Windows during boot time. For some embedded XPe devices, this has meant gates (and even relays!) that block the serial data streams until Windows says "Okay, I'm awake." Real PITA.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

We're rarely using anything other than 115200 bps, and still see the effect, so that will probably not help.

However, installing and disabling the serial mouse driver has worked well so far.

Stefan

Reply to
Stefan Reuther

There is a document from Microsoft called "Plug and Play External COM device specification" which exactly describes how Windows detects a mouse.

During Plug & Play enumeration, Windows toggles the DTR and RTS lines in a certain pattern to which a device whould respond by sending a packet of PnP information. If this information is not received or it appears to be "garbage", windows assumes it is a mouse.

The only reliable way of preventing false detection is to not send any data out of your serial port as long as you see this pattern on the DTR and RTS lines. This of course assumes you have at least one of those signals available on your serial port.

A good and proven way is how we do it with our USB products using an FT232 chip: we simply remove the PnP enumerator lines from the .INF files and change one flag (I can look that up for you). This prevents windows from executing the PnP enumerator for this particular virtual COM port.

Meindert

Reply to
Meindert Sprang

I had used serial devices communicating with COM port for years and never had seen this...

crazy

with

I

device

a

PnP

data

RTS

FT232

--------------------------------------- Posted through

formatting link

Reply to
fabatera

You're lucky.

My employer makes serial "boards" (attached via ISA, PCI, USB, Ethernet), and this has been a constant problem for our Windows customers for _decades_.

--
Grant Edwards               grant.b.edwards        Yow! Maybe I should have
                                  at               asked for my Neutron Bomb
 Click to see the full signature
Reply to
Grant Edwards

As long as your PC COM port is a master (e.g. Modbus RTU master), there is of course no problems, because the serial port does not initiate any communication, until the computer is up and running.

The problem starts, when your Windows COM port is a supposed to be a slave port (e.g. Modbus RTU slave), thus the other end is master and is continuously polling for responses from your end. If such poll happens during your Windows PC startup, you are in trouble.

Reply to
upsidedown

[...]

And sometimes, it's neither. Usage of RS232 doesn't imply a master/slave setup in any way.

Reply to
Hans-Bernhard Bröker

I certainly agree that RS-232/RS-422 connections are capable of full duplex communication. For industrial protocols, I can think of only two protocols (one IEC and one Siemens), with more or less symmetrical "connection setup", while the actual data flow is full duplex and symmetrical.

In general, there are some asymmetry in the data transfer directions, while the under laying hardware would be capable of full duplex point to point communication.

Reply to
upsidedown

Le 30/08/2012 20:58, snipped-for-privacy@downunder.com a écrit :

RS232 can certainly be full duplex. I, quite some time ago, made a Supervision device that talked to the front end in a protocol derived from X25, in fact data link, asynchronous. It was capable of both master/master or master/slave depending on the configuration. In the master/master case, each end could set up the link, the other acknowledged. There was a nasty bug in the protocol for that setup that could be avoided by using timers.

Reply to
Lanarcam

Devices that send data to the PC continuously without computer intervention cause this problem. Everyone who ever connected a GPS to a serial port has probably seen this problem... At least all of my customers have (sailors who use computer based navigation).

Meindert

Reply to
Meindert Sprang

Thanks for the info.

I have this problem with a very dumb data logging module. So dumb all it can do is spit out its logged data continuously.

It is connected and powered by an FTDI USB/RS232 bridge to recover data and Windows thinks it is a mouse when you plug in the bridge unless you connect the logger to the bridge after it is plugged in.

I could change the logger to not send data till a few seconds after power up. Any idea how long that would need to be so the PnP stuff has finished before sending data?

Reply to
nospam

See "pnp external com device specification v1.0" document.

Leo Havmøller.

Reply to
Leo Havmøller

and

connect

Just remove any references fo ftserenum.sys in the ftdiport.inf file of the driver. Then reinstall or update the driver.

Meindert

Reply to
Meindert Sprang

I've run across similar problems with the FTDI chips. I have found a 5- second delay to be adequate. It usually takes me longer than this to open a host program and tell it to search for the FTDI interface.

If your logger can be reprogrammed, you could also tell it to wait for a 'start' command.

Mark Borgerson

Reply to
Mark Borgerson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.