Mouse sensor accuracy test

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

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

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.

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

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.

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 .

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.

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.

Is there any updates yet? Mainly interested in seeing tests with A3050, AM010 and PMW3310.

Also, could you test angle snapping and deadzoning behavior too?

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.

A proper test method for this was already provided. You certainly do not need a rig like this, in fact it would be a worse measurement since the errors from the system and the mouse would be counted too. Either build a script with AHK or LGS (or similar), code a program or use a Teensy/Arduino. Doing tests like this with the machine is only taking time from more interesting tests that cannot be conducted by other means. 

Is there any updates yet? Mainly interested in seeing tests with A3050, AM010 and PMW3310.

 

Also, could you test angle snapping and deadzoning behavior too?

 

 

 

A proper test method for this was already provided. You certainly do not need a rig like this, in fact it would be a worse measurement since the errors from the system and the mouse would be counted too. Either build a script with AHK or LGS (or similar), code a program or use a Teensy/Arduino. Doing tests like this with the machine is only taking time from more interesting tests that cannot be conducted by other means. 

DPI Wiz machine is plenty accurate enough to test Viewspeed or alike. Removing any software potential discrepancies or complications.

The figure of 8 test, as provided, would also clearly display any angle snapping to ANY degree your eye, or hand, could ever detect. Dead zones?... Give your mouse a wiggle, mine don't have one.

I'm a believer in keeping tests relevant. I'm not interested if my mouse has a 1/5th pixel dead zone, neither should anyone else. Lets not worry about 'interesting tests' and let the wizard focus on relevant tests. No point measuring a football field to the nearest nanometre.

PS: Sensor in what mouse? Implementation can vary. Especially when were using the nanoscale to nail that headshot from around the world...

DPI Wiz machine is plenty accurate enough to test Viewspeed or alike. Removing any software potential discrepancies or complications.

 

The figure of 8 test, as provided, would also clearly display any angle snapping to ANY degree your eye, or hand, could ever detect. Dead zones?... Give your mouse a wiggle, mine don't have one.

Software does not cause any discrepancies. This rig and the sensor imperfection could. The result could deviate several pixels.

Those tests and SRAV are the most interesting ones that can't be tested with other means available. High-speed SRAV needs a different rig though.

How about a test on the CM Xornet II running firmware 1.14?