Jump to content


View Other Content


Categories See All →


Search Articles


- - - - -

Mouse sensor accuracy test


This is a quick test to demonstrate using an AxiDraw V3 to analyse mouse sensors.



Full article here:
http://www.mouse-sen...-accuracy-test/
  • Erick Avila and BMR_ like this


21 Comments

I would like to know to real dpi of the dark grey microsoft intellieye 3.0  :-p

Are you going to be testing more mice?

 

Edit: Just clicked the link to the forum post xd

A lot more mice, and a lot more different tests. This was a simple comparison to see if the system works. And it does!

 

It seems like G900 is a damn good benchmark for all others, so I will first put that one through a lot of different tests so we have a baseline for what's good.

A Razer Mamba 16000 Chroma and a ZOWIE EC2-A are on the way for a showdown with the G900 Chaos Spectrum!

    • WildStyle* likes this

Would this machine be able to test the viewspeed implementation? In CS:GO you can bind scripts, so you can press keys to change to different FOV presets, configured with the viewspeed sensitivity. By hand, you can move the mouse in circles and it 'feels' the same, the only difference is the image behind the crosshair is zooming in and out. If this machine can draw perfect circles consistently, there may be a way to demonstrate the viewspeed mode or test it. I'm not sure how though since the crosshair would always be in the center of the screen. Then there is also the sensor accuracy, but the G900 looks pretty damn good and up to the task.

It should be possible to add the outline of the circle in post production maybe (if it's not too much job).

 

Or even better, maybe find a perfect circle in-game and track around that?

 

I can do this circle thing with scripting mouse movement as well, which eliminates all other factors.

Tracking a circle in-game shouldn't work because the circle would be changing size with the FOV and the mouse movement should be unaffected.

 

Maybe the start point can be documented, then move the mouse in a pattern while changing FOVs, then at the end of the test, if the start point is the exact same as the end point, it would mean the viewspeed match worked. If the sensitivity sped up or slowed down at any point, then the pattern would have become distorted and shifted you away from the original position, meaning the viewspeed match isn't scaling correctly.

 

Example with me just moving my mouse in a circle while spamming 90 FOV and 40 FOV: 

 

Obviously with a script doing that instead, as my mouse movement is all over the place. It could possibly be a good testing method.

Damn, do you have to buy all these mice?

Also, why is it that the general trend for gaming mice is to have whatever causes that upward shift in that figure eight, while the desktop mouse goes way down? Is it mouse accel or something?

you should post this on ocn :P

 

this is definitely the most interesting thing developed in the mouse community in the last few months

 

some questions:

1. how fast can the thing move?

2. how sure are you that the motion is actually perfectly parallel to the mousepad? if there is a slight angle, because the mouse's actual sensitivity depends on the tracking height, there will be drift even for a perfectly accurate sensor. (in other words: a sensor that is perfect in every way except for having height-dependent dpi will drift if there is any angle between the plane of motion and the mousepad)

 

one way to quantify this would be to compare dpi measurements (in the vertical direction) when the horizontal position is at the left, middle, and right. and vice versa for horizontal/vertical.

ocn is http://www.overclock.net btw. It would get a lot of exposure on there.

That's a great way of testing the sensors! Really easy to see the sensor drift!

Damn, do you have to buy all these mice?

Also, why is it that the general trend for gaming mice is to have whatever causes that upward shift in that figure eight, while the desktop mouse goes way down? Is it mouse accel or something?

These I just had lying around actually :)

 

I have not analysed what causes the drift yet, other than it seems to be the sensor going to far in one direction compared to how far it's physically moved. Some tuning might be possible.

 

 

some questions:

1. how fast can the thing move?

2. how sure are you that the motion is actually perfectly parallel to the mousepad? if there is a slight angle, because the mouse's actual sensitivity depends on the tracking height, there will be drift even for a perfectly accurate sensor. (in other words: a sensor that is perfect in every way except for having height-dependent dpi will drift if there is any angle between the plane of motion and the mousepad)

 

one way to quantify this would be to compare dpi measurements (in the vertical direction) when the horizontal position is at the left, middle, and right. and vice versa for horizontal/vertical.

1. 11 inches pr. second. Not very fast, but decent (accuracy may suffer though).

2. Everything should be pretty flat, but I'll take that into consideration on the next tests, to make sure the mouse isn't ever so slightly tilting because the grabber lifts it.

