When designing electronics, probably the easiest way to make it communicate with a computer is to connect it as a serial port. However, occasionally you might see your device detected as a serial mouse instead of a plain serial port. When this happens the device will obviously not work and you might even see your mouse cursor jump around.
This behavior is an artefact of how Windows detect a serial mouse since that was written way before plug'n'play times. Widnows will first raise DTR and RTS signals and then monitor if there's an M or B character coming at 1,200 baud. If either character appears, congratulations - your device is now a mouse. And anything it sends will be processed as if it was a mouse action.
There's a brute force solution of disabling serial mouse in registry and that would honestly be the easiest way around. However, what if you cannot modify the registry? What if you need to make your device work in the face of an unknown machine? Well, there are certain tactics you can employ to either make this behavior unlikely or avoid it altogether.
The simplest solution of not sending M or B will unfortunately not work as easily. Yes, if your device works at the 1,200 baud rate, avoiding those characters will be fine. But if your device works at faster baud rate (and it probably does) the other end receiving at 1,200 will misunderstand its output. Depending when the actual bit sample is taken and what your device is actually sending, you might see an offending character appear either every time or every 10 times. Even worse, the frequency of the issue might change depending on the computer or even the room temperature. So, not really a solution.
The second obvious choice is detecting DTR and RTS combination and pausing whatever output your device gives until that state passes. If you can afford this, it's a great and surefire way to sort the issue out as DTR and RTS are not baud rate sensitive. The only problem happens when you need those signals for flow control or for something completely custom. Even if you're not using them they'll still "cost" you two pins.
The most practical way I found of stopping this issue is by having device not speak until spoken to. If you design your serial protocol so that a device must receive a valid command before it will send any data, it will pass serial mouse detection unharmed. And, if you really need a streaming output (a perfectly valid requirement), just use a command to turn it on. If you can additionally somehow get CRC check into your protocol, the world is your oyster.