search

FreeSpacenav / spacenavd

Free user-space driver for 6-dof space-mice.
http://spacenav.sourceforge.net
GNU General Public License v3.0
279 stars 55 forks source link

serial magellan spacemouse errors #35

Closed donnels closed 3 years ago

donnels commented 3 years ago

I've compiled (git cloned) the spacenavd for manjaro AARCH64 and get the following errors when running it with a magellan Spacemouse by 3dconnexion via a PL2303 USB to serial.

$ sudo spacenavd -d

Magellan SpaceMouse detected: vMPT1LP /.../ some binary/non printing ascii Can't guess number of buttons, default to 8, report this as a bug! 8 buttons magellan: invalid data packet, expected 24 bytes, got: /.../ different numbers between 18 and 239 etc. (on movement)

It might also be the mouse but I'm not clear on how to best diagnose it and as spacenavd asks me to post a bug I took the queue. Is there a good way to exclude the mouse itself as the source of the error?

I'll try to get a different serial adapter later today (although this one works for other serial devices). I'll also try to debug with a serial terminal but that is more or less optional for now as I'm not sure what the correct values should be. I do get the beep beep when I start spacenavd so at least that's something. And I get the errors when manipulating the mouse so that means that the mouse is at least doing something. (edit: vQ via minicom at 9600 8n1 reports: MAGELLAN Version 6.70 3Dconnexion GmbH 05/11/02) (edit: switching to a CH341 adapter seems to have removed the errors but the question for me is still why minicom seems the be able to do a vQ at 9600 and the spacenavd can't.... For me the functionality is given so I'm just left wondering why the serial port works via minicom but not spacenavd.) Does anyone have an idea?

jtsiomb commented 3 years ago

Magellan spacemice are using 2 stop bits, not 1, so the correct setting is 9600 8n2. I wonder how it's possible to get a correct response with minicom set up to use 8n1...

I do have a magellan spacemouse, so I'll do some testing with a pl2303 USB serial port and get back at you.

jtsiomb commented 3 years ago

I tested, and my pl2303 UARTs behave exactly like yours. Transmissions are garbled with 2 stop bits, but work fine with 1 stop bit.

Using more stop bits shouldn't cause this kind of garbled transmission problem, it should only result in slowing down the communication slightly. The garbled transmission is either a bug in the pl2303 chip, or the Linux driver for it (this might be an interesting thing to look into at some point).

In any case, I just commited a fix for this, changing the magellan device code to use 1 stop bit, which seems to transmit reliably on all serial ports I tried regardless of the official documentation specifying 2 stop bits. Closing this bug report, but feel free to re-open if you're still having issues.

donnels commented 3 years ago

Many thanks