A Razer Mamba 16000 Chroma and a ZOWIE EC2-A are on the way for a showdown with the G900 Chaos Spectrum!

Can't wait for the Zowie test, After trying to play with G900 for a month, going back to Zowie is like god sent gift.

Photo
Joshua Willis
Mar 21 2017 01:13 PM

Test ALL THE MICE!!!!

 

 

 

 

I plan on doing in-depth tests for popular models, including full range DPI test, in-game tests, acceleration analysis and perhaps latency tests.

 

Let me know what you would like to see tested, both in terms of mouse models and testing methods!

 

 

ALL of the above :D.

 

But seriously the full range DPI test would be good to see, I've first hand experience with the DPI being incorrect and now check every mouse I buy. Knowing the sweet spot of the DPI range would be GREAT.

Latency and acceleration would be handy to see but not a necessity as I'd expect all modern releases to be acceptable with differences much more acute than we could ever notice!

The sensor drift is the real show stopper here. Some games (OSU) it can be REALLY noticeable, the above demonstration really shows the difference in hardware.

 

As for which mice to test, it would be great to see all the most popular models put through the bench.

 

Logitech
​Zowie
Steelseries
​Razer
FinalMouse (I'd wait for the new version as the current one is still full of flaws)

 

Lots more potentials but I think that covers the majority of trending mice.
 

Tracking a circle in-game shouldn't work because the circle would be changing size with the FOV and the mouse movement should be unaffected.
 
Maybe the start point can be documented, then move the mouse in a pattern while changing FOVs, then at the end of the test, if the start point is the exact same as the end point, it would mean the viewspeed match worked. If the sensitivity sped up or slowed down at any point, then the pattern would have become distorted and shifted you away from the original position, meaning the viewspeed match isn't scaling correctly.
 
Example with me just moving my mouse in a circle while spamming 90 FOV and 40 FOV: 
 
Obviously with a script doing that instead, as my mouse movement is all over the place. It could possibly be a good testing method.


I created an AHK script that will move your mouse in a not perfect, but 100% repeatable circle. It could probably be optimized/cleaned up some but I already spent too long on it so:

#NoEnv
SendMode Input
SetWorkingDir %A_ScriptDir%

radius := 64*2

MoveMouse(x,y) {
	DllCall("mouse_event", uint, 1, int, x, int, y)
}

moveDistance(x,r) {
	output := Sqrt(r**2 - x**2) - Sqrt(r**2 - (x-1)**2)
	return output
}

NumpadEnter::
	loop %radius% {
		MoveMouse(-1,0)
		Sleep 1
	}
	i := 1-radius
	t := 0
	e := 0
	while i <= radius {
		t := moveDistance(i,radius)+e
		e := 0
		MoveMouse(1,-1*Round(t))
		e := t - Round(t)
		i++
		Sleep 1
	}
	i := 1-radius
	t := 0
	e := 0
	while i <= radius {
		t := moveDistance(i,radius)+e
		e := 0
		MoveMouse(-1, Round(t))
		e := t - Round(t)
		i++
		Sleep 1
	}
	loop %radius% {
		MoveMouse(1,0)
		Sleep 1
	}
	KeyWait NumpadEnter
Return

NumpadSub:: ExitApp

This will move away from the center of the circle, then complete 1 rotation, and move back to the center. The cursor doesn't move at a constant rate because that'd be way more complicated than I care about.

 

I should point out however: The only way the actual the circle wouldn't change is if you matched the cm/360° of the two FOVs. The useful thing that you could do would be comparing the on screen size of the circles between FOVs.

Tracking a circle in-game shouldn't work because the circle would be changing size with the FOV and the mouse movement should be unaffected.

 

Maybe the start point can be documented, then move the mouse in a pattern while changing FOVs, then at the end of the test, if the start point is the exact same as the end point, it would mean the viewspeed match worked. If the sensitivity sped up or slowed down at any point, then the pattern would have become distorted and shifted you away from the original position, meaning the viewspeed match isn't scaling correctly.

 

Example with me just moving my mouse in a circle while spamming 90 FOV and 40 FOV: 

 

Obviously with a script doing that instead, as my mouse movement is all over the place. It could possibly be a good testing method.

 

 

I created an AHK script that will move your mouse in a not perfect, but 100% repeatable circle. It could probably be optimized/cleaned up some but I already spent too long on it so:

#NoEnv
SendMode Input
SetWorkingDir %A_ScriptDir%

radius := 64*2

MoveMouse(x,y) {
	DllCall("mouse_event", uint, 1, int, x, int, y)
}

moveDistance(x,r) {
	output := Sqrt(r**2 - x**2) - Sqrt(r**2 - (x-1)**2)
	return output
}

NumpadEnter::
	loop %radius% {
		MoveMouse(-1,0)
		Sleep 1
	}
	i := 1-radius
	t := 0
	e := 0
	while i <= radius {
		t := moveDistance(i,radius)+e
		e := 0
		MoveMouse(1,-1*Round(t))
		e := t - Round(t)
		i++
		Sleep 1
	}
	i := 1-radius
	t := 0
	e := 0
	while i <= radius {
		t := moveDistance(i,radius)+e
		e := 0
		MoveMouse(-1, Round(t))
		e := t - Round(t)
		i++
		Sleep 1
	}
	loop %radius% {
		MoveMouse(1,0)
		Sleep 1
	}
	KeyWait NumpadEnter
Return

NumpadSub:: ExitApp

This will move away from the center of the circle, then complete 1 rotation, and move back to the center. The cursor doesn't move at a constant rate because that'd be way more complicated than I care about.

 

I should point out however: The only way the actual the circle wouldn't change is if you matched the cm/360° of the two FOVs. The useful thing that you could do would be comparing the on screen size of the circles between FOVs.

 

 

I think any movement must be executed from an external device, DPI wiz machine would be perfect.

In fact I think if he was to have the machine complete circles repetitively and you wrote a simple FOV script that could cycle between multiple FOV at a rate of ~0.5 Seconds? (trial and error). You could effectively get the flip book effect and EASILY notice if the cursor movement is  different between field of views?
 

I think any movement must be executed from an external device, DPI wiz machine would be perfect.

In fact I think if he was to have the machine complete circles repetitively and you wrote a simple FOV script that could cycle between multiple FOV at a rate of ~0.5 Seconds? (trial and error). You could effectively get the flip book effect and EASILY notice if the cursor movement is distorted between different field of views.
 

One step further and you could have a physical screen overlay with marked zones to effectively measure the distortion (flip book method not required?)

I've sucessfully done sensitivity stuff using AHK before. I don't see a reason why it'd be different now. It simulates the exact same movements every single time. The machine is testing the sensor. You're just wanting to test the sensitivity so we can skip the sensor by using scripts.

 

Edit: Here.

there's no point really to doing anything in-game.

 

 

about my flatness concern again:

 

the nice thing about the figure 8 pattern is that the drift from that effect is zero, to first order (i.e. assuming that the difference in the mouse's plane of motion and the mousepad is completely linear). because the drift from the counterclockwise circle cancels out exactly with that from the clockwise circle.

 

for reference: the 3360/3366's dpi varies by about 1% for every 0.1mm difference in height (higher the mouse is above the pad, the lower the dpi)

 

 

i have many many mice and mousepads that i'd be willing to donate/lend to you for testing. pm me on ocn if you're interested.

I've sucessfully done sensitivity stuff using AHK before. I don't see a reason why it'd be different now. It simulates the exact same movements every single time. The machine is testing the sensor. You're just wanting to test the sensitivity so we can skip the sensor by using scripts.

 

Edit: Here.

 

Good video. Any ideas on how to 'validate' the viewspeed calculation? Not saying it's wrong currently but I'm sure it would help preview what the new mode does to new users.

there's no point really to doing anything in-game.

 

 

about my flatness concern again:

 

the nice thing about the figure 8 pattern is that the drift from that effect is zero, to first order (i.e. assuming that the difference in the mouse's plane of motion and the mousepad is completely linear). because the drift from the counterclockwise circle cancels out exactly with that from the clockwise circle.

 

for reference: the 3360/3366's dpi varies by about 1% for every 0.1mm difference in height (higher the mouse is above the pad, the lower the dpi)

 

 

i have many many mice and mousepads that i'd be willing to donate/lend to you for testing. pm me on ocn if you're interested.

 

 

The test ingame has nothing to do with mouse sensors. It's about testing viewspeed or other methods of linking mouse movement between Field of Views.