(NOTE WELL: I have been using an unbranded, old, retired USB mouse - so it may be a fault in that mouse ("Mouse1")- I hope to test a replacement in near future).
I just installed the (https://github.com/getis/Arduino-PS2-Mouse-Handler) software yesterday and it worked first time sending signals from a mouse to my new ELEGOO Arduino Uno R3 and from there, via the PC-to_Arduino USB power/data lead, to a windows 7 PC running the Arduino serial monitor software.
I am focussed on getting scrollwheel data and my mouse is held rigidly in a stationary position where no other command signals are expected to be generated by the mouse.
It all seems good (and I am very happy with it!)
...EXCEPT...
after I stop scrolling the scrollwheel, the last non-zero integer value for the scrollwheel persists in the serial stream, whereas it should return to zero. It actually does return to zero if I press or release any of the mouse buttons or move the mouse across a mousemat or similar - but this does not solve my requirement.
I plan to test it with another mouse and report back. But if in the meantime anybody is interested in taking a look at reproducing or resolving this problem I would be glad to hear about it. Thanks!
Update 1: Have tested Mouse2 and Mouse3, both old USB mice, both give rise to "mouse error" message in Serial Monitor.
So not any wiser yet.
Update 2: Still using (suspect) Mouse1 and have noticed that X and Y serial-reported integer values are also "sticky" just like the scrollwheel values reported previously above. Similar behavior NOT seen with buttons (so far).
Update 3: So now I have tried 7 different mice in various stages of decrepitude. This rough table summarizes the results:-
Basically I couldnt find a single mouse whose scrollwheel (Z) data were correctly passed through the Arduino. But I emphasize the mice were mainly old and most of them had been retired for undocumented defects. It was an interesting exercise - for example the inconsistency between mice in which signal is carried on the green wire. For the time being I am going to look at using the X or Y signals instead of the Z (scrollwheel) signals for my system. The old ball mice have nice rotating axle optical decoders which are higher resolution than the usb-mice scrollwheel decoders which I was previously thinking to use.
(NOTE WELL: I have been using an unbranded, old, retired USB mouse - so it may be a fault in that mouse ("Mouse1")- I hope to test a replacement in near future).
I just installed the (https://github.com/getis/Arduino-PS2-Mouse-Handler) software yesterday and it worked first time sending signals from a mouse to my new ELEGOO Arduino Uno R3 and from there, via the PC-to_Arduino USB power/data lead, to a windows 7 PC running the Arduino serial monitor software.
I am focussed on getting scrollwheel data and my mouse is held rigidly in a stationary position where no other command signals are expected to be generated by the mouse.
It all seems good (and I am very happy with it!)
...EXCEPT...
after I stop scrolling the scrollwheel, the last non-zero integer value for the scrollwheel persists in the serial stream, whereas it should return to zero. It actually does return to zero if I press or release any of the mouse buttons or move the mouse across a mousemat or similar - but this does not solve my requirement.
I plan to test it with another mouse and report back. But if in the meantime anybody is interested in taking a look at reproducing or resolving this problem I would be glad to hear about it. Thanks!
Update 1: Have tested Mouse2 and Mouse3, both old USB mice, both give rise to "mouse error" message in Serial Monitor.
So not any wiser yet.
Update 2: Still using (suspect) Mouse1 and have noticed that X and Y serial-reported integer values are also "sticky" just like the scrollwheel values reported previously above. Similar behavior NOT seen with buttons (so far).
Update 3: So now I have tried 7 different mice in various stages of decrepitude. This rough table summarizes the results:-
Basically I couldnt find a single mouse whose scrollwheel (Z) data were correctly passed through the Arduino. But I emphasize the mice were mainly old and most of them had been retired for undocumented defects. It was an interesting exercise - for example the inconsistency between mice in which signal is carried on the green wire. For the time being I am going to look at using the X or Y signals instead of the Z (scrollwheel) signals for my system. The old ball mice have nice rotating axle optical decoders which are higher resolution than the usb-mice scrollwheel decoders which I was previously thinking to use.